Windows Logo Kit

Purpose

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

In This Section

  • Installing DTM
  • Getting Started
  • Using DTM to Test Logo Testing
  • Logo Tests: Device and Driver Technologies

Additional Resources

For information about how to obtain the latest version of the Windows Logo Kit (WLK) see the Windows Logo Kit (WLK) for Hardware Download page on WHDC.

Related Topics

Windows Hardware Developer Central (WHDC)

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


Legal Information

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. 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.

© 2010 Microsoft Corporation. All rights reserved.

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

UPnP™ is a certification mark of the UPnP™ Implementers Corporation.

All other trademarks are property of their respective owners.


Installing DTM

In This Section

  • Accessibility for People with Disabilities
  • Installation Guide
  • Troubleshooting DTM Problems


Accessibility for People with Disabilities

Microsoft is committed to making its products and services easier for everyone to use. The following topics provide information about the following features, products, and services that make the Device Test Manager (DTM) more accessible for people with disabilities.

  • Accessibility Features in Driver Test Manager (DTM)

  • Accessibility Products and Services from Microsoft


Accessibility Features in Driver Test Manager (DTM)

Using 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


Accessibility Products and Services from Microsoft

Microsoft is committed to making its products and services easier for everyone to use. The following topics provide information about the features, products, and services that make Microsoft Windows more accessible for people with disabilities:

Accessibility Features of Windows

Documentation in Alternative Formats

Customer Service for People with Hearing Impairments

For More Information

Note The information in this section may apply only to users who license Microsoft products in the United States. If you obtained this product outside of the United States, you can use the subsidiary information card that came with your software package or visit the Microsoft Accessibility Web site for a list of 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 section are available in your area. Information about accessibility is available in other languages, including Japanese and French.


Accessibility Features of Windows

The Windows operating system has many built-in accessibility features that 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. The features are installed during the installation of Windows. For more information about these features, see Help in Windows and the Microsoft Accessibility Web site.

Free Step-by-Step Tutorials

Microsoft offers a series of step-by-step tutorials that provide detailed procedures for adjusting the accessibility options and settings on your computer. This information is presented in a side-by-side format so that you can learn how to use the mouse, the keyboard, or a combination of both.

To find step-by-step tutorials for Microsoft products, see the Microsoft Accessibility Web site.

Assistive Technology Products for Windows

A wide variety of assistive technology products are available to make computers easier to use for people with disabilities. You can search a catalog of assistive technology products that run on Windows at the Microsoft Accessibility Web site.

If you use assistive technology, be sure to contact your assistive technology vendor before you upgrade your software or hardware to check for possible compatibility issues.


Documentation in Alternative Formats

If you have difficulty reading or handling printed materials, you can obtain the documentation for many Microsoft products in more accessible formats. You can view an index of accessible product documentation on the Microsoft Accessibility Web site.

In addition, you can obtain additional Microsoft publications from Recording for the Blind & Dyslexic, Inc (RFB&D). RFB&D distributes these documents to registered, eligible members of their distribution service. For information about the availability of Microsoft product documentation and books from Microsoft Press, contact:

Recording for the Blind & Dyslexic, Inc.
20 Roszel Road
Princeton, NJ 08540

Telephone number from within the United States: (800) 221-4792
Telephone number from outside the United States and Canada: (609) 452-0606
Fax: (609) 987-8116

Recording for the Blind & Dyslexic Web site

Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.


Customer Service for People with Hearing Impairments

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

  • For customer service, contact Microsoft Sales Information Center at (800) 892-5234 between 6:30 AM and 5:30 PM Pacific Time, Monday through Friday, excluding holidays.

  • For technical assistance in the United States, contact Microsoft Product Support Services at (800) 892-5234 between 6:00 AM and 6:00 PM Pacific Time, Monday through Friday, excluding holidays. In Canada, dial (905) 568-9641 between 8:00 AM and 8:00 PM 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.


For More Information

For more information about how accessible technology for computers helps to improve the lives of people with disabilities, see the Microsoft Accessibility Web site.


Install.htm - Installation Guide

Windows Logo Kit Installation Guide

This document provides an overview of the Microsoft Windows Logo Kit (WLK) with Driver Test Manager (DTM) and provides essential installation information. Read this document to learn how to set up your computer(s) before installation, as well as how to complete a manual installation of the Device Test Manager (DTM) Controller, Studio, and Client.

Images displayed throughout these documents are for illustration purposes only, and might appear differently on your screen.

Note The DTM Controller is currently only supported on the English language version of Microsoft Windows Server 2008 R2 64-bit.

Table of Contents

Legal Information

Release Notes

Overview

DTM Deployment Scenarios

System Requirements

Install the DTM

Install DTM Studio and DTM Client

Appendix: Optional Command-line Pre-Install directions for DTM Controller

Appendix: Command-line options to install DTM Controller

Appendix: Upgrading a DTM Controller

Appendix: Changing a Controller for a DTM Client

Configure DTM Client Kernel Debugger Settings

Supplemental Information

Technical Support

Legal Information

This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user. 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.

© 2009 Microsoft Corporation. All rights reserved.

Microsoft, 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.

All other trademarks are property of their respective owners.

To print out the license terms, open the license.rtf file in the DTM folder of the DTM installation media.

Release Notes

Read the release notes for last-minute changes and additions to the DTM. The release notes provide late-breaking information, including last-minute changes to the DTM that could affect driver compatibility among different versions of the Windows operating systems.

Overview

The WLK provides tools and documentation to test, sign, and logo drivers for the following operating systems:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

The WLK includes the Driver Test Manager (DTM). DTM is an application and collection of tools that manage tests for development teams who create Windows hardware, drivers, and validate Windows configurations. DTM provides support for automating Windows-based driver and hardware testing and is directed at those who use the WLK to test, validate, and certify drivers.

DTM is comprised of three installation components:

  1. DTM Controller - The DTM Controller manages tests that are run on available clients. The DTM Controller is installed from the DTM installation media and contains separate installers to install the DTM Studio and DTM Client components. You must install DTM Controller first from the DTM installation media. You can then install DTM Studio and DTM Client.

  2. DTM Studio - You use DTM Studio to select and schedule tests to be run on available clients that are connected to, and controlled by, the DTM Controller computer. You will not see an option to install the DTM Studio from the DTM installation media. Instead you install DTM Studio directly from a shared network location on the DTM Controller.

  3. DTM Client - Each client computer can have a different configuration, appropriate for your testing scenario(s) including different hardware, operating systems, service packs, drivers, and so forth. You will not see an option to install the DTM Client from the DTM installation media. Instead, you install DTM Client directly on your individual test computers from a shared network location on the DTM Controller.

DTM Security Warning

DTM might transmit user account names, domains, and passwords in plain text (unencrypted) through logs sent from clients to their DTM Controller. If you create a custom job in DTM that requires a user account, create a specific user account with only the permissions necessary for the job, with the understanding that the account information will be transmitted in plain text between the client and its DTM Controller.

DTM Deployment Scenarios

There are two scenarios in which you can deploy DTM:

  • In a domain-joined environment. A domain-joined environment is an environment in which a domain controller is present, and all computers on which DTM components will be installed are joined to the domain controller.

  • In a workgroup environment. A workgroup environment is one in which no domain controller is present.

Undocumented deployment scenarios, such as installing DTM Controller on a domain-joined computer and DTM Client on a workgroup-based computer, are not supported.

Supported Domain-joined Deployments and Configurations

If you plan to deploy DTM in a domain-joined environment, you need a minimum of three computers. One is a Windows domain controller, one is the test server on which you install DTM Controller and DTM Studio, and one is a test computer on which you install DTM Client. You must make sure that Microsoft Active Directory is configured and running on the domain controller. Alternately, if you have an additional computer, you can install DTM Studio on it instead of on the test server.

The following diagram shows supported domain-joined deployments and configurations. Diagram of supported domain-joined deployments and configurations

The following diagram shows supported workgroup deployments and configurations. Diagram of supported workgroup deployments and configurations

Setup procedure overview

  1. Install Windows Server 2008 R2 64-bit on the intended DTM Controller machine.

  2. Install fresh operating systems on all DTM Studio and all DTM Client computers.

  3. Join all computers to the appropriate domain.

  4. On the DTM Controller, run KitSetup.exe from the DTM installation media, as described in Install the DTM Controller.

    Note Completing this step using Kitsetup.exe will automatically install .NET Framework 2.0 and Microsoft SQL Server 2008 R2 Express 32-bit.

  5. On the DTM Controller, run KitSetup.exe to install the various logo kits appropriate to your requirements.

  6. On each computer that you want to install DTM Studio on, install Microsoft .NET Framework 2.0.

  7. On each computer that you want to install DTM Studio on, click Start, click Run, type \\ControllerName\DTMInstall\Studio\Setup.exe, and then click OK.
  8. On each computer that you want to install DTM Client on, click Start, click Run, type \\ControllerName\DTMInstall\Client\Setup.exe, and then click OK.

Note Replace ControllerName with the name of your DTM Controller computer.

Supported Workgroup Deployments and Configurations

If you plan to deploy DTM in a workgroup, you need a minimum of two computers. One is the test server on which you install DTM Controller and DTM Studio, and one is a test computer on which you install DTM Client. You should not install DTM Controller or DTM Studio on any computer that you install DTM Client on.

Setup procedure overview

Note Do not use the Default Administrator account.

  1. Install Windows Server 2008 R2 64-bit on the intended DTM Controller computer.

  2. Install fresh operating systems on all DTM Studio and all DTM Client computers.

  3. On each computer, create a new user account and add it to the Administrator group.

  4. On each computer, log on with the username you just created in step 3, and enable the Guest account.

  5. On the DTM Controller, run KitSetup.exe from the DTM installation media, as described in Install the DTM Controller.

    Note Completing this step using Kitsetup.exe will automatically install .NET Framework 2.0 and Microsoft SQL Server 2008 Express 32-bit.

  6. On the DTM Controller, run KitSetup.exe to install the various logo kits appropriate to your requirements.

  7. On the DTM Controller computer, click Start, click Run, type \\ControllerName\DTMInstall\Studio\Setup.exe, and then click OK.

  8. To grant users access to the database, add them to the dtm_DSOwners group in DTM Studio by clicking Tools, Management Console, and then Users.

    Note Only the account that installs DTM Controller has initial access to add additional users.

    Note Each unique user must be added one at a time.

  9. On each computer that you want to install DTM Client on, click Start, click Run, type \\ControllerName\DTMInstall\Client\Setup.exe, and then click OK.

Note Replace ControllerName with the name of your DTM Controller computer.

System Requirements

DTM has the following system requirements.

DTM Controller System Requirements

Note The DTM Controller is currently only supported on the English language version of Windows Server 2008 R2 64-bit.

Component Minimum Optimum

Processor

Single x86-based processor running in x64 mode, with a speed of 2.0 GHz

Multicore or multiple x64-based processors running in x64 mode, with a speed of 2.0 GHz or faster

System Memory

2 GB main memory

4 GB main memory

Hard Disk Capacity

300 GB. This value is considered a minimum because of the volume of logs that can be generated and their storage requirements.

JBOD array

Network Connection

100 megabits per second (Mbps)

Operating System

x64-based version of Windows Server 2008 R2.

Notes:

  • DTM Controller is not supported on Windows Server 2003, Windows Server 2008, Windows Vista, Windows XP, or Microsoft Windows 2000.

  • DTM Controller is not supported on a Windows Server 2008 R2 installation that has already been set up as a domain controller.

  • DTM Controller is not supported in a virtual PC environment.

DTM Studio System Requirements

Component Minimum

Processor

x86-based, or

x64-based architectures

Operating System

  • Windows 7 (all versions) for x86-based or x64-based architectures, or

  • Windows Server 2008 R2 x64-based architectures, or

  • Windows Vista (all versions) for x86-based or x64-based architectures, or

  • Windows Server 2008 for x86-based or x64-based architectures, or

  • Windows XP with Service Pack 2 (SP2) for x86-based or x64-based architectures

  • Windows Server 2003 with Service Pack 1 (SP1) for x86-based, or x64-based, or

Notes:

  • Windows Vista and Windows XP are supported when DTM is deployed in the domain-joined scenario. However, in the workgroup deployment scenario, you must install DTM Studio directly on the DTM Controller.

  • DTM Studio is not supported in a virtual PC environment.

DTM Client System Requirements

Component Minimum Optimum

Processor

x86-based, or

Itanium-based, or

x64-based architectures

System Memory

128 MB main memory (for free builds)

256 MB or more (for checked builds)

Operating System

  • Windows 7 (all versions) for x86-based or x64-based architectures, or

  • Windows Server 2008 R2 x64-based, or Itanium-based architectures, or

  • Windows Server 2008 for x86-based or x64-based, or Itanium-based architectures,

  • Windows Vista (all versions) for x86-based or x64-based architectures, or

  • Windows Server 2003 with Service Pack 1 (SP1) for x86-based, x64-based, or Itanium-based architectures, or

  • Windows XP with the latest release Service Pack

  • To test and obtain a Windows Server 2008 logo, you must use Windows Server 2008 Datacenter (x64-based) or Windows Server 2008 for Itanium-based systems (IA-64). x64-based systems may be AMD64 or Intel64. IA64-based systems must be Itanium 2 or later because Windows Server 2008 does not support Itanium 1 (Merced) processors.

Notes:

  • When selecting a computer name for the client, you must choose a unique name with 15 or fewer characters.

  • Windows 2000 is supported for testing -purposes only. There is no logo support for Windows 2000.

  • DTM Client is not supported in a virtual PC environment.

Automatically Install the DTM

Use KitSetup.exe to automatically install prerequisite software and then the DTM. When you run KitSetup.exe, you will be presented with a tree-list of components you can install, as shown in the following screen shot.

Screen shot of the Logo Kit dialog box displaying components you can install

By using KitSetup.exe, you can change the configuration of your installation of the WLK/DTM, including which logo kits you wish to install or uninstall.

Manually Install DTM Studio and DTM Client

You can only run the DTM Studio and DTM Client installers after the DTM Controller installation has completed successfully.

Follow the procedures below to manually install DTM Studio and DTM Client.

Step 1: Install the DTM Controller

To correctly install the DTM Controller, you must be logged on to the computer as a user who is a member of the local Administrators group, and you must be able to access the DTM installation media from Windows, either locally or through a network.

If, at any time, you encounter difficulties, consult the troubleshooting guide and the release notes.

To install the DTM Controller

The following procedure describes an express installation by using the DTM Controller Setup Wizard. You can manually install DTM Controller from the command line. See Appendix: Command-line options to install DTM Controller for more information about manual installations.

  1. From the automated installer program (KitSetup.exe), select Driver Test Manager, and then click OK.

    Note If any DTM Pre-install requirements are not detected, they will automatically be installed first (Microsoft .NET 2.0 and Microsoft SQL Server 2008 R2 Express 32-bit).

  2. The End-User License Agreement page appears.

    Screen shot of the Microsoft Software License Terms page

  3. After you have read the software license agreement, click I Agree, and then click OK.

  4. The Microsoft WLK Install Progress dialog box appears.

    Screen shot of the WLK installation progress bar showing that the WLK configuration is partially complete

  5. After the DTM Controller installation is finished, the Microsoft WLK Configuration 100% complete dialog box appears.

    Screen shot of the WLK installation progress bar showing that the WLK configuration is complete

  6. Click Finish.

Note After the Microsoft Driver Test Manager (DTM) Controller has been installed, any logo kit tests that you selected will be installed.

Step 2: Install the Logo Kit(s) you have selected

The DTM installation program will continue to install the logo kit tests that you selected from KitSetup.exe. These may include, for example, the Devices Logo Kit and the Display Logo Kit (if you intended to logo a display product).

The procedure for installing each logo kit is similar to the following:

  1. From the automated installer program (KitSetup.exe), select Devices Logo Kit and Display Logo Kit. The following screen shot of the Logo Kit dialog box shows two logo kits and the Driver Test Manager check boxes selected.

    Note You may select as few or as many Logo Kits as you want to install or uninstall at any given time.

    Screen shot of the Logo Kit dialog box with two logo kits and the Driver Test Manager check boxes selected

  2. To start the installation, click OK.

  3. The Microsoft WLK Install Progress dialog box appears.

    Screen shot of the WLK installation progress bar showing that the WLK configuration is partially complete

  4. After the installation has finished, the Microsoft WLK Configuration 100% complete dialog box appears.

    Screen shot of the WLK installation progress bar showing that the WLK configuration is complete

  5. Click Finish.

Note After you have installed the logo kit tests that you selected from KitSetup.exe, you can install DTM Studio and DTM Client.

Step 3: Install .NET Framework 2.0 on DTM Studio

Install .NET Framework 2.0

  1. Open a command prompt and change the directory to the NET2.0 folder on the DTM installation media.
  2. Run the .NET Framework 2.0 Redistributable installation package that is appropriate for your architecture:
    • For x86-based platforms, run Dotnetfx.exe from the X86 subfolder of the DTM installation media.
    • For x64-based platforms, run NetFx64.exe from the X64 subfolder of the DTM installation media.
    • For Itanium-based platforms, run NetFx64.exe from the IA64 subfolder of the DTM installation media.

  3. Accept all of the default selections during installation.

Step 4: Install DTM Studio

To install DTM Studio, the computer must be able to connect to the installation folder that is shared from the DTM Controller computer. Therefore, before you can install DTM Studio, you must have already installed DTM Controller. For more information, see Install the DTM Controller.

  1. Click Start, click Run, and then type \\YourDtmController\DTMInstall\Studio\Setup.exe.

    Note Replace YourDtmController with the name of the computer on which you installed the DTM Controller. Attempting to install DTM Studio directly from the %programfiles% directory is not supported and may block any future QFE updates.

    The following screen shot of the Run dialog box shows an example of what the path might look like. Screen shot of the Run dialog box displaying a sample path

  2. Click OK to start the installation.

    The Welcome to the Microsoft Windows Logo Kit - DTM Studio Setup Wizard appears.

    Screen shot of the WLK DTM Setup wizard Welcome page

  3. To start the wizard, click Next.

  4. The Custom Setup page appears.

    Screen shot of the Custom Setup page

  5. To accept the default component and installation location, click Next.

    The Ready to Install page appears.

    Screen shot of the Ready to Install page

  6. To begin DTM Studio installation, click Install.

    The Installing Microsoft Windows Logo Kit - DTM Studio page appears.

    Screen shot of the Installing Microsoft Windows Logo Kit - DTM Studio page

  7. After the installation of DTM Studio is finished, the Completing the Microsoft Windows Logo Kit - DTM Studio Setup Wizard page appears.

    Screen shot of the Completing the Microsoft Windows Logo Kit – DTM Studio Setup wizard page

  8. Click Finish. The Office XP Primary Interop Assemblies dialog box appears.

    Screen shot of the Office XP Primary Interop Assemblies progress bar showing the time remaining for installation

After the Office XP PIA is finished installing, an entry named Windows Logo Kits\Microsoft Driver Test Manager\Studio is added to the list of programs in the Start menu.

Note If you want to run DTM Studio, you must be added to the Administrators group on the DTM Controller. Otherwise, you will not be able to successfully use DTM Studio.

To add a user to the DTM Controller

  1. Open the Control Panel on the DTM Controller.

  2. Click Administrative Tools.

  3. Click Computer Management.

  4. Expand Local Users and Groups.

  5. Click Groups.

  6. In the right pane, right-click the Users group, and select Add to Group...

  7. In the Users Properties dialog box, click Add.

  8. In the Select Users, Computers, or Groups dialog box, type the user account to add.

Step 5: (Optional): Configure Internet Connection Firewall (ICF)

If you choose to install DTM Studio on a computer other than the DTM Controller, you must configure the Internet Connection Firewall correctly on the DTM Controller, otherwise DTM Studio will be unable to connect to the DTM database.

To configure ICF, complete one of the following tasks on the DTM Controller.

Option 1: Disable ICF on the computer

  1. In the Control Panel, click System and Security, and then clickWindows Firewall.

  2. On the left pane, click Turn Windows Firewall on or off.

  3. Click Turn off Windows Firewall for each selection, and then click the OK.

-Or-

Option 2: Add an exception to ICF

  1. In the Control Panel, click System and Security, and then clickWindows Firewall.

  2. On the left pane, click Advanced settings.

  3. On the left pane under Windows Firewall with Advanced Security on Local Computer, click Inbound Rules.

  4. On the right pane, under Actions, click New Rule. This launches the New Inbound Rule Wizard.

  5. Make sure that Program is selected, and then click Next.

  6. The program path should be selected. Click Browse and browse to the location where SqlServ.exe is located. Usually that is the following location: %ProgramFiles(x86)%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe .

  7. Click OK, and then click OK again.

Step 6: Install .NET Framework 2.0 on the DTM Client

Install .NET Framework 2.0

  1. Open a command prompt and change the directory to the NET2.0 folder on the DTM installation media.

  2. Run the .NET Framework 2.0 Redistributable installation package that is appropriate for your architecture:

    • For x86-based platforms, run Dotnetfx.exe from the X86 subfolder of the DTM installation media.
    • For x64-based platforms, run NetFx64.exe from the X64 subfolder of the DTM installation media.
    • For Itanium-based platforms, run NetFx64.exe from the IA64 subfolder of the DTM installation media.

  3. Accept all of the default selections during installation.

Step 7: Install the DTM Client

To install DTM Client, the client computer must be able to connect to the shared installation folder on the DTM Controller computer. Therefore, before you can install DTM Client, you must have first installed the DTM Controller.

To install DTM Client

  1. Click Start, click Run, and then type \\YourDtmController\DTMInstall\Client\Setup.exe.

    Note Replace YourDtmController with the name of the computer on which you installed DTM Controller.

    The following screen shot of the Run dialog box shows an example of what the path might look like.

    Screen shot of the Run dialog box displaying a sample path

  2. Click OK to start the installation.

    The Welcome to the Microsoft Windows Logo Kit - DTM Client Setup Wizard appears.

    Screen shot of the Welcome to the Microsoft Windows Logo Kit – DTM Client Setup Wizard page

  3. To start the wizard, click Next.

  4. The Internet Connection Firewall Agreement page appears.

    Note If the Internet Connection Firewall Agreement page does not appear, the Windows Software Firewall is not installed. Or, a hardware firewall, or another software firewall is installed on the DTM Controller computer. If another firewall is installed, you must manually open TCP port 1778 to proceed with installation. Refer to the instructions that came with your firewall product to manually open a TCP port. Otherwise, the installation will fail.

    Screen shot of the Internet Connection Firewall Agreement page

  5. Select Yes I will allow a port to be opened, and then click Next.

    The Custom Setup page appears.

    Screen shot of the Custom Setup page

  6. To accept the default components and installation location, click Next.

    The Drive Selection page appears.

    Note DTM Client is designed to identify itself to the controller through the hardware signature. Therefore, having multiple separate installs, even across OS installs, is not supported. If DTM client detects a previous installation of the client, it will use that information in lieu of any specified directories.

    Screen shot of the Drive Selection page

  7. Make sure the Use Default Drive check box is selected, and then click Next.

    The Ready to Install page appears.

    Screen shot of the Ready to Install page

  8. To begin DTM Client installation, click Install.

    The Installing Microsoft Windows Logo Kit - Client page appears.

    Screen shot of the Installing Microsoft Windows Logo Kit - DTM Client page

    Note To cancel the installation before it completes, click Cancel.

  9. After the installation of DTM Client is finished, the Completing the Microsoft Windows Logo Kit - DTM Client Setup Wizard page appears.

    Screen shot of the Completing the Microsoft Windows Logo Kit – DTM Client Setup Wizard page

  10. Click Finish.

Note After you install and set up DTM Client, the client computer will appear in the Job Monitor window in DTM Studio. You must wait until the client becomes fully registered with DTM Controller before you can see the client appear in the Job Monitor window. This process might take five or more minutes.

Appendix: Optional Command-line Pre-Install directions for DTM Controller

DTM Controller Pre-install: Install Microsoft SQL Server 2008 R2 Express 32-bit

Note This step is an optional manual step. If you are using Kitsetup for installation, the following steps will be performed automatically for you.

DTM supports Microsoft SQL Server 2008 R2 Express 32-bit, as well as Microsoft SQL 2005 and Microsoft SQL 2008. The Windows Logo Kit (WLK) includes Microsoft SQL Server 2008 R2 Express 32-bit as the default supported SQL engine. DTM is not supported with any other SQL products and only recognizes 32-bit instances of SQL.

To install Microsoft SQL Server 2008 R2 Express 32-bit

  1. Open a command prompt and change the directory to the SQL folder on the DTM installation media.

  2. If the computer has language packs other than English installed, run the following command:

    SQLEXPR_x86_ENU.exe /QUIET /HIDECONSOLE /ACTION=install /FEATURES=SQL,RS /SQLSVCACCOUNT="NT AUTHORITY\SYSTEM" /AGTSVCACCOUNT="NT AUTHORITY\SYSTEM" /ASSVCACCOUNT="NT AUTHORITY\SYSTEM" /RSSVCACCOUNT="NT AUTHORITY\SYSTEM" /ADDCURRENTUSERASSQLADMIN /INSTANCENAME=MSSQLSERVER /SAPWD=p,assword1 /TCPENABLED=1 /NPENABLED=1 /IAcceptSQLServerLicenseTerms=1 /SQLCOLLATION=SQL_Latin1_General_CP1_CI_AS

    Otherwise, run the following command:

    SQLEXPR_x86_ENU.exe /QUIET /HIDECONSOLE /ACTION=install /FEATURES=SQL,RS /SQLSVCACCOUNT="NT AUTHORITY\SYSTEM" /AGTSVCACCOUNT="NT AUTHORITY\SYSTEM" /ASSVCACCOUNT="NT AUTHORITY\SYSTEM" /RSSVCACCOUNT="NT AUTHORITY\SYSTEM" /ADDCURRENTUSERASSQLADMIN /INSTANCENAME=MSSQLSERVER /SAPWD=p,assword1 /TCPENABLED=1 /NPENABLED=1 /IAcceptSQLServerLicenseTerms=1

    Note Replace AdminPassword with a strong SQL database administrator password. Make sure to include the set of double quotation marks around the password, as the previous command instructs.

For more information about Microsoft SQL Server 2008 R2 Express 32-bit, see the SQL Server 2008 R2 page on MSDN.

To install Microsoft SQL Server 2005 (instead of using bundled SQL Server 2008 R2 Express)

WLK 1.6 is the first release to fully support SQL Server 2008 R2, and it recognizes any pre-installed instance of SQL server 2008 and SQL Server 2008 R2, 32-bit only. If you want to use a pre-installed instance of SQL server 2005 32-bit, you must manually modify the registry to bypass the Kitsetup detection that will otherwise block an attempt to install WLK 1.6.

To do this, follow these steps:

  1. Make sure that the default SQL named instance of “MSSQLSERVER” exists. Refer to the specific SQL instructions on how to check and create this, if necessary.
  2. Manually edit the registry and add the following key: HKLM\SOFTWARE\wow6432Node\Microsoft\Microsoft SQL Server\100\Machines.
  3. Launch Kitsetup normally, select the Logo Kits to install, and complete the Kitsetup installation.

Note Due to a potential SQL Server 2005 backward compatibility version mismatch between the copy distributed with WLK and the copy that may be preinstalled, we recommend that you uninstall any preinstalled versions of it before launching Kitsetup. To uninstall SQL Server 2005 backward compatibility, click Control Panel, click Uninstall a Program, and then click Uninstall.

Appendix: Command-line options to install DTM Controller

The following table shows ways that you can specify the installation and log file share-names. The share-names are the folders that are created on the DTM Controller during installation. It is from these folders that you later install DTM Client and DTM Studio. Additionally, logs are written to these folders.

Property | Description | Default value
WTTINSTFS | DTM installation file share name | DTMInstall
WTTINSTDIR | DTM installation directory mapped to file share name | %SYSTEMDRIVE%\Program Files\Microsoft Driver Test Manager\Controller\WTTInstall\
WTTLOGFS | DTM log file share name | DTMLogs
WTTLOGDIR | DTM log directory mapped to file share name | %SYSTEMDRIVE%\Program Files\Microsoft Driver Test Manager\Controller\WTTSystemLogs\

The following table shows ways that you can specify information about the log file share user. The log file share user is the account that you create to store logging information.

Property | Description | Default value
PDUSERNAME | Log file share user name | DTMShareUser
PDDOMAIN | Log file share user name domain | %COMPUTERNAME%
PDPASSWORD | Log file share user password | Randomly generated at installation time

The following table shows ways that you can specify information about the installation-user. The installation-user is the account that is created in order to set up and specify the installation and log file share-names.

Property | Description | Default value
INSTUSERNAME | Installation share user name | DTMInstallUser
INSTMACHINE | Installation computer name where the installation user is created | %COMPUTERNAME%
INSTPASSWORD | Installation user password | Randomly generated at installation time

The following table shows ways that you can specify information about the notification-user. The notification-user is the account that DTM Controller uses to communicate with SQL.

Property | Description | Default value
NOTIFICATIONUSER | Notification user name | DTMServiceAdminUser
NOTIFICATIONDOMAIN | Notification user domain | %COMPUTERNAME%
NOTIFICATIONPASSWORD | Notification user password | Randomly generated at installation time

The following table shows miscellaneous options that you can specify during installation of DTM Controller.

Property | Description | Default value
DBNAME | DTM database name | DTMJobs
DRIVESELECTION | Drive that is used for the WTT directory, using the form "C:\" | WTT is the internal name of the backend infrastructure
DTM | Installation root path (default = %ProgramFiles%\Microsoft Driver Test Manager) | %ProgramFiles%\Microsoft Driver Test Manager
ICFAGREE | Internet Connection Firewall (ICF) exception agreement. Must be ICFAGREE=Yes if ICF is enabled on the system. | "No"
SOURCEINSTALL | Must be SOURCEINSTALL=1 in order to install from command line | "0"
ADDLOCAL | Windows Installer Features. The only featured supported is ADDLOCAL=ALL. | No default value
/l*v %temp%\WLK-Install.log | Enables logging. Without these parameters, no log is created. | No default value
/package | Specifies the location of the MSI installation package | No default value
/qb | Basic installation |
/x {ProductGUID} | Uninstall the specified product |

Installation and Uninstallation Examples

To install either the Logo Kits and/or DTM Controller (Unattended)

  • To install the DTM Controller, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /install {A6E93EA5-52E2-4F16-8AB2-A3A97533FE83}

  • To install the Devices Logo Kit, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /install {EF30275E-5D68-40D2-8AF2-2665AAFCB555}

  • To install the Display Logo Kit, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /install {98EF97A5-C520-498D-8F0F-2C551636E4CC}

  • To install the Network Logo Kit, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /install {8868103C-3527-47FA-A116-84DFD1AE954E}

  • To install the Printing Logo Kit, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /install {A9D61D70-94AD-43FF-B770-B05D4A633C34}

  • To install the System Logo Kit, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /install {14DDB41C-3868-4566-B508-4F20DD649DE4}

  • To install the ALL Logo Kits, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /install {B71A0D52-48C9-45FC-919C-C8F58B009D5C}

    Note By installing one or all of the Logo kits, you automatically install all prerequisites (DTM Controller, .NET 2.0, SQL), so there is no need to individually install other WLK features.

To uninstall either the Logo Kits and/or DTM Controller (Unattended)

  • To uninstall the DTM Controller, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /remove {A6E93EA5-52E2-4F16-8AB2-A3A97533FE83}

    Note Removing the DTM Controller will automatically remove all Logo kits that are currently installed.

  • To uninstall the Devices Logo Kit, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /remove {EF30275E-5D68-40D2-8AF2-2665AAFCB555}

  • To uninstall the Display Logo Kit, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /remove {98EF97A5-C520-498D-8F0F-2C551636E4CC}

  • To uninstall the Network Logo Kit, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /remove {8868103C-3527-47FA-A116-84DFD1AE954E}

  • To uninstall the Printing Logo Kit, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /remove {A9D61D70-94AD-43FF-B770-B05D4A633C34}

  • To uninstall the System Logo Kit, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /remove {14DDB41C-3868-4566-B508-4F20DD649DE4}

  • To uninstall the ALL Logo Kits, use the following command from the root of the DTM installation media:Kitsetup.exe /ui-level express /remove {B71A0D52-48C9-45FC-919C-C8F58B009D5C}

To install the DTM Client (Unattended)

\\DtmController\DtmInstall\Client\setup.exe /qb ICFAGREE=Yes

To install the DTM Studio (Unattended)

\\DtmController\DtmInstall\Studio\setup.exe /qb

To uninstall the DTM Client (Unattended)

\\DtmController\DtmInstall\Client\setup.exe /qb /uninstall

To uninstall the DTM Studio (Unattended)

\\DtmController\DtmInstall\Studio\setup.exe /qb /uninstall

Note Replace DtmController with the name of the computer on which you installed the DTM Controller.

Appendix: Upgrading a DTM Controller

These instructions apply to the WLK version 1.0.c and later.

Note These instructions do not cover creating a backup of the database before you upgrade the DTM Controller. If you follow only these instructions, any changes you have made to the Jobs, or custom Jobs you have created will be lost forever. For more information about creating a backup of your DTM database, see the DTM Database Options and Maintenance Best Practices Web site.

To remove and replace a DTM Controller

  1. Determine installation password. Before you can upgrade your DTM Controller you must determine the existing DTMInstallUser password. If you do not have the existing password and proceed to upgrade the controller, all DTM clients that are connected to the controller will enter Debug mode and will need to be upgraded manually.

    If you must manually upgrade a DTM Client, type the following at the command prompt on the DTM Client computer:

    \\DtmController\DtmInstall\Client\setup.exe /qb /update ICFAGREE=Yes

    Note Replace DtmController with the name of the computer on which you installed the DTM Controller.

    If you do not know the password, you can determine it in one of two ways:
    1. On a DTM Client, open Notepad.exe and open %ProgramFiles%\Microsoft Driver Test Manager\Client\WTTMaster.ini.
    2. Next, search for "WTTUPDATEPWD" and make a note of the password.

    -Or-

    On the DTM Controller, run RegEdt32.exe and go to HKLM\Software\Microsoft\WTT\2.2\Setup\InstPassword, and make note of the password.

  2. Uninstall the existing DTM Controller.

  3. Open Control Panel.

  4. Double-click Add/Remove Programs, and click Remove next to Microsoft DTM Controller.

  5. Follow the instructions on the screen to uninstall the current DTM Controller.

  6. Install New DTM Controller.

    In WLK versions 1.0.c and later, you must install the DTM Controller from the command line in order to specify custom setup options. The following sample command line specifies the minimum flags and switches:

    WlkMediaDrive:\DTM\DTMController.msi /qb SOURCEINSTALL=1 ICFAGREE=Yes INSTUSERNAME="UserName" INSTMACHINE="DomainName" INSTPASSWORD="UserPassword

    Note Replace WlkMediaDrive with the drive letter that contains the WLK installation media. Replace UserName, DomainName, and UserPassword (do not remove the quotes that surround these variables) with the information that you obtained from the step one earlier in this section. The full list of command-line installation options is described in the Appendix: Command-line options to install DTM Controller section.

  7. Install and accept EULA.

    After you complete the manual DTM Controller installation, you must accept the End User License Agreement (EULA) manually. You must complete this step before you execute KitSetup.exe, or you will see the following pending setup task: "Remove: Driver Test Manager."

    To accept the EULA, execute the following command line:

    WlkMediaDrive:\EULA.exe I SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\WLK_EULA_{6C2D169E-F1E3-419C-B19F-876A4F5982B3} WLK WlkMediaDrive:\license.rtf

  8. Install the Windows Logo Kit Tests and Content.

    From the installation media, launch KitSetup.exe and continue to install Windows Logo Kit Tests. After the tests have been installed, close KitSetup.exe.

  9. Complete the upgrade process and verify.

    All DTM Client systems that were connected to the previous DTM Controller and had current heartbeats (for example, they were communicating with each other) will upgrade automatically to the latest version of DTM in approximately 20 minutes.

    If you do not want to wait for the automatic installation, you can do one of two things to force the client computer to upgrade.
    1. On each DTM Client computer, run net stop WTTSvc, and then net start WTTSvc.
    2. Reboot the DTM Client computer. This has the same effect as stopping and restarting the DTM Client WTTSvc.

All DTM Studio instances will initiate an automatic upgrade the next time they are started. If DTM Studio is open, you must close and re-open it to initiate the automatic upgrade.

You can view the status of DTM Clients in the Default Pool of your upgraded DTM Studio. You can also determine what version of WLK is running on your DTM Client in the Runtime Version column of the Job Monitor Explorer.

Appendix: Changing a Controller for a DTM Client

To change the controller of a DTM Client

Run the following command on the DTM Client computer to associate it with a different DTM Controller, while maintaining all of the DTM Client's current settings.

\\NewDtmController\DTMInstall\Client\setup.exe /update ICFAGREE=Yes SETTINGS="%SystemDrive%\WTT\JobsWorkingDir\settings.txt"

Note

  • Replace NewDtmController with the name of the new computer on which you installed DTM Controller.

  • If you installed DTM Client to any drive other than the default drive, you must replace %SystemDrive% with the location that you installed DTM Client to.

The client will no longer appear in any machine pool on the original DTM Controller and will subsequently appear in the default machine pool of the newly associated DTM Controller.

Configure DTM Client Kernel Debugger Settings

During driver development, you might want to debug crashes in the kernel. To do so, you must enable kernel debugging on the development computer.

To enable kernel debugging

From the computer on which you installed the debugger:

  1. Click Start, point to Programs, point to Debugging Tools for Windows, and click Debugging Help.

  2. Click the Search tab in the Debugging Tools for Windows window, type "Kernel-Mode Setup" (including quotes), and click Search.

  3. Read the topic Kernel-Mode Setup.

Supplemental Information

  • Windows Hardware and Driver Central

  • Hardware and Driver Testing

  • Microsoft Developers Network (MSDN)

Technical Support

For all support inquiries, visit the Microsoft Support Web site.

Copyright © 2001-2009 Microsoft Corporation. All rights reserved.

Version:


Troubleshooting.htm - Troubleshooting DTM Problems

Installing the Windows Logo Kit

If you experience difficulty when you install any of the DTM components, review the suggestions in this document to help solve the problem.

For all support inquiries, see the Microsoft Support Web site.

Table of Contents

  • Troubleshooting DTM Client Issues
    • Steps to Reinstall DTM Client
    • Windows Vista and Windows 7 DTM clients will not enter Ready state
    • Remote Desktop will not connect to a client computer
    • DTM Client computers are unable to communicate with the DTM Controller
    • I reinstalled DTM Client and now, jobs that ran before will not run
    • Can't get DTM Client machine out of "Debug" state
    • My job is stuck in the scheduler
    • Error message: Skipped as Public key is null for the machine
    • Error message: Error encountered while adding user <domain\username>
    • A client computer is in use and has been locked by an LLU account
    • Unsupported Scenarios
  • Troubleshooting DTM Studio Issues
    • Error message: X has encountered an error during installation: A connection to the data store could not be established
    • Exception: The Root element is missing
    • Error messages: Out of hard disk drive (HDD) space
    • Error message: No devices using the specified driver(s) could be found in the selected machine pool
    • Studio hangs at the splash screen when it is opened
    • Problems opening Device Console, Job Monitor, or Job ExplorerDetails
    • Error message: Failed to load Device Console
    • Unsupported Scenarios
  • Troubleshooting DTM Controller Issues
    • Transaction log grows too large
    • Sqlservr.exe pegging CPU: increased time taken to process tests
    • Unsupported Scenarios
  • Troubleshooting General Issues (including Kitsetup)
    • "Microsoft Windows Logo Kit" is left behind in "Add or Remove Programs" after uninstall
    • Unable to browse \\<controller-name>\DTMInstall\ from Studio or Client machine
    • Installation or Uninstallation fails (example using DTM Controller)

Troubleshooting DTM Client Issues

Steps to Reinstall DTM Client

The following procedure is supported for reinstalling DTM Client. This should not be the default troubleshooting step when trying to solve DTM Client problems. When you reinstall DTM Client, any Logo Submissions that are in progress will be lost. You will need to run all Logo tests again with a new submission.

  1. Uninstall DTM Client (You will need to log in as another user other than DTMLLUAdminUser).

  2. Set machine to Unsafe in DTM Studio.

  3. Install DTM Client.

  4. Wait for machine to go to Manual state in DTM Studio.

  5. Set machine to Reset in DTM Studio.

  6. Wait for the machine to return to the Ready state automatically, and then click Refresh in DTM Studio to make sure that the machine is set to Ready.

Windows Vista and Windows 7 DTM clients will not enter Ready state

A DTM test client running Windows Vista or Windows 7 can be seen in the Default Test Pool and has a recent heartbeat, but when you change the state of the client to Reset, the status never changes to Ready and eventually changes to Debug.

During the installation of Windows Vista Windows 7 on a network, you have the option of selecting Public as the network that the computer will be connected to. If you selected Public, this can prevent the DTM Client from entering the Ready state because the public network category is intended to be more restrictive to help keep the computer secure. As a security measure, network discovery is turned off by default for public networks.

Solution: Complete the following steps to set the DTM Client to a private network.

  1. Open the Control Panel on the client computer.

  2. Under Network and Internet, click View network status and tasks.

    • For Windows Vista, under Network Details, there is an entry for Network category. If this is set to Public network, click Change to private.

    • For Windows 7, under View your active networks, if this is set to Public network, click it and change it to Home network.

  4. No further action should be necessary and the client status state should change from Reset to Ready.

Remote Desktop will not connect to a client computer

I cannot 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. On the Exceptions tab, select the Remote Desktop check box, and then click OK.

DTM Client computers are unable to communicate with the DTM Controller

There are several scenarios in which it can appear that the DTM Client computers cannot communicate with the DTM Controller computer:

  • The DTM Client computers do not appear in the Machine List in the DTM Studio Job Monitor window.

  • The DTM Client computers fail to connect to the DTM Controller computer.

  • The DTM Client computers do not process jobs in the job scheduler in DTM Studio.

  • The DTM Client computers always go to debug state, even after a reset.

Solution: If you experience any of the preceding scenarios, try the following actions:

If the DTM Client is running Windows Vista, make sure that the network category for the client is set to Private.

  1. Open the Control Panel on the client computer.

  2. Under Network and Internet, click View network status and tasks.

  3. Under Network Details, there is an entry for Network category. If this is set to Public network, click Change to private. No further action should be necessary and the client status state should change from Reset to Ready.

To change the network category, go to the Control Panel. Next, make sure Control Panel Home is selected in the left column of the Control Panel. Next, under Network and Internet click View network status and tasks. Next, click Customize to the right of your network. Change the Location Type to be Private.

Alternately, you might need to check your firewall and IP security settings.

Firewall port issues

If it appears that a DTM Client computer cannot communicate with the DTM Controller computer, the necessary port might not be open in the client computer's firewall. Make sure that the Internet Connection Firewall (ICF) port for DTM is enabled on the DTM Client computer and the DTM Controller computer.

To make sure that the ICF port is enabled on a DTM Client computer:

  1. In Control Panel, click Security, click Windows Firewall, and then click Change Settings.

    The Windows Firewall dialog box appears.

    Screen shot of the Windows Firewall dialog box

  2. Click the Exceptions tab. Make sure that WTT Client appears under Programs and Services and that it is selected.

  3. If WTT Client does not appear in the list of Programs and Services, click the Add Port button and provide the following information in the dialog box that appears:
    1. In the Name box, type WTT Client.
    2. In the Port number box, type 1778.
    3. Click the TCP button, and then click OK.

  4. If you completed Step 3, make sure that the check box next to WTT Client is now selected, and then click OK.

Disabling IPsec (Internet Protocol security)

In order for your DTM Client computers and DTM Controller computers to communicate with one another, all computers must either be running IPsec or they must all have IPsec disabled.

To disable IPsec:

  • Open a command prompt and type net stop ipsec and press Enter.

To modify IPsec settings:

  1. Open a command prompt and type services.msc and press Enter.

  2. Double-click IPsec Services and change its Startup Type (Automatic/Manual/Disabled) and/or Service Status (Start/Stop).

I reinstalled DTM Client and now, jobs that ran before will not run

Details: I installed DTM Controller, DTM Studio, and DTM Client. I successfully scheduled and ran jobs on the client computer. I then uninstalled DTM Client and reinstalled it, but previously scheduled jobs no longer run.

Solution: In the scenario just described, the relationship between the client computer, the DTM controller, and the datastore is broken. To establish a new connection between the client computer and the DTM Controller, uninstall DTM Client from a computer and reinstall it. See the Steps to Reinstall DTM Client section earlier in this topic.

Can't get DTM Client machine out of "Debug" state

Details: Your DTM Client fails all attempts to get out of "Debug" state (normally changing the state to "Reset" in DTM Studio will allow the DTM Client to return to "Ready" status). In some cases, usually after reinstalling WLK (DTM Controller or DTM Client), the Client machine will fail to go to a Ready state. This can be caused by lack of communication between the Controller and Client system, or a trusted key mismatch between the two systems.

Solution: If all attempts have already been made to ensure proper network connectivity between the DTM Client and DTM Controller, then you may need to follow the steps to Reinstall DTM Client earlier in this topic.

My job is stuck in the scheduler

Solution 1: Confirm that appropriate client computers are available.

When you run a job, DTM 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 the job's status. If the Current Pipeline value for your job is Scheduler, and if this value has not changed for several minutes, verify that there is a client computer in the machine pool whose status is Ready. If no client computer is ready to run jobs, see Enabling a Client Computer to Execute Jobs to the status of the client computer to Ready.

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

If 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.

  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 running on, or ran on. If your job is still being scheduled, or if you do not know which computer your job is running on, or ran on, select the root of the machine pool hierarchy ($).

  3. Right-click your job in the Job Execution Status pane and click View Job Report.

    Alternately, you can click View Errors. This provides the Schedule Analysis, which includes how many attempts have been made for the particular job and what might be blocking it from completing.

  4. The Job Report window contains information about the job and its status. Search for the Common Context Details section to see a list of the constraints that a client computer must match to be able to run the job.

Solution 2: Make sure that services SQL Server (MSSQLSERVER), WTTSvc, and DTMSERVICE are started.

Error message: Skipped as Public key is null for the machine

Details: When I 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. On the client computer, uninstall and reinstall the DTM Client.

Error message: Error encountered while adding user <domain\username>

Details: I tried to create a DTM user account for a domain user but received an error message with the following information:

Error encountered while adding user <domain\username>
Cannot grant/remove permission for user on data store 'controller name' : User 'username' does not exist in domain 'domain'. Please ensure that user name is valid or contact your network administrator.

Solution: The domain that the error message refers to is the local machine domain. You cannot create a DTM user account for a domain user while you are logged onto the DTM Studio computer as a local administrator. You must log off and log back on as a domain user with Administrator rights and then create the DTM user account for the domain user in question.

A client computer is in use and has been locked by an LLU account

Details: A client computer is locked by a local logical user (LLU) account, but it has finished running a job and I need to investigate some issues. Or, the client computer is unresponsive and I need to log on to determine the problem.

Solution: You must log on with the correct credentials for the LLU account. The two main LLU accounts that are configured on a DTM Client computer are as follows:

Local Standard User account

The client computer uses this account to run tests that require local standard user access on the client computer and any other computers it communicates with. The local administrator account credentials can also be used for tests of this type, but the additional privileges may not be necessary.

LLU Name: LLU_LSU

UserName:<client machine name>\WDKLclStdUsr

Password: WDKStdTstUsr!

Local Administrative User account

The client computer uses this account to run tests that require local administrator access on the client computer and any other computers it communicates with.

LLU Name: LLU_LAU

UserName:<client machine name>\DTMLLUAdminUser

Password: Testpassword,1

Device console parameters are coming up blank

Details: If you start a submission or open the device console, and all of the device gatherer output has not yet been uploaded to the controller, problems can occur. One of the most common problems for jobs that take device console parameters is that those parameters can come up blank.

Solution: Shut down the device console and reboot the test system with the device attached and installed. When the test machine has logged on again, re-open the device console and verify that the device is now visible.

Unsupported Scenarios

The following scenarios are not supported by the DTM Client. If you have one of the following scenarios set up on your DTM Client, you will encounter problems. Use the suggested workaround to resolve the issue.

  • If you installed more than one operating system on the same computer, where multiple instances of DTM Client are installed, and you try to run more than one operating system, you might cause unknown errors than cannot be fixed.

    Workaround: Only one instance of DTM Client can ever be installed on the system under test. In this scenario, the system includes all related physical discs and partitions.

  • You are using multiple DTM Client machines to complete a test submission. After you start a logo submission by using Device Console, you must use the same DTM Client machine to complete the test submission. If you change anything about the DTM Client system, you might invalidate your logo submission and cause you to restart the test with a new logo submission. If you make any of the following changes, you might have to restart your test submission:

    • Change the computer name
    • Reinstall the DTM Client
    • Reinstall the operating system
    • Move the computer from a DOMAIN to a WORKGROUP or from a WORKGROUP to a DOMAIN

    Symptom: After you create a CPK, it does not contain all the logs for the logo tests that have been run.

    Workaround: Make any changes to the DTM Client, and then create a new CPK. Optionally, you can rerun the logo tests that were run before you changed the DTM Client.

  • You changed the name of the computer after you installed DTM Client.

    Workaround: Change the name back to the original name to continue testing. Optionally, follow the procedure later in this topic to reinstall DTM Client

  • You installed DTM Client while the computer was connected to a DOMAIN, and then moved the computer from the domain to a WORKGROUP.

    Symptoms: No heartbeat. Jobs are stuck in Scheduler. Jobs will not run on DTM Client.

    Workaround: Change the DTM Client system back to the original state to continue the test submission. Optionally, uninstall and reinstall DTM Controller and DTM Client so that all systems are either joined to a DOMAIN or part of a WORKGROUP.

Troubleshooting DTM Studio Issues

Error message: X has encountered an error during installation: A connection to the data store could not be established

Details: I cannot open any windows from within DTM Studio.

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

  1. Log on to the computer that hosts the DTM Controller by 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. Click the user from the Users for this computer list, and then click Properties.

    2. On the Group Membership tab of the Properties dialog box, click Other, and then click 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. Click Other, and then click Administrators from the drop-down list.

    4. Click Finish.

  6. Click OK to close the User Accounts dialog box.

Note When you run a computer as an administrator, you put your system at risk for security breaches.

Solution 2: If you are using DTM Studio on a system that is not the same system as the DTM Controller, you must ensure the firewall is configured correctly. For more information about how to configure your firewall, see Step 5: (Optional): Configure Internet Connection Firewall (ICF).

Exception: The Root element is missing

Details: When I create a submission package or when I use Job Monitor after I create a submission package, I receive an exception that the root element is missing.

Solution: Uninstall and reinstall DTM Studio.

  1. Uninstall DTM Studio.

  2. Delete the %UserProfile%\Application Data\Microsoft\WTT\2.2.2098.0\Enterprise directory.

  3. Reinstall DTM Studio.

If the problem persists, try the following:

  1. Repeat the previous procedure.

  2. Copy the Enterprise directory from Program Files\Microsoft Driver Test Manager\Controller to Program Files\Microsoft Driver Test Manager\Studio.

    By doing this, you replace the corrupted file with a good version from the source directory.

  3. Restart DTM Studio.

Error messages: Out of hard disk drive (HDD) space

Details: DTM can generate large amounts of log information about tests. It is possible to fill an entire hard disk with log information. If you run out of free hard disk space, you will receive errors from DTM.

Solution: If you receive error messages from DTM Studio that indicate you are out of hard disk drive space, delete the log files that are currently stored on your hard drive.

If DTM Studio is installed on the same computer as the DTM Controller, complete the following steps:

  1. Close DTM Studio.

  2. Open a command prompt, type cmd, and press Enter.

  3. Run net stop wttsvc.

  4. Go to the %temp% folder. The folder is usually found at: C:\Documents and Settings\<UserName>\Local Settings\Temp. Be aware that the "Local Settings" subfolder is a hidden subfolder of <UserName>.

  5. Delete all *.tmp files and all the subfolders in the temporary subfolder that begin with DTM_.

    Note Do not delete the %temp% subfolder itself.

  6. Run net start wttsvc.

  7. Restart DTM Studio.

If DTM Studio is installed on a separate computer without other DTM components, complete the following steps:

  1. Close DTM Studio.

  2. Open a command prompt, type cmd, and press Enter.

  3. Go to the %temp% folder. The folder is usually found at: C:\Documents and Settings\<UserName>\Local Settings\Temp. Note that the "Local Settings" subfolder is a hidden subfolder of <UserName>.

  4. Delete all *.tmp files and all the subfolders in the temporary subfolder that begin with DTM_.

    Note Do not delete the %temp% subfolder itself.

  5. Restart DTM Studio.

Error message: No devices using the specified driver(s) could be found in the selected machine pool

Details:

After I load my INF file in the Submission Wizard, I see a dialog box with the following message:

No devices using the specified driver(s) could be found in the selected machine pool. Running jobs with no devices will most likely result in a failed submission. Continue creating submission even though no devices have been found?

Solution:

If you receive this error, click Yes to continue, and then make sure that you can see the client computer in the Available Devices pane. If you can see the client computer, complete the steps to schedule the required logo tests for your submission. If you cannot see the client computer, perform the following steps:

Solution 1:

  1. On the DTM Client computer, reboot the system.

  2. On the DTM Studio computer, close the DTM Studio application, and then restart the application.

  3. Open the Device Console to start your submission again.

Solution 2:

  1. Confirm that the driver package contains all files referenced in the INF file.

  2. Confirm that the driver package is the same as the driver package that is installed on client computer.

Studio hangs at the splash screen when it is opened

Details: DTM Studio stops responding (hangs) at the Splash screen (the screen that pops-up before DTM Studio actually loads).

Solution: Follow the installation directions in Step 4: Install DTM Studio. Pay particular attention to the following note: Attempting to install DTM Studio directly from the %programfiles% directory is not supported and may block any future QFE updates.

Problems opening Device Console, Job Monitor, or Job ExplorerDetails

Details: In cases where there has been a significant change to the DTM Studio system, you might not be able to open Device Console, Job Monitor, and Job Explorer. You might see a message similar to the following: "JobExplorer has encountered an error during initialization: Operation failed: Parameter 'identityConnectInfo' cannot be null"

Solution: To fix this problem, complete the following steps.

  1. Uninstall DTM Studio.

  2. Open %APPDATA%\Microsoft.

  3. Rename WTT to WTTOLD.

  4. Reinstall DTM Studio.

Error message: Failed to load Device Console

Details: You are able to open File, Job Explorer, File, Job Monitor, but attempts to open File, Device Console return the following error: "Failed to load Device Console". If this is the case, you may have accidentally moved your controller system from the System machine pool.

Solution: Move all of your controller machine resources back to the built-in System machine pool ($\System). Your controller machine resources are all machine name entries in Job Monitor that match the %COMPUTERNAME% of the system where DTM Controller is installed.

Unsupported Scenarios

The following scenarios are not supported by the DTM Studio. If you have one of the following scenarios set up on the DTM Studio, you will encounter problems. Use the suggested workaround to resolve the issue.

  • If you installed DTM Studio while the computer was connected to a DOMAIN, you might have problems if you remove the computer from the domain and make the computer a member of a WORKGROUP.

    Workaround: Change the DTM Studio system back to the original state to continue the test submission. Optionally, uninstall and reinstall DTM Controller and DTM Studio so that all systems are either joined to a DOMAIN or part of a WORKGROUP.

Troubleshooting DTM Controller Issues

Transaction log grows too large

Details: It is possible that the SQL transaction log can grow too large to be usable. This is because the transaction log is designed to continue to grow in size as long as there is available disk space to contain it.

Solution: To solve this problem, you must reduce the size of the transaction log. For information about how to manually reduce the size of the transaction log, see DTM Database Options and Maintenance Best Practices on WHDC.

Sqlservr.exe pegging CPU: increased time taken to process tests

Details: If you have more than one or two active logo submissions running at one time, it might take longer than expected for tests to get scheduled and run as well as CPU of the DTM Controller getting pegged by Sqlservr.exe.

Solution: You might need to upgrade the hardware you are running DTM Controller on. If you typically run several submissions at the same time, upgrade your DTM Controller system to a minimum of quad processor with at least 2Ghz and 4G RAM.

Unsupported Scenarios

The following scenarios are not supported by the DTM Controller. If you have one of the following scenarios set up on your DTM Controller, you will encounter problems. Use the suggested workaround to resolve the issue.

  • If you change the name of the computer after you install DTM Controller.

    Workaround: Uninstall and reinstall DTM Controller.

  • If you installed DTM Controller while the computer was connected to a DOMAIN, you might have problems if you remove the computer from the domain and make the computer a member of a WORKGROUP.

    Symptom: You receive the following error message: SQL server does not exist or access denied.

    Workaround: Uninstall and reinstall DTM Controller.

Troubleshooting General Issues (including Kitsetup)

"Microsoft Windows Logo Kit" is left behind in "Add or Remove Programs" after uninstall

Details: You might notice that after you uninstall WLK features from your system by using Kitsetup that Microsoft Windows Logo Kit is still listed in Add or Remove Programs.

This can be caused by a momentary loss of communication between the computer and Kitsetup.exe program (for example, if you removed the WLK DVD before the WLK was completely uninstalled, or if the installation location was from the network or a connection was lost).

Solution: Use Kitsetup.exe to install DTM Controller and then to uninstall DTM Controller. Completing this sequence allows Add or Remove Programs to be clear of Microsoft Windows Logo Kit. Open Add or Remove Programs and next to Microsoft Windows Logo Kit click Change. When Kitsetup.exe opens, click DTM Controller, and then click Apply. After DTM Controller is installed, select to remove it by un-selecting DTM Controller, then click Apply.

Unable to browse \\<controller-name>\DTMInstall\ from Studio or Client machine

Details: If you are unable to browse the DTMInstall directory from the DTM Studio or DTM Client, review the information in the Install.htm.

You might also need to allow an Internet Connection Firewall Exception for File and Printer Sharing. You allow an exception by placing a check-mark next to the item in the Windows Firewall Exceptions tab.

Installation or Uninstallation fails (example using DTM Controller)

Details: If you are trying to install or uninstall DTM Controller and you get a failure, you can check the setup logs to find information that might help you to determine the reason for the failure. You can find the setup logs in the %temp% folder.

To navigate to the %temp% folder and read the setup logs:

  1. Click Start, and then click Run.

  2. Type cmd.exe, and press Enter.

  3. Type %HomeDrive%, and press Enter.

  4. Type cd %temp%, and press Enter.

  5. Type dir *.log, and press Enter.

    In this list, you should see a file named WLK-DTMControllerInstall.log.

  6. To review this log file, type notepad WLK-DTMControllerInstall.log and press Enter.

  7. Type dir *.log, and press Enter.

    In this list, you should see a file named WLK-DTMControllerUninstall.log.

  8. To review this log file, type notepad WLK-DTMControllerUninstall.log and press Enter.

  9. Search for return value 3 to discover what custom action failed. The specific error will be located a few lines above the returned value.

If you get the error message Setup Ended Premature and you look in the WLK-DTMControllerInstall.log for return value 3 and notice the following message, follow the subsequent steps to recover from this problem.

ERROR MESSAGE:
MSI (s) (7C:0C) [16:43:52:429]: Executing op: CustomActionSchedule(Action=CreateStandaloneEnterprise,ActionType=17409,Source=BinaryData,Target=CAQuietExec,CustomActionData="C:\Program Files\Microsoft Driver Test Manager\Controller\WTTStandaloneEnterpriseSetup.exe" "[YOUR_COMPUTER_NAME]" "DTMJobs" "C:\StandaloneEnterprise")
MSI (s) (7C:B4) [16:43:52:429]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI47B.tmp, Entrypoint: CAQuietExec
CAQuietExec:  Standalone Enterprise setup started by user [DOMAIN]\[USERACCOUNT]
CAQuietExec:  Error::
************************************************************ERROR REPORT (Exception levels including inner exceptions. Level 0 denotes outermost exception)
CAQuietExec:
CAQuietExec:  ------------START OF ERROR REPORT------------
CAQuietExec:
CAQuietExec:  Level            : 0
CAQuietExec:  Error Message    : Error while creating new data store  'DTMJobs' .
CAQuietExec:  Source           : Void CreateEnterprise(Microsoft.DistributedAutomation.DSLink, Microsoft.DistributedAutomation.ServiceCollection, Boolean)
CAQuietExec:  Inner Exception  : System.Runtime.InteropServices.COMException (0x80041432): Cannot create file 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\DTMJobs_Data.mdf' because it already exists.
CREATE DATABASE failed. Some file names listed could not be created. Check previous errors.
CAQuietExec:     at Interop.SQLDMO.Databases.Add(_Database Object)
CAQuietExec:     at Microsoft.DistributedAutomation.SqlDataStore.SqlDataStoreSetup.CreateDeploymentDataStore(ServiceCollection serviceList, DSLink newDSLink)
CAQuietExec:  Call Stack       :    at Microsoft.DistributedAutomation.SqlDataStore.SqlDataStoreSetup.CreateEnterprise(DSLink identityDSLink, ServiceCollection serviceList, Boolean standaloneInstall)
CAQuietExec:     at Microsoft.DistributedAutomation.EnterpriseSetup.EnterpriseSetupHelper.CreateEnterprise(EnterpriseConfiguration enterpriseConfig, DSLink dsLink, String setupFilePath, Boolean standaloneInstall)
CAQuietExec:     at Microsoft.DistributedAutomation.EnterpriseSetup.Tools.CMain.Main(String args)
CAQuietExec:  Trace            :
CAQuietExec:
CAQuietExec:  Level            : 1
CAQuietExec:  Error Message    : Cannot create file 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\DTMJobs_Data.mdf' because it already exists.
CREATE DATABASE failed. Some file names listed could not be created. Check previous errors.
CAQuietExec:  Source           : Void Add(Interop.SQLDMO._Database)
CAQuietExec:  Inner Exception  :
CAQuietExec:
CAQuietExec:  --------------END OF ERROR REPORT------------************************************************************
CAQuietExec:  Error 0x80070001: Command line returned an error.
CAQuietExec:  Error 0x80070001: CAQuietExec Failed
Action ended 16:44:39: InstallFinalize. Return value 3.

  1. Delete the following two files from C:\Program Files\Microsoft SQL Server\MSSQL\Data folder on the computer:

    DTMJobs_Data.mdf
    DTMJobs_Log.ldf

  2. Install the DTM Controller component again.

Copyright 2001-2009 Microsoft Corporation. All rights reserved.

Version:


Getting Started

To get started with the Windows Logo Kit process, please visit the following Microsoft Web site:

http://www.microsoft.com/whdc/getstart/testing.mspx

In This Section

  • Overview of DTM

  • Setting Up DTM

  • Troubleshooting DTM Problems

Additional Resources

  • For an overview of the Windows Logo Program, please visit http://www.microsoft.com/whdc/winlogo/default.mspx

  • To view the most current Windows Logo Program requirements and policies, please visit http://www.microsoft.com/whdc/winlogo/hwrequirements.mspx

  • For more information about the Windows Logo Kit, please visit http://www.microsoft.com/whdc/winlogo/WLK/default.mspx

  • For more information about online logo tools, please visit http://www.microsoft.com/whdc/winlogo/LogoTools.mspx

  • For Windows Logo Program resources and support, please visit http://www.microsoft.com/whdc/winlogo/resources.mspx


Overview of DTM

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

With DTM, you can 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, with DTM you can create custom tests to help determine driver performance and to identify causes of driver failures. See the Creating Your Own DTM Jobs topic for more details.

This section includes the following topics:

Driver Test Manager Components

General DTM Concepts

DTM Lab Security

DTM Controller and Client Organization


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 that testers use to create and schedule tests and otherwise manipulate controllers and clients. With DTM Studio, you can organize the computers in your lab into the appropriate environment to test your driver.


General DTM Concepts

DTM executes jobs and jobs are comprised of individual tasks, such as open a file, save a file, and close a file.

You use DTM Studio to schedule jobs. The DTM controller then executes these jobs on an available client. The controller schedules 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 must allocate at least one computer on which to install the DTM Controller. You can allocate up to 150 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, you might have 5 to 10 computers on which to test a driver. Set up one computer as a controller, one with DTM Studio installed, and the remaining computers with DTM Client installed. In larger labs, you can allocate dozens of clients to a controller. For each set of computers per controller, each tester should install DTM Studio on their primary work computer. Then, you can work with the other testers to create and schedule jobs for the drivers that you 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. You and the other testers can share the task of reviewing job results from your primary work computers.

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


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

    Do not change or create an autologon account, as this may cause DTM to stop functioning properly. The DTM handles this process automatically.

  • Running tests in an administrator role

Additional security precautions

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, search the Windows XP Professional Resource Kit for information about 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 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 a bit more detail in the section that follows.

For more information about security and enabling automatic logon, see the following references:

  • Microsoft Security

  • Microsoft TechNet

  • Automating Logon in Windows XP

  • Automating Logon in Windows 2003


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 best use 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 a logo for.

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.

    Advantages: You will have less overhead administering the controllers and clients. Also, the chances are higher for a client with the necessary hardware and software configuration to be available, or become 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.

    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, they will be able to handle more clients.

Note : Multiple controllers are independent of each other.

DTM puts a limit of 150 clients that can connect to a single controller. If you have a large lab that has more than 150 computers intended to be clients, you must allocate multiple controllers. Regardless of the size of your lab, you can allocate multiple controllers, each with any number of clients (up to 150 per controller) connected to a given controller.

Note : Installing DTM Studio does not count toward the limit of 150 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 151

1 or more

1 to 150

Allocate at least one controller, and possibly more.

For example, you can allocate one controller that can have up to 150 clients. Or, you can allocate two controllers and distribute the computers as their clients in an arbitrary manner.

The decision about the ratio in which to allocate clients to controllers is completely at your discretion.

152 or more

2 or more

150 or more

You must allocate at least two or more controllers for labs that contain more than 150 clients because this release of DTM supports only a maximum of 150 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.


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 will become a DTM client. Although it is possible to install DTM controller and DTM Studio on the same computer, 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, however, 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:

DTM Lab Security

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.

This section includes the following topics:

DTM Controller and Client Configuration

Starting DTM Studio

Grouping Client Computers into Machine Pools

Managing DTM User Accounts

Preparing Client Computers to Run the Logo Tests


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. By specifying a machine pool, you restrict 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.

To create a machine pool

  1. Start DTM Studio.

  2. Switch to the Job Monitor window.

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

  3. Select your DTM controller from the drop-down box at the upper-left corner of the Job Monitor window.

  4. In the Machine Pool pane, right-click the dollar sign ($) at the root of the machine pool hierarchy, and then click Add Machine Pool.

  5. 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.

To move a computer from one machine pool to another machine pool

  1. Start DTM Studio.

  2. Switch to the Job Monitor window.

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

  3. Select your DTM controller from the drop-down box at the upper-left corner of the Job Monitor window.

  4. 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.

  5. Drag the computer from the Machines pane to the machine pool that you want the computer to belong to.

  6. You can also right-click the computer in the Machines pane then select Move... from the pop-up menu.

  7. Note If you want to move more than one computer at a time, you must first select all the relevant computers before you move them.

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


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.

Important To create a DTM user account for a domain user, as opposed to a user account for a local user, you must be logged on to the DTM Studio computer as a domain user with administrator rights on the local machine.

If you try to create a DTM user account for a domain user while you are logged on as a local user with administrator rights, an error message will appear informing you that the user for whom you are trying to set up permissions does not exist in the domain. The domain referred to in the error message is the local machine and not the domain to which it is connected.

For details about this error message, refer to the "Error message: Error encountered while adding user <domain\username>" topic in the Troubleshooting DTM Problems section of this documentation.

The following topics describe ways that a DTM administrator can manage user accounts:

Assigning Roles

Creating a DTM User Account

Granting Permissions


Assigning Roles

When you create a new user account for a DTM user, you must also assign a datastore role for the user.

The following is a list of the DTM datastore roles that you can assign a user when you create the new user account.

dtm_DSGuests

With a guest user account, you can log in without having a user account to access the DTM datastore. This level of access is very restricted and only allows the user to view the results of a job.

dtm_DSUsers

To obtain access to a Microsoft SQL Server database, you must have a corresponding user account for that database.

This user account allows the DTM user to perform several of the basic tasks associated with logo testing. See the permissions table that follows for more details.

dtm_DSAdministrators

If a user is assigned this role, that user has administrator privileges on the local system and is able to install a system. Additionally, if the host computer is part of a Windows domain, the Administrator account usually has domain-wide privileges as well.

dtm_DSOwners

The datastore owner is a user that has permission to perform all activities in the database. See the permissions table that follows for more details.

To the DTM Studio user interface, the dtm_DSOwners and the dtm_DSAdministrators roles are the same. However, the level of access a user has to the DTM datastore itself when he or she is assigned the dtm_DSOwners role far surpasses the level of access a dtm_DSAdministrators user has. As such, you must only assign the dtm_DSOwners role to users who are very knowledgeable about Microsoft SQL Server.

Permissions Table

 | dtm_DSGuests | dtm_DSUsers | dtm_DSAdministrators | dtm_DSOwners
Schedule/Run jobs |  | x | x | x
Create Jobs |  | x | x | x
Edit Jobs |  | x | x | x
View Results | x | x | x | x
Delete Jobs |  |  | x | x
Cancel Jobs |  |  | x | x
Add Users |  |  | x | x
Remove Users |  |  | x | x


Creating 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, expand Console Root.

  3. Expand your datastore, right-click Users, and then click New User.

  4. 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.

    Note If you are creating multiple user accounts, separate each user with a semicolon.

  5. In the Datastore Role pane, select the dtm_DSUsers check box.

    Note You can assign multiple roles to a new user at the same time. To grant this user administrater priveleges, select the dtm_DSAdmins check box also.

  6. Click OK.


Granting Permissions

Complete the following procedure to grant a DTM user 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 list box at the upper-left corner.

  3. In the Machine Pool pane, 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.

  4. On the Security tab, click Add.

  5. In the User List dialog box, click the user name, and then click OK.

    Note If the user name does not appear in the user list, 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, 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

Creating a Machine Pool

If a machine pool has not already been created, perform the following steps to create one:

  1. Right-click $ in Machine Pool window on the left, and then click Add Machine Pool.

  2. In the Add Machine Pool dialog box, type a name for the machine pool, and then click OK.

Setting the DTM Client Status

Before you can run tests on a client computer, you must make sure that the status of the computer is set to Ready. 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.

To reset the status of a client computer to Ready state

  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, click 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.

To reset the status of a client computer to another state

  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.


Troubleshooting DTM Problems

To view information about how to fix common problems with DTM, please see Troubleshooting.htm - Troubleshooting DTM Problems.


Using DTM for Logo Testing

This section contains the following topics:

Logo Testing Overview

Creating DTM Jobs

Scheduling DTM Jobs

Managing DTM Jobs

Logging in DTM

Using DTM from a Command Line

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:

  • To obtain a logo for a device

  • To obtain a Driver Quality Signature for a driver

  • To obtain a logo for a computer system

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

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

To obtain a Driver Quality Signature for a driver, the driver must meet all the criteria and design requirements that are defined by Microsoft for drivers running on the Windows family of operating systems.

To obtain a logo for a computer system, 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 topics explain what you must do to acquire a "Designed for Microsoft Windows" logo:

Configuring the Test Environment

Generic Logo Submission exercise

Running the Logo Tests

Avoiding Test Failures

Resolving Errors, Updating DTM with QFE Patches

Submitting Logo Test Results


Configuring the Test Environment

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

Many of the tests in the DTM require a test system to restart (often more than once) to complete a test run. As a result of this, it is recommended that you do the following:

  1. Configure your test computers to boot from the regular boot sector of a hard drive and not from external devices, CD, or DVD boot discs.

  2. Follow the guidelines to enable automatic logon on your test computers (client computers) in the DTM Lab Security topic.

You might also need to configure your test clients specifically to the logo tests you plan to run. For example, if you are testing a specific device, you must ensure that each client has the device connected to it, and the necessary drivers are installed and configured.

To configure your test clients to test for a Windows logo, read the Testing topic under "Logo Tests: Device and Driver Technologies" that is appropriate for your device class.

After you have configured the testing environment that is appropriate for your device, you can follow the steps in the generic logo submission exercise to familiarize yourself with the submission process.


Generic Logo Submission exercise

The information in this topic provides a general overview of the logo testing and submission processes. The following instructions assume that you have successfully installed DTM controller, DTM Studio, and DTM client. If you have not already installed these three DTM components, refer to the Install.htm file on your installation medium for installation instructions. For more information about how to set up DTM, see the Setting Up DTM topic.

Important If you rerun a job, switch to the Device Console window and repeat the tasks in Step 8 in the following procedure.

Note The monitor test was selected for this exercise because it uses drivers that are shipped with Windows and thus provides a simple scenario.

For this exercise, the computer on which DTM client is installed is referred to as client computer.

To configure a client computer for logo testing, run tests, and then create a submission package

  1. Open DTM Studio and 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 pane, click Default Pool, and then locate the client computer in the Machines pane.

    Note The status column for the client computer shows that it is in the Manual state. This is the default state for any client computer that has been automatically added to the default pool as a result of installing DTM client.

  3. Create a new machine pool.

    1. In the Machine Pool pane, right-click the root pool (indicated by the '$' symbol), and then click Add Machine Pool.

    2. Type the name Test Pool, and then click OK.

      Your new machine pool, Test Pool, now appears in the Machine Pool console tree.

  4. Move the client computer to the new machine pool.

    1. Drag the client computer from the Machines pane and drop it onto Test Pool in the Machine Pool pane.

    2. Click Test Pool to make sure that the client computer now appears in the Machines pane for that machine pool.

      If you do not see your client computer in the Machines pane, click Refresh or press F5.

  5. Change the status of the client computer to the Ready state.

    1. Right-click the client computer, and then click Change Status.

    2. Select Reset.

    3. The Status column for the client computer should show that the client is in the Reset state.

    4. Wait a few seconds, and then click Refresh or press F5. The client computer's status column should now show the Ready state.

      Note The "Preparing for the Xxx Test" topics will tell you whether or not you must apply a dimension to the machine pool before running certain jobs. If the job you are about to schedule and run requires a dimension to be applied, you must apply the dimension at this stage in the procedure. Refer to the Configuring the Test Environment topic for instructions about how to apply a dimension to a machine pool.

  6. Next, select a logo program.

    Important If you have an INF file or a driver for your device, make sure that you copy the INF file or driver to the hard drive of the client computer before you begin the logo submission process. Make a note of the location of the file or driver and browse to it in Step 7. If the INF file or driver is on a removable storage device, like a floppy disk or a flash drive, and this storage device is removed before you attempt to create a submission package, the process will fail and you will receive an error message.

    1. Click Explorers, and then select Device Console.

    2. When Device Console finishes loading, confirm that Test Pool is selected in the Machine Pool drop-down list box.

      Note If you are testing a device that is, by default, hidden by Device Manager, you must first select the Show Hidden Devices check box before you complete the next step.

    3. From the Submission drop-down list box, select <New Submission>.

    4. In the Create New Submission dialog box, select your operating system, and then click Next.

    5. Click Device Submission, and then click Next.

    6. Click Display > Monitors > CRT, and then click Next.

      If you are using a portable computer, click Display > Monitors > LCD, and then click Next.

    7. Select a submission level (Premium or Basic), and then click Next.

    8. Provide a name for your submission: Type Display submission.

    9. In the Machine Pool pane, click Test Pool, and then click Next.

      Note You select Test Pool because it contains the client computer.

  7. Select a driver for your monitor.

    1. If you are not providing an INF or Driver Package, then select the I am not providing an INF or Driver Package check box, and then click Next.

      Note If you are testing a para-virtualization driver, you must also select the Para-virtualization Driver check box, and then click Next.

      Para-virtualization drivers are device drivers present in a virtual machine instance of the Windows operating system that represent hardware and functionality similar to, but not necessarily identical with, the underlying physical hardware used by the system virtualization software layer.

      For example, the physical network interface adapter installed in the system can be either presented or abstracted to the virtual instance(s) of Windows. This is achieved using a para-virtualization driver that emulates a network adapter, but not necessarily the same network adapter as the actual physical device.

    2. Expand the Test Pool node, and then expand Monitors to select the device to be tested.

    3. Select the check box next to your monitor, and then click Next.

    4. If you see the message "ERROR: No Submission Drivers specified," click OK.

    5. In the summary that shows the submission name, machine pool name, and your monitor's identifier, click Finish.

  8. Select the job you are going to run.

    1. In the Available Jobs pane in the Device Console window expand the CRT or the LCD node.

    2. Select the check box for the EDID 1.3 and DDC (32-bit) job.

    3. At the bottom-left of the Device Console window, click Add Selected.

      Note You might be required to edit some job parameters for some of the selected jobs before they can be scheduled against the machine pool for logo-related testing. The "Running the Xxx Tests" topics will tell you whether or not you must edit the required parameters. Refer to the Running the Logo Tests topic for instructions about how to edit parameters for a logo job.

    4. Click Schedule Jobs.

      Note You can switch to the Job Monitor window, wait about 5 seconds, and then click Refresh or press F5. The Job Execution Status pane displays the job that is currently running. After a few moments, your monitor should start responding to the scheduled EDID 1.3 and DDC (32bit) job.

  9. Create a submission package after the job is completed.

    1. Switch to the Device Console window.

    2. In the Available Devices pane, right-click the submission name, which in our case is Display Submission, and click Create Submission Package.

      Important You must make sure that all the computers that were used to run the logo tests are present in the machine pool before you select Create Submission Package. If any of these computers is missing from the machine pool when you try to create a submission package, a foreign key violation error message will appear. It is recommended that you leave the relevant computers in the machine pool until you have completed the submission package.

      And also, you can right-click anywhere in the Available Devices pane to create a submission package. The resulting submission package files will contain the same submission information.

    3. Save the submission package.

      Note It will typically take a few minutes for the submission package file to be created. It is normal during this time for DTM Studio to appear as if it has stopped responding.

    Note You can now upload your submission package to the Winqual team for review. For information about how to submit a package, refer to the Winqual Web site.


Running the Logo Tests

To run the logo tests and create a submission cabinet file to send to WHQL for logo approval, complete the following procedures:

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

  1. Open a new Device Console window by clicking Explorers, and then clicking Device Console.

  2. Select your DTM controller from the Data Store drop-down list box in the upper-left corner 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, and then click Open.

    Note When you click Open to load your saved Device Job Schedule file, the Add Selected and Schedule Jobs buttons are automatically activated. This means that the jobs are immediately scheduled against the computers in the machine pool. If the computers against which the saved jobs were originally scheduled are no longer in the machine pool, the jobs will not run. No dialog boxes will appear with any of this information.

  5. Skip ahead to the Monitor logo test progress portion of this document.

--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 Data Store drop-down list box in the upper-left corner of the Device Console window.

  3. In the Submission area, click Submission.

  4. To the right of the Submissionarea, select <New Submission> from the Submission drop-down list, and follow the instructions in the Create New SubmissionWizard 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, you might receive an error message indicating that no machine was specified. If you receive this error message, follow the instructions for "Error message: No Machine Specified" in the Troubleshooting DTM Problems topic.

    Note After you click Finish in Step 6a or 6b, the device or device driver is selected for test through the Device Console Submission Wizard in the left-hand pane of the Device Console. Do not change this selection unless you want select another device for the test specified in the INF. Do not choose the root submission name or a non-device, as this will cause the test to lose device information.

  6. Optional: Click the Save button to save this submission as a Device Job Schedule file. Next time you create a similar submission, you can load the Device Job Schedule file instead of completing the wizard again.

To select and schedule logo tests

  1. Select the check boxes for the displayed logo tests from the filtered list in the Available Jobs pane.

  2. Click Add Selected.

    Note Some of the logo jobs require you to edit some parameters manually before the jobs can be scheduled against the machine pool. The "Running the Xxx Tests" topics will tell you whether or not you must edit parameters. To edit parameters for a logo related job, complete the following procedure.

    1. In the bottom pane showing the selected jobs, right-click the job whose parameters you want to edit, then click Edit parameters.

      Note The values shown under Edit parameters are the default values of the job. They are not what the user selects in the submission wizard. You cannot change the values created in the submission wizard in Edit parameters.

    2. In the Parameters for "" pane, click the label for the Schedule Value column.
    3. Change the value of the <parameter_name> parameter to the required value.
    4. Click the pencil icon to the left of the parameter name to save your changes.
    5. Close the Parameters for "" dialog box.

  3. Click ScheduleJobs.

    Important If you rerun this job, do not do so from the Job Monitor window by using the Rerun option. Switch to the Device Console window and repeat the tasks under To select and schedule logo tests.

Monitor logo test progress

  • Observe logo test progress using Job Monitor, and manually intervene if required by the test.

  • Examine the results of a job in the Result Explorer and diagnose the source of any errors. If necessary, debug your device and/or driver and continue to rerun the logo tests until they pass.

    Note Under certain circumstances some tasks within a job will fail but the overall status for the completed job will be a PASS. This is a known condition and as long as the overall status of the completed job is a PASS, the job will be accepted. If you have questions about a failed task within a job that has a PASS status, refer to the Resolving Errors, Updating DTM with QFE Patches topic for more information.

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


Avoiding Test Failures

The Microsoft Logo and Customer Service and Support (CSS) teams recommend the following guidelines to avoid logo test failures.

To avoid test failures

  • Do not change the client hardware during setup unless advised by Microsoft.

  • Make sure you complete all submissions for a client before you try to submit a different submission on the same client. Mark the client as unsafe in DTM Studio, and then uninstall the client.

  • Launch all tests that you intend to submit for a logo through the Device Console submission view.

  • From the Device Console in DTM Studio, make sure that you select your device, that the driver is loaded on the client, and that you have loaded the INF file for your submission.

  • After your tests and submissions are completed, make sure that you review the DTM submission status window or the DTM log viewer to confirm submission and test status.

  • Avoid generic VGA drivers for video and other outdated drivers. Load only the system BIOS and drivers that are recommended.

  • Do not change the AutoLogon settings on the client.

  • Do not use the Job Monitor rerun option.

  • Do not alter or change jobs in the database.

  • Do not place errata numbers in the Readme file before you obtain the errata from the Windows Hardware and Driver Central (WHDC) Web site.

  • Run Storage > Adapter and LAN (Ethernet) test submissions for Windows Server 2008 on systems with a minimum of 4 processor cores and 6 gigabytes of memory. These requirements are in addition to those related to the Dynamic Partitioning (DP) Simulator and Test that all Windows Server 2008 device driver submissions must meet.

  • Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Take these proactive steps after setup to avoid unnecessary delays with your submission

  • Download the latest errata update for your controller from the Windows Quality Online Services (Winqual) Web site.

  • Clear the default Startup/Shutdown OS option on the DTM Client to reboot if there is a system failure.

    Important If you are running the Crashdump test for storage testing, ignore this guideline.

  • Review the best practices for DTM maintenance on the Windows Hardware and Driver Central (WHDC) Web site.

  • To determine if the test failure is filtered, log on to the Winqual Web site and download the latest filter updates. The DTM Controller Job Monitor does not apply the filters to the submission or show if a test failure is currently addressed by a DTM filter. The DTM filters are only applied during the creation of a Job Submission. However, the best time to download filter updates is after all the tests have been completed and you are ready to check the results.

Tracing down the exact reason for a test failure

When reviewing test logs for the source of failures, the Complete filter view of the Log viewer is acceptable for most testing. However, for tests which log context, the ContextTree filter view will show you the name of the test and the location of the functionality tested that failed and may results in a faster diagnosis of the failure.

To successfully test drivers with multiple INFs

  • Run a complete logo test against each INF. The test should be run against every INF that is included in the driver package.

  • Submit multiple CPK files (one for each INF file).


Resolving Errors, Updating DTM with QFE Patches

The DTM is updated periodically. These updates might include changes to the DTM test harness itself or to the testing content and the jobs available for a particular device category.

When these updates, or Quick Fix Engineering (QFE) patches, are ready for distribution, you can download them from the Windows Logo Kit: QFE Updates Web site. This Web site provides a brief explanation about the issue addressed by each QFE patch, along with instructions for how to download and install the patch.

In certain cases, one QFE depends on another for proper operation. In such cases, the QFE patches must be installed in a specific order. The instructions in the accompanying readme file explain the order of installation.

To avoid performance and maintenance issues, make sure to do the following:

  • Install all required infrastructure QFE patches. These are updates for the DTM test harness.

  • Install only the logo test-related QFE patches that you currently need to run your jobs.

  • After you have completed a logo submission that is dependent upon a logo test-related QFE patch, leave the QFE patch installed on your computer.

If you do not find a QFE patch that applies to your test scenario, or you downloaded and installed a QFE patch and you now have problems, contact Microsoft to request help.


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 Save to save the file.

  4. Go to the 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.


Creating 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.

Note Non-logo use is unsupported.

This section includes the following topics:

  • How Jobs Are Organized

  • Exploring the Job Information Tabs

  • 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 screen shot illustrates one possible hierarchy of features for organizing jobs.

Diagram of a sample hierarchy of features (such as Configuration, Gatherer, Library, and WDK Tools) for organizing jobs

A job feature hierarcy

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.

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 ( Screen shot of a button icon displaying a hierarchy of folders).

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.

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.

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 ( Screen shot of a button icon displaying a funnel and a pencil).

  4. Select the Advanced Query tab. A form similar to the following screen shot is displayed.

    Screen shot of the Query Builder's Advanced Query tab

  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 ( Screen shot of a button icon displaying two horizontal arrows pointing in opposite directions).

    The jobs that match the query are displayed in the Jobs pane.


Exploring the Job Information Tabs

This topic provides a basic overview of the tabs in the Job Information dialog box. These tabs provide additional information about any given job.

The names of the tabs are:

  • Details

  • Parameters

  • Constraints

  • LMS

  • Tasks

  • Attributes

To become familiar with the tabs in the Job Information dialog box, complete the following steps to access the Details and the Tasks tabs.

To view details in the Job Information dialog box

  1. Switch to the Job Explorer window.

    You can also open a new Job Explorer window by clicking Explorers and selecting Job Explorer.

  2. In the Feature pane on the left side, expand the WDK Tests node.

  3. Click the top-level category for a job.

    Note If the top-level category for the job has subfolders, you must first expand the node, and then click the appropriate subfolder.

  4. The Jobs pane on the right should now show the list of jobs in the category you selected.

  5. Double-click the job whose information you want to review. The Job Information dialog box appears, with the Details tab selected by default.

    You can also right-click the job, and then click Open.

More information about the Details and Tasks tabs now follows:

The Details tab

If populated with text, this tab will provide a brief summary of how the job works. You can find more detailed information about the job in the WDK documentation.

The Tasks tab

The Tasks tab provides a list of the tasks performed by the job. If you select the Tasks tab, three more tabs are available. They are:

  • Setup

  • Regular

  • Cleanup

The Regular tab is selected by default.

To view the details about a task:

  1. Click the task to highlight it, and then click View.

    You can also double-click the task.

  2. The View Task Details dialog box appears, with the General tab selected by default.


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 how to create a custom job with DTM:

Basic Job Concepts

Basic Task Concepts

Defining a Job

Defining Tasks

Executing Tasks in a Custom Order

Specifying Which Computers a Job Can 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:

  • Automated: Runs without user intervention.

  • Manual: Represents the need for a user to perform manual actions.

  • Library: Is similar to an automated job, but can be reused within other jobs.

  • 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 in the form of 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.

Before you create your own job, it is recommended that you study the details of any existing job that performs tasks that are similar to the ones you want your new job to complete. That way you can make sure that you do not create a duplicate of a job that already exists. Exploring the job information tabs for any job will provide you with more information about how a particular job works and how it can be modified for non-logo testing.

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.

    Note 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.

Before you create a job, refer to the exploring the job information tabs topic to make sure you do not duplicate an existing job.

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.

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.

Note Before you create a Set Dimension Change Job, make sure that the dimension is already defined on the controller. To define a new dimension, see Defining and Viewing Dimensions.

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.

To create a Set Dimension Change job

  1. Create a new job and enter the basic job information.

  2. From the Role drop-down list box, in the Status area, select Config.

  3. In the bottom pane of the New Job window, click the Parameters tab.

  4. In the Name column on the Local tab, type a name for the parameter.

  5. In the Value column, type a value for the parameter. This is the value that will be assigned to the dimension when the job has completed.

  6. Click the Dimension Change tab, and click Set from the Operation drop-down list box.

  7. If the job will install a new version of the operating system, select the Check this if the config job clean installs the OS check box.

  8. Click the Dimension column to activate the drop-down list box, and select the dimension to set.

  9. Click the Parameter column to activate the drop-down list box, and select the parameter you created in Step 4.

  10. Add tasks to the job by following the procedure in the Defining Tasks topic.

  11. If the tasks you added in Step 10 trigger changes that Asset Configuration Management will automatically report, such as WTT\MachineName, skip this step. Otherwise follow this procedure to set the dimension:

    1. Create an Execute task in the Regular Execution phase.

    2. Open a command prompt window and type

      [WTTBIN]\WTTCMD.EXE" /AddSysparseReg /v:<dimension> /d:"[<parameterName>]"

      where <dimension> is the name of the dimension you are setting and <parameterName> is the name you provided in Step 4 for the parameter.

    3. Set the task to fail on WTT Log.

    4. Set the task to run in system context.

      Note The task will always fail if it is not run in system context.

  12. Click Save ( Screen shot of a button icon displaying a floppy disc) 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.

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 ( Screen shot of a button icon displaying a floppy disc) 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.

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.

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 eventually succeed, 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 tab, 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.

    Note 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.

    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 Console if logged in, or Run as user in Console even 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.

      Important 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.

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 Console if logged in, or Run as user in Console even 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.

      Important 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.

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.

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.

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 Console if logged in, or Run as user in Console even 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.

      Important 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

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

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.

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.

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.

      Note

      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.

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.

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.

    Note

    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".

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 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 for Logo Testing 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.

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.

        Note 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.


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


Overview of 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.

Related Topics

Scheduling DTM Jobs


Schedule Toolbar Options

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

  • Screen shot of an open-folder icon Open a saved file

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

  • Screen shot of a floppy disc icon Save current component to a file

    Saves current schedule data, including all settings.

  • Screen shot of a printer icon Print the current component data

    Prints current schedule data.

  • Screen shot of a scissors icon Cut

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

  • Screen shot of an icon displaying two duplicate sheets of paper Copy

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

  • Screen shot of an icon displaying a sheet of paper attached to a clipboard Paste

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

  • Screen shot of an icon displaying a calendar and pencil Create schedule

    Creates the new schedule.

Related Topics

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 consider 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.

Diagram of a hierarchy of folders

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.

Related Topics

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.

Related Topics

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.

Related Topics

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.

Related Topics

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.

Related Topics

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.

Related Topics

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.

Related Topics

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.

Related Topics

Smart Scheduler


Managing DTM Jobs

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

Note Non-logo use is unsupported.

Manual Tasks

Using Job Monitor

Enabling a Client Computer to Execute Jobs

Examining the Result of Executing a Job

Reviewing the Result Report

Reviewing the Job Report

Reviewing the Job Logs

Reviewing the Machine Configuration Logs

Canceling a Job

Deleting a Job

Restoring a Deleted Job

Defining and Viewing Dimensions

Defining and Modifying Global Parameters

Using FileData Parameters


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.

The following screen shot shows the Job Monitor window after a sample job (test job) has finished executing.

Screen shot of the Job Monitor dialog box displaying the Job Execution and Task Execution status

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 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.

    Note If you want to keep track of additional job parameters while monitoring a job, you can add more columns to the Job Execution Status pane by doing the following:

    1. Right-click any of the columns in the pane, and then click Add/Remove Columns.
    2. In the Available Fields list, click the job parameter you want to monitor, and click Add to transfer your selection to the Displayed Fields list.

      Note You must repeat this step to add parameters that you want to monitor.

    3. Click the Move Up or the Move Down button to change the order in which the selected parameters appear in the Job Execution Status pane.
    4. Click OK.
    5. On the File menu, click Save.
    6. Type a name for your selected parameters, and then click Save.

      Note After you exit from DTM Studio, restart it and open the Job Monitor window, the columns you added will not be displayed by default. To see the additional columns, you must click Open on the File menu, and open the file that you just saved.

  • 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.

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. Screen shot of an icon displaying two green vertical arrows pointing in opposite directions

To interpret the Job Execution Status pane information

You can review the Job Execution Status pane for information regarding your job, as shown in the following screen shot.

Screen shot of the Job Execution Status (Filtered) pane

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.
    • Screen shot of an icon displaying two blue vertical arrows pointing in opposite directions: The job is executing.
    • Screen shot of a sheet of paper with a green check mark on it: The job has ended and passed.
    • Screen shot of a sheet of paper with a red X on it: The job has ended and failed.
    • Screen shot of an icon displaying two blue vertical arrows pointing in opposite directions with a red X: 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.

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. Screen shot of the Refresh icon (two horizontal arrows pointing in opposite directions)

To interpret the Task Execution Status pane information

You can review the Task Execution Status pane for information regarding your task, as shown in the following screen shot.

Screen shot of the Task Execution Status pane

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:
    • Screen shot of an icon displaying two blue vertical arrows pointing in opposite directions: The job is executing.
    • Screen shot of a sheet of paper with a green check mark on it: The job has ended and passed.
    • Screen shot of a sheet of paper with a red X on it: The job has ended and failed.
    • Screen shot of an icon displaying two blue vertical arrows pointing in opposite directions with a red X: The job 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.

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
    Screen shot of an icon displaying a computer and a hand

    Ready

    Yes

    The computer is available and ready to execute jobs.
    Screen shot of an icon displaying two blue vertical arrows pointing in opposite directions

    Executing

    No

    A job is currently executing on the computer.
    Screen shot of an icon displaying a computer and a hand

    Manual

    No

    A user put the job into this state by using DTM Studio.
    Screen shot of an icon displaying a computer and a red X

    Debug

    No

    A job that specifies "FailStopFreeze" has failed, or DTM encountered a problem with the computer.
    Screen shot of an icon displaying a computer with a green circle on it

    Reset

    No

    DTM is trying to restore the computer to its original state.
    Screen shot of a computer icon with an exclamation mark on it

    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. Screen shot of the Refresh icon (two horizontal arrows pointing in opposite directions)


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.

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 screen shot shows an example of the Result Explorer window.

Screen shot of the Result Explorer window displaying filtered results

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.

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.

To interpret the information in the Results pane

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

  1. The first column is unnamed and shows the following icons to indicate the status of the job that is associated with the result.

    • Screen shot of an icon displaying two blue vertical arrows pointing in opposite directions: The job is executing.

    • Screen shot of a sheet of paper with a green check mark on it: The job has ended and passed.

    • Screen shot of a sheet of paper with a red X on it: The job has ended and failed.

  2. 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.

  3. Job Name : The name of the job.

  4. Job Execution Type : One of the following values:

    • Automated: The job executes automatically.

    • Manual: The job requires manual intervention.

  5. Assigned To : The user name of the person who created the job.

  6. 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.

  7. 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.

  8. 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.

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.

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.

To view job 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, or only contains Library jobs which may be returning WTT Logs, then Browse Job Logs will not be available.

    If you are not sure if your job contains the Library job with results, right-click your job, select Child Job Results, and then follow the steps above to view your job logs manually. You can also access a tree view of results and logs using Device Console / Status / Report.

  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.

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

After you cancel a job from DTM, it will continue to appear in the Job Monitor window, in the Job Execution Status (Filtered) pane; however, the status icon will indicate that the job has been canceled ( Screen shot of an icon displaying two blue vertical arrows pointing in opposite directions with a red X on them). The job's results will appear in the Result Explorer and Result Collection windows.

If the Job Monitor window is already open, 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 list box in the upper-left corner 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 running.

    Note 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 that the job has not completed. If the job's status icon consists of two blue arrows ( Screen shot of an icon displaying two blue vertical arrows pointing in opposite directions), the job is still running.

  5. If the job is still running, then, in the Machines pane, set the status of the client computer to Unsafe or Manual.

    If the job has already completed and you want to delete it, follow the steps to delete a job.

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

    Note If you want to cancel more than one job you must first select all the relevant jobs.

  7. If the job status icon in the Job Execution Status (Filtered) pane does not show that the job is now canceled, click the machine pool name, and press F5 to refresh the pane.


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.


Restoring a Deleted Job

To restore a job that was accidentally deleted from Job Explorer or irreversibly modified, complete the following procedure.

Note Performing these steps may affect any in-progress Logo Submission. If possible, please complete all Logo testing before performing these steps.

This process restores the entire set of logo jobs and can take up to half an hour, depending on the hardware specification of the computer onto which you are restoring the jobs.

To restore a deleted job

  1. On the Tools menu, click Management Console.

  2. In the left pane, right-click the Packages node, and then click Register Package.

  3. In the Select Package to Open dialog box, select and open the appropriate .PCK file.

    Note Multiple PCK files may be installed, depending on the logo kit that was installed. To locate the appropriate PCK, select the name that is similar to the installed logo kit. For example, if System Logo Kit was installed, you will see system_lk.pck at %system_root%\Program Files\Microsoft Driver Test Manager\Tests\Package\.

  4. In the left pane, expand the Packages node.

  5. Right-click <your_package_name> node, and then click Open in Job Explorer.

  6. In the Package Explorer window, click Refresh near the top right.

    Note It can take up to five minutes for the window to refresh and display all the logo jobs in the package. During this time, the mouse pointer will not be displayed as an hour glass. However, you will see a progress bar at the bottom-right corner of the window.

  7. Press CTRL+A to select all the displayed logo jobs.

  8. On the File menu, click Export Jobs.

  9. On the Export Jobs dialog box, click Start.

  10. After the job export process has completed, close the Package Explorer window.

  11. Switch to the Job Explorer window.

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

  12. On the File menu, click Import Jobs.

  13. On the Import Options dialog box, click Start.

    Note When you click Start, you will not see a progress bar and the pointer will retain its default shape. A dialog box titled Job GUID Collision might appear. If it does, select the Always do the Selected Action check box, and then click Overwrite to continue. A running count of the imported files is displayed near the bottom-left corner of the dialog box. If the running count for the imported files still shows 0 after several minutes, press ALT+TAB to reveal the Job GUID Collision dialog box. This process of importing all the logo jobs can take about 20 minutes.


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.

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 Console Root, expand your Datastore, and then select Dimensions.

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

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 Console Root, expand your Datastore, 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.

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 Dimensions 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.

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 ( Screen shot of a floppy-disc icon) 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.

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 Console Root, expand your Datastore, 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.

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 Console Root, expand your Datastore, 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). This tool 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 model 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 DTM Studio that the job or task reports now includes the out-of-context error, blocked, warned, and skipped traces.

Note Non-logo use is unsupported.

This section includes:

Introduction to DTM Logger

Getting Started with DTM Logger

Code Samples for DTM Logger

DTM Logger Troubleshooting

DTM 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 of Logging 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 configuration enables 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, including:
    • 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 control 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 the C/C++, COM, and .NET programming languages. If you use 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 use C, you can access the logging engine by 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 support 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, such 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 that is being checked matches any error in the expected error list for both value and type, the error is considered a valid error and does not cause the test to fail. If the error that is being checked matches any error in the break-on error list for both value and type, 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, DTM Logger considers S_OK a valid error. However, if the list is not empty and S_OK is not in the error lists, the logger considers S_OK a failure.

For more information about 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 CWTTLogger::CheckResultEx method instead of the CWTTLogger::CheckResult method.

See Also

Getting Started with DTM Logger, Error List Sample Using C++


Maintaining Error Lists

You can add an error to the list of expected errors or the list of break-on errors, remove an error from either of those lists, 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 by 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 by 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 by 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 by 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 the list of expected errors or the list of break-on 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 by using C
    • Call the WTTLogCheckResult function or the WTTLogCheckResultEx function.
  • To check test results by using C++
    • Call the CWTTLogger::CheckResult method or the CWTTLogger::CheckResultEx method.
  • To check test results by using COM
    • Call the IWTTLog::CheckResult method or the IWTTLog::CheckResultEx method.
  • To check test results by using .NET
    • Call the WTTLogger.CheckResult method.


Integration of Logging with DTM Jobs

Test software that a DTM job's tasks run might use DTM Logger as the logging service to record information and results of running 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 "Task Failure Conditions" execution option is set to "Declare task failure based on results from log," DTM will determine the pass or fail status for the task based on the contents of the pass-fail rollup log file that DTM Logger creates.

Pass-Fail Rollup Files

The pass-fail rollup file is created when the test software closes the DTM Logger object (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.

DTM performs two operations on the information that is provided in the pass-fail rollup file:

  • Maps "Blocked" to "Not Run" and "Skipped" to "Not Applicable".

  • Sums the Pass, Failed, Not Run, and Not Applicable attributes of the TaskResult and AdditionalResult elements.

    Note DTM does not use the "Warned" attribute.

Out-of-Context Errors

Out-of-context errors can occur during testing, depending on the way in which test software has been implemented. To help resolve problems with out-of-context errors, DTM:

  • Isolates test execution for a specific device handle from the log messages that are delivered for other device handles. This isolation prevents, for example, the system processes and modules that use DTM Logger, such as WTTCmd.exe or the WTTSDK API, from changing the test results of the user test application.

  • Indicates which messages were recorded as additional results because the computer restarted and which messages were recorded as out-of-context. Restarting, which the test software might initiate during a test, causes re-execution of a process. Re-execution is identified in the rollup file by the presence of AdditionalResult tags. Out-of-context errors within an additional result are identified by an OutOfContext attribute, which can be set to "true" or "false". An AdditionalResult tag with an attribute value of OutOfContext="true" indicates the presence of an out-of-context error.

  • Each additional result includes a LogFileList item that shows the names of the log files to which the result was written.

The combination of out-of-context errors and restarting leads to different entries in the pass-fail rollup file, as shown in the following examples.

Example 1: No Out-of-Context Errors, No Restart

In the case where the task runs once (without restarting) and the test software does not record out-of-context errors, the pass-fail rollup file will be similar to the following example.

<TaskResult Total="10" Pass="5" Failed="5" Blocked="0"
 Warned="0" Skipped="0" StartTime="4/20/2006 0:21:30"
 EndTime="4/20/2006 0:21:31" >
 <LogFileList>
 <File Name="C:\log1.wtl" />
 <File Name="C:\hdevice2.wtt" />
 </LogFileList>
 <AdditionalResultList>
 <AdditionalResult Total="10" Pass="5" Failed="5"
  Blocked="0" Warned="0" Skipped="0" StartTime="4/20/2006 0:21:40"
  EndTime="4/20/2006 0:21:41" OutOfContext="false" >
 <LogFileList>
 <File Name="C:\log1.wtl" />
 <File Name="C:\hdevice2.wtt" />
 </LogFileList>
 </AdditionalResult>
 </AdditionalResultList>
</TaskResult>

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

Example 2: Out-of-Context Errors Occur, No Restart

When a task runs once, without restarting, and the test software records out-of-context errors, the resulting pass-fail rollup file will include an AdditionalResult element with a non-zero value for Failed, similar to the following example.

<TaskResult Total="10" Pass="5" Failed="5" Blocked="0"
 Warned="0" Skipped="0" StartTime="4/20/2006 20:39:27"
 EndTime="4/20/2006 20:39:28" >
 <LogFileList>
 <File Name="C:\log1.wtl" />
 <File Name="C:\hdevice2.wtt" />
 </LogFileList>
 <AdditionalResultList>
 <AdditionalResult Total="5" Pass="0" Failed="5"
  Blocked="0" Warned="0" Skipped="0" StartTime="4/20/2006 20:39:27"
  EndTime="4/20/2006 20:39:28" OutOfContext="true" >
 <LogFileList/>
 </AdditionalResult>
 </AdditionalResultList>
</TaskResult>

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

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

Example 1: Out-of-Context Errors Occur, System Restarts

If the test software calls for a restart and the task is configured to re-run after the restart, 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 will look similar to the following example.

<TaskResult Total="10" Pass="5" Failed="5" Blocked="0"
 Warned="0" Skipped="0" StartTime="4/20/2006 20:39:27"
 EndTime="4/20/2006 20:39:28" >
 <LogFileList>
 <File Name="C:\log1.wtl" />
 <File Name="C:\hdevice2.wtt" />
 </LogFileList>
 <AdditionalResultList>
 <AdditionalResult Total="5" Pass="0" Failed="5"
  Blocked="0" Warned="0" Skipped="0" StartTime="4/20/2006 20:39:27"
  EndTime="4/20/2006 20:39:28" OutOfContext="true" >
 <LogFileList/>
 </AdditionalResult>
 <AdditionalResult Total="10" Pass="5" Failed="5"
  Blocked="0" Warned="0" Skipped="0" StartTime="4/20/2006 20:39:42"
  EndTime="4/20/2006 20:39:42" OutOfContext="false" >
 <LogFileList>
 <File Name="C:\log1.wtl" />
 <File Name="C:\hdevice2.wtt" />
 </LogFileList>
 </AdditionalResult>
 <AdditionalResult Total="5" Pass="0" Failed="5"
  Blocked="0" Warned="0" Skipped="0" StartTime="4/20/2006 20:39:42"
  EndTime="4/20/2006 20:39:42" OutOfContext="true" >
 <LogFileList/>
 </AdditionalResult>
 </AdditionalResultList>
</TaskResult>

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

See Also

Getting Started


TraceAll.wtl

The following code example shows a 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

The DTM Logger rollup data is stored in a file named <Taskguid>.xml and is copied to the DTM controller's log file share. The following example shows a rollup file for the case in which out-of-context errors occur and the system restarts.

<TaskResult Total="10" Pass="5" Failed="5" Blocked="0"
 Warned="0" Skipped="0" StartTime="4/20/2006 20:39:27"
 EndTime="4/20/2006 20:39:28" >
 <LogFileList>
 <File Name="C:\log1.wtl" />
 <File Name="C:\hdevice2.wtt" />
 </LogFileList>
 <AdditionalResultList>
 <AdditionalResult Total="5" Pass="0" Failed="5"
  Blocked="0" Warned="0" Skipped="0" StartTime="4/20/2006 20:39:27"
  EndTime="4/20/2006 20:39:28" OutOfContext="true" >
 <LogFileList/>
 </AdditionalResult>
 <AdditionalResult Total="10" Pass="5" Failed="5"
  Blocked="0" Warned="0" Skipped="0" StartTime="4/20/2006 20:39:42"
  EndTime="4/20/2006 20:39:42" OutOfContext="false" >
 <LogFileList>
 <File Name="C:\log1.wtl" />
 <File Name="C:\hdevice2.wtt" />
 </LogFileList>
 </AdditionalResult>
 <AdditionalResult Total="5" Pass="0" Failed="5"
  Blocked="0" Warned="0" Skipped="0" StartTime="4/20/2006 20:39:42"
  EndTime="4/20/2006 20:39:42" OutOfContext="true" >
 <LogFileList/>
 </AdditionalResult>
 </AdditionalResultList>
</TaskResult>


Getting Started with DTM Logger

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 that are 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 by 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 WttLog.lib library files for C/C++.

Scripting the Logger

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

  1. Register the COM version of the logging engine (WttLogCM.dll).

  2. Use the WttLogger object as you would use any Microsoft ActiveX object.

This section includes:

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

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.

The following procedures describe how to initialize a log device and set up your desired logging output.

To initialize a log device by using C

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

To initialize a log device by 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 by 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 by using .NET

  1. Use the Microsoft.WTT.Log namespace.

  2. Create a new WTTLogger object and pass it a device string.

This section includes:

Device String

Log Device Types

See Also

Getting Started with DTM Logger, Code Samples for DTM Logger


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 CWTTLogger::CreateLogDevice method 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 in the following 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 you 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. You 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 in the following code example, contains only the child devices.

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

The following code 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: one that describes the server-side topology and one that describes 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 through TCP/IP on port 2204.

Setting device strings outside an application

There might be times when you want to change the topology for a test. For example, you might want a test to look different when it is being written than when it is being run. You can allow for topology changes by passing a null device string to the CreateLogDevice function. The device string can then 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 the following code example shows.
    /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:
    HKLM\CurrentUser\Software\Microsoft\WTT\Log

    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. DTM 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 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 typically not need to specify the $LocalPub device; it is created automatically by the DTM 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 option 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 option will be the name of the executible file (.exe) with the .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 operating system.
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 include a Cyclic Redundancy Check (CRC) 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

Note 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 $PlainLog device type.

Option Syntax Description

file

file=somefilename

File name. By default, this name will be the name of the executibl file (.exe) with the .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 operating system.
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 include a Cyclic Redundancy Check (CRC) 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

Note 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, you can specify only the common options.


$Debugger Options

For the $Debugger device type, you can specify only the common options.


$NetPub Options

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

Option Syntax Description

server

server=servername

Name of the remote server. This option must be set for the device to work properly.

port

port=portnumber

Port number of the remote server.
Default = 2204


$NetSub Options

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

Option Syntax Description

port

port=portnumber

Port number of the remote server.
Default = 2204


$Tactics Options

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

Option Syntax Description

logmode

logmode=[offline|realtime]

Specifies whether to log to the Tactics database in real time.
Default = offline

sqlfile

sqlfile=somefilename

Name of the SQL file that this device generates.
Default = Sql.txt


Managing a Test Case

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

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

To manage a test case by 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 by 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 by 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 by 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.

This section includes:

Logger Modes and Test Case Results

Selective Roll Up of Test Case Results

See Also

Getting Started with DTM Logger, Code Samples for DTM Logger


Logger Modes and Test Case Results

There are two modes in which the DTM 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 that the user provides might be overridden according to the previous traces. In this mode, one of the following types of test case results might be logged:

  • Passed. No error, assert, invalid parameter, break, warning, or bug traces occurred during the test case.

  • Warned. A warning trace occurred, but no error, assert, invalid parameter, break, or bug trace occurred during the test case.

  • Failed. An error, assert, invalid parameter, or break trace occurred, but no bug trace occurred during the test case.

  • Blocked. A bug trace occurred during the test case, or the user application declares the test case blocked.

  • Skipped. The user application declares the test case skipped.

Note DTM Logger tracks 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, DTM Logger will not override the test case result that the Xxx EndTest function sets. This mode is used primarily for advanced users to enable better test result handling and for backward compatibility with existing user applications where only the Xxx StartTest and Xxx 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 with DTM Logger, 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 option 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 file.

  2. To this DLL, add a string table with an entry for each test case that 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 code 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 that contains your string table.

  5. In your test code, start the test by using the WTTLogger.StartTest(String, Guid) (.NET) or CWTTLogger::StartTestWithResID (C++) method.

  6. End the test by using the WTTLogger.EndTest(String, String, Guid) (.NET) or CWTTLogger::EndTestWithResID (C++) method.

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 with DTM Logger, Managing a Test Case


Performing a Trace

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

The following attributes are associated with a trace:

  • Run-time information (RTI) is information about who generated the trace.

  • Trace context is 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 by using C

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

To perform a trace by 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 by using COM

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

To perform a trace by 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.

This section includes:

Trace Context

Trace Level

Trace Priority

Trace Message

See Also

Getting Started with DTM Logger, Code Samples for DTM Logger


Trace Context

A trace context is a tag that you can apply 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.

You can use context to tag messages that span across multiple computers, processes, or threads. This operation becomes particularly useful when you want to perform client-server testing.

Your application can 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 by using C

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

To switch contexts by using C++

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

To switch contexts by using COM

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

To switch contexts by using .NET

Call the WTTLogger.SetContext method.

Context XML element

A typical context element in an XML log file looks like the following example.

    <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 that DTM Logger should log. There are many trace levels available for your use. For example, trace levels exist for logging errors, bugs, warnings, computer information, messages, and so on.

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++ code example, a Message trace accepts one additional string parameter.

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 the following code example shows.

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 that the Trace and UserDefinedTrace functions require 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 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 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 DTM 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 enables certain traces to be blocked or filtered based on their importance during run time. If user-defined trace levels are used, you can use the trace priority to determine the urgency for logging those user traces in the log file. If, on the other hand, predefined trace levels are used, 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-defined priority traces

Trace priorities for predefined trace levels

The following list shows each of the predefined trace levels and the trace priority that is 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 DTM 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 by 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 Msxsl.exe program, which is a free download from Microsoft. You can also design your own .NET transformation program.

Example transformation

The following example command 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

Logging in DTM, Getting Started with DTM Logger, Logger XML Schema


Code Samples for DTM Logger

The DTM Logger code samples are divided into the following groups:

Managed Code Samples (.NET)

Unmanaged Code Examples (C/C++, COM, scripting)

See Also

Logger XML Schema, Logger Reference, Logging in DTM


Managed Code Samples (.NET)

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

Complete DTM Logger Sample Using C#

DTM Logger Example Using C#

DTM Logger Example Using C# (Legacy)

See Also

Logger XML Schema, Sample Code


Complete DTM Logger Sample Using C#

The following code 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)
        {
            // Perform 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 by using a message string
            Logger.Trace(new LevelMessage("Testing Tracing Messages"));

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

            Logger.Trace(new LevelMessage(userObject));

            // Trace a message by using a user object and a message string
            Logger.Trace(new LevelMessage("Testing Tracing Messages with user Objects",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

Code Samples for DTM Logger


DTM Logger Example Using C#

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

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 by using a message string
        m_Logger.Trace(new LevelMessage("Testing Tracing Messages"));

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

        // Trace a message by using a user object and a message string
        m_Logger.Trace(new LevelMessage("Testing Tracing Messages with user Objects",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

Code Samples for DTM Logger


DTM Logger Example Using C# (Legacy)

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

The following code example demonstrates how to implement logging for a simple test case with only one variation by 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." );
    // 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

Code Samples for DTM Logger


Unmanaged Code Examples (C/C++, COM, scripting)

The following code examples show the basics of using the DTM Logger for applications that are written in C/C++, COM, and Tactics scripting.

DTM Logger Example Using C

DTM Logger Example Using C++

Error List Example Using C++

DTM Logger Example Using COM

DTM Logger Example Using Tactics Scripting

See Also

Logger XML Schema, Sample Code


DTM Logger Example Using C

The following C language code example 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

Code Samples for DTM Logger


DTM Logger Example Using C++

The following C++ code example 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

Code Samples for DTM Logger


Error List Example Using C++

The following code example 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 DTM Logger logs nothing. However, on the second call to CWTTLogger::CheckResult, E_ACCESSDENIED is logged as a failure because it is not in the known error list.

See Also

Code Samples for DTM Logger, Using Error Lists


DTM Logger Example Using COM

The following code example 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

Code Samples for DTM Logger


DTM Logger Example Using Tactics Scripting

The following code example 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

Code Samples for DTM Logger


DTM Logger Troubleshooting

The following topics provide tips for solving problems you might encounter when using DTM Logger:

Tests That Formerly Passed Now Fail

Test Shows Out-of-Context Errors


Tests That Formerly Passed Now Fail

If your test passed in versions of DTM before 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) are now considered to be failures rather than passes. This change is because an all-zero return typically implies that something is wrong with a test or the test has had an early catastrophic failure. This behavior is the same behavior that is found in logs elsewhere in DTM.

Out-of-Context Failures

Previously, DTM ignored DTM Logger failures that were reported out of context. This situation caused 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, DTM can report test status 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 DTM Studio that the job or task reports includes the out-of-context error, blocked, warned, and skipped traces. If your test logs such traces outside of Xxx StartTest or Xxx EndTest, these traces will be reported.

To work with out-of-context errors, we recommend that you:

  • Fix all out of context errors or find a way to handle them by using the CheckResult or CheckResultEx methods and error lists.

  • Better handle unexpected warnings, blocking issues, and skipped traces.

  • Fix the problems as soon as they show up in the rollup in DTM Studio.


DTM Logger Reference

This reference contains the DTM Logger XML schema and the API interfaces for the C/C++ programming languages and COM technology .

Logger XML Schema

CWTTLogger Class (C++)

IWTTLog Interface (COM)

WTTLog Functions (C)


DTM 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 that you should use for displaying or parsing. It stores the entries (that is, XML entities) for the contexts and run time-information blocks. The actual traces in XML format are contained in the t.xml file.

The DTM Logger XML schema defines the format of these files. Each XML element (also called a tag) contains a number of attributes and encloses sub-elements.

Common Attributes and Sub-Elements

The following attributes are common to all DTM Logger elements:

  • CA is the called-at time-stamp, which is relative to the beginning of the test run.

  • LA is the logged-at time-stamp, which is relative to the beginning of the test run.

The following subelements are common to all DTM Logger elements:

  • RTI is the index to the run time-information table in the m.xml file, which describes the run-time information of each trace. This subelement contains the following attributes:

    • ID is the identifier of the run time-information table.
    • Machine is the name of the computer that is being used.
    • ProcessName is the name of the test that is being run.
    • ProcessID is the identifier of the test that is being run.

    • ThreadID is the identifier of the thread.

    The following code example demonstrates the RTI subelement and its attributes.

    <RTI ID="1207879918" Machine="WEIYOU-WIS5" ProcessName="CTLUnitTest.exe"
     ProcessID="2824" ThreadID="2740" />
  • CTX is the index to the context table in the m.xml file, which describes the context of each trace. This subelement contains the following attributes:
    • ID is theidentifier of the context table.
    • Current is the name of the current context.
    • Parent is the name of the parent context.

The following code example demonstrates the CTX subelement and its attributes.

<CTX ID="1637872268" Current="DTM Logger COM Test" Parent="WTTLOG" />

Note The RTI and CTX subelements contain all attributes only the first time that they are logged. Every other logging contains just the ID attribute, as the following code example shows.

<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

Logging in DTM, Getting Started with DTM Logger


Assert Element

The Assert element represents a logged trace for an assertion.

Attributes

Attribute | Description
File | The full file name to the source file where the assert is reported.
Line | The line number of the assert.
UserText | The 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

The Break element represents a logged trace for a break into the debugger.

Attributes

Attribute | Description
File | The full file name to the source file where the break is reported.
Line | The line number where the error occurred.
ErrorCode | The identifier code for the error.
ErrorType | The type of error that occurred. This should be one of the following: WIN32, BOOL, HRESULT, NT_STATUS.
ErrorText | The description of the error for Microsoft Win32 and HRESULT errors. For Boolean and NTStatus errors, this description 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

The Bug element represents a logged trace for a known bug.

Attributes

Attribute | Description
DB | The name of the bug database.
ID | The identifier of the bug.
Type | The type of the bug (that is, 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

The EndTest element represents a logged trace for the end of a test case.

Attributes

Attribute | Description
Title | The name of the test.
Result | The result of running the test (that is, pass or fail).
Repro | The reproduction line.
TUID | The 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

The Entry element represents a logged trace for a function entry point.

Attributes

Attribute | Description
Function | The name of the entry-point function of the test.
File | The source file name that contains 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

The Error element represents a logged trace for an error.

Attributes

Attribute | Description
File | The full file name to the source file where the error is reported.
Line | The line number where the error occurred.
ErrCode | The rrror code.
ErrType | The type of error that occurred. This attribute should be one of the following values: WIN32, BOOL, HRESULT, or NT_STATUS.
ErrorText | The description of the error for Microsoft Win32 and HRESULT errors. For Boolean and NTStatus errors, this text will be in the following format: ErrorText="Error 0xc0000005"
UserText | Additional 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

The Exit element represents a logged trace for a function exit point.

Attributes

Attribute | Description
Function | The name of the exit-point function for the test.
File | The source file name the contains 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

The InvalidParam element represents a logged trace for an error that an invalid parameter causes.

Attributes

Attribute | Description
File | The full file name to the source file where the invalid parameter is reported.
Line | The 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

The Machine element represents logged information about a test computer.

Attributes

Attribute | Description
Build | The build number of the operating system where the application test runs.
Platform | The CPU type in the computer.
OS | The operating system in the computer.
ServicePack | The service pack, if present, on the operating system.
Version | The version of the operating system.
BuildLab | The lab where the operating system was built.
BuildDate | The date when the operating system was built.
Language | The currently set language in the operating system.
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

The Msg element represents a logged trace for a message.

Attributes

Attribute | Description
UserText | The 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

The PFRollup element represents a logged summary of pass-fail roll-up information.

Attributes

Attribute | Description
Total | The total number of test runs.
Passed | The number of tests that completed successfully.
Failed | The number of tests that failed.
Blocked | The number of tests that were blocked and did not complete.
Warned | The number of tests that ended with a warning.
Skipped | The 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

The StartTest element represents a logged trace for the start of a test case.

Attributes

Attribute | Description
Title | The name of the test.
TUID | The 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

The TCM element represents logged information for test case management.

Attributes

Attribute | Description
TestCase | The identifier for the test case.
Path | The directory path to the test case.
Title | The name of the test case.
HashKey | The handle to the hash table entry for this test case.
CreatedBy | The name of the person that created the test case.
ModifiedBy | The name of the person that last modified the test case.
AssignedTo | The name of the person to whom the test case is assigned.
Type | The type of test.
ResultType | The type of the result that the test case returns.
Milestone | The project milestone for the test case.
Priority | The priority level that is assigned to the test case.
TestTime | The time, in seconds, to run the test case.
Remarks | Remarks about the test case.
Method | The test case type (automated or manual).
Frequency | The number of times the test case is run.
Description | The description of the test case to be displayed.
Script | The names of the test scripts.
LogPath | The directory path to the log file.
Suite | The name of the test suite.
Area | The name of the project area.
Component | The name of the component under test.
SubComponent | The name of the subcomponent under test.
Dev | The name of the test case developer.
TestLead | The name of the test lead that is assigned to the test case.
LogTable | The 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

The Warn element represents a logged trace for a warning.

Attributes

Attribute | Description
File | The full file name to the source file where the warning is reported.
Line | The line number where the warning occurred.
UserText | A 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++)

The CWTTLogger class encapsulates C++ methods for logging messages and errors.

public  class  CWTTLogger

CWTTLogger contains the following public methods.

Method | Description
~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 that the device string or the handle specify.
CreateLogDevice | Creates a log device topology according to the device string.
CreateLogDeviceCallback | For internal use only. 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 the current test case context, and sets it to the parent context.
EndTestEx | Traces the end of a test case and enables you to specify a GUID-based test ID and a test hierarchy.
EndTestWithResID | Traces the end of a test case by 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.
SetDeviceOption | 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 enables you to specify a GUID-based test ID and a test hierarchy.
StartTestWithResID | Traces the start of a test case by 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 by using an XML-formatted data string.
TraceExV | Logs a trace of the specified device at the given trace level by using an XML-formatted data string and a prepared argument list.
TraceMachineInfo | Logs a trace of the operating system where the test is run.
TraceMsg | Logs a trace of the specified device at the user-defined trace level and a given priority.
CWTTLogger::TraceMsgV | Logs a trace of the specified device at the user-defined trace level and a given priority by using a prepared argument list.
TraceV | Logs a trace of the specified device at the given trace level by using a prepared argument list.
UserDefinedTrace | Logs trace data by using a user-defined trace level.
UserDefinedTraceEx | Logs trace data by using a user-defined trace level and an XML-formatted data string.
UserDefinedTraceExV | Logs trace data by using a user-defined trace level and an XML-formatted data string.
UserDefinedTraceV | Logs trace data by 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 Method

The ~CWTTLogger method destroys and cleans up after this instance of the CWTTLogger class.

Syntax

public ~CWTTLogger(

);

Parameters

None

Return Value

None

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

CWTTLogger Class (C++)


CWTTLogger::AddErrorToErrorList Method

The AddErrorToErrorList method adds the specified error type and error code to the given list of known errors.

Syntax

HRESULT AddErrorToErrorList(
    DWORD dwErrorToAdd,
    DWORD dwErrorType,
    DWORD dwErrorList
);

Parameters

dwErrorToAdd

[in] The error code to add.

dwErrorType

[in] The type of the error. This parameter can be one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

dwErrorList

[in] The list to which the error will be added. This parameter can be one of the following values: WTT_ERROR_LIST_EXPECTEDWTT_ERROR_LIST_BREAKON

Return Value

AddErrorToErrorList returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

DTM Logger uses the error lists to enable 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 that are passed to it with the know errors on the list. If the error is on the list, CheckResult returns S_OK to indicate that the test passed. If the error is not on the list, the test fails.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::RemoveErrorFromErrorList
CWTTLogger::ClearErrorList


CWTTLogger::Assert Method

The Assert method 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.

Syntax

HRESULT Assert(
    BOOL fCondition,
    LPWSTR pwszFile,
    UINT uiLine,
    LPWSTR pwszAssertMsg,
    LONG hDevice
);

Parameters

fCondition

[in] A Boolean value that specifies whether the method should prevent the test case from failing if the bug trace is not logged. If this parameter is true, Assert prevents the test case from failing if the bug trace is not logged. If this parameter is false, Assert fails the test case unless the bug trace is logged.

pwszFile

[in] The name of the source file where the assert happened.

uiLine

[in] The line number within the source file where the assert happened.

pwszAssertMsg

[in] The text message of the assertion.

hDevice

[in] The handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

Assert returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::Trace


CWTTLogger::CheckResult Method

The CheckResult method checks a specified result and logs an error if the result shows a failure.

Syntax

HRESULT CheckResult(
    DWORD dwResultToCheck,
    DWORD dwResultType,
    LPWSTR pwszFile,
    ULONG ulLine,
    LPWSTR pwszErrMsg,
    LONG hDevice
);

Parameters

dwResultToCheck

[in] The result to check.

dwResultType

[in] The type of the result. This parameter can be one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

pwszFile

[in] The name of the source file where the assert happened.

ulLine

[in] The line number within the source file where the assert happened.

pwszErrMsg

[in] The text of the error message.

hDevice

[in] The handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

CheckResult returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::CheckResultEx


CWTTLogger::CheckResultEx Method

The CheckResultEx method checks a specified result against a target result and logs an error if both the value and type match.

Syntax

HRESULT CheckResultEx(
    DWORD dwResultToCheck,
    DWORD dwResultType,
    DWORD dwTargetResult,
    DWORD dwTargetResultType,
    LPWSTR pwszFile,
    ULONG ulLine,
    LPWSTR pwszErrMsg,
    LONG hDevice
);

Parameters

dwResultToCheck

[in] The result to check.

dwResultType

[in] The type of the result to check. This parameter can be one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

dwTargetResult

[in] The target result to check the dwResultToCheck result against.

dwTargetResultType

[in] The type of the target result. This parameter can be one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

pwszFile

[in] The name of the source file where the assert happened.

ulLine

[in] The line number within the source file where the assert happened.

pwszErrMsg

[in] The text message for the error.

hDevice

[in] The handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

CheckResultEx returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::CheckResult


CWTTLogger::ClearContext Method

The ClearContext method clears the current context of the logger object.

Syntax

HRESULT ClearContext(
    LPWSTR pwszCurrentContext,
    LPWSTR pwszParentContext
);

Parameters

pwszCurrentContext

[in] The current context of the logger object.

pwszParentContext

[in] The parent context of the logger object.

Return Value

ClearContext returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::SetContext


CWTTLogger::ClearErrorList Method

The ClearErrorList method removes all errors of the specified type from a given list of known errors.

Syntax

HRESULT ClearErrorList(
    DWORD dwErrorList,
    DWORD dwErrorType
);

Parameters

dwErrorList

[in] The error list to clear. This parameter can be one of the following values: WTT_ERROR_LIST_EXPECTEDWTT_ERROR_LIST_BREAKON

dwErrorType

[in] The type of the error to remove. This parameter can be one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

Return Value

ClearErrorList returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::AddErrorToErrorList
CWTTLogger::RemoveErrorFromErrorList


CWTTLogger::CloseLogDevice Method

The CloseLogDevice method closes a log device topology that the device string or the handle specifies.

Syntax

HRESULT CloseLogDevice(
    LPWSTR pwszLogDeviceName,
    LONG hDevice
);

Parameters

pwszLogDeviceName

[in] The 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] The handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

CloseLogDevice returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::CreateLogDevice


CWTTLogger::CreateLogDevice Method

The CreateLogDevice method creates a log device topology according to the device string.

Syntax

HRESULT CreateLogDevice(
    LPWSTR pwszLogDeviceName,
    LONG* phDevice
);

Parameters

pwszLogDeviceName

[in] The 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] A pointer to a handle that represents the device tracing topology.

Return Value

CreateLogDevice returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::CloseLogDevice
CWTTLogger::CreateLogDeviceCallback


CWTTLogger::CreateLogDeviceCallback Method

Reserved for internal use only. The CreateLogDeviceCallback method is called by the parser after servicing the CreateLogDevice method.

Syntax

HRESULT CreateLogDeviceCallback(
    PVOID pvObj,
    DWORD tnNav,
    DWORD wttDevType,
    PVOID pParams
);

Parameters

pvObj

[in] A pointer to the callback object.

tnNav

[in] The tree navigation command. This parameter can be one of the following values: TREE_NAV_CREATE_CHILDTREE_NAV_SKIP_CHILDTREE_NAV_GOTO_PARENT

wttDevType

[in] The log device type. This parameter can be one of the following values: WTT_LOGDEVICE_LOCALPUBWTT_LOGDEVICE_FILEWTT_LOGDEVICE_CONSOLEWTT_LOGDEVICE_DEBUGGERWTT_LOGDEVICE_SPYWINWTT_LOGDEVICE_NETPUBWTT_LOGDEVICE_NETSUBWTT_LOGDEVICE_FILTERWTT_LOGDEVICE_TACTICSWTT_LOGDEVICE_PLAINLOGWTT_LOGDEVICE_SECURELOGWTT_LOGDEVICE_CUSTOM

pParams

[in] An array of named parameters.

Return Value

CreateLogDeviceCallback returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::CreateLogDevice


CWTTLogger::CWTTLogger Method

The CWTTLogger method initializes a new instance of the CWTTLogger class.

Syntax

public CWTTLogger(

);

Parameters

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::~CWTTLogger


CWTTLogger::DisableTraceLevels Method

The DisableTraceLevels method disables the specified set of device trace levels.

Syntax

HRESULT DisableTraceLevels(
    LPWSTR pwszTraceLevels,
    LONG hDevice
);

Parameters

pwszTraceLevels

[in] The string that contains a list of trace levels to be disabled.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

DisableTraceLevels returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::EnableTraceLevels


CWTTLogger::EnableTraceLevels Method

The EnableTraceLevels method enables the specified set of device trace levels.

Syntax

HRESULT EnableTraceLevels(
    LPWSTR pwszTraceLevels,
    LONG hDevice
);

Parameters

pwszTraceLevels

[in] The string that contains a list of trace levels to be enabled.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

EnableTraceLevels returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::DisableTraceLevels
CWTTLogger::SetDeviceTraceLevel


CWTTLogger::EndTest Method

The EndTest method traces the end of a test case, clears current test case context, and sets it to the parent context.

Syntax

HRESULT EndTest(
    LPWSTR pwszTestName,
    DWORD dwResult,
    LPWSTR pwszRepro,
    LONG hDevice
);

Parameters

pwszTestName

[in] The name of the test case.

dwResult

[in] The test case result. This parameter 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 on, the logger automatically overrides 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 on, the logger automatically overrides 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 automatically overrides 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] The command line that is rerunning the test. If this parameter is NULL, DTM Logger tries to get the command line for the current process.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

EndTest returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::EndTestEx
CWTTLogger::StartTest
CWTTLogger::EndTestWithResID


CWTTLogger::EndTestEx Method

The EndTestEx method traces the end of a test case and enables you to specify a GUID-based test ID and a test hierarchy.

Syntax

HRESULT EndTestEx(
    DWORD dwResult,
    LPWSTR pwszTUID,
    LPWSTR pwszTestName,
    LPWSTR pwszParentTUID,
    LPWSTR pwszParentTestName,
    LONG hDevice
);

Parameters

dwResult

[in] The test case result. This parameter 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 on, the logger automatically overrides 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 on, the logger automatically overrides 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 automatically overrides 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] The globally unique identifier (GUID) for the test case.

pwszTestName

[in] The name of the test case.

pwszParentTUID

[in] The GUID for the parent test case.

pwszParentTestName

[in] The name of the parent test case.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

EndTestEx returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

The following code example demonstrates how to use the EndTestEx method.

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 test case 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
);

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::EndTest
CWTTLogger::StartTestEx


CWTTLogger::EndTestWithResID Method

The EndTestWithResID method traces the end of a test case by using the specified resource ID.

Syntax

HRESULT EndTestWithResID(
    UINT uiResID,
    DWORD dwResult,
    LPWSTR pwszRepro,
    LONG hDevice
);

Parameters

uiResID

[in] The identifier (ID) of the resource.

dwResult

[in] The test case result. This parameter 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 on, the logger automatically overrides 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 on, the logger automatically overrides 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 automatically overrides 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] The command line for the result.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

EndTestWithResID returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::EndTest
CWTTLogger::StartTestWithResID


CWTTLogger::GetContext Method

The GetContext method retrieves the current context of the logger object.

Syntax

HRESULT GetContext(
    LPWSTR pwszContext,
    LPWSTR pwszParentContext
);

Parameters

pwszContext

[in] The current context of the logger object.

pwszParentContext

[in] The parent context of the logger object.

Return Value

GetContext returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::ClearContext
CWTTLogger::SetContext


CWTTLogger::GetPFRollupStats Method

The GetPFRollupStats method retrieves the current pass-fail statistics.

Syntax

HRESULT GetPFRollupStats(
    PWTTLOGROLLUPINFO pWTTPFStats
);

Parameters

pWTTPFStats

[in] A pointer to a structure that contains the pass-fail 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

GetPFRollupStats returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

To retrieve the current pass-fail statistics, you must create an empty structure, as defined in the pWTTPFStats parameter, and call the GetPFRollupStats method. GetPFRollupStats passes DTM Logger a pointer the structure, and then DTM Logger populates the structure.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)


CWTTLogger::RemoveErrorFromErrorList Method

The RemoveErrorFromErrorList method deletes the specified error from a list of known errors.

Syntax

HRESULT RemoveErrorFromErrorList(
    DWORD dwErrorToRemove,
    DWORD dwErrorType,
    DWORD dwErrorList
);

Parameters

dwErrorToRemove

[in] The error code to remove.

dwErrorType

[in] The type of the error. This parameter can be one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

dwErrorList

[in] The error list to remove the error from. This parameter can be one of the following values: WTT_ERROR_LIST_EXPECTEDWTT_ERROR_LIST_BREAKON

Return Value

RemoveErrorFromErrorList returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

See Also

CWTTLogger Class (C++)
CWTTLogger::AddErrorToErrorList
CWTTLogger::ClearErrorList


CWTTLogger::SetContext Method

The SetContext method sets the current context of the logger object for all subsequent traces.

Syntax

HRESULT SetContext(
    LPWSTR pwszCurrentContext,
    LPWSTR pwszParentContext
);

Parameters

pwszCurrentContext

[in] The current context of the logger object.

pwszParentContext

[in] The parent context of the logger object.

Return Value

SetContext returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::ClearContext
CWTTLogger::GetContext


CWTTLogger::SetDeviceOption Method

The SetDeviceOption method sets the given options for the specified device.

Syntax

HRESULT SetDeviceOption(
    LONG hDevice,
    LPWSTR pwszDeviceName,
    LPWSTR pwszDeviceOptions
);

Parameters

hDevice

[in] The handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

pwszDeviceName

[in] The name of the device.

pwszDeviceOptions

[in] A string that contains the options to set.

Return Value

SetDeviceOption returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::SetDeviceTraceLevel
CWTTLogger::SetDeviceTracePriority


CWTTLogger::SetDeviceTraceLevel Method

The SetDeviceTraceLevel method sets the specified device trace level for all subsequent traces.

Syntax

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-defined message. This type of trace 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 trace causes the logger (in the usermode) 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 trace 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 trace 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 trace 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 trace 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 trace 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. This trace does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This trace does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This trace marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This trace 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, your plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that you provide and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

SetDeviceTraceLevel returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::EnableTraceLevels
CWTTLogger::DisableTraceLevels
CWTTLogger::SetDeviceTracePriority


CWTTLogger::SetDeviceTracePriority Method

The SetDeviceTracePriority method sets the specified device trace priority for all subsequent traces.

Syntax

HRESULT SetDeviceTracePriority(
    DWORD dwTracePri,
    LONG hDevice
);

Parameters

dwTracePri

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

SetDeviceTracePriority returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::SetDeviceTraceLevel


CWTTLogger::StartTest Method

The StartTest method traces the start of a test case.

Syntax

HRESULT StartTest(
    LPWSTR pwszTestName,
    LONG hDevice
);

Parameters

pwszTestName

[in] The name of the test case.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

StartTest returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::EndTest
CWTTLogger::StartTestEx
CWTTLogger::StartTestWithResID


CWTTLogger::StartTestEx Method

The StartTestEx method traces the start of a test case and enables you to specify a GUID-based test ID and a test hierarchy.

Syntax

HRESULT StartTestEx(
    LPWSTR pwszTUID,
    LPWSTR pwszTestName,
    DWORD dwTestType,
    LPWSTR pwszParentTUID,
    LPWSTR pwszParentTestName,
    LONG hDevice
);

Parameters

pwszTUID

[in] A globally unique identifier (GUID) for the test case.

pwszTestName

[in] The name of the test case.

dwTestType

[in] The type of the test case. This parameter can be one of the following values: WTTLOG_TESTCASE_TYPE_NOPARENTWTTLOG_TESTCASE_TYPE_ISCHILDWTTLOG_TESTCASE_TYPE_ISSIBLINGWTTLOG_TESTCASE_TYPE_SPECIFYPARENT

pwszParentTUID

[in] The GUID for the parent test.

pwszParentTestName

[in] Te name of the parent test.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

StartTestEx returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

The following code example demonstrates how to use the StartTestEx method.

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 test case 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
);

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::EndTestEx
CWTTLogger::StartTest


CWTTLogger::StartTestWithResID Method

The StartTestWithResID method traces the start of a test case by using the specified resource ID.

Syntax

HRESULT StartTestWithResID(
    UINT uiResID,
    LONG hDevice
);

Parameters

uiResID

[in] The identifier of the resource.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

StartTestWithResID returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::StartTest
CWTTLogger::EndTestWithResID


CWTTLogger::Trace Method

The Trace method logs a trace of the specified device at the given trace level.

Syntax

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 trace 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 trace 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 trace 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 trace 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 trace 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 trace 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 trace 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. This trace does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This trace does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This trace marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This trace 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, your plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that the user provides and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

...

[in] One or more optional arguments that depend on the trace level that you specify in the dwLevel parameter. For information about the arguments that are required for each trace Level, see Trace level.

Return Value

Trace returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::UserDefinedTrace
CWTTLogger::TraceV
CWTTLogger::TraceEx
CWTTLogger::TraceMsg


CWTTLogger::TraceEx Method

The TraceEx method logs a trace of the specified device at the given trace level by using an XML-formatted data string.

Syntax

HRESULT TraceEx(
    DWORD dwLevel,
    DWORD dwPriority,
    LONG hDevice,
    LPWSTR pwszUserXML,
     ...
);

Parameters

dwLevel

[in] The trace level. This parameter should be one of the following values:

WTT_LVL_MSG

Trace a user-define message. This trace 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 trace 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 trace 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 trace 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 trace 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 trace 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 trace 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. This trace does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This trace does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This trace marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This trace 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, your plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that the user provides and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

pwszUserXML

[in] An XML-formatted string that you define.

...

[in] One or more optional arguments that depend on the trace level specified in the dwLevel parameter. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

TraceEx returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::Trace
CWTTLogger::TraceExV


CWTTLogger::TraceExV Method

The TraceExV method logs a trace of the specified device at the given trace level by using an XML-formatted data string and a prepared argument list.

Syntax

HRESULT TraceExV(
    DWORD dwLevel,
    DWORD dwPriority,
    LONG hDevice,
    LPWSTR pwszUserXML,
    va_list VarArgs
);

Parameters

dwLevel

[in] The trace level. This parameter should be one of the following values:

WTT_LVL_MSG

Trace a user-define message. This trace 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 trace 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 trace 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 trace 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 trace 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 trace 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 trace 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. This trace does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This trace does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This trace marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This trace 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, your plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that the user provides and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

pwszUserXML

[in] An XML-formatted string that you define.

VarArgs

[in] A prepared list of variable arguments as required for the specified trace level. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

TraceExV returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::Trace
CWTTLogger::TraceEx


CWTTLogger::TraceMachineInfo Method

The TraceMachineInfo method logs a trace of the operating system where the test is run.

Syntax

HRESULT TraceMachineInfo(
    LONG hDevice,
    LPWSTR pwszUserDefinedData
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

pwszUserDefinedData

[in] User-defined data. This parameter is ignored in the current version of DTM Logger.

Return Value

TraceMachineInfo returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

The following code example demonstrates how to use the TraceMachineInfo method.

//
//  Collect machine information
//

Log.TraceMachineInfo (
hDevice,
NULL
);

Requirements

Header | Wttlogger.h
Library | Library:WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::Trace


CWTTLogger::TraceMsg Method

The TraceMsg method logs a trace of the specified device at the user-defined trace level and a given priority.

Syntax

HRESULT TraceMsg(
    LONG hDevice,
    LPWSTR pwszUserDefinedLevel,
    DWORD dwPriority,
     ...
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

pwszUserDefinedLevel

[in] A user-defined trace level.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

...

[in] One or more optional arguments that depend on the user-defined trace level.

Return Value

TraceMsg returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::Trace
CWTTLogger::TraceMsg


CWTTLogger::TraceMsgV Method

The TraceMsgV method logs a trace of the specified device at the user-defined trace level and a given priority by using a prepared argument list.

Syntax

HRESULT TraceMsgV(
    LONG hDevice,
    LPWSTR pwszUserDefinedLevel,
    DWORD dwPriority,
    va_list VarArgs
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

pwszUserDefinedLevel

[in] A user-defined trace level.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

VarArgs

[in] A prepared list of variable arguments as required for the specified trace level. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

TraceMsgV returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::Trace
CWTTLogger::TraceMsg


CWTTLogger::TraceV Method

The TraceV method logs a trace of the specified device at the given trace level by using a prepared argument list.

Syntax

HRESULT TraceV(
    DWORD dwLevel,
    LONG hDevice,
    va_list VarArgs
);

Parameters

dwLevel

[in] The trace level. This parameter should be one of the following values:

WTT_LVL_MSG

Trace a user-define message. This trace 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 trace 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 trace 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 trace 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 trace 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 trace 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 trace 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. This trace does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This trace does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This trace marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This trace 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, your plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that the user provides and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles b using the bitwise OR operator (for example, hDevice1 OR hDevice2).

VarArgs

[in] A prepared list of variable arguments as required for the specified trace level. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

TraceV returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

The TraceV method is similar to the Trace method, except that TraceV takes a prepared variable argument list as its third variable.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::Trace
CWTTLogger::TraceEx


CWTTLogger::UserDefinedTrace Method

The UserDefinedTrace method logs trace data by using a user-defined trace level.

Syntax

HRESULT UserDefinedTrace(
    LPCWSTR pcwszUserLevel,
    LONG hDevice,
    DWORD dwBaseLevel,
    DWORD dwPriority,
     ...
);

Parameters

pcwszUserLevel

[in] A user-defined trace level.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

dwBaseLevel

[in] The base trace level. This parameter should be one of the following values:

WTT_LVL_MSG

Trace a user-define message. This trace 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 trace 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 trace 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 trace 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 trace 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 trace 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 trace 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. This trace does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This trace does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This trace marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This trace 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, your plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that the user provides and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

...

[in] One or more optional arguments that depend on the trace level that is specified in the dwBaseLevel parameter. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

UserDefinedTrace returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

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".

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::Trace
CWTTLogger::UserDefinedTraceV
CWTTLogger::UserDefinedTraceEx


CWTTLogger::UserDefinedTraceEx Method

The UserDefinedTraceEx method logs trace data by using a user-defined trace level and an XML-formatted data string.

Syntax

HRESULT UserDefinedTraceEx(
    LPCWSTR pcwszUserLevel,
    LONG hDevice,
    DWORD dwBaseLevel,
    DWORD dwPriority,
    LPWSTR pwszUserXML,
     ...
);

Parameters

pcwszUserLevel

[in] A user-defined trace level.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

dwBaseLevel

[in] Thebase trace level. This parameter should be one of the following values:

WTT_LVL_MSG

Trace a user-define message. This trace 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 trace 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 trace 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 trace 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 trace 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 trace 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 trace 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. This trace does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This trace does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This trace marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This trace 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, your plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that the user provides and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

pwszUserXML

[in] An XML-formatted string that you define.

...

[in] One or more optional arguments that depend on the trace level that is specified in the dwBaseLevel parameter. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

UserDefinedTraceEx returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

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".

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

CWTTLogger Class
CWTTLogger::UserDefinedTrace
CWTTLogger::UserDefinedTraceExV


CWTTLogger::UserDefinedTraceExV Method

The UserDefinedTraceExV method logs trace data by using a user-defined trace level and an XML-formatted data string.

Syntax

HRESULT UserDefinedTraceExV(
    LPCWSTR pcwszUserLevel,
    LONG hDevice,
    DWORD dwBaseLevel,
    DWORD dwPriority,
    LPWSTR pwszUserXML,
    va_list VarArgs
);

Parameters

pcwszUserLevel

[in] A user-defined trace level.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

dwBaseLevel

[in] The base trace level. This parameter should be one of the following values:

WTT_LVL_MSG

Trace a user-define message. This trace 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 trace 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 trace 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 trace 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 trace 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 trace 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 trace 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. This trace does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This trace does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This trace marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This trace 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, your plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that the user provides and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

pwszUserXML

[in] An XML-formatted string that you define.

VarArgs

[in] A prepared list of variable arguments as required for the specified trace level. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

UserDefinedTraceExV returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

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".

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::UserDefinedTraceV
CWTTLogger::UserDefinedTraceEx


CWTTLogger::UserDefinedTraceV Method

The UserDefinedTraceV method logs trace data by using a user-defined trace level and a prepared argument list.

Syntax

HRESULT UserDefinedTraceV(
    LPCWSTR pcwszUserLevel,
    LONG hDevice,
    DWORD dwBaseLevel,
    DWORD dwPriority,
    va_list VarArgs
);

Parameters

pcwszUserLevel

[in] A user-defined trace level.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator(for example, hDevice1 OR hDevice2).

dwBaseLevel

[in] The base trace level. This parameter should be one of the following values:

WTT_LVL_MSG

Trace a user-define message. This trace 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 trace 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 trace 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 trace 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 trace 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 trace 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 trace 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. This trace does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This trace does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This trace marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This trace 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, your plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that the user provides and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

VarArgs

[in] A prepared list of variable arguments as required for the specified trace level. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

UserDefinedTraceV returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

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".

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

CWTTLogger Class (C++)
CWTTLogger::UserDefinedTrace
CWTTLogger::UserDefinedTraceEx


IWTTLog Interface (COM)

The IWTTLog interface implements a COM interface for logging messages and errors.

IWTTLog contains the following public methods.

Method | Description
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 you specifically declare 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 that the device string or the handle specify.
CreateLogDevice | Creates a log device topology according to the device string.
EndTest | Traces the end of a test case, clears the current test case context, and sets it to the parent context.
EndTestEx | Traces the end of a test case and enables you 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 enables you 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 by using a user-defined trace level.

Requirements

IDL file: Log.idl

Library: WTTLogCM.dll

See Also

CWTTLogger Class (C++), WTTLog Functions (C)


IWTTLog::AddErrorToErrorList Method

The AddErrorToErrorList method adds the specified error type and error code to the given list of known errors.

Syntax

HRESULT AddErrorToErrorList(
    DWORD dwErrorToAdd,
    WTTLOGGER_ERROR_TYPE dwErrorType,
    WTTLOGGER_ERROR_LIST dwErrorList
);

Parameters

dwErrorToAdd

[in] The error code to add.

dwErrorType

[in] The type of the error. This parameter can be one of the following values: WTTLOG_ERROR_TYPE_HRESULTWTTLOG_ERROR_TYPE_NTSTATUSWTTLOG_ERROR_TYPE_WIN32WTTLOG_ERROR_TYPE_BOOL

dwErrorList

WTTLOGGER_ERROR_LIST

[in] The list to which the error will be added. This parameter can be one of the following values: WTTLOG_ERROR_LIST_EXPECTEDWTTLOG_ERROR_LIST_BREAKON

Return Value

AddErrorToErrorList returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

DTM Logger uses the error lists to enable a test to pass even though the return value from a test function is an error. The CheckResult method compares the error type and error code that is 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.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::RemoveErrorFromErrorList
IWTTLog::ClearErrorList


IWTTLog::Assert Method

The Assert method 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.

Syntax

HRESULT Assert(
    VARIANT_BOOL fCondition,
    BSTR bstrFile,
    UINT uiLine,
    BSTR bstrAssertMsg,
    LONG hDevice
);

Parameters

fCondition

[in] A Boolean value that specifies whether the method should prevent the test case from failing if the bug trace is not logged. If this parameter is true, Assert prevents the test case from failing if the bug trace is not logged. If this parameter is false, Assert fails the test case unless the bug trace is logged.

bstrFile

[in] The name of the source file where the assert happened.

uiLine

[in] The line number within the source file where the assert happened.

bstrAssertMsg

[in] The text message of the assertion.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator(for example, hDevice1 OR hDevice2).

Return Value

Assert returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::Trace


IWTTLog::CheckResult Method

The CheckResult method checks a specified result and logs an error if the result shows a failure.

Syntax

HRESULT CheckResult(
    DWORD dwResultToCheck,
    WTTLOGGER_ERROR_TYPE dwResultType,
    BSTR bstrFile,
    UINT uiLine,
    BSTR bstrErrMsg,
    LONG hDevice
);

Parameters

dwResultToCheck

[in] The result to check.

dwResultType

[in] The type of the result. This parameter can be one of the following values: WTTLOG_ERROR_TYPE_HRESULTWTTLOG_ERROR_TYPE_NTSTATUSWTTLOG_ERROR_TYPE_WIN32WTTLOG_ERROR_TYPE_BOOL

bstrFile

[in] The name of the source file where the assert happened.

uiLine

[in] The line number within the source file where the assert happened.

bstrErrMsg

[in] The text of the error message.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

CheckResult returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::CheckResultEx


IWTTLog::CheckResultEx Method

The CheckResultEx method checks a specified result against a target result and logs an error if both the value and type match.

Syntax

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] The result to check.

dwResultType

[in] The type of the result. This parameter can be one of the following values: WTTLOG_ERROR_TYPE_HRESULTWTTLOG_ERROR_TYPE_NTSTATUSWTTLOG_ERROR_TYPE_WIN32WTTLOG_ERROR_TYPE_BOOL

dwTargetResult

[in] The target result to check the dwResultToCheck result against.

dwTargetType

[in] The type of the target result. This parameter can be one of the following values: WTTLOG_ERROR_TYPE_HRESULTWTTLOG_ERROR_TYPE_NTSTATUSWTTLOG_ERROR_TYPE_WIN32WTTLOG_ERROR_TYPE_BOOL

bstrFile

[in] The name of the source file where the assert happened.

uiLine

[in] The line number within the source file where the assert happened.

bstrErrMsg

[in] The text message for the error.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

CheckResultEx returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::CheckResult


IWTTLog::ClearErrorList Method

The ClearErrorList method removes all errors of the specified type from a given list of known errors.

Syntax

HRESULT ClearErrorList(
    WTTLOGGER_ERROR_TYPE dwErrorType,
    WTTLOGGER_ERROR_LIST dwErrorList
);

Parameters

dwErrorType

[in] The type of the error to remove. This parameter can be one of the following values: WTTLOG_ERROR_TYPE_HRESULTWTTLOG_ERROR_TYPE_NTSTATUSWTTLOG_ERROR_TYPE_WIN32WTTLOG_ERROR_TYPE_BOOL

dwErrorList

[in] The error list to clear. This parameter can be one of the following values: WTTLOG_ERROR_LIST_EXPECTEDWTTLOG_ERROR_LIST_BREAKON

Return Value

ClearErrorList returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::AddErrorToErrorList
IWTTLog::RemoveErrorFromErrorList


IWTTLog::CloseLogDevice Method

The CloseLogDevice method closes a log device topology that the device string or the handle specifies.

Syntax

HRESULT CloseLogDevice(
    BSTR bstrLogDeviceName,
    LONG hDevice
);

Parameters

bstrLogDeviceName

[in] A 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] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

CloseLogDevice returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

If a handle is specified in the hDevice parameter, the device string in the bstrLogDeviceName parameter is ignored.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)


IWTTLog::CreateLogDevice Method

The CreateLogDevice method creates a log device topology according to the device string.

Syntax

HRESULT CreateLogDevice(
    VARIANT vtDeviceStr,
    LONG* phDevice
);

Parameters

vtDeviceStr

[in] A 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] A pointer to a handle that represents the device tracing topology.

Return Value

CreateLogDevice returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::CloseLogDevice


IWTTLog::EndTest Method

The EndTest method traces the end of a test case, clears the current test case context, and sets it to the parent context.

Syntax

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 on, the logger will overrides 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 automatically overrides 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 overrides 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] A command line number for rerunning the test. If this parameter is NULL, DTM Logger tries to get the command line for the current process.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

EndTest returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::EndTestEx
IWTTLog::StartTest


IWTTLog::EndTestEx Method

The EndTestEx method traces the end of a test case and enables you to specify a GUID-based test ID and a test hierarchy.

Syntax

HRESULT EndTestEx(
    WTTLOGGER_TEST_RESULT dwResult,
    BSTR bstrTUID,
    BSTR bstrTestName,
    BSTR bstrParentTUID,
    BSTR bstrParentTestName,
    LONG hDevice
);

Parameters

dwResult

[in] The test case result. This parameter 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 on, the logger will overrides 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 automatically overrides 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 overrides 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] A globally unique identifier (GUID) for the test case.

bstrTestName

[in] The name of the test case.

bstrParentTUID

[in] A GUID for the parent test case.

bstrParentTestName

[in] The name of the parent test case.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

EndTestEx returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::EndTest
IWTTLog::StartTestEx


IWTTLog::GetCurrentContext Method

The GetCurrentContext method retrieves the current context of the logger object.

Syntax

HRESULT GetCurrentContext(
    BSTR pbstrCurrentContext
);

Parameters

pbstrCurrentContext

[out] The current context of the logger object.

Return Value

GetCurrentContext returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::SetContext


IWTTLog::RemoveErrorFromErrorList Method

The RemoveErrorFromErrorList method deletes the specified error from a list of known errors.

Syntax

HRESULT RemoveErrorFromErrorList(
    DWORD dwErrorToRemove,
    WTTLOGGER_ERROR_TYPE dwErrorType,
    WTTLOGGER_ERROR_LIST dwErrorList
);

Parameters

dwErrorToRemove

[in] The error code to remove.

dwErrorType

[in] The type of the error. This parameter can be one of the following values: WTTLOG_ERROR_TYPE_HRESULTWTTLOG_ERROR_TYPE_NTSTATUSWTTLOG_ERROR_TYPE_WIN32WTTLOG_ERROR_TYPE_BOOL

dwErrorList

[in] The error list to remove. This parameter can be one of the following values: WTTLOG_ERROR_LIST_EXPECTEDWTTLOG_ERROR_LIST_BREAKON

Return Value

RemoveErrorFromErrorList returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::AddErrorToErrorList
IWTTLog::ClearErrorList


IWTTLog::SetContext Method

The SetContext method sets the current context of the logger object for all subsequent traces.

Syntax

HRESULT SetContext(
    BSTR bstrContext,
    BSTR bstrParentCTX
);

Parameters

bstrContext

[in] The current context of the logger object.

bstrParentCTX

[in] The parent context of the logger object.

Return Value

SetContext returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)


IWTTLog::SetDeviceOption Method

The SetDeviceOption method sets the current context of the logger object for all subsequent traces.

Syntax

HRESULT SetDeviceOption(
    LONG hDevice,
    BSTR bstrDeviceName,
    BSTR bstrDeviceOptions
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2 ).

bstrDeviceName

[in] The name of the device.

bstrDeviceOptions

[in] A string that contains the device options to set.

Return Value

SetDeviceOption returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)


IWTTLog::StartTest Method

The StartTest method traces the start of a test case.

Syntax

HRESULT StartTest(
    BSTR bstrTestName,
    LONG hDevice
);

Parameters

bstrTestName

[in] The name of the test case.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

StartTest returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::EndTest
IWTTLog::StartTestEx


IWTTLog::StartTestEx Method

The StartTestEx method traces the start of a test case and enables you to specify a GUID-based test ID and a test hierarchy.

Syntax

HRESULT StartTestEx(
    BSTR bstrTUID,
    BSTR bstrTestName,
    DWORD dwTestType,
    BSTR bstrParentTUID,
    BSTR bstrParentTestName,
    LONG hDevice
);

Parameters

bstrTUID

[in] A globally unique identifier (GUID) for the test case.

bstrTestName

[in] The name of the test case.

dwTestType

[in] The type of the test case. This parameter can be one of the following values: WTTLOG_TESTCASE_TYPE_NOPARENTWTTLOG_TESTCASE_TYPE_ISCHILDWTTLOG_TESTCASE_TYPE_ISSIBLINGWTTLOG_TESTCASE_TYPE_SPECIFYPARENT

bstrParentTUID

[in] The GUID for the parent test.

bstrParentTestName

[in] The name of the parent test.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

StartTestEx returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL

 Log.IDL

See Also

IWTTLog Interface (COM)
IWTTLog::EndTestEx
IWTTLog::StartTest


IWTTLog::Trace Method

The Trace method logs a trace of the specified device at the given trace level.

Syntax

HRESULT Trace(
    WTTLOGGER_TRACE_LEVEL dwLevel,
    LONG hDevice,
    SAFEARRAY(VARIANT)* psaVarArgs
);

Parameters

dwLevel

[in] The trace level. This parameter should be one of the following values:

WTTLOG_LVL_MSG

Trace a user-define message. This trace 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 trace causes the logger (in the usermode) 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 trace 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 trace 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 trace 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 trace 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 trace 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. This trace does not affect the test case result.

WTTLOG_LVL_FUNCTION_EXIT

Trace the function exit point.This trace does not affect the test case result.

WTTLOG_LVL_START_TEST

Trace the start of a test case. This trace marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTTLOG_LVL_END_TEST

Trace the end of a test case. This trace 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, you should call the EndTest method instead of using this level.

WTTLOG_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTTLOG_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This trace does not affect the test case result

WTTLOG_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, your plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that you provide and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

psaVarArgs

[in] An array of variable arguments (VARARG) as required for the specified trace level. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

Trace returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)
IWTTLog::UserDefinedTrace


IWTTLog::TraceMachineInfo Method

The TraceMachineInfo method sets the given information about the specified trace computer.

Syntax

HRESULT TraceMachineInfo(
    BSTR bstrUserMachineInfo,
    LONG hDevice
);

Parameters

bstrUserMachineInfo

[in] A string that contains the computer information to set.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

TraceMachineInfo returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface (COM)


IWTTLog::UserDefinedTrace Method

The UserDefinedTrace method logs trace data by using a user-defined trace level.

Syntax

HRESULT UserDefinedTrace(
    BSTR bstrUserLevel,
    LONG hDevice,
    WTTLOGGER_TRACE_LEVEL dwBaseLevel,
    WTTLOGGER_TRACE_PRIORITY dwPriority,
    SAFEARRAY(VARIANT)* psaVarArgs
);

Parameters

bstrUserLevel

[in] A user-defined trace level.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

dwBaseLevel

[in] The base trace level. This parameter should be one of the following values:

WTTLOG_LVL_MSG

Trace a user-define message. This trace 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 trace 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 trace 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 trace 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 trace 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 trace 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 trace 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. This trace does not affect the test case result.

WTTLOG_LVL_FUNCTION_EXIT

Trace the function exit point.This trace does not affect the test case result.

WTTLOG_LVL_START_TEST

Trace the start of a test case. This trace marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTTLOG_LVL_END_TEST

Trace the end of a test case. This trace 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, you should call the EndTest method instead of using this level.

WTTLOG_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTTLOG_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This trace does not affect the test case result

WTTLOG_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, your plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that you provide and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTTLOG_TRACE_PRIORITY_HIGH_CLASSWTTLOG_TRACE_PRIORITY_MEDIUM_CLASSWTTLOG_TRACE_PRIORITY_LOW_CLASSWTTLOG_TRACE_PRIORITY_RESERVED_CLASSWTTLOG_TRACE_PRIORITY_USER_CLASS

psaVarArgs

[in] An array of variable arguments (VARARG) as required for the specified trace level. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

UserDefinedTrace returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

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".

Requirements

IDL | Log.IDL
Library | WTTLogCM.dll

See Also

IWTTLog Interface
IWTTLog::Trace


WTTLog Functions (C)

The following C functions represent an interface (IWTTLog) for logging messages and errors.

Function | Description
WTTLogAddErrorToErrorList | Adds 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 you specifically declare 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 that the device string or the handle specifies.
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 enables you 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 enables you 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 by using an XML-formatted data string.
WTTLogTraceMachineInfo | Sets the specified computer as the trace machine.
WTTLogUninit | Removes the DTM Logger DLL from memory.
WTTLogUserDefinedTrace | Logs trace data by using a user-defined trace level.
WTTLogUserDefinedTraceEx | Logs trace data by 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 Function

The WTTLogAddErrorToErrorList function adds the specified error type and error code to the given list of known errors.

Syntax

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 that dwErrorList specifies.

dwErrorType

[IN][DWORD] The type of the error. This parameter can be one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

dwErrorList

[IN][DWORD] - The list that the error will be added to. This parameter can be one of the following values: WTT_ERROR_LIST_EXPECTEDWTT_ERROR_LIST_BREAKON

Return Value

WTTLogAddErrorToErrorList returns an HRESULT value.

Remarks

DTM Logger uses error lists to enable 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 that are passed to it with the know errors on the list. If the error is on the list, WTTLogCheckResult returns S_OK, indicating that the test passed. If the error is not on the list, the test fails.

Requirements

Header | Wttlogger.h
Library | WTTLogCM.dll

See Also

WTTLogCheckResult


WTTLogAssert Function

The WTTLogAssert function checks the specified condition and, if the condition is false, fails the test case unless a trace is logged or you specifically declare the test case to be skipped.

Syntax

HRESULT WTTLogAssert(
    LONG hDevice,
    BOOL fCondition,
    LPWSTR pwszFile,
    UINT uiLine,
    LPWSTR pwszUserMsg
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

fCondition

[in] A Boolean value that specifies whether the function should prevent the test case from failing if the bug trace is not logged. If this parameter is true, the function prevents the test case from failing if the bug trace is not logged. If this parameter is false, the function fails the test case unless the bug trace is logged.

pwszFile

[in] The name of the source file where the assert happened.

uiLine

[in] The line number within the source file where the assert happened.

pwszUserMsg

[in] The text message of the assertion.

Return Value

WTTLogAssert returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogTrace


WTTLogCheckResult Function

The WTTLogCheckResult function checks a specified result and logs an error if the result shows a failure.

Syntax

HRESULT WTTLogCheckResult(
    LONG hDevice,
    DWORD dwResultToCheck,
    DWORD dwResultType,
    LPWSTR pwszFile,
    ULONG ulLine,
    LPWSTR pwszErrMsg
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

dwResultToCheck

[in] The result to check.

dwResultType

[in] The type of the result. This parameter can be one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

pwszFile

[in] The name of the source file where the assert happened.

ulLine

[in] The line number within the source file where the assert happened.

pwszErrMsg

[in] The text of the error message.

Return Value

WTTLogCheckResult returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogCheckResultEx


WTTLogCheckResultEx Function

The WTTLogCheckResultEx function checks a specified result against a target result and logs an error if both the value and type match.

Syntax

HRESULT WTTLogCheckResultEx(
    LONG hDevice,
    DWORD dwResultToCheck,
    DWORD dwResultType,
    DWORD dwTargetResult,
    DWORD dwTargetResultType,
    LPWSTR pwszFile,
    ULONG ulLine,
    LPWSTR pwszErrMsg
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

dwResultToCheck

[in] The result to check.

dwResultType

[in] The type of the result. This parameter can be one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

dwTargetResult

[in] The target result to check the dwResultToCheck result against.

dwTargetResultType

[in] The type of the target result. This parameter is one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

pwszFile

[in] The name of the source file where the assert happened.

ulLine

[in] Te line number within the source file where the assert happened.

pwszErrMsg

[in] The text message for the error.

Return Value

WTTLogCheckResultEx returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogCheckResult


WTTLogClearErrorList Function

The WTTLogClearErrorList function removes all errors of the specified type from a given list of known errors.

Syntax

HRESULT WTTLogClearErrorList(
    DWORD dwErrorList,
    DWORD dwErrorType
);

Parameters

dwErrorList

[in] The error list to clear. This parameter can be one of the following values: WTT_ERROR_LIST_EXPECTEDWTT_ERROR_LIST_BREAKON

dwErrorType

[in] The type of the error to remove. This parameter can be one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

Return Value

WTTLogClearErrorList returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogAddErrorToErrorList
WTTLogRemoveErrorFromErrorList


WTTLogCloseLogDevice Function

The WTTLogCloseLogDevice function closes a log device topology that the device string or the handle specifies.

Syntax

HRESULT WTTLogCloseLogDevice(
    LONG hDevice,
    LPWSTR pwszDeviceName
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

pwszDeviceName

[in] A 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

WTTLogCloseLogDevice returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogCreateLogDevice


WTTLogCreateLogDevice Function

The WTTLogCreateLogDevice function creates a log device topology according to the device string.

Syntax

HRESULT WTTLogCreateLogDevice(
    LPWSTR pwszDevStr,
    LONG* phDevice
);

Parameters

pwszDevStr

[in] A 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] A pointer to a handle that represents the device tracing topology.

Return Value

WTTLogCreateLogDevice returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogCloseLogDevice


WTTLogDisableTraceLevels Function

The WTTLogDisableTraceLevels function disables the specified set of device trace levels.

Syntax

HRESULT WTTLogDisableTraceLevels(
    LPWSTR pwszTraceLevels,
    LONG hDevice
);

Parameters

pwszTraceLevels

[in] A string that contains a list of trace levels to be disabled.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

WTTLogDisableTraceLevels returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogEnableTraceLevels


WTTLogEnableTraceLevels Function

The WTTLogEnableTraceLevels function enables the specified set of device trace levels.

Syntax

HRESULT WTTLogEnableTraceLevels(
    LPWSTR pwszTraceLevels,
    LONG hDevice
);

Parameters

pwszTraceLevels

[in] A string that contains a list of trace levels to be enabled.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

WTTLogEnableTraceLevels returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogDisableTraceLevels


WTTLogEndTest Function

The WTTLogEndTest function traces the end of a test case, clears the current test case context, and sets it to the parent context.

Syntax

HRESULT WTTLogEndTest(
    LONG hDevice,
    LPWSTR pwszTestName,
    DWORD dwResult,
    LPWSTR pwszRepro
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

pwszTestName

[in] The name of the test case.

dwResult

[in] The test case result. This parameter 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 on, the logger automatically overrides 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 on, the logger automatically overrides 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 automatically overrides 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] The command line for rerunning the test. If this parameter is NULL, DTM Logger tries to get the command line for the current process.

Return Value

WTTLogEndTest returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogEndTestEx
WTTLogStartTest


WTTLogEndTestEx Function

The WTTLogEndTestEx function traces the end of a test case and enables you to specify a GUID-based test ID and a test hierarchy.

Syntax

HRESULT WTTLogEndTestEx(
    LONG hDevice,
    DWORD dwResult,
    LPWSTR pwszTUID,
    LPWSTR pwszTestName,
    LPWSTR pwszParentTUID,
    LPWSTR pwszParentTestName
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

dwResult

[in] The test case result. This parameter 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 on, the logger automatically overrides 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 on, the logger automatically overrides 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 automatically overrides 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] The globally unique identifier (GUID) for the test case.

pwszTestName

[in] The name of the test case.

pwszParentTUID

[in] The GUID for the parent test case.

pwszParentTestName

[in] The name of the parent test case.

Return Value

WTTLogEndTestEx returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

The following code example shows how to use WTTLogEndTestEx.

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 test case 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
);

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogEndTest
WTTLogStartTestEx


WTTLogGetContext Function

The WTTLogGetContext function retrieves the current context of the logger object.

Syntax

HRESULT WTTLogGetContext(
    LPWSTR ppwszContext,
    LPWSTR ppwszParentContext
);

Parameters

ppwszContext

[in] The current context of the logger object.

ppwszParentContext

[in] The parent context of the logger object.

Return Value

WTTLogGetContext returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogSetContext


WTTLogGetPFRollupStats Function

The WTTLogGetPFRollupStats function retrieves the current pass-fail statistics.

Syntax

HRESULT WTTLogGetPFRollupStats(
    PWTTLOGROLLUPINFO pWTTPFStats
);

Parameters

pWTTPFStats

[in] A pointer to a structure that contains the pass-fail 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

WTTLogGetPFRollupStats returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

To retrieve the current pass-fail statistics, you must create an empty structure, as defined in the pWTTPFStats parameter, and call the WTTLogGetPFRollupStats function, which passes DTM Logger a pointer to the structure. DTM Logger will then populate the structure.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogPFRollup


WTTLogInit Function

The WTTLogInit function initializes the DTM Logger DLL.

Syntax

HRESULT WTTLogInit(
     None
);

Parameters

None

Return Value

WTTLogInit returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogUninit


WTTLogPFRollup Function

The WTTLogPFRollup function initializes the pass-fail statistics to the specified values.

Syntax

HRESULT WTTLogPFRollup(
    LONG hDevice,
    ULONG ulPassed,
    ULONG ulWarned,
    ULONG ulFailed,
    ULONG ulBlocked,
    ULONG ulSkipped
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

ulPassed

[in] The number of test cases that passed.

ulWarned

[in] The number of warnings.

ulFailed

[in] The number of tests cases that failed.

ulBlocked

[in] The number of test cases that were blocked.

ulSkipped

[in] The number of test cases that were skipped.

Return Value

WTTLogPFRollup returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogGetPFRollupStats


WTTLogRemoveErrorFromErrorList Function

The WTTLogRemoveErrorFromErrorList function deletes the specified error from a list of known errors.

Syntax

HRESULT WTTLogRemoveErrorFromErrorList(
    DWORD dwErrorToRemove,
    DWORD dwErrorType,
    DWORD dwErrorList
);

Parameters

dwErrorToRemove

[in] The error code to remove.

dwErrorType

[in] The type of the error. This parameter can be one of the following values: WTT_ERROR_TYPE_HRESULTWTT_ERROR_TYPE_NTSTATUSWTT_ERROR_TYPE_WIN32WTT_ERROR_TYPE_BOOL

dwErrorList

[in] The error list to remove. This parameter can be one of the following values: WTT_ERROR_LIST_EXPECTEDWTT_ERROR_LIST_BREAKON

Return Value

WTTLogRemoveErrorFromErrorList returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogAddErrorToErrorList
WTTLogClearErrorList


WTTLogSetContext Function

The WTTLogSetContext function sets the current context of the logger object for all subsequent traces.

Syntax

HRESULT WTTLogSetContext(
    LPWSTR pwszCurrentCTX,
    LPWSTR pwszParentCTX
);

Parameters

pwszCurrentCTX

[in] The current context of the logger object.

pwszParentCTX

[in] The parent context of the logger object.

Return Value

WTTLogSetContext returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogGetContext


WTTLogStartTest Function

The WTTLogStartTest function traces the start of a test case.

Syntax

HRESULT WTTLogStartTest(
    LONG hDevice,
    LPWSTR pwszTestName
);

Parameters

hDevice

[in] The name of the test case.

pwszTestName

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

This function can return one of the following values.

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogEndTest
WTTLogStartTestEx


WTTLogStartTestEx Function

The WTTLogStartTestEx function traces the start of a test case and enables you to specify a GUID-based test ID and a test hierarchy.

Syntax

HRESULT WTTLogStartTestEx(
    LONG hDevice,
    LPWSTR pwszTUID,
    LPWSTR pwszTestName,
    DWORD dwTestType,
    LPWSTR pwszParentTUID,
    LPWSTR pwszParentTestName
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

pwszTUID

[in] The globally unique identifier (GUID) for the test case.

pwszTestName

[in] The name of the test case.

dwTestType

[in] The type of the test case. This parameter can be one of the following values: WTTLOG_TESTCASE_TYPE_NOPARENTWTTLOG_TESTCASE_TYPE_ISCHILDWTTLOG_TESTCASE_TYPE_ISSIBLINGWTTLOG_TESTCASE_TYPE_SPECIFYPARENT

pwszParentTUID

[in] The GUID for the parent test.

pwszParentTestName

[in] The name of the parent test.

Return Value

This function can return one of the following values.

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

The following code example shows how to use WTTLogStartTestEx.

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 test case 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
);

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogEndTestEx
WTTLogStartTest


WTTLogTrace Function

The WTTLogTrace function logs a trace of the specified device at the given trace level.

Syntax

HRESULT WTTLogTrace(
    DWORD dwTraceLvl,
    LONG hDevice,
     ...
);

Parameters

dwTraceLvl

[in] The trace level. This parameter should be one of the following values:

WTT_LVL_MSG

Trace a user-define message. This trace 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 trace causes the logger (in the usermode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_ASSERT

Trace an assertion. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_INVALID_PARAM

Trace an invalid parameter. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_BUG

Trace a known bug. This trace causes the logger (in the user mode) to log a test case as blocked, unless you declare the test case as skipped.

WTT_LVL_BREAK

Trace a debug break. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_WARN

Trace a warning message. This trace causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or you declare the test case as skipped.

WTT_LVL_FUNCTION_ENTRY

Trace the function entry point. This value does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This value does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This value marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This value 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that you provide and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

...

[in] One or more optional arguments that depend on the trace level that is specified in the dwTraceLvl parameter. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

WTTLogTrace returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogUserDefinedTraceEx
WTTLogTraceEx


WTTLogTraceEx Function

The WTTLogTraceEx function logs a trace of the specified device at the given trace level by using an XML-formatted data string.

Syntax

HRESULT WTTLogTraceEx(
    DWORD dwLevel,
    DWORD dwPriority,
    LONG hDevice,
    LPWSTR pwszUserXML,
     ...
);

Parameters

dwLevel

[in] The trace level. This parameter should be one of the following values:

WTT_LVL_MSG

Trace a user-define message. This trace 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 trace causes the logger (in the usermode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_ASSERT

Trace an assertion. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_INVALID_PARAM

Trace an invalid parameter. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_BUG

Trace a known bug. This trace causes the logger (in the user mode) to log a test case as blocked, unless you declare the test case as skipped.

WTT_LVL_BREAK

Trace a debug break. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_WARN

Trace a warning message. This trace causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or you declare the test case as skipped.

WTT_LVL_FUNCTION_ENTRY

Trace the function entry point. This value does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This value does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This value marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This value 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that you provide and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

pwszUserXML

[in] An XML-formatted string that you define.

...

[in] One or more optional arguments that depend on the trace level that is specified in the dwLevel parameter. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

WTTLogTraceEx returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogTrace


WTTLogTraceMachineInfo Function

The WTTLogTraceMachineInfo function sets the specified computer as the trace machine.

Syntax

HRESULT WTTLogTraceMachineInfo(
    LONG hDevice
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

Return Value

WTTLogTraceMachineInfo returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogTrace


WTTLogUninit Function

The WTTLogUninit function removes the DTM Logger DLL from memory.

Syntax

void WTTLogUninit(
     None
);

Parameters

None

Return Value

None

Remarks

If the WTTLogUninit function is not called, the results will not roll up into DTM Studio.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogInit


WTTLogUserDefinedTrace Function

The WTTLogUserDefinedTrace function logs trace data by using a user-defined trace level and the specified priority.

Syntax

HRESULT WTTLogUserDefinedTrace(
    LONG hDevice,
    LPCWSTR pwszUserLevel,
    DWORD dwBaseLevel,
    DWORD dwPriority,
     ...
);

Parameters

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

pwszUserLevel

[in] A user-defined trace level.

dwBaseLevel

[in] A base trace level. This parameter should be one of the following values:

WTT_LVL_MSG

Trace a user-define message. This trace 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 trace causes the logger (in the usermode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_ASSERT

Trace an assertion. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_INVALID_PARAM

Trace an invalid parameter. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_BUG

Trace a known bug. This trace causes the logger (in the user mode) to log a test case as blocked, unless you declare the test case as skipped.

WTT_LVL_BREAK

Trace a debug break. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_WARN

Trace a warning message. This trace causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or you declare the test case as skipped.

WTT_LVL_FUNCTION_ENTRY

Trace the function entry point. This value does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This value does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This value marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This value 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that you provide and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

...

[in] One or more optional arguments that depend on the trace level that is specified in the pwszUserLevel parameter. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

WTTLogUserDefinedTrace returns one of the following values:

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Remarks

User-defined trace levels must be enabled for them to be traced in the log. You can enable custom trace levels on a device by using a device string, such as "$LogFile:EnableLvl=MyTrace".

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogUserDefinedTraceEx


WTTLogUserDefinedTraceEx Function

The WTTLogUserDefinedTraceEx function logs trace data by using a user-defined trace level and an XML-formatted data string.

Syntax

HRESULT WTTLogUserDefinedTraceEx(
    LPCWSTR pcwszUserLevel,
    LONG hDevice,
    DWORD dwBaseLevel,
    DWORD dwPriority,
    LPWSTR pwszUserXML,
     ...
);

Parameters

pcwszUserLevel

[in] A user-defined trace level.

hDevice

[in] A handle to the device tracing topology. You can combine multiple handles by using the bitwise OR operator (for example, hDevice1 OR hDevice2).

dwBaseLevel

[in] A base trace level. This parameter should be one of the following values:

WTT_LVL_MSG

Trace a user-define message. This trace 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 trace causes the logger (in the usermode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_ASSERT

Trace an assertion. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_INVALID_PARAM

Trace an invalid parameter. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_BUG

Trace a known bug. This trace causes the logger (in the user mode) to log a test case as blocked, unless you declare the test case as skipped.

WTT_LVL_BREAK

Trace a debug break. This trace causes the logger (in the user mode) to fail a test case unless a bug trace is logged or you declare the test case as skipped.

WTT_LVL_WARN

Trace a warning message. This trace causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or you declare the test case as skipped.

WTT_LVL_FUNCTION_ENTRY

Trace the function entry point. This value does not affect the test case result.

WTT_LVL_FUNCTION_EXIT

Trace the function exit point. This value does not affect the test case result.

WTT_LVL_START_TEST

Trace the start of a test case. This value marks the beginning of a test case and sets a new context whose name is the current test case name. However, you should call the StartTest method instead of using this level.

WTT_LVL_END_TEST

Trace the end of a test case. This value 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, you should call the EndTest method instead of using this level.

WTT_LVL_TCMINFO

Sets the Tactics fields. This value does not affect the test case result.

WTT_LVL_MACHINEINFO

Sets machine-related test case fields for Tactics. This value does not affect the test case result

WTT_LVL_ROLLUP

Trace the test suite roll-up information. If the pass-fail mode is set to user, the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters that you provide and use its internal counts. However, this value does not cause DTM to perform a rollup operation.

dwPriority

[in] The priority of the trace. This parameter should be one of the following values: WTT_TRACE_PRIORITY_HIGH_CLASSWTT_TRACE_PRIORITY_MEDIUM_CLASSWTT_TRACE_PRIORITY_LOW_CLASSWTT_TRACE_PRIORITY_RESERVED_CLASSWTT_TRACE_PRIORITY_USER_CLASS

pwszUserXML

[in] An XML-formatted string that you define.

...

[in] One or more optional arguments that depend on the trace level that is specified in the pcwszUserLevel parameter. For information about the arguments that are required for each trace level, see Trace Level.

Return Value

This function can return one of the following values.

Return code Description
S_OK

The operation was successful.
S_FALSE

The operation was successful but the last device has been detached, which has triggered a rollup.
HRESULT

The operation failed. You should use the FAILED macro to check HRESULT values.

Requirements

Header | Wttlogger.h
Library | WTTLog.dll

See Also

WTTLog Functions (C)
WTTLogUserDefinedTrace


Macros for Error Handling

Use HRESULT macros and functions for error handling.

The error handling macros are described in the following table.

Macro | Description
SUCCEEDED | Tests the severity bit of the SCODE or HRESULT. This macro returns TRUE if the severity is zero and FALSE if it is one.
FAILED | Tests the severity bit of the SCODE or HRESULT. This macro returns TRUE if the severity is one and FALSE if it is zero.


SUCCEEDED

The SUCCEEDED macro provides a generic test for success on any status value. Non-negative numbers indicate success.

#define SUCCEEDED(Status) ((HRESULT)(Status) >= 0)

Requirements

Header

 Winerror.h (include IncludeWinerror.h)


FAILED

The FAILED macro provides a generic test for failure on any status value. Negative numbers indicate failure.

#define FAILED(Status) ((HRESULT)(Status) < 0)

Requirements

Header

 Winerror.h (include Winerror.h)


Using DTM from a Command Line

Note Non-logo use is unsupported.

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 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

Remarks

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

Remarks

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

Remarks

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

Remarks

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

Remarks

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

Remarks

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

Remarks

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

Remarks

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"

Remarks

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

Remarks

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

Remarks

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, as discussed in the following topics.

Best Practices for Logo Testing and Avoiding Test Failures

Audio Device Testing

Communicaton Testing

Bus and Controller Testing

Display Testing

Game Devices Testing

Imaging Testing

Input Testing

Network Controller Testing

Network Media Device Testing

Terminal Server PNP Redirection Testing Overview

Portable Media Devices Testing Overview

Printer Testing Overview

Storage Testing

Streaming Media and Broadcast Testing

System Test Categories

Windows Server 2008 R2 System Testing Overview

Unclassified Signature Testing Overview

Device Fundamental Tests

Device Installation Tests

Kernel-Mode Driver Tests

Supplemental Tests

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.


Device Fundamental Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Common Scenario Stress with IO

Type: Automated Test

Overview

The Common Scenario Stress with IO job ensures that the device that you are testing accepts and correctly handles numerous Plug and Play (PnP) and power management state change scenarios, including disable/enable and suspend/hibernate/wake scenarios. Additionally, this job ensures that the device is still functional after these state changes 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 that you are testing through its service name or device instance identifier (ID). Additionally, the underlying scenario can run only disable/enable scenarios on disableable devices. A disableable device is a device that has the Disable option available in Windows 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.

If the driver is a UMDF driver, then AppVerifier will be enabled on the host process for the following checks:

  • Handles
  • Locks
  • Memory
  • Exceptions
  • TLS

UMDF Object tracking will be enabled for the UMDF driver. If there is a UMDF object leak, then a DriverStop will occur. You can use UMDF debugger extension !wudfext.dumpobjects <objecttrackeraddress> to analyze the problem.

For KMDF drivers, WDF Verifier will be enabled along with KMDF Enhanced Verifier and KMDF Handle Tracking for all objects.

Run Time: 3 hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running Common Scenario Stress with IO

Prerequisite Before you can run the Common Scenario Stress with IO job, you must install the device and driver on the test client computer. Next, install and configure Driver Test Manager (DTM).

To run Common Scenario Stress with IO, do the following:

  1. Open DTM Studio.

  2. 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.

  3. 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 on.

  4. In the Available Jobs pane, click the Common Scenario Stress with IO job.

  5. 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.

  6. Click Schedule Jobs.

  7. 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.

Troubleshooting

The underlying scenario is based on the new Microsoft Windows Device Testing Framework (WDTF). The Windows Driver Kit (WDK) contains extensive documentation about using and extending this framework in your own driver development process. For more information, search the WDK documentation for "Windows Device Testing Framework". For details about the specific operation of this scenario, open the WDK documentation, expand Windows Driver Kit, expand Other Tools, expand Windows Device Testing Framework, and click Automated Scenarios.

You may receive an error message similar to the following: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid." This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

  • For redundant network paths, add an additional NIC connected to the network.

Some machines will go into standby mode at the end of the test on Windows XP. If this occurs, you must wake the machine manually to complete the test. This is acceptable for Logo submission. If automation is required, you can wake the system by calling PoSetSystemState(ES_USER_PRESENT) from kernel mode.


Concurrent Hardware And OS Test (CHAOS)

Type: Automated Test

Overview

This is a stress test that is designed to help find concurrency issues in device drivers that may arise when Pnp, I/O and Power operations are sent at the same time. To test these concurrency issues, this test runs pnpdtest, devpathexer, and pwrtest in parallel.

Details

This test runs the Pnpdtest, DevicePathExerciser, and pwrtest in parallel with the below parameters.

Pnpdtest: /concurrentio /timedstress 10

Devpathexer: /hct

Pwrtest: /sleep /c:4 /d:300 /s:all

For more details on each of these individual tests, please refer to the WDK documentation for each of these tools.

If the driver is a UMDF driver, then AppVerifier will be enabled on the host process for the following checks:

  • Handles
  • Locks
  • Memory
  • Exceptions
  • TLS

UMDF Object tracking will be enabled for the UMDF driver. If there is a UMDF object leak, then a DriverStop will occur. You can use UMDF debugger extension !wudfext.dumpobjects <objecttrackeraddress> to analyze the problem.

For KMDF drivers, WDF Verifier will be enabled along with KMDF Enhanced Verifier and KMDF Handle Tracking for all objects.

Run Time: Approximately 1 hour
Log File: pnpdtest-log.txt, dc2.log, Pwrtestlog.xml
System Restart Required: No
Test Category: Stress, Integration, Security

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program: devpathexer.exe, pnpdtest.exe, pwrtst.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running Concurrent Hardware And OS Test (CHAOS)

This test is a stress type test that will try to exercise the integration scenarios between Pnp, Power and I/O, and runs devpathexer, pnpdtest and pwrtest in parallel. Each of these tests generate log files which can be reviewed to find specific details about failures. Details about these log files are documented in the WDK.

Command Syntax

N/A. This tool does not have a command line version. However, since this launches 3 other test tools with the arguments listed above, they can be run simultaneously from the command line to achieve the same effect as this test.

Code Tour

File Manifest

File | Location
Test.exe | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\
Pnpdtest.exe | [osbinroot]\pnp\pnpd2\
Devpathexer.exe | [osbinroot]\devpathexer2\
Pwrtest.exe | [osbinroot]\pwrtest\


Device Install Check for Other Device Stability

Type: Automated Test

Overview

This test verifies that no device or driver, except the device under test, has been affected by the device(s)/driver(s) install OR co-install process.

Details

No driver or device installs or co-installs are permitted to affect other drivers and/or their functionality in any way.

Run Time: 30 minutes
Log File: DeviceScan.wtl
System Restart Required: No
Test Category: Device Fundamental
Program: DeviceScan

Requirements

Software Requirements

Device Install Check for Other Device Stability test will run on the following Windows operating systems:

  • Windows 7

  • Software components included with the device that is being tested

Hardware Requirements

Device Install Check for Other Device Stability test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

Device Install Check for Other Device Stability test tool runs on the following processor architectures:

  • x86

  • amd64

Running Device Install Check for Other Device Stability

  1. Runs DeviceScan.exe with data acquisition mode.

    • This will scan status of all the devices attached to the test machine and store the device status information in PreInstallScan.xml

      Fail condition: Unexpected error in scan"

      Pass Condition: No unexpected failures

  2. Initiate device/driver reinstall Job.
    1. Verify that the specified Driver Package (A) is currently installed on the device.
    2. Do some Basic_IO, don't log failures.
    3. InstallFromInf(A).
    4. If #2 passed, do some more Basic_IO, log failures.
    5. Remove() -> Rescan() -> InstallFromInf(A).
    6. If #2 passed, do some more Basic_IO, log failures.
    7. InstallFromInf(NULL-Driver) -> InstallFromInf(A).
    8. If #2 passed, do some more Basic_IO, log failures.
    9. InstallFromInf(NULL-Driver) -> Rollback.
    10. If #2 passed, do some more Basic_IO, log failures.

    11. Go back to #3 'Count' times.

      Pass condition If Reinstall_With_IO Job passes

      Fail Condition: If Reinstall_With_IO Re Install Job fails

  3. Run DeviceScan.exe with Diff Mode.
    • This will scan status of all the devices attached to the test machine and store the device status information in PostInstallScan.xml

    • Compare the PreInstallScan.xml with PostInstallScan.xml and log the variations.

      Pass Condition: No mismatches in the status/missing nodes/added node found in the scan

      Fail Condition: At least one mismatch in the device status / missing / new devices found.

DeviceScan.exe [DA]/[DIFF]

Command option | Description
DA | In this mode, devicescan tool will scan all the devices attached to the test machine and log the status in PreInstallScan.xml file.
DIFF | In this mode, devicescan tool will scan all the devices attached to the test machine and log the status in PostInstallScan.xml file, compare the PostInstallscan.xml with PreInstallScan.xml, and log the variation in "DeviceScan.wtl" file.

cscript.exe "Reinstall_With_IO.wsf" /WDTF /DeviceID:"[DeviceID]" /IOPeriod:[IOPeriod] /Cycles:[Cycles] [WDKLogo] 2>ScriptErrors.txt

Command option | Description
/DeviceID | DeviceInstancePath of the device to reinstall its drivers for.
/IOPeriod | This is an optional parameter. The time (in msec) spent testing I/O between each reinstall testcase. Default value is 20000 msec
/Cycles | This is an optional parameter. Its value specifies the number of Test Cycles. Default value is 3.
WDKLogo | Run in 'Logo' mode. Running from DTM Device Console will set this.

File Manifest

File | Location
DeviceScan.exe | [WTT\Testbinroot]\NTTEST\DRIVERSTEST\WDKTools\DeviceScan\
DeviceScan.wtl | Default Test result folder
ReInstall_With_IO.wsf | [WTT\Testbinroot]\NTTEST\WDTF\
ScriptErrors.txt | Default Test result folder
ScriptErrors.txt | Default Test result folder


Device Install Check for System File Consistency

Type: Automated Test

Overview

This test verifies that no system resources have been overwritten during the process of a device/driver package install.

Details

No Driver or Device installs are permitted to overwrite system components, per DevFund-0005. As a result, the test will fail the test if detected.

Run Time: 2 hours
Log File: SFCLogDetails.wtl
System Restart Required: No
Test Category: Device Fundamental
Program: SFCLibrary

Requirements

Software Requirements

Device Install Check for System File Consistency test will run on the following Windows operating systems:

  • Windows 7

  • Software components included with the device that is being tested

Hardware Requirements

Device Install Check for System File Consistency test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

Device Install Check for System File Consistency test tool runs on the following processor architectures:

  • x86

  • amd64

Running Device Install Check for System File Consistency

  1. Start SFC with /SCANNOW mode.

    • Check for the console output from the sfc.exe run.

      Pass Condition: Not finding the string "Windows Resource Protection found integrity violations"

      Fail Condition: Finding string "Windows Resource Protection found integrity violations". If it fails, parse the CBS.log file, check for the string "Repair results created," and write the details of the error into log file.

  2. Initiate device/driver reinstall Job.
    1. Verify that the specified Driver Package (A) is currently installed on the device.
    2. Do some Basic_IO, don't log failures.
    3. InstallFromInf(A).
    4. If #2 passed, do some more Basic_IO, log failures.
    5. Remove() -> Rescan() -> InstallFromInf(A).
    6. If #2 passed, do some more Basic_IO, log failures.
    7. InstallFromInf(NULL-Driver) -> InstallFromInf(A).
    8. If #2 passed, do some more Basic_IO, log failures.
    9. InstallFromInf(NULL-Driver) -> Rollback.
    10. If #2 passed, do some more Basic_IO, log failures.

    11. Go back to #3 'Count' times.

      Pass condition If Reinstall_With_IO Job passes

      Fail Condition: If Reinstall_With_IO Re Install Job fails

  3. Perform the second SFC Scan.

    • Check for the console output from the sfc.exe run.

      Pass Condition: Not finding the string "Windows Resource Protection found integrity violations"

      Fail Condition: Finding string "Windows Resource Protection found integrity violations". If it fails, parse the CBS.log file, check for the string "Repair results created," and write the details of the error into log file.

SFCLibrary.exe [/SCANNOW]/[/VERIFYONLY]

Command option | Description
SFCLibrary.exe | Without any options, the test runs the SFC with /Scannow mode and checks for the system consistency errors from the output. If there are any errors, parse the CBS.log file and write the errors to SFCLogDetails.wtl.
/scannow | Run the SFC with /Scannow mode and check for the system consistency errors from the output. If there are any errors, parse the CBS.log file and write the errors to SFCLogDetails.wtl.
/VerifyOnly | Runs the SFC with /VerifyOnly mode and check for the system consistency errors from the output. If there are any errors, parse the CBS.log file and write the errors to SFCLogDetails.wtl.

cscript.exe "Reinstall_With_IO.wsf" /WDTF /DeviceID:"[DeviceID]" /IOPeriod:[IOPeriod] /Cycles:[Cycles] [WDKLogo] 2>ScriptErrors.txt

Command option | Description
/DeviceID | DeviceInstancePath of the device to reinstall its drivers for.
/IOPeriod | This is an optional parameter. The time (in msec) spent testing I/O between each reinstall testcase. Default value is 20000 msec
/Cycles | This is an optional parameter. Its value specifies the number of Test Cycles. Default value is 3.
WDKLogo | Run in 'Logo' mode. Running from DTM Device Console will set this.

File Manifest

File | Location
SFCLibrary.exe | [WTT\Testbinroot]\NTTEST\DRIVERSTEST\WDKTools\SystemFileChecker\
SFCLogDetails.wtl | Default Test result folder
ReInstall_With_IO.wsf | [WTT\Testbinroot]\NTTEST\WDTF\
ScriptErrors.txt | Default Test result folder
ScriptErrors.txt | Default Test result folder


Device Path Exerciser

Type: Automated Test

Overview

The Device Path Exerciser test is designed to test the reliability and security of drivers.

Details

The 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 cause the driver to stop responding (that is, "crash") if they are not managed correctly.

The Device Path Exerciser test is designed to test a single device driver as part of a Device Logo test.

The Systems - Device Path Exerciser test is designed to test every device driver in the system as part of a Systems Logo test.

If the driver is a UMDF driver, then AppVerifier will be enabled on the host process for the following checks:

  • Handles
  • Locks
  • Memory
  • Exceptions
  • TLS

UMDF Object tracking will be enabled for the UMDF driver. If there is a UMDF object leak, then a DriverStop will occur. You can use UMDF debugger extension !wudfext.dumpobjects <objecttrackeraddress> to analyze the problem.

For KMDF drivers, WDF Verifier will be enabled along with KMDF Enhanced Verifier and KMDF Handle Tracking for all objects.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running Device Path Exerciser

Before you can run the DRS - Device Path Exerciser job, you must install the device and driver on the test client. Next, install and configure Driver Test Manager (DTM).

To run DRS - Device Path Exerciser, do the following:

  1. On the Explorers menu, click Device Console.

  2. Select the machine pool that contains the computer where you want to run the test.

  3. 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.

  4. In the Available Jobs pane, select the DRS - Device Path Exerciser job.

  5. In the lower-left corner of the Device Console window, click Add Selected to add the jobs to the schedule of jobs to be run.

  6. Click Schedule Jobs.

You can follow the progress of the DRS - Device Path Exerciser job by using the Job Monitor window. Use the Result Explorer window 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 the "Device Path Exerciser Logs" topic in the Microsoft Windows Driver Kit (WDK) documentation.


Disable Enable with IO

Type: Automated Test

Overview

The Disable Enable with IO job ensures that the device that you are testing can be disabled and enabled without error. Additionally, this job 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 that you are testing through its service name or device instance identifier (ID). Additionally, the underlying scenario can target only disableable devices. A disableable device is a device that has the Disable option available in Windows Device Manager and that is not of the "LegacyDriver" class. If the scenario is targeted at a non-disableable device, the scenario should auto-pass.

If the driver is a UMDF driver, then AppVerifier will be enabled on the host process for the following checks:

  • Handles
  • Locks
  • Memory
  • Exceptions
  • TLS

UMDF Object tracking will be enabled for the UMDF driver. If there is a UMDF object leak, then a DriverStop will occur. You can use UMDF debugger extension !wudfext.dumpobjects <objecttrackeraddress> to analyze the problem.

For KMDF drivers, WDF Verifier will be enabled along with KMDF Enhanced Verifier and KMDF Handle Tracking for all objects.

Run Time: Less than 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running Disable Enable with IO

Prerequisite Before you can run the Disable Enable with IO job, you must install the device and driver on the test client computer. Next, install and configure Driver Test Manager (DTM).

To run Disable Enable with IO, do the following:

  1. Open DTM Studio.

  2. 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.

  3. 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 on.

  4. In the Available Jobs pane, click the Disable Enable with IO job.

  5. 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.

  6. Click Schedule Jobs.

  7. 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.

Troubleshooting

The underlying scenario is based on the new Microsoft Windows Device Testing Framework (WDTF). The Windows Driver Kit (WDK) contains extensive documentation about using and extending this framework in your own driver development process. For more information, search the WDK documentation for "Windows Device Testing Framework". For details about the specific operation of this scenario, open the WDK documentation, expand Windows Driver Kit, expand Other Tools, expand Windows Device Testing Framework, and click Automated Scenarios.

You may receive an error message similar to the following: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid." This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

  • For redundant network paths, add an additional NIC connected to the network.


Dynamic Partitioning (DP) Simulator and Test

Overview

There are two test tools in this package:

  • A CPU simulator with hot-add capability that tests a driver's compatibility with the hot-add CPU feature. For example, drivers should not import KeNumberProcessors and allocate per processor arrays based on that value.

  • A tool that tests driver compatibility with S4 IRP processing. Typically, drivers should request a D3 IRP in response to an S4 IRP, and they should stop DMA transfers and shut off their interrupts.

Details

The CPU simulator with hot-add capability starts the system under test with one processor and starts the remaining processors at system runtime. Drivers that are aware of the number of CPUs must behave appropriately. Drivers that are not aware of the number of CPUs and do not have per processor data or try to utilize processor affinity should be unaffected.

The tool for testing driver compatibility with S4 simply forces S4 power IRPs to all driver stacks, waits for all stacks to complete their D3 IRPs, and then resumes normal operation with the conventional startup sequence, as if the machine was resuming from the hibernate state. However, a hiberfile will not be written and the machine will not power down.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2008 R2 Datacenter x64 or Windows Server for Itanium-based Systems (IA64)

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Unsupported Software

  • Any device that has a driver that indicates that it cannot be power managed to the operating system causes the Device DP Simulator Test to fail. Specifically, if any driver in the system specifies that it is CM_DEVCAP_NONDYNAMIC, the Device DP Simulator test fails.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • 2 processors

  • 4 or more cores

  • 1 GB or more of system RAM

Processor

The test tool runs on the following processor architectures:

  • x64

  • Itanium

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Running Dynamic Partitioning (DP) Simulator and Test

A multiprocessor machine meeting the requirements above is required for these tests. Run the automated test jobs on such a multiprocessor machine.

Additionally, the system must either be an x64-based system (AMD64 or Intel64), or IA64-based (Itanium 2 or later). Windows Server 2008 R2 does not support Itanium 1 (Merced) processors.

For testing your device or driver to obtain a logo for Windows Server 2008 R2, the requirement is that the test system supports the minimum requirements defined above. These system capabilities are required in order for the "Dynamic Partitioning (DP) Simulator and Test" to run, which is required for all server supported device and driver categories. You do not need a system that actually supports DP capabilities to test your device.

If a pool of systems is used to test devices, at least one system in the pool must support the minimum requirements defined above. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Warning Any device that has a driver that indicates that it cannot be power managed to the operating system causes the Device DP Simulator Test to fail. Specifically, if any driver in the system specifies that it is CM_DEVCAP_NONDYNAMIC, the Device DP Simulator test fails. The failure might include error information that states, "The PnPReplacePartitionUnit() failed with 0x57, ERROR_INVALID_PARAMETER" or error information that shows "0x80004005, Unspecified error".

To isolate the problem, execute the DP Simulator test without the adapter and driver that are being tested in the system. If the test still fails, the system might contain a driver that is non-dynamic. Remove or disable devices until the test passes. If you cannot make the test pass on the system that is failing, use a different model or vendor system for device testing.

Test Assertions

Test Assertion GUID:
Windows Logo Program: SYSFUND-0129 Server system includes necessary devices and functionality
Additional Information: SYSFUND-0141 Drivers must operate normally when processors are dynamically added to a server. Effective Date: June 1, 2007 Form Factor Old ID: NEW Standalone Rack Status: Open Logo R R A driver that queries for the number of processors in a server must correctly handle dynamic addition of processors. Processor aware drivers must register for notification of hot-add processor events and must adjust any per-processor information they maintain accordingly. The legacy KeNumber Processors variable must not be used. Design and Implementation Note: More information about this requirement is given in the Driver Compatibility for Dynamic Hardware Partitioning white paper, which is available at the WHDC Web site. SYSFUND-0142 Drivers must support Resource Rebalance requests. Effective Date: June 1, 2007 Form Factor Old ID: NEW Standalone Rack Status: Open Logo R R A system wide resource rebalance can be executed on Windows Server 2008 R2. This can occur when a processor is dynamically added to a server. Device drivers must honor the resource rebalance flow and the Plug and Play requests that are dispatched as part of the flow. Device drivers must queue all IO requests during the resource rebalance operation. Design and Implementation Note: For more information, see the WHDC Web site and the Windows Driver Kit on MSDN. SYSFUND-0143 Drivers must support Query Power and Set Power Management requests. Effective Date: June 1, 2007 Form Factor Old ID: NEW Standalone Rack Status: Open Logo R R During transition into hibernation (S4) system sleep state, device drivers receive power requests from the operating system. A server is placed into a 'pseudo' S4 state with Windows Server 2008 R2 during a processor or memory hot-replace operation. Device drivers must honor the Query Power and Set Power requests that are dispatched as part of this operation. Device drivers must queue all IO requests during this pseudo S4 operation. Design and Implementation Note: More detail is available in the Driver Compatibility for Dynamic Hardware Partitioning white paper, which is available on the WHDC Web site.

Troubleshooting

You may receive an error message similar to the following:
"SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid."

This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

  • For redundant network paths, add an additional NIC connected to the network.

You may receive error the following error message when the Dynamic Partitioning Hot-Replace Test fails the "Quiesce System" task:
Replace - ReplacePartitionUnit() failed

You can load a standard VGA driver for the display, which prevents the system from going to sleep (or "Quiesce").

Install the fully-featured display driver for your graphics card so that power management works correctly. If the test continues to result in the same failure, check for legacy devices by copying pnpcpu.exe from DTM Controller's Tests, and running "pnpcpu -showlegacy".


Embedded Signature Verification

Type: Automated

Overview

This test will verify that the device under test contains an embedded signature only if the driver is of boot start. The test will pass if it is not a boot start device and will fail only if the boot start device is not embed signed.

Details

Run Time:
Log File: embeddedsignature.wtl
System Restart Required: No
Test Category:

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running Embedded Signature Verification

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.


IO Cancellation Test with Direct IO on local disk

Type: Automated Test

Overview

This test launches processes that issue IOs. The test then kills the processes randomly, thus cancelling IOs. If a driver doesn't cancel the pending IOs before a timeout, driver verifier breaks into the debugger. This is considered a failure of the test. Timely IO cancellation is very important for the responsiveness of applications, and this test catches issues with drivers that don't cancel IOs in appropriate time.

Details

If the driver is a UMDF driver, then AppVerifier will be enabled on the host process for the following checks:

  • Handles
  • Locks
  • Memory
  • Exceptions
  • TLS

UMDF Object tracking will be enabled for the UMDF driver. If there is a UMDF object leak, then a DriverStop will occur. You can use UMDF debugger extension !wudfext.dumpobjects <objecttrackeraddress> to analyze the problem.

For KMDF drivers, WDF Verifier will be enabled along with KMDF Enhanced Verifier and KMDF Handle Tracking for all objects.

Run Time: ~20 minutes.
Log File: IoCancelTest.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program:

  • IoCancel.exe

  • IoCancelTests.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • USB storage device to test. The device should be formatted with a file system and have at least 1.5 GB of free disk space.

  • Computer that meets the minimum software requirements

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

The shell of the test (IoCancel.exe) is run with a configuration file that is generated through the DTM job. The shell runs for the duration of the test specified in the configuration file. The shell has a set of IO tests (IoCancelTests.exe) that it iterates through continuously until the timer times out. In each iteration, IoCancelTests.exe is launched and allowed to run for a random time and is killed. The tests issues IOs (both synchronous and asynchronous) by reading from the device and writing to the device. Upon killing the process, if the pended IOs are not canceled by the driver in time specified (currently set to 5 seconds), verifier breaks into the debugger. This break is considered a failure. If there are no debugger breaks then the test is considered a success. The test log files should be available through DTM.

Code Tour

File Manifest

File | Location
IoCancel.exe | [testbinroot]\nttest\basetest\IoCancel\Tools\
IoCancelTests.exe | [testbinroot]\nttest\basetest\IoCancel\Tools\
Config.xml | Generated by DTM job (DTM job run directory)
IoCancelTest.wtl | Log for the test (DTM job run directory)


IO Cancellation with Direct IO on network storage (Preview)

Type: Automated Test

Overview

This test requires two machines: M1 and M2 (the test machine). The test creates a share and a file on M1 and launches processes on M2 that issue IOs against the file on M1. The test then kills the processes randomly, thus cancelling IOs. If a driver doesn't cancel the pending IOs before a timeout, driver verifier breaks into the debugger. This is considered a failure of the test. Timely IO cancellation is very important for the responsiveness of applications, and this test catches issues with drivers that don't cancel IOs in the appropriate time.

Details

If the driver is a UMDF driver, then AppVerifier will be enabled on the host process for the following checks:

  • Handles
  • Locks
  • Memory
  • Exceptions
  • TLS

UMDF Object tracking will be enabled for the UMDF driver. If there is a UMDF object leak, then a DriverStop will occur. You can use UMDF debugger extension !wudfext.dumpobjects <objecttrackeraddress> to analyze the problem.

For KMDF drivers, WDF Verifier will be enabled along with KMDF Enhanced Verifier and KMDF Handle Tracking for all objects.

Run Time: About 40 minutes
Log File: "IoCancelTest.wtl"
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program:

  • IoCancel.exe

  • IoCancelTests.exe

Requirements

Software Requirements

Firewall service (MpsSvc) should be running. You can disable the firewall if necessary by using the firewall UI or netsh commands.

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Two machines are required for the test. For a description of the setup, go to "DTM Setup for LAN (Ethernet) Device Testing" in LAN (Ethernet) Testing Overview

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

The shell of the test (IoCancel.exe) is run with a configuration file that is generated through the WTT job. The shell runs for the duration of the test specified in the configuration file. The shell has a set of IO tests (IoCancelTests.exe) that it iterates through continuously until the timer times out. In each iteration, IoCancelTests.exe is launched, allowed to run for a random time, and then killed. The tests issues IOs (both synchronous and asynchronous) by reading from the device and writing to the device. When killing the process, if the pended IOs are not canceled in the time specified by the driver, verifier breaks into the debugger. This break is considered a failure. If there are no debugger breaks, then the test is considered a success. The test log files are available through WTT.

Code Tour

File Manifest

File | Location
IoCancel.exe | [testbinroot]\nttest\basetest\IoCancel\Tools\
IoCancelTests.exe | [testbinroot]\nttest\basetest\IoCancel\Tools\
Config.xml | Generated by WTT job (WTT job run directory)
IoCancelTest.wtl | WTT log for the test (WTT job run directory)


Multiple Processor Group and >64 Processor Test

Type: Automated Test

Overview

This requirement applies to all Device Categories that can be Server Logo qualified. This test requires configuration of the system into multiple processor groups and a reboot, prior to running Windows Server 2008 R2 Device Logo qualification tests. DTM automatically checks that the system is correctly configured with multiple processor groups when tests are scheduled.

The processor group concept was introduced in Windows 7 and Windows Server 2008 R2 to support more than 64 logical processors. Any machine with more than 64 logical processors has more than one processor group by necessity. Drivers are expected to run properly in the multi-group context in anticipation of servers increasingly having more than 64 logical processors. This test limits the maximum group size to a small value, thereby forcing multiple groups on a machine that would normally have only one group. This test requires at least 2 logical processors to run, but because Windows Server 2008 R2 testing in general requires 4 logical processors, that is the minimum that the systems being used for testing must contain. The test requires ia64 or amd64 architectures; x86 does not apply. The test requires Windows Server 2008 R2.

The Multiple Processor Group test will not execute when Hyper-V is enabled, because Hyper-V limits the number of processor groups to 1. Please uninstall Hyper-V before you run this test.

Details

The test determines whether BCD settings were manually set correctly before testing began. It does not directly perform any specific validation of the device or driver being tested. Rather, it ensures the BCD settings are correct for Windows Server 2008 R2 Device Logo qualification testing. Device category-specific and Driver Fundamentals tests execute in this multiple processor group configuration and environment.

The bcdedit command prompt utility is enhanced for Windows 7 and Windows Server 2008 R2 to include the groupsize setting. This setting specifies the maximum number of logical processors per processor group in the system. The default maximum number of logical processors per processor group is 64.

Testers must set the value for the processor group size for Windows Logo Kit testing of Windows Server 2008 R2 Device Drivers for Logo qualification. This is done by running bcdedit in an elevated Command Prompt window, using the /set option. For example:

The command lines for adding the group settings and rebooting:

  • bcdedit.exe /set groupsize 2

  • bcdedit.exe /set groupaware on

  • shutdown.exe -r -t 0 -f

The command lines for removing the group settings and rebooting:

  • bcdedit.exe /deletevalue groupsize

  • bcdedit.exe /deletevalue groupaware

  • shutdown.exe -r -t 0 -f

Vendors are encouraged to configure a system similar to what is required by the WLK/DTM to do their own testing in a multiple processor group configuration as detailed above. Vendors should test their drivers on systems that are configured to have multiple processor groups whether or not they call the group-aware Ex versions of device driver interfaces newly added for Server 2008 R2.

The processor group size must be a power of 2 between 1 and 64, inclusive.

By default, a system that has 64 or fewer active logical processors has one processor group. One must set the processor group size to forcibly configure such a system to have multiple processor groups. (Note that the group size setting is for testing and one should not configure shipping systems with this setting.) This setting allows one to test group-aware code on a system that has fewer than 64 logical processors. It also allows one to test legacy non-group-aware code.

We do not recommended that the processor group size be set to one, because this can limit concurrency of non-group-aware code. A processor group size of two avoids this problem while still allowing multiple processor groups on a system that has as few as four logical processors.

Windows 7 and Windows Server 2008 R2 support a maximum of four processor groups. If a system is configured with a processor group size that is less than one-fourth of the total number of logical processors in the system, some of the logical processors are not used.

Setting the processor group size can have ramifications. If the processor group size is set to a value that is less than the number of logical processors in a non- uniform memory access (NUMA) node or if the system is non-NUMA, this setting redefines the NUMA node size to be the same as the processor group size. In other words, NUMA nodes are split into multiple NUMA nodes that fit within the new group size and a non-NUMA system becomes a NUMA system.

To reset the maximum size of processor groups to the default value of 64, run bcdedit in an elevated Command Prompt window by using the /deletevalue option. For example:

bcdedit.exe /deletevalue groupsize

This removes the groupsize setting. By default, the groupsize setting is not set.

Examples:

Consider a non-NUMA system that has one processor package (socket) that contains four processor cores and has hyperthreading enabled, for a total of eight logical processors. If one runs the following command to set the processor group size to two and then restarts the system, the system will be configured to have four processor groups where each group has two logical processors, one core, and one NUMA node. GetLogicalProcessorInformationEx reports 8 logical processors, four processor packages, 4 nodes, and 4 groups. Each group contains one node, one package, and 2 logical processors.

bcdedit.exe /set groupsize 2

If one runs the following command to set the processor group size to one and then restarts the system, the system will be configured to have four processor groups where each group has one logical processor, one core, one package, and one NUMA node. GetLogicalProcessorInformationEx reports 4 logical processors, four processor packages, 4 nodes, and 4 groups. Each group contains one node , one package, and one logical processor.

bcdedit.exe /set groupsize 1

In this situation, four of the logical processors in the system are started while the other four are not. (Four processor groups maximum) * (groupsize of one) = a maximum of four active logical processors in the system.

Note that in the above examples, Windows splits NUMA nodes and packages so as not to span group boundaries. Nodes can never span group boundaries. A non-NUMA machine becomes a NUMA machine to Windows when its single node is split into two or more nodes. Packages can span group boundaries one situation. If a system defines multiple NUMA nodes within a package, Windows may assign the nodes to different groups, in which case the package then spans group boundaries. This is an important corner case for software taking advantage of future multi-chip module (MCM) processor packages that contain multiple die, where each die has its own memory controller. Testing software in this scenario requires the system's Static Resource Affinity Table (SRAT) to define NUMA nodes to be subsets of processor packages.

Vendors whose drivers are expected to run on any system running Server 2008 R2 or later should validate their drivers in a multiple group environment with the groupaware BCD setting enabled. Backward compatibility is not seamless for all non-group-aware device driver interfaces (DDIs) running on Server 2008 R2 in the context of multiple processor groups. Both the multiple group configuration and the groupaware BCD setting help expose driver bugs that are probable and only manifest themselves on larger server class systems, which are expected to increase over time.

The groupaware setting causes several now legacy (non-group-aware) DDIs to behave incorrectly all the time when running in a multiple group configuration. This helps expose driver bugs that may otherwise be difficult to find. Non-group-aware DDIs like KeGetCurrentProcessorNumber and KeSetTargetProcessorDpc are not designed to run in a multiple group configuration because they do not accommodate the processor group number now required to fully qualify a processor number. This is also true for other now-legacy DDIs. They behave correctly on all single group machines, and perhaps sometimes on multi-group machines. Some legacy processor-related DDIs operate on group 0. The two APIs mentioned above use the group associated with the affinity of the calling thread. The driver does not control the affinity of all threads calling into it. Determining whether a thread is running on processor 1 and affinitizing a DPC to processor 0x4 are ambiguous operations without the proper group qualification, because the particular processors involved could be in any group.

Some bugs exposed via the groupaware BCD setting might otherwise only be exposed on a platform that chooses to associate a device with a particular NUMA node. A platform designer can choose to associate a device with a node by adding the optional _PXM (proximity domain) object to the ACPI namespace of the device or its parent. Several driver entry points, StartDevice for example, run on processors of the NUMA node where the device resides. Other driver entry points are not constrained and may run in a different group. This has the potential to wreak havoc with legacy non-group-aware driver code, because the driver does not realize DPCs are affinitized to processors in one group, while other code may run in any group.

The solution is to port the driver to be group-aware by replacing calls to legacy interfaces, such as KeGetCurrentProcessorNumber and KeSetTargetProcessorDpc, to their new group-aware counterparts (KeGetCurrentProcessorNumberEx to KeSetTargetProcessorDpcEx, respectively).

Drivers calling the new group-aware DDIs can opt into being able to run downlevel by including procgrp.h and linking against procgrp.lib included with the Server 2008 R2 or later DDK. A runtime check determines the actual DDIs called. Because downlevel operating systems by definition have exactly one group, the new group-aware DDI calls are routed to an alternate implementation that leverages the legacy non-group-aware DDIs.

Troubleshooting

The multi-group configuration this test imposes may cause a driver to function improperly, or the machine may fail to boot.

Follow these steps until your problem is resolved:

  1. Disable the groupaware BCD setting as follows:

    Bcdedit.exe /set groupaware off

  2. Reboot.

  3. Disable the groupsize BCD setting as follows:

    Bcdedit.exe /deletevalue groupsize

  4. Reboot.

If either of these corrects the problem, it is likely that a driver needs to call new processor group-aware APIs added for Windows 7 to function properly in a multi-group configuration. For more information, view the "Supporting Systems That Have More Than 64 Processors" whitepaper at http://www.microsoft.com/whdc/system/Sysinternals/MoreThan64proc.mspx.

Run Time: Depends on device category test time
Log File: None
System Restart Required: Yes
Test Category: Server-qualified Devices and Drivers

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: There is no test binary that exercises driver code or device. The test only checks that the manually configured BCD settings are correct. Booting into a multiple processor group configuration and the execution of Windows Server 2008 R2 Device Category-specific and Driver Fundamentals tests validates that a Server Logo-qualified driver will operate correctly in a multiple processor group environment.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x64

  • IA64

Running Multiple Processor Group and >64 Processor Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
Bcdedit.exe | Must be run with Administrator privileges. Without any options, the command displays Windows Boot Manager and Windows Boot Loader options.
/set | Sets the value that immediately follows.
/deletevalue | Deletes the value that immediately follows.
groupsize | Any number that is a power of 2, between 1 and 64, inclusive.
groupaware | Changes the behavior of several now-legacy APIs to make multiple processor group testing more effective in finding code errors.


Plug and Play Driver Test

Type: Automated Test

Overview

The Plug and Play Driver Test (Pnpdtest) exercises various Plug and Play (PnP)-related code paths in the driver and user-mode components. This Plug and Play Driver test runs with Driver Verifier enabled.

Details

The Plug and Play Driver test provides you with a tool that exercises various PnP-related codes paths in the driver and user-mode components. If you use this test with Driver Verifier, you can feel more confident that your code is performing properly. This tool is for use on Windows Vista, Windows Server 2003, Windows XP, and Windows 2000.

Although by using this tool a driver will be forced to handle almost all of the PnP IRPs, there are three areas that are stressed specifically: Removal, Rebalance, and Surprise Removal. The test provides a mechanism to test each of these separately or all together (that is, stress). This testing is accomplished by using a combination of user-mode API calls (through the test application) and kernel-mode API calls (through an upper filter driver).

The first time the test is run, you will be prompted with a dialog box for the location of the test filter driver (pnpfiltr.sys). After you point to the proper location for the filter driver, its service will be installed and the driver copied. If you have run an older version of the test previously, you might need to restart the computer after the new filter driver is copied if the old driver is currently loaded.

Note Troubleshooting Note: If the Pnpfilter driver fails to install you may need to manually perform the following procedure:

  1. Using RegEdit, navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\USB (or your appropriate bus)\<Your Hardware ID>\<Instance ID>\Device Parameters\WUDF

  2. Add a DWORD key "UpperDriverOK" and set it equal to "1".

Device removal

Device removal is tested by selecting the target device and clicking the Test Removal button. This test encompasses IRP_MN_QUERY_REMOVE_DEVICE, IRP_MN_CANCEL_REMOVE_DEVICE, and IRP_MN_REMOVE_DEVICE.

The test will attempt to install its upper filter driver on the target device stack. This attempt results in a query-remove IRP-if this query-remove is failed, you might need to restart the computer to get the filter driver onto the device stack. If the remove request is not vetoed, the device stack will be removed and restarted with the filter driver on the device stack.

The test, by using Setup APIs, will cause a query-remove to be sent to the device stack. The filter driver will fail this remove request so a cancel-remove IRP will be sent. The filter driver will assert that the cancel-remove was successful.

Next, the test application calls the appropriate class installer and any registered co-installers to disable or enable and remove or reenumerate the device (this tests the class and co-installers handling of DIF_PROPERTYCHANGE with DICS_DISABLE, DICS_ENABLE, and DICS_PROPCHANGE). When receiving IRP_MN_REMOVE_DEVICE, the filter driver will assert that the lower drivers completed it successfully.

The test will again call the class or co-installers (this time with DIF_REMOVE) and then will reenumerate the device's parent to attempt to restart the device. This step essentially uninstalls the device as if you had used Device Manager.

Of course, each of these steps involves a preliminary remove request. If that request if vetoed, the device will not be removed. You can choose to veto a remove request when appropriate, such as while streaming video on a USB camera or if the target device is in the boot or paging path. Remember that simply failing all remove requests is generally not good practice-it will not guarantee that driver will never receive a remove because a remove IRP will still be issued after a surprise removal or if anyone in the device stack fails a start IRP.

Rebalance

Rebalance is tested by selecting the target device and clicking the Test Rebalance button. When you press this button, a separate window will appear. Select your desired mode of rebalance from this window.

As with the removal test, the test application will attempt to add an upper filter to the target device stack and then restart the device stack by using SetupDiCallClassInstaller with DIF_PROPERTYCHANGE. If this attempt is not successful (that is, if someone on the target device stack failed the query-remove IRP), you might need to restart the computer to test rebalance.

Depending on the mode of rebalance that you choose, the test might take the following possibilities:

  1. Simple: This option initiates a rebalance procedure which results in the IRP_MN_QUERY_STOP_DEVICE PnP Irp to the device driver.

    If any driver in the stack fails this IRP the rebalance procedure is abandoned. Please note that in Windows Vista, there is support for multi-level rebalance. If a rebalance is started on a non-leaf device node, all of the device stacks that are present in the device tree with that device node as the root also go through rebalance. And if any of the child device stacks fails query stop, the whole rebalance procedure is abandoned. So drivers must not fail query stop without a genuine reason to do so. If this failure happens, the PnP manager sends cancel stop (IRP_MN_CANCEL_STOP) to all the device stacks that had been sent query stop.

    If all of the device stacks involved pass query stop, the test continues with the rebalance and sends the IRP_MN_QUERY_RESOURCE_REQUIREMENTS and IRP_MN_FILTER_RESOURCE_REQUIREMENTS IRPS to find the resource requirement of the devices.

    After this point , two different paths are possible depending on whether the target device consumes any resources or not:

    • If the device does not consume any resources, the PnP manager itself sends a cancel stop (IRP_MN_CANCEL_STOP_DEVICE) as an optimization.
    • If the device actually consumes resources, the rebalance procedure is completed with the IRP_MN_STOP_DEVICE and IRP_MN_START_DEVICE IRPs.

    With this option, the resources of the device do not change.

  2. FailQueryStop: This option initiates a rebalance procedure but the filter driver deliberately fails the query stop. So the order of IRPs looks like IRP_MN_QUERY_STOP_DEVICE (which is failed by the filter driver while coming up, causing a cancellation of rebalance) and IRP_MN_CANCEL_STOP_DEVICE.

    With this option, the resources of the device do not change

  3. NewResources: This option initiates a rebalance and also manipulates the resource requirement of the device to maximize the chances that actually new resources are allocated to the device. This option also helps a device with no resources to actually go through the complete rebalance procedure:
    • First the simple rebalance is started, causing the following IRPs:
      • IRP_MN_QUERY_STOP_DEVICE (assuming this IRP is passed by all the drivers. The test already covered the case where this IRP is failed.)
      • IRP_MN_QUERY_RESOURCE_REQUIREMENTS
      • IRP_MN_FILTER_RESOURCE_REQUIREMENTS. In response to this IRP, while going up, filter driver takes action based on whether the device consumes any resources or not:
        • If the device has no resource requirement, filter assigns a fake resource.
        • If the device has a resource requirement, it tries to restructure the resource requirement list in such a way that maximizes the probability of changing the current assignment. For example, if a device needs 2 bytes of memory anywhere between 00 to FF and currently is assigned 3A-3B, modify such that the new resource requirement (in order of preference) looks like 00-39 or 3C-FF or 3A-3B. Similarly if the device resource requirement list has any alternate requirements, it will change their order so the alternate requirement comes earlier in the list.
    • Now the device should always complete the rebalance procedure.
      • IRP_MN_STOP_DEVICE
      • IRP_MN_START_DEVICE (The new allocated resources. If fake requirements were created, mask the new resources from the actual drivers.)

  4. Fail Restart: This option initiates a rebalance but when the filter driver gets the start after the rebalance, it deliberately fails it-which causes the surprise removal IRP followed by Removal IRP.

    First, it starts the rebalance procedure and makes sure that the driver gets a stop and a start by generating fake resource requirement for a device which does not consume any resources.

    • IRP_MN_QUERY_STOP_DEVICE (assuming this IRP is passed by all the drivers. The test already covered the case where this IRP is failed.)
    • IRP_MN_QUERY_RESOURCE_REQUIREMENTS
    • IRP_MN_FILTER_RESOURCE_REQUIREMENTS (If the actual resource requirement are null, filter assign fake resource requirement, so there is a stop and a start.)
    • IRP_MN_STOP_DEVICE
    • IRP_MN_START_DEVICE (The filter fails this IRP while going up. This action causes the surprise remove IRP.)
    • IRP_MN_SURPRISE_REMOVAL
    • IRP_MN_REMOVE

    After the rebalance test is complete, the device will be uninstalled and reenumerated, also removing the filter driver from the stack.

Double Start

Double Start is tested by selecting the target device and clicking Test Double Start.

As with the removal test, the test application will attempt to add an upper filter to the target device stack and then restart the device stack by using SetupDiCallClassInstaller with DIF_PROPERTYCHANGE. If this attempt is not successful (that is, if someone on the target device stack failed the query-remove IRP), you might need to restart the computer to test double start.

This option creates a scenario in which a driver gets two start IRPs without getting a stop in between. This option is not included as part of stress. This test should be run, if you think your driver should handle this case. In this case, the filter driver tells the PnP manager that resources have changed but does not want the device stack to be stopped. This action cause:

  • IRP_MN_START (When the device is started, it must have this IRP.)

  • IRP_MN_QUERY_RESOURCE_REQUIREMENTS

  • IRP_MN_FILTER_RESOURCE_REQUIREMENTS

  • IRP_MN_START_DEVICE

After the double start test is complete, the device will be uninstalled and reenumerated, also removing the filter driver from the stack.

Surprise Removal

Surprise removal is tested by selecting the target device and clicking Test Surprise Removal. This test encompasses IRP_MN_SURPRISE_REMOVAL followed by IRP_MN_REMOVE_DEVICE.

As with the previous tests, the test application will attempt to add an upper filter to the target device stack and then restart the stack. If this attempt is not successful, you might need to restart the computer to test surprise removal.

When triggered by the test application, the filter driver will cause the system to send an IRP_MN_SURPRISE_REMOVAL to the device stack, followed by an IRP_MN_REMOVE_DEVICE. The filter driver will assert that both of these IRPs are completed successfully by lower drivers.

Note On Windows 2000 only, after handling the surprise removal IRP, the device will be marked by the system with the status code DN_HAS_PRIVATE_PROBLEM. The device will still appear in the device tree in Device Manager because, because it has not actually been physically removed, it will still be reported by its bus driver in response to an IRP_MN_QUERY_DEVICE_RELATIONS for BusRelations. To restore the device to working order, the physical device object (PDO) for the device must be deleted. This deletion can be accomplished by rebooting the system, removing and reenumerating the device's parent, or physically removing the device and reattaching it. On Windows XP and later operating system, the operating system can handle this properly and the test should be able restart the device successfully, unless an error occurred.

After the surprise removal test is complete, the device will be uninstalled and reenumerated, also removing the filter driver from the stack.

Stress

You can test all of the preceding scenarios (except for Double Start) together by selecting the target device and clicking Start Stress. The test application will keep choosing one of the preceding tests (remove, surprise remove, or one of the rebalance tests) and running it on the selected device for five minutes.

Device Error Code

If the test gives an error saying that the device status is not OK, you can learn more about the device status through Device Manager. For a summary of the various device error codes, see Explanation of error codes generated by Device Manager in Microsoft Windows XP Professional.

Automation

Pnpdtest offers command-line options to run all of the preceding options and some other extra options for stress. For more information, see the following Command Syntax section.

Pnpdtest uses WTTLogging to log results. The test reates two log files: one in plain text format called pnpdtest-log.txt and another one in XML formal called pnpdtest-log.xml.trace (to be used with WTT).

Some example commands include the following:

  • pnpdtest /stress /device All /nodbgbreak /driverpath c:\pnpdstress

    Run stress on all devices one by one, copying filter driver from C:\pnpdstress and do not break in the debugger when a wrong PnP IRP is failed by the driver.

  • pnpdtest /remove /device "flpydisk" Run the remove test on all devices that have the service name as flpydisk.

  • pnpdtest /timedstress 120 /nodbgbreak /driverpath c:\pnpdstressRun random tests on random devices for two hours, copying filter driver from C:\pnpdstress and do not break in the debugger when a wrong PnP IRP is failed by the driver.

  • pnpdtest /rebalance NewResources /device "FDC\GENERIC_FLOPPY_DRIVE\5&c4ae404&1&0" Run the rebalance test with the newresources option on the device.

If the driver is a UMDF driver, then AppVerifier will be enabled on the host process for the following checks:

  • Handles
  • Locks
  • Memory
  • Exceptions
  • TLS

UMDF Object tracking will be enabled for the UMDF driver. If there is a UMDF object leak, then a DriverStop will occur. You can use UMDF debugger extension !wudfext.dumpobjects <objecttrackeraddress> to analyze the problem.

For KMDF drivers, WDF Verifier will be enabled along with KMDF Enhanced Verifier and KMDF Handle Tracking for all objects.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Running Plug and Play Driver Test

Before you can run the DRS - Plug and Play Driver Test job in Driver Test Manager (DTM), install the device and driver on the test client. Next, install and configure DTM.

To run the DRS - Plug and Play Driver Test job, do the following:

  1. Open DTM Studio.

  2. 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

  3. 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.

  4. In the Available Jobs pane, click DRS - Plug and Play Driver Test.

  5. 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.

  6. Click Schedule Jobs.

  7. Follow the progress of the DRS - Plug and Play Driver Test job by using the Job Monitor window. Use the Result Explorer window 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
Pnpdtest [ /device <service> | <HW ID> | <Device Instance> | <All> ][ /driverpath <Filter driver directory> ] [ /stress ] [ /rebalance [mode] ][/surprise] [/remove] [/doublestart] [ /timedstress <minutes> ] [ /NoDbgBreak ] [ /? ] |
/device | Specifies the device (by either its Service name, Hardware ID, or Device instance Id) on which to carry out the tests. If you specify "All", the selected test is run on all of the devices on the system. This parameter is necessary for automation.
/driverpath | Specifies the path of the directory where the filter driver file is present. The driver file name should not be included in the path. If the path is not correct, the test will look in the system32\drivers directory. And if it cannot find the driver there also, it will display the open file dialog box.
/nodbgbreak | The test does not break into the debugger when the filter driver detects that a Plug and Play (PnP) IRP has failed, which should have been succeeded. The test logs an error in the log file.
/remove | Run the Remove test.
/surprise | Run the Surprise Remove test.
/rebalance | Run the Rebalance test, where the optional mode can be FailQueryStop (fail the Query Stop Irp), NewResources (try to change allocated resources or create fake requirement), or FailRestart (fail the start IRP that comes after stop).
/doublestart | Run the Double Start test (which is not run as part of the stress test).
/stress | Run the stress option. This option will run different tests (remove, surprise remove, or one of the rebalance tests) on the selected device for five minutes. If you specify "All" as an option, the test will go through the device list and run stress (5 minutes on each device) on those devices that a filter driver can be installed on without requiring a restart.
/timedstress | Run stress for the specified amount of time in minutes. With this option, the test first creates a list of devices that a filter driver can be installed on without a restart. This part of the test can take some time, depending on the number of devices in the system. Then, the test continuously selects a random device from that pruned list and runs a random test on it. The only other options that can be used with this option are /driverpath and /nodbgbreak.
/? | Display Help for this test.


Reinstall with IO

Type: Automated Test

Overview

This test reinstalls a driver several times (three by default) to test install functionality. It initiates IO against the driver/device after each reinstall. This test is designed to improve the overall install/reinstall experience of a device driver and/or a device for end-users. The test should help guide INF design to prevent problems with driver upgrades, etc. The test also helps with overall driver package design and testing.

Various application verifier settings are enabled based on operating system, testing driver installers, applications, and co-installers as appropriate.

Ui-less reinstall of drivers can be a problem seen in upgrades. This test is helpful in exposing these issues.

The test will loop through three uninstall/reinstall cycles, each time without user-intervention, and test the driver stack using IO after each, as applicable.

Test sign your driver prior to running this test. Failure to do so could result in the test failing if the Inbox driver score takes precedence over your driver during ui-less install.

Details

If the driver is a UMDF driver, then AppVerifier will be enabled on the host process for the following checks:

  • Handles
  • Locks
  • Memory
  • Exceptions
  • TLS

UMDF Object tracking will be enabled for the UMDF driver. If there is a UMDF object leak, then a DriverStop will occur. You can use UMDF debugger extension !wudfext.dumpobjects <objecttrackeraddress> to analyze the problem.

For KMDF drivers, WDF Verifier will be enabled along with KMDF Enhanced Verifier and KMDF Handle Tracking for all objects.

Run Time: 1 Hour
Log File: Reinstall_With_IO.wsf.wtl, setupapi.log*.log
System Restart Required: Yes
Test Category: Device Fundamentals

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program: Reinstall_With_IO.wsf

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Driver should be test-signed

  • Driver and INF to be tested (if applicable)

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if there are no devices or drivers specified by the device object.

Command Syntax

Command option | Description
CScript.exe Reinstall_With_IO.wsf DevID InfName|DriverPath | Must specify at least one of the identifiers, either Device ID and/or INFName|DriverPath
/S:Reinstall|Uninstall | Type of test, either reinstall(remove both device, driver, and install both) or uninstall (remove device and driver)
/T:Number | Number of iterations (default is 5)
/T:Minutes | Number of minutes to run the test for (default is 5)

Code Tour

File Manifest

File | Location
Reinstall_With_IO.wsf | tests\%cpu%\NTTest\wdtf\samplescripts


Sleep Stress with IO

Type: Automated Test

Overview

The Sleep Stress with IO job ensures that the Device under test permits the system to be cycled through all supported sleep states. Additionally, it ensures that the device is still functional after these state changes 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 test directs the underlying scenario to target the Device under test via its service name or device instance ID.

The script has the following command line parameters:

Devices - The device(s) to run stress on. By default, the test runs IO stress on all media, network, and disk devices.

MinutesToRun - The amount of time the script will run.

SleepPeriod - The RTC timer will be set to this value (in minutes) each time the machine goes into sleep mode.

MinIOPeriod and MaxIOPeriod specify the time (in milliseconds) that IO tests will be running between subsequent sleep cycles.

ResumeDelay - The delay time (in milliseconds) after the machine resumes from sleep mode and before next IO cycle starts. The delay time is necessary to allow devices to restore their working state (renew IP address for network card and so on).

The script runs IO tests for a random amount of time between minimum and maximum values. Then it pauses the SimpleIO, picks up the next supported sleep state, and sends the computer into sleep mode with an RTC wake timer set to automatically wake the computer. After the computer wakes up, these actions are repeated until MinutesToRun minutes pass.

If the driver is a UMDF driver, then AppVerifier will be enabled on the host process for the following checks:

  • Handles
  • Locks
  • Memory
  • Exceptions
  • TLS

UMDF Object tracking will be enabled for the UMDF driver. If there is a UMDF object leak, then a DriverStop will occur. You can use UMDF debugger extension !wudfext.dumpobjects <objecttrackeraddress> to analyze the problem.

For KMDF drivers, WDF Verifier will be enabled along with KMDF Enhanced Verifier and KMDF Handle Tracking for all objects.

Run Time: 40 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Windows Device Testing Framework components

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • 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

  1. Start DTM Studio.

  2. 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.

  3. In the Available Devices pane, expand the type of device that is associated with your driver, and then click the specific device on which to run the test.

  4. In the Available Jobs pane, click the Sleep Stress with I/O job.

  5. 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.

  6. Click Schedule Jobs.

  7. 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.

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. You can also find this information in the table of contents in the WDK documentation under Windows Driver Kit > Other Tools > Windows Device Testing Framework > Automated Scenarios.

You may receive an error message similar to the following: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid." This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

  • For redundant network paths, add an additional NIC connected to the network.

Some machines will go into standby mode at the end of the test on Windows XP. If this occurs, you must wake the machine manually to complete the test. This is acceptable for Logo submission. If automation is required, you can wake the system by calling PoSetSystemState(ES_USER_PRESENT) from kernel mode.


WDF Logo Test

Type: Automated Test

Overview

The WDF Logo Test ensures that the Windows Driver Framework (WDF) drivers comply with the Windows Driver Framework fundamentals, doesn't cause any resource leaks, can handle DDI failures gracefully, and are reliable and stable.

Details

WDF Logo Test category has test cases for KMDF Drivers and WDF Coinstallers.

KMDF driver under the test will have WDF verifier on. Handle tracking will be enabled on all KMDF objects, and for v1.9 KMDF drivers, Enhanced Verifier will be set. Enhanced Verifier will perform IRQL and critical region checks for event callbacks of v1.9 KMDF drivers. Driver verifier will also be enabled for the KMDF driver under test.

KMDF drivers will be tested with Fault Injection. Device Driver will be unloaded and then reloaded, during which time return values of DDIs called from the driver will be fault injected. For the DDIs that have an NTSTATUS return code, driver is expected to check the return values to properly handle DDI failures.

The following is an example of a typical call into a WDF DDI that returns an NTSTATUS code:

status = WdfFdoInitQueryProperty(DeviceInit,

DevicePropertyEnumeratorName,

sizeof(enumeratorName),

enumeratorName,

&returnSize);

if(!NT_SUCCESS(status)){

return status;

}

DDIs called during device driver load/unload will be fault injected to return STATUS_UNSUCCESSFUL. Drivers should be cautious with the error codes and shouldn't miss STATUS_UNSUCCESSFUL by wrongly assuming that DDI can't return this value.

User Mode Driver Framework (UMDF) drivers must be secure, stable, reliable and not have application compatibility issues. Application verifier will be enabled for the UMDF host process. Application verifier can be enabled on the host process with the command line:

appverif -enable handles locks heaps memory COM exceptions TLS -for WUDFHost.exe

Object tracking will be enabled on the umdf drivers via the registry value below:

HKLM\Software\Microsoft\WindowsNT\CurrentVersion\WUDF\Services\{193a1820-d9ac-4997-8c55-be817523f6aa}

TrackObjects REG_DWORD 1

UMDF test cases haven't been incorporated into the test yet, but with WLK 1.5, necessary tests will be under the WDF Logo Test category. There will be two library jobs within WLK 1.4 for individual testing purposes, "UMDF Logo Test - Setup" and "UMDF Logo Test - Cleanup", which are responsible for the setup and clean up of the necessary UMDF related settings indicated above. You can create your own jobs that call into these two library jobs at setup and cleanup tasks, respectively. Both of these library jobs require the "IsUmdf" and "LLU_NetAccessOnly" parameters. So the main job calling into these library jobs should have these two parameters within its parameter list (parameter names are case sensitive), and must pass them into the library jobs. This main job can execute any test at its regular task phase. For more information about creating your own jobs in DTM please refer to Creating Your Own DTM Jobs.

WDF drivers are expected to be packaged with RTM fre versions for both KMDF and UMDF drivers. "Verify WDF Coinstaller Version for KMDF" test validates the KMDF Coinstaller (WdfCoinstallerMMmmm.dll)."Verify WDF Coinstaller Version for UMDF" validates the UMDF coinstaller (wudfupdate_MMmmm.dll).

Inf files for WDF drivers will also be inspected via the "Run INFTest against a single INF". WDF specific sections should be properly structured. For more information about WDF specific inf sections, please visit the following Microsoft web sites:

http://msdn.microsoft.com/en-us/library/aa510978.aspx

http://msdn.microsoft.com/en-us/library/aa490024.aspx

http://www.microsoft.com/whdc/driver/wdf/wdfbook.mspx

Run Time: < 1 minute
Log File: ScriptRunTestLog.txt and ScriptInstallDriverLog.txt
System Restart Required: No

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running WDF Logo Tests

Prerequisite

Before you can run the WDF Logo Tests- Final job, you must install the device and driver on the test client computer. Then, install and configure Driver Test Manager (DTM).

To run WDF Logo Tests - Final job, follow these steps:

  1. Open DTM Studio.

  2. 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.

  3. 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 on.

  4. In the Available Jobs pane, click the WDF Logo Tests - Final job.

  5. 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.

  6. Click Schedule Jobs.

Follow the progress of the WDF Logo Tests - Final 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.

Troubleshooting

For any failure cases, inspect the log files.

Code Tour

File Manifest

File | Location
WdfTester.exe | [testbinroot]\wdftest\bin\
WdfTester.sys | [testbinroot]\wdftest\bin\
WdfTesterScript.wsf | [testbinroot]\wdftest\bin\
WdfTester.inf | [testbinroot]\wdftest\bin\
Devcon.exe | [testbinroot]\idw


Audio Device Testing

This section describes how to test audio devices in order to qualify them for the Windows logo. To complete logo testing, you must install and run Device Test Manager (DTM) and setup your testing environment. For information on installing and configuring DTM, see Install the DTM.

This section includes:

Audio Device Testing Overview

Communication Testing Overview

Audio System Effect Audio Processing Objects Testing Overview

Audio Device Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Audio Device Testing Overview

The procedures that are presented in this section outline the process for testing your audio device for correct functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that 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.

Note : A set of HD Audio Class Driver Tests will re-run various audio device tests to test the compliance these devices with the Microsoft HD Audio Class Driver.

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 Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

Note You must use the latest version of the WLK to compile your driver in order for it to pass testing and obtain a logo.

Audio 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 the Audio Device Tests.

Run time: Four hours

Hardware Requirements

The following hardware is required for Audio 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.

  • The device to be tested.

  • Audio Precision System Two analyzer (AP Device) (used for the Fidelity Test).

  • Two computers with the following:
    • One x86-based or x64-based processor with a minimum speed of 450 MHz
    • 512 MB of RAM
    • One 17-inch monitor with at least 1024x768x24 bits per pixel (BPP) resolution
    • One AGP or PCI display adapter

  • 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.

  • All audio devices must be plugged in during audio testing.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

The following software is required to run the Audio Device tests:

  • One of the following operating systems:
    • Windows 7
    • Windows Vista
    • Microsoft Windows XP Professional with Service Pack 2 (SP2)
    • Microsoft Windows Server 2003 with Service Pack 1 (SP1), Enterprise Edition
    • Microsoft Windows Server 2003 with SP1, Standard Edition
    • Microsoft Windows XP. Professional x64 Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Standard x64 Edition
    • Microsoft Windows Server 2008 R2

  • Any drivers that are not shipped with the operating system

  • The current release of the Windows Logo Kit (WLK)

  • Audio Precision System Two software

  • For loopback tests, loopback cables must be plugged into all jacks under testing, linking the render jacks to the capture jacks .
  • For in-air tests, a microphone or other active capture source (such as an S/PDIF cable attached to an AVR actively playing back audio) must be attached to all capture endpoints. In addition, speakers or headphones must be attached to all render endpoints.

Tester Knowledge Requirements

To run the Audio Device tests, testers must know how to accomplish the following tasks:

  • Install the audio device hardware

  • Install the manufacturer-supplied device driver, if necessary.

  • Install the operating system from the product DVD.

  • Install the WLK.

This section includes:

Preparing for the Audio Device Testing

Running the Audio Device Tests

For a development resource for Audio System Effect Audio Processing Objects testing, see the Microsoft DirectX Software Development Kit (SDK).


Preparing for the Audio 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 Audio Device Testing Overview.

Many of the tests in the Windows Logo 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 How to turn on automatic logon in Windows XP.

Test System Configuration

To configure the test system for audio device testing:

  1. Install the appropriate Microsoft Windows operating system on the test system.

  2. Install the hardware to be tested on the test system.

  3. Install the manufacturer-supplied device driver, if necessary, on the test system.

  4. Set up the device configuration that is specified in the Fidelity Test Setup section.

  5. Check that the capture device functions properly on the test system.

  6. If appropriate, enable autologon functionality.

  7. Set up DTM.

  8. After you set up the DTM controller and create a machine pool, move the client to that pool.


Running the Audio Device Tests

To run the logo tests and create a submission cabinet file to send to WHQL for logo approval, either run the logo tests from a previously saved device job schedule file, or create a new submission. These procedures are as follows:

Run the Logo Tests from a Previously Saved Device Job Schedule File

  1. Open a Device Console window from the Explorers menu.

  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.

Use the Create New Submission Wizard to Select and Run Logo Tests

  1. Open a Device Console window from the Explorers menu.

  2. Select your DTM controller from the drop-down box at the upper left of the Device Console window.

  3. Click the Submission option button in the View By section.

  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 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 a Device Submission, then select the logo program "Audio -> System Effect Audio Processing Objects", 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 systems to use for the submission, and then click Next.
    6. If the device has its own drivers, select the location in the Driver Install File control and then click Finish.

  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 that you selected.

  7. 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 button.
  8. Monitor logo test progress:
    1. Observe logo test progress by using Job Monitor, and manually intervene if required by test.
    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.

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

The following tests should be listed in the Audio job list:

  • AC3 Test

  • Audio Power Management (Lullaby)

  • DRM Test - Vista (Manual)

  • Fidelity Test - Premium (Manual)

  • Fidelity Test - Standard (Manual)

  • Full Duplex Test - Premium (Manual)

  • Full Duplex Test - Standard (Manual)

  • General Audio Test

  • KS Position Test

  • KS Topology Test

  • Midi Driver Test

  • Round Trip Test - Win 7 (Manual)

  • SysFX Test

  • UAA Test - Vista

  • Wave Test - Premium

  • Wave Test - Standard


Troubleshooting Audio Testing

Some audio device vendors use a 4-ring combo jack, which uses headsets similar to those used for the iPhone. Normal MIC or HP plugs have the following 3 contacts (TRS): tip: left, ring: right, and sleeve: ground. The combo headset has the following 4 contacts (TRRS): tip: left, ring1: right, ring2: ground, and sleeve: mic. These combo jacks are connected to two ports on the codec simultaneously, and therefore need to trigger two jack detect signals simultaneously.

There is a known issue with the HDAudio.sys driver on Windows 7 and Windows Vista. It does not correctly handle simultaneous, or near-simultaneous jack detect signals. This issue can be worked around by plugging the device into the jack more slowly.


Audio System Effect Audio Processing Objects Testing Overview

The procedures that are presented in this section outline the process for testing your Audio System Effect Audio Processing Objects device for correct 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 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 Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Audio System Effect Audio Processing Objects Tests

The tests that you need to run depend on the capabilities of the device or system that you are testing. To see the complete list of tests that could be required for your device, see the Audio System Effect Audio Processing Objects Tests.

Run time: less than 10 minutes

Hardware Requirements

The following hardware is required for Audio System Effect Audio Processing Objects 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.

  • The device to be tested.

  • One computer with the following:
    • x86-based or x64-based processor with a minimum speed of 450 MHz
    • 512 MB of RAM
    • One AGP or PCI display adapter
    • One 17-inch monitor with at least 1024x768x24 bits per pixel (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.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

The following software is required to run the Audio System Effect Audio Processing Objects tests:

  • Windows 7

  • Windows Vista

  • Any drivers that are not shipped with the operating system

  • The current release of the Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the Audio System Effect Audio Processing Objects tests, testers must know how to accomplish the following tasks:

  • Install the Audio System Effect Audio Processing Objects device hardware.

  • Install the manufacturer-supplied device driver, if necessary.

  • Install the operating system from the product DVD.

  • Install the WDK.

This section includes:

Preparing for the Audio System Effect Audio Processing Objects Testing

Running the Audio System Effect Audio Processing Objects Tests

For a development resource for Audio System Effect Audio Processing Objects testing, see the Microsoft DirectX Software Development Kit (SDK).


Preparing for the Audio System Effect Audio Processing Objects 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 Audio System Effect Audio Processing Objects Testing Overview.

Many of the tests in the Windows Driver Kit (WDK) 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 How to turn on automatic logon in Windows XP.

Test System Configuration

To configure the test system for Audio System Effect Audio Processing Objects testing:

  1. Install the appropriate Microsoft Windows operating system on the test system.

  2. Install the hardware to be tested on the test system.

  3. Install the manufacturer-supplied device driver, if necessary, on the test system.

  4. Check that the device functions properly on the test system.

  5. If appropriate, enable autologon functionality.

  6. Set up DTM.

  7. After you set up the DTM controller and create a machine pool, move the client to the pool you just created.


Running the Audio System Effect Audio Processing Objects Tests

To run the logo tests and create a submission cabinet file to send to WHQL for logo approval, use one of the following procedures:

Run the Logo Tests from a Previously Saved Device Job Schedule File

  1. Open a Device Console window from the Explorers menu.

  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.

Use the Create New Submission Wizard to Select and Run Logo Tests

  1. Open a Device Console window from the Explorers menu.

  2. Select your DTM controller from the drop-down box at the upper left of the Device Console window.

  3. Click the Submission option button in the View By section.

  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 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 a Device Submission, then select the logo program "Audio -> System Effect Audio Processing Objects", 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 systems to use for the submission, and then click Next.
    6. If the device has its own drivers, select the location in the "Driver Install File" control and then click Finish.

  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 that you selected.

  7. 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 button.
  8. Monitor logo test progress:
    1. Observe logo test progress by using Job Monitor, and manually intervene if required by test.
    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.

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

The following test should be listed in the Audio System Effect Audio Processing Objects job list:

  • SysFX Test


Audio Device Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


AC-3 Test

Type: Automated Test

Overview

The AC-3 test checks to make sure that audio devices that support the AC-3 format comply with the Microsoft Windows Logo Kit (WLK) documentation.

Details

The AC-3 test ensures that each enumerated KSCATEGORY_AUDIO and KSCATEGORY_RENDER filter that exposes AC-3 format pins complies with the WLK documentation that is related to implementing AC-3 format pins. Also, this test ensures that the filter does not prevent support for AC-3 streaming through the wave and Microsoft DirectSound APIs.
Run Time:
Log File: AC3Test.log
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 AC-3 Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP, which you should consider to be PASS for the overall test if there are no AC-3 compatible devices present on the system. If the test does not detect AC-3 devices and the hardware does support it, a problem exists with the way that the pin in the filter of the specific device advertises itself.

Command Syntax

Command option | Description
Ac3Test.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to be tested.
wdk_ac3test.pro | The .profile file of test cases to be run.

Code Tour

File Manifest

File | Location
Ac3Test.exe | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\


Audio KS Position Test

Type: Automated Test

Overview

Audio KS Position Test ensures that an audio device and driver accurately implement audio render position for stream synchronization.

Details

This test requires that an audio device and driver are installed on a test system. The test exercises the audio device and calls GetPosition on the Kernel Streaming (KS) filter to ensure the position is reported accurately.

All test cases return PASS or FAIL. You should review the test results in the generated log file for specific details about failures.

This test is installed as part of the Microsoft Windows Logo Kit (WLK) (Audio) kit.

Run Time: 10 minutes
Log File: kspostest.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 KS Position Test

Command Syntax

Command option | Description
kspostst.exe | Without any options, starts the user interface
-c [string] | Starts the application and runs the test cases that are specified in the profile file (.pro) that [string] specifies.
-h [string] | Specifies the Plug and Play (PnP) ID of the device to test. Default is all devices.

Code Tour

File Manifest

File | Location
kspostst.exe | [testbinroot]\nttest\multimediatest\avcore\audio\wdk\


Audio Logo Test

Type: Automated Test

Overview

This test hosts test cases for audio devices on generic streaming of audio.

Details

Run Time: 5 minutes
Log File: AudioLogo.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: AudioLogo.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running Audio Logo Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test should return PASS if :

  1. Render to all audio endpoints simultaneously is successful

  2. There exists a nearby associated hardware mute control on compressed endpoints

  3. All audio render endpoints successfully render stream in exclusive pull mode

  4. All audio capture endpoints successfully capture stream in exclusive pull mode

Command Syntax

Command option | Description
AudioLogo.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to be tested.
logo_win7_audiologo.pro | The .profile file of test cases to be run.

Code Tour

File Manifest

File | Location
AudioLogo.exe | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\


Audio Power Management (Lullaby)

Type: Automated Test

Overview

The Lullaby test verifies audio during power state transitions.

Details

Lullaby plays audio before, during, and after transitions into Sleep and Hibernate power states to verify the integrity of the audio pipeline.

This test is installed as part of the WLK (Audio) kit. The test uses Microsoft DirectSound and the wave API to play audio, calls ACPI functions to put the computer into a low-power state, and awakens the computer by using a waitable timer event. The test then verifies that audio still plays correctly.

All test cases return PASS or FAIL. The test will return FAIL if it does not detect an audio device, if it cannot set the power state of the machine, or if the audio pipeline is in an inconsistent state after. Review the test results in the generated log file for specific details about failures.

Run Time:
Log File: Lullaby.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 Power Management (Lullaby)

Depending on BIOS, the test might require user-intervention. If BIOS does not support sleep-wake and hibernate-wake, you will need to bring the computer out of sleep states for the test to continue.

Command Syntax

Command option | Description
lullaby.exe | Without any options, opens the graphical user interface (GUI).
-c [string] | Starts the application and runs the test cases that are specified in the .pro file that [string] specifies.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device for the test cases to use. The default value is all devices.

Code Tour

File Manifest

File | Location
lullaby.exe | [testbinroot]\nttest\multimediatest\avcore\audio\wdk

Test Assertions

Render works with S4 state
Test Assertion GUID: ED3EF886-C436-46B2-B666-38E19BFA66FA

Windows Logo Program: AUDIO-0026 Audio device complies with related power management specifications

Capture works with S4 state
Test Assertion GUID: BAB06254-6C73-4346-8C50-84CFF154035F

Windows Logo Program: AUDIO-0026 Audio device complies with related power management specifications


Audio SysFX Test

Type: Automated Test

Overview

The Audio SysFX test is a test for SysFx (both Global Fx [GFx] and Local Fx [LFx]) audio processing object (APO) implementation. This test verifies the correct behavior of APO and more strict guidelines specifically for SysFx.

Details

The Audio SysFX test is a certification test for audio device drivers, specifically for audio drivers that install SysFx (a GFx, a LFx, 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 combinations. By default, all such SysFx are selected; you can enable or disable a tested SysFx through the Select Devices command in the Options menu.

The Audio SysFX tests include:

  • General tests that verify any interface support that the APO claims.

  • IAudioProcessingObject tests that verify each method on this interface for correct behavior.

  • IAudioProcessingObjectRT tests that verify each method on this interface for correct behavior.

  • Certification tests that verify 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Command Syntax

Command option | Description
ExtFxTst.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the profile file (.pro).
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to test.
ExtFxTst_WDK.pro | The profile file (.pro) of the test cases to run.

Code Tour

File Manifest

File | Location
ExtFxTst.exe | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\

Test Assertions

AUDIO-0048 System effect APOs comply with Windows Protected Environment conformance and compliance criteria
Test Assertion GUID: a9c09f20-b573-4f91-a2ac-abc1154f0389

Windows Logo Program: AUDIO-0048 System effect APOs comply with Windows Protected Environment conformance and compliance criteria

Additional Information: This test verifies that the appropriate Audio Processing Object (APOs) are loaded into the system effect infrastructure by the audio device driver. The INF file must be signed with a certificate that indicates conformance and compliance with the robustness rules of the Windows Protected Environment.


Bluetooth Audio Logo Test

Type: Manual Test

Overview

This test hosts test cases for Bluetooth audio devices.

Details

Run Time: 5 minutes
Log File: Shellrunner.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: Shellrunner.exe and BTAudLogo.dll

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running Bluetooth Audio Logo Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test will return PASS if:

  1. Bluetooth audio device and driver supports one or more of the following Bluetooth profiles: Handsfree Profile (HFP), Advanced Audio Distribution Profile (A2DP), Audio/Video Remote Control Profile (AVRCP)

  2. Bluetooth audio device supports Major/Minor Class of Device identifier and accurately refect form factor/primary usage

  3. The device and third party driver supports "Windows 7 HID Call Control" specification appropriately

  4. Bluetooth audio device paired with a PC will automatically attempt to reconnect to the PC after they are powered up or come back into range

  5. Bluetooth audio deivce will complete an HCIDisconnect before powering down

The test will return SKIP if no Bluetooth device that supports the aforementioned Bluetooth profiles is enumerated on the system.

Command Syntax

Command option | Description
Shellrunner.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to be tested.
logo_win7_btaudlogo.pro | The .profile file of test cases to be run.

Code Tour

File Manifest

File | Location
shellrunner.exe | [testbinroot]\nttest\multimediatest\common\
BTAudLogo.dll | [testbinroot]\nttest\multimediatest\avcore\audio\wdk


Digital Rights Management Test

Overview

The Digital Rights Management (DRM) test verifies that a device and driver properly protect the copyrighted digital audio stream.

Details

The 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 test focuses 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 more information about the DRM implementation in the Microsoft Windows operating system, please refer to the "Digital Rights Management" section for Streaming Devices in the Windows Logo Kit (WLK).

Run Time:
Log File: DRMTest.log
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • If the sound card has S/PDIF output, a receiver with S/PDIF input or a speaker with S/PDIF input is required.
  • All audio loopback cables and microphones must be disconnected, before running the test.
Processor
  • x86

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 application and runs the test cases that are specified in the profile file (.pro).
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to that you are testing.
wdk_drmtest.pro | The profile file (.pro) of the test cases to run.

Code Tour

File Manifest

File | Location
DRMTest.exe | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\


Fidelity Test

Type: Manual Test

Overview

Fidelity Test verifies hardware audio fidelity by using an Audio Precision (AP) System Two or AP2700 series analog analyzer and analog generator.

Note If you are using an AP System Two analyzer, an S-AES17 "Special Lowpass filter" filter is also required.

The test allows exporting a signed copy of the log, which can be imported in subsequent runs. These subsequent runs would not need to be done in physical proximity to the AP analyzer/generator. The pass/fail result of the subsequent runs would be the same as the initial exporting run.

Details

Fidelity Test will verify that the audio device meets the Microsoft Windows Logo Program requirements for a high-fidelity audio playback/recording experience. To verify the playback experience, the test plays a tone that is analyzed by an Audio Precision analyzer that is connected to the analog output jack of the system; to verify the recording experience, the test plays a tone from the Audio Precision generator that is connected to the analog input 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 test system to play a signal while the analyzer listens. This coordination happens over the local network.

Fidelity Test takes eight measurements on analog outputs:

  • Output level. The test plays a digital full-scale signal and verifies that it meets the Full-Scale Output Voltage requirement in the Windows Logo Program Device Fidelity Requirements.

  • Dynamic range. The test takes a noise floor measurement in the presence of a signal per AES-17 and verifies that the measurement meets the Dynamic Range requirement in the Windows Logo Program Device Fidelity Requirements.

  • THD+N. The test takes a THD+N measurement and verifies the measurement per the Windows Logo Program Device Fidelity Requirements document.

  • Magnitude response. The test measures the frequency response of the device and verifies it meets the Magnitude Response requirement in the Windows Logo Program Device Fidelity Requirements.

  • Phase Delay. The test measures the interchannel phase delay and verifies that it meets the requirements.

  • System Activity. The test measures the noise level of the system during system activity (GPU activity, disk activity, etc.) and verifies that it meets the requirements.

  • Skew. The test plays a high-frequency tone with strong settling parameters and verifies via the analyzer that the fundamental frequency is within the requirement of the expected value.

  • Power State Transition. The test measures the noise level of the system during transition to low power and back to normal audio playback.

Fidelity Test also takes five measurements on analog inputs:

  • Input level. The test plays analog signals of varying voltages into the recording jack and attempts to find the voltage that induces a full-scale signal (or equivalent, per AES6) in the digital domain.

  • Skew. The test captures a large sample of a high-frequency tone generated from the analyzer and verifies via DSP that the fundamental frequency is within the requirement of the expected value.

  • THD+N. The test captures a signal and measures the THD+N via DSP. It then validates that the noise level is lower than the requirement allows.

  • Dynamic range. The test captures a signal and takes a noise measurement, and verifies that the dynamic range is at least as big as the requirement requires.

  • Frequency response. The test captures signals at various frequency levels and verifies that the measured intensity of the signal does not vary more than the requirement allows.

All test cases return PASS or FAIL, and the generated log file contains the actual measurement that is recorded.

Fidelity Test requires special hardware to run. The test requires the presence of a System Two series or an AP2700 series audio analyzer/generator from Audio Precision. For information about the Audio Precision analyzer that is used for Fidelity Test, see Audio Precision Machine Requirements.

Fidelity Test will test only:

  • Analog line out jacks.

  • Analog headphone jacks.

  • Analog speaker jacks.

  • Analog line in jacks.

  • Analog microphone jacks.

Integrated speakers and integrated microphones are not tested; neither are digital jacks such as S/PDIF or HDMI.

When importing:

  • The AP analyzer/generator is not necessary. However, when you are running this test under DTM, you will still need a second computer for the job to be scheduled. This requirement is because DTM considers this job a "two-machine job". There is currently no capacity in DTM to have a machine to be a "two-machine job" sometimes and a "one-machine job" at other times.

  • Fidelity Test will check the audio hardware in the system under test against the audio hardware in the log that is being imported. If they do not match, the import will be rejected and the job will fail.

  • If an HD Audio device has jack presence detection, ensure that the system under test has the same audio endpoints plugged in during import as were plugged in when the export job started; otherwise, the test might result in unexpected failure.

For more information, see

Audio Fidelity Testing

Windows Logo Kit

Run Time: 30 minutes
Log File:
System Restart Required: Maybe
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

  • Software Requirements

    The test tool requires the following software:

    • Supported operating system (see list above).
    • Software components included with the device that is being tested.
    • Audio Precision APWin or AP2700 software

  • Supported Software

  • Hardware Requirements
    • Device to be tested
    • Computer that meets the minimum software requirements
    • Windows keyboard
    • Two-button pointing device
    • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
    • Hard drive with a minimum of 20 GB available on partition C:
    • Test requires a second computer (AP Host)
    • Audio Precision System Two series or AP2700 series analyzer connected to AP Host. See Audio Precision Machine Requirements
    • Audio cables connecting test system to Audio Precision analyzer. Stereo 3.5mm male on PC end. Dual mono BNC male on AP analyzer end. Shielded cable is recommended to reduce interference with audio signal. Four cables are recommended - two for capture, two for render.
  • Processor
    • x86
    • x64

Running Fidelity Test

This test requires the following systems:

  • System Under Test (SUT)

  • Audio Precision host (AP host)

  • Audio Precision System Two analyzer/generator (AP analyzer).

This test requires the following binaries:

  • FidelityTest.dll

  • sndanlyz.dll

  • rws.exe

  • FidelityTestApp.exe

  • Wttlog.dll

  • SetDevicePower.exe

You should set up the following connections:

  • The AP host is connected to the AP analyzer/generator per the Audio Precision manual.

  • The AP host and SUT are connected to a common LAN.

  • The SUT stereo Line-Out or Speaker jack is connected to a dual BNC unbalanced analog inputs on the AP analyzer.
    • Left Channel (tip connector) connects to Channel A on the AP analyzer.
    • Right Channel (ring connector) connects to Channel B on the AP analyzer.
  • The SUT stereo Line-In or Microphone jack is connected to a dual BNC unbalanced analog outputs on the AP generator.
    • Left Channel (tip connector) connects to Channel A on the AP generator.
    • Right Channel (ring connector) connects to Channel B on the AP generator.

Previous versions of Fidelity Test required changing the default format from 44100 Hz to 48000 Hz. This is no longer necessary, as Fidelity test now plays in exclusive mode.

Test Setup for Manual Runs

  1. Ensure that ApWin or Ap2700 software is installed on the AP host per Audio Precision manual.

  2. Copy all binaries to the SUT and AP host.

  3. regsvr32 fidelitytest.dll on both SUT and AP host.

  4. Previous versions of Fidelity Test required adding firewall exceptions. This is no longer necessary, as the firewall exceptions are added by fidelitytest.dll when it is regsvr32'd, and by fidelitytestapp.exe when it is run.

  5. "SetDevicePower /conserveidle:2 /performidle:2" to configure audio device for a short duration for idle timeout.

  6. Log in the same user on both machines.

    • If machines are not on a domain, use the same username and password on both machines.
    • If the machines are on a domain, they must be on the same domain. The logged-in user can either be a domain user (the same domain user on both machines,) or it can be a local user (use the same username and password on both machines.)
    • This user must be in the Administrators group on both machines.

Test Setup for Automatic Runs

  1. Ensure that ApWin or Ap2700 software is installed on the AP host per Audio Precision manual.

  2. Previous versions of Fidelity Test required adding firewall exceptions. This is no longer necessary, as the firewall exceptions are added by fidelitytest.dll when it is regsvr32'd, and by fidelitytestapp.exe when it is run.

  3. Log in the same user on both machines.
    • If machines are on a domain, the user should be a domain user.
    • If machines are not on domain, use the same username and password on both machines.
    • This user must be in the Administrators group on both machines.

Command Syntax

Command option | Description
FidelityTestApp.exe /? | Shows usage instructions
FidelityTestApp.exe /import <filename> [ <premium-switches> ] [ <mobile-switches> ] [ -h <device-id> ] | Imports test results from previously /exported file
FidelityTestApp.exe /aphost <aphostname> <testswitch> [ <premium-switches> ] [ <mobile-switches> ] [ /export <filename> ] [ -h <device-id> ] | Runs test(s) using AP Host computer specified by <aphostname>
<testswitch> | /alltests or a specific test (see fidelitytestapp.exe /?)
<basic-switches> | Optional - either /basic or /premium (/basic is default)
<mobile-switches> | Optional - either /desktop or /mobile (/desktop is default)
<device-id> | For the device kit only - the PnP Hardware Id of the device being tested
SetDevicePower.exe | Displays usage instructions.
SetDevicePower.exe [/conserveidle:t] [/powerstate:x] [/performidle:t] | Sets audio device to new power settings, where x is the power state and t is measured in seconds. If a parameter is omitted, it is not changed.
SetDevicePower /restore | Reverts back to previous settings from any changes above.

Troubleshooting

The System Activity Test can fail with the following error:" Process returned error code -1". To understand the cause of the failure, review the system activity *.log file in the C:\WTT\JobsWorkingDir\Tasks\{GUID} folder on the test machine immediately after the test fails. One possible cause of this error is that the Standard VGA graphics driver is installed instead of the graphic card vendor's featured driver.

For more information about connecting the AP analyzer to the AP Host machine, see Audio Precision SYS-2722A Audio Analyzer and the documentation that came with the AP analyzer.

Code Tour

File Manifest

File | Location
fidelitytestapp.exe, fidelitytest.dll | [testbinroot]\nttest\multimediatest\avcore\audio\wdk
sndanlyz.dll | [testbinroot]\nttest\multimediatest\common
rws.exe | [testbinroot]\nttest\multimediatest\wmmftest
SetDevicePower.exe | [testbinroot]\nttest\multimediatest\avcore\audio\bin

Test Assertions

Output Level Test
Test Assertion GUID: 431F41DF-90E5-48a6-AE70-AC67D326FF90
Windows Logo Program: AUDIO-0025 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The Output Level Test plays a digital full-scale signal and verifies that it meets the Full-Scale Output Voltage requirement in the Fidelity Requirements (AUDIO-0025 for basic, AUDIO-0006 for premium). This test returns PASS or FAIL, and the generated log file contains the actual measurement that is recorded.
Dynamic Range Test
Test Assertion GUID: 5B568BFE-0EEC-42f3-AA9A-72332E4D6683
Windows Logo Program: AUDIO-0025 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The Dynamic Range Test takes a noise floor measurement in the presence of a signal per AES-17 and verifies that the measurement meets the Dynamic Range requirement in the Fidelity Requirements (AUDIO-0025 for basic, AUDIO-0006 for premium). This test returns PASS or FAIL, and the generated log file contains the actual measurement that is recorded.
Assertion Friendly ID THD+N Test
Test Assertion GUID: 26343FFF-6A8A-42a2-BBA2-6626DD6D3F64
Windows Logo Program: AUDIO-0025 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The THD+N Test takes a THD+N measurement and verifies the measurement according to the Fidelity Requirements (AUDIO-0025 for basic, AUDIO-0006 for premium). This test returns PASS or FAIL, and the generated log file contains the actual measurement that is recorded.
Assertion Friendly ID Magnitude Response Test
Test Assertion GUID: 41F5B9E4-3DFE-409b-8DB7-951CCB9D3E94
Windows Logo Program: AUDIO-0025 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The Magnitude Response Test measures the frequency response of the device and verifies that it meets the Magnitude Response requirement in the Fidelity Requirements (AUDIO-0025 for basic, AUDIO-0006 for premium). This test returns PASS or FAIL, and the generated log file contains the actual measurement that is recorded.
Phase Delay Test
Test Assertion GUID: B36AD902-F1E7-46e6-B796-04F5CC84E1C1
Windows Logo Program: AUDIO-0025 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The Phase Delay test measures the interchannel phase delay of the device and verifies that it meets the Phase Delay requirement.
System Activity Test
Test Assertion GUID: D835D386-FABB-43a9-BAF5-04EFF72BB6C5
Windows Logo Program: SYSFUND-0118 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The System Activity test measures the noise level of the system during system activity and verifies that it meets the System Activity noise requirement.
Input Level Test
Test Assertion GUID: 83821130-73F5-40cd-9E75-A6202F843ABA
Windows Logo Program: AUDIO-0025 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The Input Level test measures the input voltage necessary to induce a full-scale digital wave form and verifies that it meets the Input Level requirement.
Capture Skew Test
Test Assertion GUID: D826A360-86C1-4155-AE29-195046F72951
Windows Logo Program: AUDIO-0025 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The Capture Skew Test measures the skew on a capture device and verifies that it meets the "Sampling frequency accuracy" requirement.
Capture THD+N test
Test Assertion GUID: B71269B4-A766-4ad1-98BE-A21728DE036D
Windows Logo Program: AUDIO-0025 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The Capture THD+N test measures the THD+N on a capture device and verifies it meets the THD+N requirement.
Capture Dynamic Range test
Test Assertion GUID: EF7DB2F7-851E-4170-AF4B-A15B9C1D2357
Windows Logo Program: AUDIO-0025 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The Capture Dynamic Range test measures the dynamic range on a capture device and verifies it meets the Dynamic Range requirement.
Capture Frequency Response test
Test Assertion GUID: 447EFEE5-114C-41cd-BF15-F1656DA418CF
Windows Logo Program: AUDIO-0025 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The Capture Frequency Response test measures the magnitude/frequency response of a capture device and verifies it meets the THD+N requirement.
Render Skew Test
Test Assertion GUID: {BE51C25A-47CC-4834-9FA1-A4C2425A9C80}
Windows Logo Program: AUDIO-0025 Digital audio record and playback meet basic performance requirements for audio device
Additional Information: The Render Skew Test measures the skew on a render device and verifies that it meets the "Sampling frequency accuracy" requirement.

Render Power Transition Test
Test Assertion GUID: 4B84A808-6E1B-48C8-9B27-B2B2B83DD1BC
Windows Logo Program: SYSFUND-0050 System employs anti-pop measures on all system audio outputs
Additional Information: The Render Power Transition test measures the noise level of the system while it transitions to a low power state and returns to normal playback state.


Full Duplex test

Type: Automated Test

Overview

The Full Duplex (FDuplex) test verifies the ability of the audio system to perform simultaneous capture and rendering. The test enumerates through audio device endpoints, finds a matching pair, and performs automated verification or captured signal vs. rendered signal.

Details

The test uses three APIs for rendering and capture: Microsoft DirectSound, WaveIn/Out, and Kernel streaming. The following configurations are tested:

  • DirectSound/DirectSound Capture

  • DirectSound/WaveIn

  • WaveOut/WaveIn

  • WaveOut/DirectSound Capture

  • Kernel Streaming

For every configuration, the test tries two scenarios:

  • Create capture first, and then render.

  • Create the render first, and then capture

For every scenario, the test cycles though most common PCM formats (ranging from 3kHz through 100kHz). You can select which combinations and which formats to try. In all cases, FDuplex tries to establish a verified connection between two endpoints. It cycles through devices and endpoints, sends a sine signal to the render device, reads data from the capture device, and checks if RMS is no larger than -10dB. After the matching pair of endpoints is established, the test continues to cycle though various PCM formats and duplex scenarios.

Run Time: 20
Log File: fduplex.log and fduplex.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • loopback cable (from LineOut to LineIn, or from LineOut to Microphone)
Processor
  • x86
  • x64
  • Itanium

Running Full Duplex test

In Control Panel, mark the test audio devices as "selected".

Install the manual loopback cable.

Command Syntax

Command option | Description
fduplex -loopback [-c profile.pro] |

Cautions

Do not run in parallel with another audio-configuring programs. Do not alternate audio settings and connections unless the test prompts you.

Test Assertions

Test Assertion GUID:
Windows Logo Program: AUDIO-0024 Audio subsystem supports full duplex operation


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 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.

The KS Topology test checks:

  • Nodes 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 to see if their messages are well formatted and behave as expected. The test checks KSPROPERTY_DESCRIPTION values, including the Access flags and the KSPROPERTY_MEMBERSHEADER structure for channel properties. Also the test makes sure that each channel exists and functions within the specified ranges.

  • Pins 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 to make sure that the connections between nodes (internal connections) and between filters (physical connections) 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 on failures.

Command Syntax

Command option | Description
KsTopTest.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases specified in the .profile
-h [string] | Specifies the PnP ID of the device to be tested
KsTopTest.pro | The profile of test cases to be run

Code Tour

File Manifest

File | Location
KsTopTest.exe | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\


MIDI Driver Test

Type: Automated Test

Overview

The MIDI Driver Test (MIDDRV32) ensures that an audio device complies with the Multimedia SDK documentation that is related to the MIDI family of multimedia APIs.

Details

This test requires that an audio device and driver are installed in a test system. You must attach a MIDI loopback cable to the device that you are testing.

This test enumerates all MIDI in/out devices by using the midiOutGetNumDevs and midiInGetNumDevs APIs.

Depending on the type of devices that are found (In/Out), the test dynamically decides to run the appropriate test cases.

The application tests for Device Control, Buffer Preparation, MIDI Recording, SysEx Message Recording, and so on.

All test cases return PASS, FAIL or PENDING. You should 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.

This test is installed as part of the Microsoft Windows Logo Kit (WLK) (Audio) kit.

Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software RequirementsThe test tool requires the following software:
  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • MIDI device
Processor
  • x86
  • x64
  • Itanium

Running MIDI Driver Test

Command Syntax

Command option | Description
middrv.exe | Without any options, the test starts the user interface.
-c [string] | Starts the application and runs the test cases that are specified in the profile file (.pro) that [string] specifies.
-h [string] | Specifies the Plug and Play (PnP) ID of the device to test. The default value 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\

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:
Windows Logo Program: Anonymous
Additional Information: The dwSupport field must be 0. The szPname field must be null-terminated. The wMid (Manufacturer ID) field and wPid (Product ID) field must both be registered with Microsoft. The vDriverVersion field must not equal 0.
16.10.2 MIDM_GETDEVCAPS with various sizes of MIDIINCAPS
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: On a call to midiInGetDevCaps, the device must populate the memory that the lpMidiInCaps parameter points to with no more than the number of bytes that the cbMidiInCaps parameter specifies. cbMidiInCaps could even be 0. The device must not cause midiInGetDevCaps to return anything other than MSYSERR_NOERROR in this scenario.
16.10.3 MODM Get Device Capabilities - The device must correctly populate the MIDIOUTCAPS structure on a call to midiOutGetDevCaps.
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: The szPname field must be null-terminated. The wMid (Manufacturer ID) field and wPid (Product ID) field must both be registered with Microsoft. The vDriverVersion field must not equal 0. If the device reports that it is external (wTechnology field equals MOD_MIDIPORT), the wVoices field must equal 0, the wNotes field must equal 0, the wChannelMask field must equal 0xFFFF, and the dwSupport field must not have the MIDICAPS_VOLUME, MIDICAPS_LRVOLUME, nor the MIDICAPS_CACHE flags set. If the device reports that it is internal (wTechnology field equals MOD_SYNTH), the wVoices field must be greater than 0, the wNotes field must be greater than 0, and the wChannelMask field must not equal 0. If the device has set the MIDICAPS_CACHE flag in the dwSupport field, it must force neither midiOutCachePatches nor midiOutCacheDrumPatches to return MMSYSERR_NOTSUPPORTED.If the MIDICAPS_CACHE flag was not set, the device must force neither midiOutCachePatches nor midiOutCacheDrumPatches to return MMSYSERR_NOERROR. If the device has set the MIDICAPS_VOLUME flag or the MIDICAPS_LRVOLUME flag in the dwSupport field, it must force neither midiOutGetVolume nor midiOutSetVolume to return MMSYSERR_NOTSUPPORTED. If neither the MIDICAPS_VOLUME flag nor the MIDICAPS_LRVOLUME flags were set, the device must force neither midiOutGetVolume nor midiOutSetVolume to return MMSYSERR_NOERROR.
16.10.4 MODM Get Device Capabilities with various sized MIDIOUTCAPS
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: On a call to midiOutGetDevCaps, the device must populate the memory pointed to by the lpMidiOutCaps parameter with no more than the number of bytes specified by the cbMidiOutCaps parameter. cbMidiOutCaps could even be 0. The device must not cause midiOutGetDevCaps to return anything other than MMSYSERR_NOERROR in this scenario.
16.10.5 MIDM_OPEN and MIDM_CLOSE with function callback
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: When opening an input device with a MidiInProc callback function specified in the dwCallback parameter and the CALLBACK_FUNCTION flag set in the dwFlags parameter of the midiInOpen call, the MIM_OPEN and MIM_CLOSE messages must be passed in the wMsg parameter of the specified callback function when calling midiInOpen and midiInClose respectively. The hMidiIn parameter of the callback function must be the same as the MIDI input device handle obtained from the call to midiInOpen. The dwInstance parameter of the callback function must be the same as the dwInstance parameter passed to midiInOpen.
16.10.6 MIDM_OPEN and MIDM_CLOSE with window callback
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: When opening an input device with a window callback function specified in the dwCallback parameter and the CALLBACK_WINDOW flag set in the dwFlags parameter of the midiInOpen call, the MM_MIM_OPEN and MM_MIM_CLOSE messages must be passed in the Msg.message parameter of the specified window callback function when calling midiInOpen and midiInClose respectively. The Msg.wParam parameter of the window callback function must be the same as the MIDI input device handle obtained from the call to midiInOpen.
16.10.7 MIDM_OPEN and MIDM_CLOSE with event callback
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: When opening an input device with an event handle specified in the dwCallback parameter and the CALLBACK_EVENT flag set in the dwFlags parameter of the midiInOpen call, the event must be signaled every time either midiInOpen or midiInClose is called.
16.10.8 MIDM_CLOSE while buffers are in the queue
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Calling midiInClose on an opened input device that contains incomplete buffers that are added through midiInAddBuffer must return MIDIERR_STILLPLAYING and must not perform a MIM_CLOSE callback.
16.10.9 MODM_OPEN and MODM_CLOSE with function callback
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: When opening an output device with a MidiOutProc callback function specified in the dwCallback parameter and the CALLBACK_FUNCTION flag set in the dwFlags parameter of the midiOutOpen call, the MOM_OPEN and MOM_CLOSE messages must be passed in the wMsg parameter of the specified callback function when calling midiOutOpen and midiOutClose respectively. The hMidiOut parameter of the callback function must be the same as the MIDI output device handle obtained from the call to midiOutOpen. The dwInstance parameter of the callback function must be the same as the dwInstance parameter passed to midiOutOpen.
16.10.10 MODM_OPEN and MODM_CLOSE with window callback
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: When opening an output device with a window callback function specified in the dwCallback parameter and the CALLBACK_WINDOW flag set in the dwFlags parameter of the midiOutOpen call, the MM_MOM_OPEN and MM_MOM_CLOSE messages must be passed in the Msg.message parameter of the specified window callback function when calling midiOutOpen and midiOutClose respectively. The Msg.wParam parameter of the window callback function must be the same as the MIDI output device handle obtained from the call to midiOutOpen.
16.10.11 MODM_OPEN and MODM_CLOSE with event callback
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: When opening an output device with an event handle specified in the dwCallback parameter and the CALLBACK_EVENT flag set in the dwFlags parameter of the midiOutOpen call, the event must be signaled every time either midiOutOpen or midiOutClose is called.
16.10.12 MIDM_PREPARE and MIDM_UNPREPARE with various buffer sizes
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: The MHDR_PREPARED flag must be set in the dwFlags field of the lpMidiInHdr parameter after a call to midiInPrepareHeader. The MHDR_PREPARED flag must be cleared from the dwFlags field of the lpMidiInHdr parameter after a call to midiInUnprepareHeader. The dwUser field of the lpMidiInHdr parameter must be changed by neither midiInPrepareHeader nor midiInUnprepareHeader.
16.10.13 MODM_PREPARE and MODM_UNPREPARE with various buffer sizes
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: The MHDR_PREPARED flag must be set in the dwFlags field of the lpMidiOutHdr parameter after a call to midiOutPrepareHeader. The MHDR_PREPARED flag must be cleared from the dwFlags field of the lpMidiOutHdr parameter after a call to midiOutUnprepareHeader. The dwUser field of the lpMidiOutHdr parameter must be changed by neither midiOutPrepareHeader nor midiOutUnprepareHeader.
16.10.14 MIDI Start while already recording short message
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertion 16.10.5 and the MIM_DATA message must be received for each MIDI message recorded. The correct MIDI messages must be received by the callback function in the same order they were sent to and recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with a time that is before the time it was sent. A second call to midiInStart must not reset the timestamp timer back to 0.
16.10.15 MIDI Start while already recording SysEx message
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertion 16.10.5 and the MIM_LONGDATA message must be received for each SysEx message recorded. The SysEx message received must be identical to the one sent. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the dwBytesRecorded field of the lpMidiOutHdr parameter of midiOutLongMsg. The SysEx messages must be received by the callback function in the same order they were sent to or recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with that is before the time it was sent. A second call to midiInStart must not reset the timestamp timer back to 0.
16.10.16 MIDI Start after recording is stopped
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertions 16.10.14 and 16.10.15, except when midiInStop is called after the first call to midiInStart but before the second call, the second call to midiInStart must reset the timestamp timer back to 0.
16.10.17 MIDI Start after recording is reset
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertions 16.10.14 and 16.10.15, except that instead of calling midiInStart a second time, midiInReset is called in its place. This action must reset the timestamp timer back to 0.
16.10.18 MIDI Start with no buffers to record SysEx message
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertion 16.10.5 and, because no buffers have been added to the input device through midiInAddBuffer, no callbacks must be received for any sent SysEx messages. The input device must ignore any received SysEx messages. MIDI messages, on the other hand must still be received correctly and generate the proper MIM_DATA callbacks.
16.10.19 MIDI Stop while recording SysEx message
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: If midiInStop is called when the input device still has an incomplete SysEx buffer, a MIM_LONGERROR callback must be received for that buffer. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the number of bytes received before midiInStop was called. The data that the lpData field of the lpMidiInHdr parameter points to must be identical to the data received before the midiInStop call. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter. Any empty buffers in the input queue must not have been returned to the callback. The MHDR_INQUEUE flag must be set and the MHDR_DONE flag must be clear in the dwFlags field of the lpMidiInHdr parameter for all empty buffers.
16.10.20 MIDI Stop after recording is reset
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: A call to midiInStop immediately after a call to midiInReset must return MMSYSERR_NOERROR. Any MIDI messages received before the call to midiInReset must generate the appropriate MIM_DATA callbacks.
16.10.21 MIDI Stop, verify recording stops
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Any MIDI messages sent after a call to midiInStop must not be recorded and must not generate any callbacks.
16.10.22 MIDI Reset while recording SysEx messages
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: If midiInReset is called when the input device still has an incomplete SysEx buffer, a MIM_LONGERROR callback must be received for that buffer. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the number of bytes received before midiInReset was called. The data pointed to by the lpData field of the lpMidiInHdr parameter must be identical to the data received before the midiInReset call. Any empty buffers in the input queue must be returned by MIM_LONGDATA callbacks after midiInReset is called. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter for all returned buffers, incomplete or complete. The incomplete buffer's timestamp must be based off of the call to midiInStart and not based off of the reset timer because of midiInReset.
16.10.23 MIDI Reset after recording is stopped
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertion 16.10.22 and a second call to midiInReset must return MMSYSERR_NOERROR.
16.10.24 MIDI Reset while recording short messages only
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Any MIDI messages sent after a call to midiInReset must not be recorded and must not generate any callbacks.
16.10.25 MIM DATA function callback verification
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertion 16.10.5 and the MIM_DATA message must be received for each MIDI message recorded. The correct MIDI messages must be received by the callback function in the same order they were sent to/recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with that is before the time it was sent.
16.10.26 MIM LONGDATA function callback verification
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertion 16.10.5 and the MIM_LONGDATA message must be received for each SysEx message recorded. The SysEx message received must be identical to the one sent. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the dwBytesRecorded field of the lpMidiOutHdr parameter of midiOutLongMsg. The SysEx messages must be received by the callback function in the same order they were sent to/recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with a time before the time it was sent.
16.10.27 MIM LONGERROR function callback verification
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: If an incomplete SysEx message is received, a MIM_LONGERROR callback must be received for that buffer. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the number of bytes received before midiInStop was called. The data pointed to by the lpData field of the lpMidiInHdr parameter must be identical to the data received before the time the midiInStop call. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter.
16.10.28 MIM LONGDATA without callbacks
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: When midiInOpen is called with dwCallback equal to NULL and dwFlags equal to CALLBACK_NULL, the driver must still call DriverCallback. This is verified by ensuring that the MHDR_DONE flag is set in the dwFlags field of the lpMidiInHdr parameter to midiInAddBuffer after a SysEx message is received. The SysEx message received must be identical to the one sent.
16.10.29 MODM LONGDATA without callbacks
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: When midiOutOpen is called with dwCallback equal to NULL and dwFlags equal to CALLBACK_NULL, the driver must still call DriverCallback. This is verified by ensuring that the MHDR_DONE flag is set in the dwFlags field of the lpMidiOutHdr parameter to midiOutLongMsg after a SysEx message is sent.
16.10.30 MIDM Add Buffer before recording is started
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Calling midiInAddBuffer before recording is started must clear the MHDR_DONE flag and set the MHDR_INQUEUE flag in the dwFlags parameter of lpMidiInHdr.
16.10.31 MIDM Add Buffer after recording is started
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertion 16.10.37 and calling midiInAddBuffer after recording has been started must clear the MHDR_DONE flag and set the MHDR_INQUEUE flag in the dwFlags parameter of lpMidiInHdr.
16.10.32 MIDM Add Buffer with five buffers of various sizes
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertion 16.10.32 must be met for buffers of various sizes.
16.10.33 SysEx message recording with buffers same size as SysEx messages
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertion 16.10.5 and the SysEx messages received must be identical to the ones sent. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the dwBytesRecorded field of the lpMidiOutHdr parameter of midiOutLongMsg. The SysEx messages must be received by the callback function in the same order they were sent to/recorded by the device.
16.10.34 SysEx message recording with buffers smaller than the SysEx message
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: Requirements of assertion 16.10.34, except that a SysEx message can span more than one buffer. The dwBytesRecorded field of the first buffer must be its size, and the dwBytesRecorded field of the remaining buffers must be either their size (if they're full) or the remainder of the sent SysEx message's size. When appended to each other, the buffers must make up the original SysEx message. Each received buffer must generate a MIM_LONGDATA callback with the proper information. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter.
16.10.35 SysEx message recording with buffers larger than the SysEx message
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: 16.10.34 and when a complete SysEx message is received, even if the buffer is not full, it must be returned through a MIM_LONGDATA callback. Its data must be correct just as specified in 16.10.34.
16.10.36 SysEx msg recording and running status
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: SysEx messages must not use running status. Any SysEx message that fails to start with the SysEx status byte must not be recorded and must not generate a MIM_LONGDATA callback.
16.10.37 Short msg recording with running status
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: When messages sent using a running status byte are received, a MIM_DATA callback must be generated and the dwParam1 parameter must be expanded to include the running status byte. Real-time messages must not interfere with a running status and a running status must end when a new status byte is received.
16.10.47 MIDI Volume Control message verification
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: If the wTechnology field in the lpMidiOutCaps parameter equals MOD_MIDIPORT after a call to midiOutGetCaps, the device must support the midiOutGetVolume and midiOutSetVolume calls. If the dwSupport field has the MIDICAPS_CACHE flag set, the device must support a call to midiOutCachePatches.
16.10.48 Basic midiOutGetVolume/midiOutSetVolume test
Test Assertion GUID:
Windows Logo Program: Anonymous
Additional Information: If the device supports volume controlling, it must successfully respond to midiOutGetVolume and midiOutSetVolume calls. This response is verified by setting the volume and getting it to make sure it returns what it was set to.


Round Trip Test

Type: Manual Test

Overview

Roundtrip verifies that audio solution can stream end-to-end using two different verification mechanisms:

  • The first mechanism operates on device jack pairs, rendering to one endpoint and simultaneously capturing from another. If the captured buffer contains the signal that was rendered, the test passes.

  • The second mechanism verifies the functionality of endpoints "in-air."

Roundtrip verifies the full-duplex requirement for audio devices (AUDIO-0024), which differs from the audio fidelity requirements.

Details

  • In loopback mode, Roundtrip tests end to end streaming using a hardware loopback cable, which must be connected before the test is run. This is usually a regular 3.5mm audio cable plugged into both audio jacks. The test sends a signal out a render endpoint, which is then conveyed to the capture endpoint by the hardware cable. The test captures this signal and compares it to the signal that was rendered.

  • In in-air mode, Roundtrip verifies basic functionality for all endpoints on the system. In the case of render endpoints, a sound file containing a number between 1 and 9 is played back, and the user is asked to correctly identify the number. For capture endpoints, the user is asked to make noise. If the amplitude of the captured sound information is above the required threshold, the test passes.

Run Time: Depending on the number of audio devices installed, 15 seconds to 5 minutes
Log File: ShellRunner.wtl, ShellRunner.log
System Restart Required: No
Supported operating systems for logo testing:

  • Windows 7

  • Windows Vista

Program: ShellRunner.exe, Roundtrip.dll

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • A computer that meets the following minimum software requirements:
    • For loopback tests, loopback cables must be plugged into all jacks under test, linking render jacks to capture jacks
    • For in-air tests, a microphone or other active capture source (such as an S/PDIF cable attached to an AVR actively playing back audio) must be attached to all capture endpoints. Speakers or headphones must be attached to all render endpoints.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running Round Trip Test

For loopback tests, Roundtrip checks each pair of render device and capture device for the presence of a loopback signal. If Roundtrip can't find a loopback signal, the test will fail. In this case, the user can look into the ShellRunner.wtl logfile to determine which endpoints were tested.

If the test reports that no loopback could be found, it could mean several things:

  • No loopback cable is connected for that type of device.

  • The render endpoint in use is not working.

  • The capture endpoint in use is not working.

  • The loopback volume is too low or too distorted to detect a signal

For in-air render tests, Roundtrip plays back a sound file to each render endpoint under test. In each case, the user is asked to identify the word spoken in the file from a list of possible choices. If the incorrect word is chosen, or an error is encountered while rendering audio, the test will fail. In this case, the user can look into the ShellRunner.wtl logfile for more specifics on the failure.

If the user is unable to hear the word played back by the test, it could mean one of the following:

  • No speakers or headphones are attached to the endpoint under test.

  • The endpoint under test is muted, or the endpoint volume is set too low.

  • The endpoint under test is not working.

For in-air capture tests, Roundtrip records data from each capture endpoint on the system. If the recorded audio is not loud enough, the test will prompt the user to make noise. If the test is still unable to identify any recorded sound, or an error is encountered at any point while capturing audio, the test will fail. In this case, the user can look into the Shellrunner.wtl logfile for more specifics on the failure.

If the test is unable to detect recorded sound, this could mean one of the following:

  • No microphone or active audio source is attached to the endpoint under test.

  • The endpoint under test is muted, or the endpoint volume is set too low.

  • The endpoint under test is not working.

Troubleshooting

Issue Description:

If you do not adjust the setting of the volume to unity gain (play back to 100% and recording to 0), you may receive a failure for the external microphone.

Issue Resolution:

You can change the setting of the volume to unity gain for the roundtrip test for a no loopback detected failure of the external microphone only.

Command Syntax

Command option | Description
ShellRunner.exe | Without any options, the shell runs in GUI mode on the test binary in the same directory (Roundtrip.dll must be present).
-c [foo.pro] | Starts the application and runs the test cases that are specified in the foo.pro file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to be tested.
Logo_win7_roundtrip.pro | The .profile file of test cases to be run.
Logo_Vista_Roundtrip.pro | The .profile file of test cases to be run.

Code Tour

File Manifest

File | Location | Description
ShellRunner.exe | [testbinroot]\nttest\multimediatest\Common\WDK\ | Test Shell
Roundtrip.dll | [testbinroot]\nttest\multimediatest\AVCore\Audio\bin\ | Roundtrip test binary
Audiostreaming.dll | [testbinroot]\nttest\multimediatest\AVCore\Audio\bin\ | Streaming helper binary
Sndanlyz.dll | [testbinroot]\nttest\multimediatest\common\ | Analysis helper binary


SysFX UI Test

Type: Automated Test

Overview

The SysFX UI Test is an automated user interface test. The script verifies that each extensible vendor-provided system effects property page set which is in turn to be registered on each visible endpoint (displayed to the user within the MM Control Panel CPL configuration dialogs) implements at least one check box to enable and disable the said audio effect; per the Microsoft Windows Logo Program requirements.

Details

The test ensures that users have the ability to enable and disable system effects on an endpoint in the event it is malfunctioning or otherwise affecting the user experience.

On each audio playback or recording endpoint found to have registered user interface (UI) to be displayed in the form of a property sheet set visible to end users, a checkbox requirement exists.

For these endpoints, a conventional check box control must be both visible and functional on at least one (1) property page sheet in each vendor provided property page set on each registered endpoint. The check box must have the correct Control ID set so that this user interface automation test can identify it and ensure it is working appropriately.

The check box must toggle the correct property key value for enabling/disabling the APO; setting its state to disabled when checked and enabled when unchecked.

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Install your device and driver and have them running before you start this test. Like most user interface automation tests, ensure the desktop is clean and free of unnecessary windows or other elements, and do not cause any manual input (keyboard, mouse, and so on) that might disturb the test while it is running.

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


UAATest

Type: Automated Test

Overview

UAATest validates that HDAudio controller and codec hardware meet the requirements necessary for the Microsoft HDAudio class driver to work. As part of this, this test also validates that the system BIOS is correctly programming the pin configuration registers in the codec.

Details

UAATest installs test drivers for both controllers and codecs that it uses to communicate directly with the hardware. After testing, the original drivers are restored. Sometimes, a reboot is required during the test, and the test application will perform this automatically. If automatic logon is enabled on the machine, no user interaction will be required. Each test case will be marked as PASS, FAIL, or SKIP, as appropriate. In the Audio device kit, the test will cover the codec hardware specified by the submission's DeviceID. In the Systems kit, the test will cover all controllers and codecs (audio and modem) found in the system.

Run Time: 5 minutes
Log File: uaatest.wtl and uaatest.log
System Restart Required: Yes
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 UAATest

Run the UAATest jobs in the DTM. No additional setup is required.

Command Syntax

Command option | Description
uaatest.exe -p "replace restart restore" [-C <profilename>] | Runs all controller/codec tests, installs test drivers, reboots, and restore original drivers as necessary.
uaatest.exe -p "codec replace restart restore" [-C <profilename>] | Same as above, but codec tests only.
uaatest.exe -p "cnt replace restart restore" [-C <profilename>] | Same as above, but controller tests only.
uaatest.exe -p "[[codec] [cnt]] replace restart" | Install the test drivers, but run no test cases.
uaatest.exe [-C <profilename>] | Run tests.
uaatest.exe -p "[[codec][cnt]] restore restart" | Restore the original test drivers, but run no test cases.

Code Tour

File Manifest

File | Location
uaatest.exe | nttest\MultimediaTest\AVCore\Audio\WDK
t_hdaud.inf | nttest\MultimediaTest\AVCore\Audio\WDK
t_hdaud.sys | nttest\MultimediaTest\AVCore\Audio\WDK
t_hdaud.cat | nttest\MultimediaTest\AVCore\Audio\WDK
hdaudbustest.inf | nttest\MultimediaTest\AVCore\Audio\WDK
hdaudbustest.sys | nttest\MultimediaTest\AVCore\Audio\WDK
hdaudbustest.cat | nttest\MultimediaTest\AVCore\Audio\WDK
wdk_uaatest.pro | nttest\MultimediaTest\AVCore\Audio\Profiles


USB Audio Logo Test

Type: Manual Test

Overview

This test hosts test cases for USB audio devices.

Details

Run Time: 5 minutes
Log File: Shellrunner.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: Shellrunner.exe and USBAudLogo.dll

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running USB Audio Logo Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test will return PASS if Audio capable and video capable and audio/video capable USB communication devices implement HID controls according to USB HID Specifications.

The test will return SKIP if no USB device is enumerated on the system.

Command Syntax

Command option | Description
Shellrunner.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to be tested.
logo_win7_usbaudlogo.pro | The .profile file of test cases to be run.

Code Tour

File Manifest

File | Location
shellrunner.exe | [testbinroot]\nttest\multimediatest\common\
USBAudLogo.dll | [testbinroot]\nttest\multimediatest\avcore\audio\wdk


Wave test

Type: Automated Test

Overview

Wave Test ensures that an audio device and driver meet the basic requirements for capture and playback of PCM data.

Details

This test requires that an audio device and driver are installed on a test system. The test exercises simple combinations of capture and playback of PCM data using the Kernel Streaming (KS) interfaces.

All test cases return PASS or FAIL. You should review the test results in the generated log file for specific details about failures.

This test is installed as part of the Microsoft Windows Logo Kit (WLK) (Audio) kit.

Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 Wave test

Command Syntax

Command option | Description
wavetest.exe | Without any options, starts the user interface
-c [string] | Starts the application and runs the test cases that are specified in the profile file (.pro) that [string] specifies.
-h [string] | Specifies the Plug and Play (PnP) ID of the device to test. Default is all devices.

Code Tour

File Manifest

File | Location
wavetest.exe | [testbinroot]\nttest\multimediatest\avcore\audio\wdk\


Bus and Controller Testing

This section describes how to test buses and controllers in order to qualify them for the Windows logo. To complete logo testing, you must install and run the Device Test Manager (DTM) and set up your testing environment. For information about installing and configuring DTM, see Install the DTM.

1394 Controller Testing Overview

Bluetooth Controller Testing Overview

CardBus-PCMCIA Testing Overview

Secure Digital Host Controller Testing Overview

USB Device Logo Testing Recommended Practices

USB Controller Testing Overview

USB Hub Testing Overview

Bus and Controller Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


1394 Controller Testing Overview

The list of tests you must 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 IEEE 1394 Host Controller Tests.

Run time: approximately 2 hours

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Hardware requirements

The IEEE 1394 Host Controller is required for testing.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Note 1394-specific devices are not required for 1394 Controller testing. The 1394 Interoperability test has been removed. This testing has been replaced by the 1394 Manual test, which requires you to enter the ID from the 1394 trade association logo test body.

Software requirements

There are no additional software requirements.

Tester knowledge requirements

There are no special knowledge requirements for testers.


Preparing for 1394 Controller Testing

Many of the tests in the Windows Driver Kit (WDK) 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 How to turn on automatic logon in Windows XP.


Running the 1394 Controller Tests

To run the 1394 controller tests, you must schedule the IEEE 1394 controller tests in Device Manager.


Schedule the IEEE 1394 Controller Tests

To schedule the IEEE 1394 controller tests, do the following:

  1. In DTM Studio, open the Device Console window, as shown in the following screen shot (on the Explorers menu, click Device Console). Screen shot of the DTM Studio window with the Explorers menu highlighted and the Device Console command circled

    Device Console should appears, as shown in the following screen shot.

    Screen shot of a blank Device Console window

  2. In the Submission list, click <New Submission>. (This option will help you create a submission package that is required for a logo for the appropriate Microsoft Windows product. This procedure shows the steps for a Windows Vista Basic logo.) Screen shot of the Device Console window with New Submission circled

    The Create New Submission wizard will appear. This wizard describes the various Windows operating system combinations and platforms that you can use to acquire a logo.

  3. In the Create New Submission wizard, select the correct operating system and platform that the test machines in the machine pools have, and then click Next. (This procedure uses the Windows Vista Client option as an example.) Screen shot of the Create New Submission wizard where, under Select OS, Windows Vista Client is selected

  4. Under Select Category, select the Device Submission category, and then click Next. Screen shot of the Create New Submission wizard where, under Select Category, Device Submission is selected

  5. Under Logo Program, select Bus Controllers and Ports > 1394 Controller, and then click Next. Screen shot of the Create New Submission wizard where, under Logo Program, Bus Controllers and Ports > 1394 Controller is selected

  6. Under Qualification Level, select the Basic or Premium qualification level for the logo programs, and then click Next. (This procedure uses a Basic program as an example. There is not a Premium logo for the 1394 controller category.) Screen shot of the Create New Submission wizard where, under Qualification Level, Basic is selected

  7. In the Name for new submission box, enter a descriptive name for your submission package, and under Machine Pool, select the machine pool on which you want to run the tests for the submission package. Screen shot of the Create New Submission wizard where the Name box and, under Machine Pool, Device are circled

  8. After you have selected a machine pool and given the package a name, click Next. Screen shot of the Create New Submission wizard where the Name box has content and, under Machine Pool, several devices are circled

  9. The following screen appears where you can specify if you need to submit drivers that will be part of the submission.

    In this example, the drivers for 1394 controllers are included in the operating system (which is Windows Vista in this example). Because the driver is already included in the operating system, you must select I am not Providing an INF or Driver Package, and then click Next.

    Note The logo requirements for 1394 controllers require that the device must not require an external driver; it must work with the included generic Windows Vista driver. This requirement enables you to create a submission package without including a custom INF file with it.

    Screen shot of the Create New Submission wizard where the I am not Providing an INF or Driver Package box is selected

  10. In the devices tree in the left pane, select the device that you are testing, click Next, and then click Finish to create a submission package. Screen shot of the Create New Submission wizard with the list of devices circled

  11. In the Submission list, select the submission package that you just created.

    DTM will load all of the required files and present you with a list of available jobs that are related to the submission package. It will also show you a brief summary of the conditions that the tests will be running against on the left side of the screen (including the device, and so on).

    Screen shot of the Create New Submission wizard with Available Jobs circled

  12. In the Available Jobs list, select the tests, and click Add Selected to make the jobs ready for scheduling. Screen shot of the Create New Submission wizard with the Available Jobs list expanded and circled Screen shot of the Create New Submission wizard with the results of the job-selection process displayed

    The jobs that you selected now appear in the pane below with a short description of each job.

  13. Click Schedule Jobs, and the DTM controller will start scheduling the jobs to run on the machines in the pool. Screen shot of the Create New Submission wizard with the available jobs listed The following screen shot of the Create New Submission wizard shows the results of a different job-selection process. Screen shot of the Create New Submission wizard with the results of a different job-selection process displayed


Troubleshooting 1394 Controller Testing

You can troubleshoot problems you are having by completing the following steps:

  1. From the "Task Execution Status" pane of Job Monitor, right-click the failed task (typically the "execute" task is the most critical).

  2. Right-click the task and select View task log to open the relevant log file. If that option is not available, you might need to first select Child job results, and then select a failed task from the child job.


Bluetooth Controller Testing Overview

These procedures test your Bluetooth controllers for correct 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 Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Bluetooth Controller Tests

The tests that must 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.

  • Three test systems that are connected over TCP/IP.

  • Two Bluetooth control devices (such as those provided by Cambridge Silicon Radio and Broadcom) that have received Windows logos.

  • One USB 2.0 High-speed hub for each system that is being tested to meet the requirements of the USB Device Framework (CV) Test and USB HIDView (CV) Test.

Software Requirements

The following software is required to run the Bluetooth controller tests:

  • Windows 7

  • Windows Vista

  • Windows XP Professional with Service Pack 2 (SP2)

  • 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.

The Microsoft Bluetooth Driver Stack is the only driver stack that is supported to logo your device. Loading any other driver stack causes the tests to fail.

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 (WDK) 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 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 operating 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.
  5. When you connect the Bluetooth controller to the test system:
    • If any test system contains an OHCI USB controller, attach the Bluetooth controller downstream of a USB 2.0 high-speed hub for the Bluetooth - SCO test.
  6. If the Bluetooth controller contains an embedded USB 1.1 full-speed hub, do the following:
    • For the USB Device Framework (CV) Test and USB HIDView (CV) Test attach the device downstream of a USB 2.0 high-speed hub.
    • For all other tests, attach the Bluetooth radio directly to the system.
  7. If the Bluetooth controller does not contain an embedded hub, do the following:
    • For the USB Device Framework (CV) Test, USB HIDView (CV) Test, and USB Selective Suspend test, attach the device downstream of a USB 2.0 high-speed hub.
    • For all other tests, attach the Bluetooth radio directly to the system.
  8. If the Bluetooth controller is embedded inside the test system and cannot be removed, do the following:

    • Set the IsEmbeddedUSBDevice job parameter to TRUE when you run only the USB Device Framework (CV) Test, USB HIDView (CV) Test, USB Selective Suspend test, and USB Serial Number test. To set the parameter, right-click the device in the Device Console, and click Edit Parameters.

      Screen shot of the Device Console with a device and the Edit Parameters command selected

    • All other tests should be run with the IsEmbeddedUSBDevice job parameter set to its default of FALSE.


Running the Bluetooth Controller Tests

For the Bluetooth controller tests, you must have at least three computers in your machine pool to complete the various test jobs. This number of computers is required to test communication that uses multiple Bluetooth interfaces on multiple machines.

To run the Bluetooth controller tests, you must schedule the Bluetooth controller tests.


Schedule the Bluetooth Controller Tests

To schedule the Bluetooth controller tests, do the following:

  1. In DTM Studio, open the Device Console window (on the Explorers menu, click Device Console). Screen shot of the DTM Studio window with the Explorers menu highlighted and the Device Console command circled

    Device Console should appear, as shown in the following screen shot.

    Screen shot of a blank Device Console window

  2. In the Submission list, click <New Submission>. (This option will help you create a submission package that is required for a logo for the appropriate Microsoft Windows product. This procedure shows the steps for a Windows Vista Basic logo.) Screen shot of the Create New Submission wizard where, in the Submissions list, New Submission is selected

    The Create New Submission wizard will appear. This wizard describes the various Windows operating system combinations and platforms that you can use to acquire a logo.

  3. In the Create New Submission wizard, select the correct operating system and platform that the test machines in the machine pools have, and then click Next. (This procedure uses the Windows Vista Client option as an example.) Screen shot of the Create New Submission wizard where, under Select OS, Windows Vista Client is selected

  4. Under Select Category, select the Device Submission category, and then click Next. Screen shot of the Create New Submission wizard where, under Select Category, Device Submission is selected

  5. Under Logo Programs, select Bus Controllers and Ports > Bluetooth Controller, and then click Next. Screen shot of the Create New Submission wizard where, under Logo Program, Bus Controllers and Ports > Bluetooth Controller is selected

  6. Under Qualification Level, select the Basic or Premium qualification level for the logo programs, and then click Next. (This procedure uses a Basic program as an example There is not a Premium logo for the Bluetooth controller category.) Screen shot of the Create New Submission wizard where, under Qualification Level, Basic is selected

  7. In the Name for new submission box, enter a descriptive name for your submission package, and under Machine Pool, select the machine pool on which you want to run the tests for the submission package. Screen shot of the Create New Submission wizard where the Name box and, under Machine Pool, Device are circled

  8. After you have selected a machine pool and given the package a name, click Next. Screen shot of the Create New Submission wizard where the Name box has content and, under Machine Pool, some devices are circled

  9. The following screen appears where you can specify if you need to submit drivers that will be part of the submission.

    In this example, the drivers for Bluetooth controllers are included in the operating system (which is Windows Vista in this example). Because the driver is already included in the operating system, select I am not providing an INF or Driver Package, and then click Next.

    Note The logo requirements for Bluetooth controllers require that the device must not require an external driver; it must work with the included generic Windows Vista driver. This requirement enables you to create a submission package without including a custom INF file with it.

    Screen shot of the Create New Submission wizard where the I am not Providing an INF or Driver Package box is selected

  10. In the devices tree in the left pane, select the device that you are testing, click Next, and then click Finish to create a submission package. Screen shot of the Create New Submission wizard with the device list circled

  11. In the Submission list, select the submission package that you just created.

    DTM will load all of the required files and present you with a list of available jobs that are related to the submission package. It will also show you a brief summary of the conditions that the tests will be running against on the left side of the screen (including the device, and so on).

    Screen shot of the Create New Submission wizard with an available device and available jobs circled

  12. For those tasks that are marked with an icon that looks like an exclamation point within a yellow diamond, right-click the task, and click Add Information.

    These tasks require a special setup for the test to run correctly.

    Screen shot of the Create New Submission wizard where some tasks are marked with an icon displaying an exclamation point within a yellow diamond

  13. In the Job extension dialog box that appears, select the machines in the current pool that you want to use for the task.

    The Job extension window also tells you how many machines the test requires (three in this example) to run successfully.

    Screen shot of the Create New Submission wizard where the Job Extension window indicates the number of machines required

  14. In the Available Jobs list, select the tests, and click Add Selected to make the jobs ready for scheduling. Screen shot of the Create New Submission wizard listing the scheduled jobs to run on the machines in the pool

    The jobs that you selected now appear in the pane below with a short description of each job.

  15. Click Schedule Jobs, and the DTM controller will start scheduling the jobs to run on the machines in the pool. Screen shot of the Create New Submission wizard listing the scheduled jobs to run on the machines in the pool


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 correct functionality by using the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that 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:

  • Preparing: The preparing topics describe how to configure the system or systems for Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

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

  • Sleep Stress with I/O

  • Disable Enable with I/O

  • Common Scenario Stress with IO

  • Plug and Play Driver Test

  • Run INFTest against a single INF

  • Storage Device Stress test (SDStress)

If your device is connected through PCI, you will need:

  • (Windows Vista and later versions) PCI/PCI Express Compliance Test (PCIHCT)

Run time: approximately 2 hours

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.

    Note The test system must be included in the Microsoft Windows Marketplace.

  • 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

    Note Contact the CardBus card vendor if you are uncertain about ACPI compliance.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

The following software is required to run the CardBus-PCMCIA controller tests:

  • One of the following operating systems:
    • Windows 7
    • Windows Vista
    • Windows XP Professional with Service Pack 2 (SP2)
    • Windows Server 2003 with Service Pack 1 (SP1), Enterprise Edition
    • Windows Server 2003 with Service Pack 1 (SP1), Datacenter Edition
    • Windows XP Professional x64 Edition
    • Windows Server 2003, Enterprise x64 Edition
    • Windows Server 2003, Datacenter x64 Edition
    • Windows Server 2003 with SP1, Enterprise Edition for Itanium-based Systems
    • Windows Server 2003 with SP1, Datacenter Edition for Itanium-based Systems
    • Windows Server 2008 R2

  • 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 (WDK) require a test system to restart (often more than once) to complete a test run. To facilitate this DTM will configure the client to automatically login using the DTMLLUAdminUser. This happens when you first create your submission. DTM will also turn off workstation locking and prevent the machine from automatically hibernating/sleeping. If you wish to Remote Desktop into the client after starting a submission, please use DTMLLUAdminUser.

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 card device and any device driver that the manufacturer supplies.

  4. Install DTM client.

  5. Set up the test machines in a pool as specified in the DTM initial setup documentation.


Running the CardBus-PCMCIA Tests

To test CardBus-PCMCIA controllers, you must do the following:

  1. In DTM Studio, open the Device Console window (on the Explorers menu, click Device Console).

    Screen shot of the DTM Studio window with the Explorers menu highlighted and the Device Console command circled

    Device Console should appear, as shown in the following screen shot.

    Screen shot of a blank Device Console window

  2. In the Submission list, click <New Submission>. (This option will help you create a submission package that is required for a logo for the appropriate Microsoft Windows product. This procedure shows the steps for a Windows Vista Basic logo.) Screen shot of the Create New Submission wizard where, in the Submissions list, New Submission is selected

    The Create New Submission wizard will appear. This wizard describes the various Windows operating system combinations and platforms that you can use to acquire a logo.

  3. In the Create New Submission wizard, select the correct operating system and platform that the test machines in the machine pools have, and then click Next. (This procedure uses the Windows Vista Client option as an example.) Screen shot of the Create New Submission wizard where, under Select OS, Windows Vista Client is selected

  4. Under Select Category, select the Device Submission category, and then click Next. Screen shot of the Create New Submission wizard where, under Select Category, Device Submission is selected

  5. Under Logo Programs, select Bus Controllers and Ports > CardBus-PCMCIA Controller, and then click Next. Screen shot of the Create New Submission wizard where, under Logo Program, Bus Controllers and Ports > CardBus-PCMCIA Controller is selected

  6. Under Qualification Level, select the Basic or Premium qualification level for the logo programs, and then click Next. (This procedure uses a Basic program as an example. There is not a Premium logo for the CardBus-PCMCIA controller category.) Screen shot of the Create New Submission wizard where, under Qualification Level, Basic is selected

  7. In the Name for new submission box, enter a descriptive name for your submission package, and under Machine Pool, select the machine pool on which you want to run the tests for the submission package. Screen shot of the Create New Submission wizard where the Name box and, under Machine Pool, Device are circled

  8. After you have selected a machine pool and given the package a name, click Next. Screen shot of the Create New Submission wizard where the Name box has content and, under Machine Pool, several devices are circled

  9. The following screen appears where you can specify if you need to submit drivers that will be part of the submission.

    In this example, the drivers for CardBus-PCMCIA controllers are included in the operating system (which is Windows Vista in this example). Because the driver is already included in the operating system, select I am not providing an INF or Driver Package, and then click Next.

    Note The logo requirements for CardBus-PCMCIA controllers require that the device must not require an external driver; it must work with the included generic Windows Vista driver. This requirement enables you to create a submission package without including a custom INF file with it.

    Screen shot of the Create New Submission wizard where the I am not Providing an INF or Driver Package box is selected

  10. In the devices tree in the left pane, select the device that you are testing, click Next, and then click Finish to create a submission package. Screen shot of the Create New Submission wizard with several of the devices circled

  11. In the Submission list, select the submission package that you just created.

    DTM will load all of the required files and present you with a list of available jobs that are related to the submission package. It will also show you a brief summary of the conditions that the tests will be running against on the left side of the screen (including the device, and so on).

    Screen shot of the Create New Submission wizard where several available jobs are selected

  12. In the Available Jobs list, select the tests, and click Add Selected to make the jobs ready for scheduling. Screen shot of the Create New Submission wizard where several available jobs are selected

    The jobs that you selected now appear in the pane below with a short description of each job.

  13. Click Schedule Jobs, and the DTM controller will start scheduling the jobs to run on the machines in the pool. Screen shot of the Create New Submission wizard where the scheduled jobs are listed


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 correct 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:

  • Preparing: The preparing topics describe how to configure the system or systems for Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Secure Digital Host Controller Tests

The tests that you must 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

  • Sleep Stress with IO

  • Disable Enable with IO

  • Plug and Play Driver Test

  • Run INFTest against a single INF

  • Storage Device Stress test (SDStress)

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:

  • (Windows Vista and later versions) PCI/PCI Express Compliance Test (PCIHCT)

Run time: approximately 2 hours

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.

    Note The test system must be included in the Microsoft Windows Marketplace

  • 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.

    Note If the secure digital host controller supports High Speed mode, the memory card used must also be High Speed.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

The following software is required to run the Secure Digital Host controller tests:

  • One of the following operating systems:
    • Windows 7
    • Windows Vista
    • Windows Server 2008 R2

  • 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


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 (WDK) require a test system to restart (often more than once) to complete a test run. To facilitate this DTM will configure the client to automatically login using the DTMLLUAdminUser. This happens when you first create your submission. DTM will also turn off workstation locking and prevent the machine from automatically hibernating/sleeping. If you wish to Remote Desktop into the client after starting a submission, please use DTMLLUAdminUser.

Test system configuration

  1. Install the appropriate Microsoft Windows operating system.

  2. Install the test device and any accessories.

  3. Install DTM client.

  4. Set up the test machines in a pool as specified in the DTM initial setup documentation.


Running the Secure Digital Host Controller Tests

To test Secure Digital Host controllers, you must:

  1. In DTM Studio, open the Device Console window (on the Explorers menu, click Device Console). Screen shot of the DTM Studio window with the Explorers menu highlighted and the Device Console command circled

    Device Console should appear, as shown in the following screen shot.

    Screen shot of a blank Device Console window

  2. In the Submission list, click <New Submission>. (This option will help you create a submission package that is required for a logo for the appropriate Microsoft Windows product. This procedure shows the steps for a Windows Vista Basic logo.) Screen shot of the Create New Submission wizard where, in the Submissions list, New Submission is selected

    The Create New Submission wizard will appear. This wizard describes the various Windows operating system combinations and platforms that you can use to acquire a logo.

  3. In the Create New Submission wizard, select the correct operating system and platform that the test machines in the machine pools have, and then click Next. (This procedure uses the Windows Vista Client option as an example.) Screen shot of the Create New Submission wizard where, under Select OS, Windows Vista Client is selected

  4. Under Select Category, select the Device Submission category, and then click Next. Screen shot of the Create New Submission wizard where, under Select Category, Device Submission is selected

  5. Under Logo Programs, select Bus Controllers and Ports > Secure Digital Host Controller, and then click Next. Screen shot of the Create New Submission wizard where, under Logo Program, Bus Controllers and Ports > Secure Digital Host Controller is selected

  6. Under Qualification Level, select the Basic or Premium qualification level for the logo programs, and then click Next. (This procedure uses a Basic program as an example. There is not a Premium logo for the Secure Digital Host controller category.) Screen shot of the Create New Submission wizard where, under Qualification Level, Basic is selected

  7. In the Name for new submission box, enter a descriptive name for your submission package, and under Machine Pool, select the machine pool on which you want to run the tests for the submission package. Screen shot of the Create New Submission wizard where the Name box and, under Machine Pool, Device are circled

  8. After you have selected a machine pool and given the package a name, click Next. Screen shot of the Create New Submission wizard where the Name box has content and, under Machine Pool, four devices are circled

  9. The following screen appears where you can specify if you need to submit drivers that will be part of the submission.

    In this example, the drivers for Secure Digital Host controllers are included in the operating system (which is Windows Vista in this example). Because the driver is already included in the operating system, select I am not providing an INF or Driver Package, and then click Next.

    Note The logo requirements for Secure Digital Host controllers require that the device must not require an external driver; it must work with the included generic Windows Vista driver. This requirement enables you to create a submission package without including a custom INF file with it.

    Screen shot of the Create New Submission wizard where the I am not Providing an INF or Driver Package box is selected

  10. In the devices tree in the left pane, select the device that you are testing, click Next, and then click Finish to create a submission package. Screen shot of the Create New Submission wizard with several devices circled

  11. In the Submission list, select the submission package that you just created.

    DTM will load all of the required files and present you with a list of available jobs that are related to the submission package. It will also show you a brief summary of the conditions that the tests will be running against on the left side of the screen (including the device, and so on).

    Screen shot of the Create New Submission wizard with several available devices and available jobs circled

  12. In the Available Jobs list, select the tests, and click Add Selected to make the jobs ready for scheduling. Screen shot of the Create New Submission wizard where a submission package is circled

    The jobs that you selected now appear in the pane below with a short description of each job.

  13. Click Schedule Jobs, and the DTM controller will start scheduling the jobs to run on the machines in the pool. Screen shot of the Create New Submission wizard where the scheduled jobs are listed


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 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 might be corrupted.
    8. Delete the machine from the machine pool, uninstall the client, and then repeat steps 3 and 4 of Test System Configuration.

  • If jobs are appearing incorrectly, ensure that you have completed step 4 of Test System Configuration.

For more information about troubleshooting Secure Digital Host controller testing, see Troubleshooting Storage Tests.


USB Device Logo Testing Recommended Practices

Generic USB Tests: Microsoft

  • USB Address Description Test

  • USB Device Control Requests Test

  • USB Enumeration Stress Test

  • USB Descriptor Test

  • USB Selective Suspend

  • USB Serial Number

Generic USB Tests: USB interface (IF) and Intel

  • Command Verifier (CV) Test Suite:
    • USB Device Framework (CV) Test
    • USB HIDView (CV) Test

  • USB Specification Compliance

Connecting a device to a USB 2.0 hub

  • Advantages with this method:
    • Recommended for regular USB devices
    • Required for the USB Selective Suspend test
    • Forces low and full-speed devices to be enumerated by the EHCI (high speed) controller
  • Disadvantages with this method:
    • Devices with embedded hubs must be directly connected for Microsoft tests
    • Multi-TT hubs not recommended for logo testing

Devices with embedded hubs

  • For embedded full-speed hubs:
    • Use an external USB 2.0 hub for the USB Device Framework (CV) Test and USB HIDView (CV) Test
    • Attach the device directly to the system for all other tests
  • For embedded high-speed hubs
    • Attach the device directly to the system for all tests
  • Note: Exposed ports
    • If the hub exposes ports, the embedded hub must separately pass the USB Hub logo program
    • Embedded full-speed hubs are exempt from the USB Hub Basic Transfer Test
    • Change the IsEmbeddedUSBDevice parameter from FALSE to TRUE for the following tests:
      • USB HIDView (CV) Test
      • USB Address Description Test
      • USB Descriptor Test
      • USB Device Control Requests Test
      • USB Device Framework (CV) Test
      • USB Enumeration Stress Test
      • USB Hub Compliance (CV) Test
      • USB Selective Suspend
      • USB Serial Number

Systems with embedded devices

  • For embedded devices that are not attached via a USB hub:
    • The USB Selective Suspend test will always fail
    • The USB Device Framework (CV) Test and the USB HIDView (CV) Test will fail unless the embedded device is a high-speed (USB 2.0) device
  • For embedded devices that are attached downstream of 2 or more hubs:
    • All Microsoft-supplied tests will fail. The USB Device Framework (CV) Test and the USB HIDView (CV) Test will fail unless the device is a high-speed device
  • Solution:
    • Set the IsEmbeddedUSBDevice job parameter to TRUE if and only if your device falls into one of the above categories
    • The IsEmbeddedUSBDevice job parameter is used in the following tests:
      • USB HIDView (CV) Test
      • USB Address Description Test
      • USB Descriptor Test
      • USB Device Control Requests Test
      • USB Device Framework (CV) Test
      • USB Enumeration Stress Test
      • USB Hub Compliance (CV) Test
      • USB Selective Suspend
      • USB Serial Number

For the USB Basic Transfer Test

  • The USB Hub Basic Transfer Test is designed only to evaluate USB 2.0 high-speed hubs (400 Mbps), not full-speed or USB 1.1 hubs (11 Mbps). For full-speed hubs, customer should set the IsEmbeddedFullSpeedHub schedule-time parameter to TRUE in the Device Console when scheduling this test. The parameter lets DTM know that the hub is not a high-speed hub and will therefore exempt the test entirely.

USB Serial Number test

  • The USB Serial Number test runs only if device supports unique serial number

  • The test validates the uniqueness of the serial number

  • The test requires two identical devices to run

  • The devices must be attached before the test is scheduled to run

For the USB Device framework test, the USB HIDView test and the USB Hub compliance test

  • If the test machine has two USB controllers disable the controller that is not under test or the test will fail


Bluetooth WLK Tips and Troubleshooting Guide

Vista SP1 Testing

TIP: When testing on Vista SP1, be sure to install the WUR package update before running the WLK Bluetooth tests. If you do not have WUR, please contact Microsoft for details.

Setup Tips

TIP: When setting up the Bluetooth tests for WLK, consider the physical layout of your lab and testing environment. Setting up the radios so that they are within several feet of each other and have a clear line of sight of each other will reduce possible false failures. A relatively noise-free environment will also help reduce false failures of the Bluetooth tests.

Bluetooth SCO Test

TIP: Make sure that you have a second machine setup in DTM with a Bluetooth radio attached to act as the secondary machine in this test.

Bluetooth Point to Point Test

TIP: Make sure that you have a second machine setup in DTM with a Bluetooth radio attached to act as the secondary machine in this test.

Bluetooth Scatternet Test

TIP: Make sure that you have two other machines setup in DTM with Bluetooth radios attached to act as the two secondary machines needed to run this test.

Bluetooth 2.1 Test

TIP: Make sure that you have a second machine setup in DTM with a Bluetooth radio attached to act as the secondary machine in this test.

TIP: Use 2.1 radios on both the primary and secondary machines.

Bluetooth Remote Wake Test

TIP: Make sure that you have a second machine setup in DTM with a Bluetooth radio attached to act as the secondary machine in this test.

Troubleshooting common Bluetooth test issues

Issue: "Failures finding devices during Inquiry"

This failure can happen when testing in a noisy environment. Rerunning the test will usually fix this error. You can also try to bring the radios closer together, ensuring that they have a clear line of sight. Turn off other radios that may be causing interference.

Issue: "Failures connecting devices during inquiry tests or other"

This failure is due to the test timing out before the devices could be reconnected. Rerunning the test will usually fix this error.


USB Controller Testing Overview

USB Host Controller Tests

The list of tests you must run depend upon the capabilities of the device or system being tested.

Run time: approximately 2 hours

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Hardware requirements

The following hardware is required for USB Host controller testing.

  • One USB host controller

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software requirements

Microsoft Windows Server 2008 R2 is supported.

Tester knowledge requirements

There are no special knowledge requirements for testers.


Preparing for USB Host Controller Testing

Many of the tests in the Windows Driver Kit (WDK) 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

Ensure that the USB Host controller is installed and functional before proceeding. Otherwise, there are no special configuration requirements for USB Host controller testing.


Running the USB Host Controller Tests

To run the USB Host controller tests, you must schedule the USB Host controller tests.


Schedule the USB Host Controller Tests

To schedule the USB Host controller tests, do the following:

  1. In DTM Studio, open the Device Console window (on the Explorers menu, click Device Console). Screen shot of the DTM Studio window with the Explorers menu highlighted and the Device Console command circled

    Device Console should appear, as shown in the following screen shot.

    Screen shot of a blank Device Console window

  2. In the Submission list, click <New Submission>. (This option will help you create a submission package that is required for a logo for the appropriate Microsoft Windows product. This procedure shows the steps for a Windows Vista Basic logo.) Screen shot of the Submissions list with New Submission selected

    The Create New Submission wizard will appear. This wizard describes the various Windows operating system combinations and platforms that you can use to acquire a logo.

  3. In the Create New Submission wizard, select the correct operating system and platform that the test machines in the machine pools have, and then click Next. (This procedure uses the Windows Vista Client option as an example.) Screen shot of the Create New Submission wizard where, under Select OS, Windows Vista Client is selected

  4. Under Select Category, select the Device Submission category, and then click Next. Screen shot of the Create New Submission wizard where, under Select Category, Device Submission is selected

  5. Under Logo Programs, select Bus Controllers and Ports > USB Controller, and then click Next. Screen shot of the Create New Submission wizard where, under Logo Program, Bus Controllers and Ports, USB Controller is selected

  6. Under Qualification Level, select the Basic or Premium qualification level for the logo programs, and then click Next. (This procedure uses a Basic program as an example. There is not a Premium logo for the USB Host controller category.) Screen shot of the Create New Submission wizard where, under Qualification Level, Basic is selected

  7. In the Name for new submission box, enter a descriptive name for your submission package, and under Machine Pool, select the machine pool on which you want to run the tests for the submission package. Screen shot of the Create New Submission wizard where the Name box and, under Machine Pool, Device are circled

  8. After you have selected a machine pool and given the package a name, click Next. Screen shot of the Create New Submission wizard where the Name box has content and, under Machine Pool, four devices are circled

  9. The following screen appears where you can specify if you need to submit drivers that will be part of the submission.

    In this example, the drivers for USB Host controllers are included in the operating system (which is Windows Vista in this example). Because the driver is already included in the operating system, select I am not providing an INF or Driver Package, and then click Next.

    Note The logo requirements for USB Host controllers require that the device must not require an external driver; it must work with the included generic Windows Vista driver. This requirement enables you to create a submission package without including a custom INF file with it.

    Screen shot of the Create New Submission wizard where the I am not Providing an INF or Driver Package box is selected

  10. In the devices tree in the left pane, select the device that you are testing, click Next, and then click Finish to create a submission package. Screen shot of the Create New Submission wizard with several devices selected

  11. In the Submission list, select the submission package that you just created.

    DTM will load all of the required files and present you with a list of available jobs that are related to the submission package. It will also show you a brief summary of the conditions that the tests will be running against on the left side of the screen (including the device, and so on).

    Screen shot of the Create New Submission wizard with two of the available devices selected

  12. In the Available Jobs list, select the tests, and click Add Selected to make the jobs ready for scheduling. Screen shot of the Create New Submission wizard where several available jobs are selected

    The jobs that you selected now appear in the pane below with a short description of each job.

  13. Click Schedule Jobs, and the DTM controller will start scheduling the jobs to run on the machines in the pool. Screen shot of the Create New Submission wizard where the scheduled jobs are listed


Troubleshooting USB Controller Testing

From the Task Execution Status pane of Job Monitor, right-click the failed task and select View task log. If that option is not available, you might need to first select Child job results and select a failed task from the child job.


USB Hub Testing Overview

To see the complete list of tests that could be required for your device, see the USB Hub Tests.

Run time: approximately 4 hours

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Hardware requirements

The following hardware is required for USB Hub testing.

  • One USB Hub under test (two test devices are required for USB serial number support)

  • One external USB 2.0 high-speed hub, self-powered

  • One external USB 1.1 full-speed hub, self-powered

  • One Cypress Full-Speed USB 2.0 Compliance test board

  • One Cypress Low-Speed USB 2.0 Compliance test board

The low-speed and full-speed Cypress functional compliance test boards can be purchased directly from the USB Implementer's forum:

PDK Order Form

Note To reduce the chance of failures caused by unrelated hardware problems, Microsoft recommends that all tests be performed on a client test system which is part of the "Windows Catalog" at Windows Vista Upgrade Advisor.

Software requirements

There are no additional software requirements.

Tester knowledge requirements

The tester must be able to answer basic technical questions about the test device, such as whether the USB Hub supports multiple transaction translators.


Preparing for USB Hub Testing

Many of the tests in the Windows Driver Kit (WDK) 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 device(s) under test must be connected via an external USB 2.0 hub (not directly connected to the client test system)

  • Ensure that the hub under test is recognized by the client test system before proceeding

  • If the device supports a USB serial number, be sure to attach the additional test device to the external hub before scheduling the USB Serial Number test


Running the USB Hub Tests

To create a new Pointing Device submission in Device Console:

  1. Select "New submission" from the submission drop-down list.

  2. Select the target operating system for the logo submission.

  3. Select Device submission.

  4. Select Bus Controllers and Ports > USB Hub for the logo program:

    Screen shot of the Create New Submission dialog box with Bus Controllers and Ports > USB Hub selected

  5. Select Basic for the Qualification Level.

  6. Name the submission and specify the machine pool that contains the client test system and test hub.

  7. Next, if the hub uses an INF file to supply model-specific device information, select the INF file. (Note that Microsoft class drivers that ship with Windows are supported, so no driver binaries should be added in this dialog box.) If you do not want to supply an INF file, select I am not providing an INF or Driver Package as shown, and then click Next:

    Screen shot of the Create New Submission dialog box with I am not providing an INF or Driver Package selected

After you select your test device (if prompted), you will be ready to schedule tests.

The USB Hub Basic Transfer test is a heavily interactive test and will require the operator to answer several questions about the test hub and re-connect the hub in a number of different topologies. Follow the instructions on the screen.

The USB device tests must be run against the hub to ensure basic USB functionality. For more information about USB tests, refer to the document for each individual test.

The remaining tests are included as part of the Driver Reliability Signature test suite. These tests examine generic device behavior, such as power state management. See the documentation for each individual test for more information about requirements and/or troubleshooting.


Troubleshooting USB Hub Testing

From the Task Execution Status pane of Job Monitor, right-click the failed task (typically the "execute" task is the most critical). Right-click the task and select View task log to open the relevant log file. If the View task log option is not available, you might need to first select Child job results and then select a failed task from the child job.


How to Manually Schedule USB DTM Jobs

To manually schedule USB DTM jobs, follow these steps:

  1. Go to the Device Manager of the client machine and make a note of the VID and PID of the device you would like to test.

    Note If you are not running a USB test, then this is probably not needed. Please check what other parameters are needed to run the test.

    Screen shot of the Device Manager dialog box with a device's VID circled
  2. Go to Explorers > Job Explorer and find the test that you would like to run.

  3. Right-click the job and select Schedule.

    Screen shot of the DTM Studio dialog box with the job highlighted and the Schedule command selected

  4. Enter the VID and PID of the device from step 1.

    Note If you are not running a USB test, then you may have to enter different parameters here. Also, there may be additional parameters that you want to change, such as the number of iterations on stress tests.

    Screen shot of the DTM Studio dialog box with the VID and PID values on the Jobs tab circled

  5. Select the client machine that you would like the test to run on.

    Screen shot of the DTM Studio dialog box, on the Machines tab, with the Browse box selected

  6. Select Create Schedule to run the job. The job will show up in the job monitor under the system that you selected...


Bus and Controller Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


1394 Industry Certification Test ID Entry (Manual)

Type: Manual Test

Overview

Manual test to enter in the test ID from the 1394 trade association logo tests.

Details

If the device has a 1394 trade association logo select the pass radio button and enter the test ID in the details section.

Results Interpretation

Run Time: 1 minute

Log File:

System Restart Required:No

Test Category:

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

Processor

The test tool runs on the following processor architectures:

  • x86
  • x64
  • Itanium

Troubleshooting

19.18.1 All devices must support the IEEE 1212-2000 general ROM format. This requirement includes having header information and bus information block and root directory entries.

Reference document: WLP#-B2.2.4.2; IEEE 1212-2000.

19.18.2 Devices must supply textual descriptors for the Vendor_ID and Model_ID entries of the configuration ROM.

Reference document: WLP#-B2.2.4.12; IEEE 1212-2000.


Bluetooth 2.1 Logo tests

Type: Automated

Overview

The goal of the Bluetooth 2.1 logo tests is to verify mandatory functionality of Bluetooth 2.1 features like Secure Simple Pairing (SSP) and Extended Inquiry Response (EIR). Logo tests verify above features by running different combinations of tests on selected BT hardware.

Details

Test case breakdown is as follows:

Test ID: VerifyAuthForAuthMethOOB

Title: Verify authentication successes for authentication method OOB

Description: Verify authentication procedure when Out of Band data is present

Procedures: Master initiates the authentication

Master uses slave OOB data for authentication

Verify callback function registered should not get called

Verify authentication successes for authentication method OOB

Timeout: 100

Test ID: VerifyEventLogNotGenForDebugEnabled

Title: Verify event log message is not generated on debug system when both of the system is in debug enabled mode

Description: Verify debug mode supported by BT radio

Procedures: Master and slave registers for authentication

Master and slave is in debug mode and initiates the authentication

Verify that authentication succeed and on no event log is generated on both machines

Timeout: 120

VerifyAuthForIOCapMxSx Tests Description:

Verify authentication procedure for various authentication method as defined in BT specification when different IO capability is specified by system

Possilbe IO capabilities are:

DisplayOnly - 0

DisplayYesNo - 1

KeyBoardOnly - 2

NoInputNoOutput - 3

In Test names M stands for Master Device IO capability and S stands for Slave Device IO Capability

Test ID: VerifyAuthForIOCapM0S0

Title: Verify authentication successes for authentication method LEGACY when master and slave has device capability set to NoInputNoOutput

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities DisplayOnly for master and slave

Procedures: Master and slave registers for authentication

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

NOTES: Make sure proper config test case is executed before to set io capabilities

Timeout: 100

Test ID: VerifyAuthForIOCapM0S1

Title: Verify authentication successes for IOCapabilities DisplayOnly for master and DisplayYesNo for slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities DisplayOnly for master and DisplayYesNo for slave

Procedures: Master and slave registers for authentication with IOCapabilities DisplayOnly on master and DisplayYesNo on Slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM0S2

Title: Verify authentication successes for IO capabilities DisplayOnly for master and KeyboardOnly for slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities DisplayOnly for master and KeyBoardOnly for slave

Procedures: Master and slave registers for authentication with IOCapabilities display only on master and Display YesNo on Slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM0S3

Title: Verify authentication successes for IO capabilities DisplayOnly for master and NoInputNoOutput for slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities DisplayOnly for master and NoInputNoOutput for slave

Procedures: Master and slave registers for authentication with IOCapabilities display only on master and NoInputNoOutput on Slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM1S0

Title: Verify authentication successes for IO capabilities DisplayYesNo for master and DisplayOnly for slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities DisplayYesNo for master and DisplayOnly for slave

Procedures: Master and slave registers for authentication with IOCapabilities display only on both

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM1S1

Title: Verify authentication successes for IO capabilities DisplayYesNo for both master and slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities DisplayYesNo for master and slave

Procedures: Master and slave registers for authentication with IOCapabilities displayYesNo on both

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM1S2

Title: Verify authentication successes for IO capability DisplayYesNo for master and KeyboardOnly for slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities DisplayYesNo for master and KeyBoardOnly for slave

Procedures: Master and slave registers for authentication with IOCapabilities DisplayYesNo for master and KeyBoardOnly on Slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM1S3

Title: Verify authentication successes for IO capabilities DisplayYesNo for master and NoInputNoOutput for slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities DisplayYesNo for master and KeyBoardOnly for slave

Procedures: Master and slave registers for authentication with IOCapabilities display YesNo on master and NoInputNoOutput on Slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM2S0

Title: Verify authentication successes for IOCapabilities KeyBoardOnly for master and DisplayOnly for slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities KeyBoardOnly for master and DisplayOnly for slave

Procedures: Master and slave registers for authentication with IOCapabilities KeyBoardOnly on master and DisplayOnly on Slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM2S1

Title: Verify authentication successes for IOcapabilities KeyBoardOnly for master and DisplayYesNo for slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities KeyBoardOnly for master and DisplayYesNo for slave

Procedures: Master and slave registers for authentication with IOcapabilities KeyBoardOnly for master and DisplayYesNo for slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM2S2

Title: Verify authentication successes for IO capabilities KeyBoardOnly for master and slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities KeyBoardOnly for master and DisplayYesNo for slave

Procedures: Master and slave registers for authentication with IOCapabilities KeyBoardOnly on both.

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM2S3

Title: Verify authentication successes for IO capabilities KeyBoardOnly for master and NoInputNoOutput for slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities KeyBoardOnly for Master and NoInputNoOutput for slave

Procedures: Master and slave registers for authentication with IOCapabilities KeyBoardOnly on master and NoInputNoOutput on Slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM3S0

Title: Verify authentication successes for IO capabilities NoInputNoOutput for master and DisplayOnly for slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities NoInputNoOutput for Master and DisplayOnly for slave

Procedures: Master and slave registers for authentication with IOCapabilities NoInputNoOutput for master and DisplayOnly for Slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM3S1

Title: Verify authentication successes for IO capability NoInputNoOutput for master and DisplayYesNo for slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities NoInputNoOutput for Master and DisplayYesNo for slave

Procedures: Master and slave registers for authentication with IOCapabilities NoInputNoOutput for master and DislpayYesNo for Slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM3S2

Title: Verify authentication successes for IO capabilities NoInputNoOutput for master and KeyBoradOnly for Slave.

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities NoInputNoOutput for Master and KeyBoardOnly for slave

Procedures: Master and slave registers for authentication with IOCapabilities NoInputNoOutput for Master and KeyBoardOnly for Slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: VerifyAuthForIOCapM3S3

Title: Verify authentication successes for IO capabilities NoInputNoOutput for master and Slave

Description: See VerifyAuthForIOCapMxSx Tests Description

Verify authentication successes for IOCapabilities NoInputNoOutput for Master and Slave

Procedures:Master and slave registers for authentication with IOCapabilities NoInputNoOutput for both Master and Slave

Master initiates the authentication

Slave accepts authentication request and sent positive response

Verify that authentication succeed

Timeout: 100

Test ID: EIREE1.1

Title: Complete EIR name is present and not null

Description: Complete EIR name is present and not null

Procedures:

Timeout: 250

Test ID: EIREE1.2

Title: Partial EIR name is present and not null

Description: Partial EIR name is present and not null

Procedures:

Timeout: 250

Test ID: EIREE1.3

Title: Complete EIR name is present and null

Description: Complete EIR name is present and null

Procedures:

Timeout: 110

Test ID: EIREE1.4

Title: Partial EIR name is present and null

Description: Partial EIR name is present and null

Procedures:

Timeout: 125

Run Time: about 45 minutes
Log File: Logs files can be specified while running tests
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows 7

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • 2 Devices to be tested
  • 2 Computers that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
Processor
  • x86
  • x64
  • IA64

Command Syntax

Command option | Description
Mjolnir.exe | Runs TCM file tet cases
-m [test machine name] | Test machine name
-c [string] | TCM file name
-l [string] | Log file name

Code Tour

File Manifest

File | Location
mjolnir.exe | [WTT\TestBinRoot]\NTTEST\driverstest\bluetooth_test
testutils.dll | [WTT\TestBinRoot]\NTTEST\DriversTest\bluetooth_test
hct.tcm | [WTT\TestBinRoot]\NTTEST\driverstest\bluetooth_test\tcm
scatternet.tcm | [WTT\TestBinRoot]\NTTEST\driverstest\bluetooth_test\tcm
sco_hct.tcm | [WTT\TestBinRoot]\NTTEST\driverstest\bluetooth_test\tcm
BTHLOGO.tcm | [WTT\TestBinRoot]\NTTEST\driverstest\bluetooth_test\tcm


Bluetooth Device Version Check

Type: Manual Test

Overview

The Bluetooth Device Version Check test verifies that the remote radio in a Bluetooth device is a 2.1 radio. This test requires two systems of the same operating system to run. The device must be paired with the system at the beginning of the test. The test does not apply to PC attached Bluetooth Radios.

Details

Two systems are required, because the test first checks whether it can connect to another known radio before trying to check the device radio.

You can run this test manually by using the command-line options with two computers (one primary and one secondary), as follows:

  • On the primary computer, run mjolnir.exe -c functional -t f8.1 -l <logFileName>

  • On the secondary computer, run mjolnir.exe -m <PrimaryMachineName>

  • On the primary computer, make sure that the device is still paired, and then enter the Bluetooth Device address in the command window when prompted. Enter the device address in the format xxxxxxxx, using no punctuation and using only the characters 0,1,2,3,4,5,6,7,8,9,0,a,b,c,d,e,f,A,B,C,D,E,F.

When running this test, there will be a prompt on the primary machine to enter the device address. The address must then be manually entered. To find the device address, double-click the Bluetooth icon in the task bar, right-click the device under test, go to Properties, and then select the Bluetooth tab. The address of the device is listed in this tab as the unique identifier. Enter the unique identifier in the prompt without spaces, dots or dashes, using only the characters shown above.

Note This test times out in two minutes so it does not block other tests from running. The test fails if a user does not enter the device address within two minutes.

Run Time: 2 minutes
Log File: bthVersionTestLog.wtl
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Two computers that meet the minimum software requirements with the same operating system

  • Windows keyboard on the primary system

  • Bluetooth Radio on the secondary system

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

The test will return fail if the device is not a Bluetooth 2.1 device.

Command Syntax

Command option | Description
mjolnir.exe | Without any options, the test does nothing.
-c functional -t f8.1 -l <logFileName> | Command options for the primary machine in the test. The primary machine will wait for the secondary machine before completing the test.
-m <PrimaryMachineName>. | Command options for the secondary machine. This must be run for the test to complete.

Code Tour

File Manifest

File | Location
mjolnir.exe | [testbinroot]\nttest\driverstest\Bluetooth
Functional.tcm | [WTT\TestBinRoot]\NTTEST\DriversTest\bluetooth_test\tcm
testutils.dll | [WTT\TestBinRoot]\NTTEST\DriversTest\bluetooth_test


Bluetooth - Point to Point

Type: Automated Test

Overview

The Bluetooth - point to point test checks the Bluetooth requirements and verifies that the system that you are testing is using valid Bluetooth specifications.

You can run this test manually by using the command-line options with 2 computers (one primary computer and one secondary computer), as follows:

On the primary computer, run mjolnir.exe -c HCT -l <logFileName>.

On the secondary computer, run mjolnir.exe -m <PrimaryMachineName>.

To debug test failures, you will need complete log files. The test will generate a text log file that you specify (in the <logFileName> parameter). Please include this file with any questions about failing results. You might also need to include a kernel debugger remote session.

Details

The test succeeds or fails based on the result of each test case, which is printed in the log file at end of each test case. Each test case that is listed in the log file must pass for the overall result to be successful.

Run Time: 45 Mins

Log File:

System Restart Required: No

Test Category:

Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows 7

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • 2 devices to be tested
  • Computer that meets the minimum software requirements
  • Color display monitor capable of at 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 the test, start the test, wait for the test to finish, and examine the generated log file for results.

In the following test descriptions, local radio refers to the radio attached to the DTM "master".

hct32.1.1.01 - Create and Close Socket Test

This test verifies that Windows Bluetooth stack is properly installed. This test does not interact with the Bluetooth radio.

Overview

The test performs the following steps:

  • Creates a Bluetooth socket.

  • Closes the socket.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Create/close socket call fails.

hct32.1.1.02 - Bind Socket Test

This test verifies that Windows Bluetooth stack is properly installed. This test does not interact with the Bluetooth radio.

Overview

The test performs the following steps:

  1. Creates a Bluetooth socket.

  2. Binds to the new socket.

  3. Closes the socket.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

hct32.2.0.01- SDP Get Device List

This test performs an inquiry.

Overview

The test performs the following steps:

  • Sends an inquiry command to the local radio.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Inquiry fails.

hct32.2.1.01 - No response when not discoverable

This test verifies that the radio can be placed in a non-discoverable state.

Overview

The test performs the following steps:

  1. Remote radio checks that it can find the local radio when it is in a discoverable state.

  2. Local radio is placed into a non-discoverable state.

  3. Remote radio verifies that the local radio is no longer found on inquiry.

  4. Local radio is returned to discoverable state.

  5. Remote radio verifies that local radio is now being found with a new inquiry.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Cannot change the discoverability of the radio.

  • Cannot find the radio when discoverable.

  • The radio is found when not discoverable.

hct32.2.2.01- Find in-range devices

This test verifies that the local radio can be found via inquiry and can find the remote radio.

Overview

The test performs the following steps:

  1. Remote radio inquires for local radio and verifies it is found.

  2. Remote host inquires its local caches and verifies the local radio is found.

  3. Local radio inquires for remote radio and verifies it is found.

  4. Local radio checks local inquiry cache and verifies remote radio is listed.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Local radio is not found during inquiry.

  • Local radio does not find remote device via inquiry.

hct32.2.3.01- Find in-range devices

This test verifies that the local radio can be found via inquiry and can find the remote radio. This test case is exactly the same of hct32.2.2.01.

Overview

The test performs the following steps:

  1. Remote radio inquires for local radio and verifies it is found.

  2. Remote host inquires its local caches and verifies the local radio is found.

  3. Local radio inquires for remote radio and verifies it is found.

  4. Local radio checks local inquiry cache and verifies remote radio is listed.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Local radio is not found during inquiry.

  • Local radio does not find remote device via inquiry.

hct32.2.4.01- Respond when not connectable

This test verifies that the remote radio is able to initiate connect when in non-connectable mode.

Overview

The test performs the following steps:

  1. A connection is established and a small amount of data is transferred to validate the functionality between the two radios.

  2. The connection is disconnected.

  3. The remote radio is put into non-discoverable and non-connectable mode.

  4. A connection is established from the remote radio and a small amount of data is transferred.

  5. The connection is disconnected.

  6. A connection is attempted from the local radio and expected to fail.

  7. The remote radio is returned to discoverable and connectable mode.

  8. A final connection is established and a small amount of data transferred.

  9. The final connection is disconnected.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The radio fails to enter non-connectable mode.

  • A connection is made to the non-connectable radio.

  • The non-connectable radio cannot initiate a connection to another radio.

hct32.3.1.01- Bonded connection

This test verifies that the two radios are able to authenticate with each other.

Overview

The test performs the following steps:

  1. Unpair any previous pairing with remote radio.

  2. Local radio pairs to remote radio.

  3. Both sides do an inquiry, local radio first.

  4. Both sides verify that the pairing was completed successfully.

  5. Some discoverability tests are run.

  6. The two radios are unpaired.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The radios fail authentication.

hct32.3.2.01- Slave role request authentication to Master role followed by connection test

This test verifies that the remote radio is able to authenticate to the local radio.

Overview

The test performs the following steps:

  1. Unpair any previous pairing with remote radio.

  2. Remote radio initiates authentication to local radio.

  3. Both sides do an inquiry, local radio first.

  4. Both sides verify that the pairing was completed successfully.

  5. The local radio establishes an authenticated connection to the remote.

  6. The link is disconnected.

  7. The two radios are unpaired.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Authentication attempt fails.

  • Post-authentication connection attempt fails.

  • Disconnect fails.

hct32.3.2.02- Master role authenticate to Slave role with connection test

This test verifies that the local radio is able to authenticate to the remote radio.

Overview

The test performs the following steps:

  1. Unpair any previous pairing with remote radio.

  2. Local radio initiates authentication to remote radio.

  3. Both sides do an inquiry, remote radio first.

  4. Both sides verify that the pairing was completed successfully.

  5. The local radio establishes an authenticated connection to the remote.

  6. The link is disconnected.

  7. The two radios are unpaired.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Authentication attempt fails.

  • Post-authentication connection attempt fails

  • Disconnect fails.

hct32.3.3.01- Master role Accept/Slave role Connect Test

This test verifies that the local radio is able to accept a socket initiated connect from the remote.

Overview

The test performs the following steps:

  1. Local radio binds to a socket and listens for an incoming connect.

  2. Remote radio attempts a connection.

  3. Both sides disconnect.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • The connect or disconnect fail.

hct32.3.3.02- Slave role Accept/Master role Connect call Test

This test verifies that the remote radio is able to accept a socket initiated connect from the local host.

Overview

The test performs the following steps:

  1. Remote radio binds to a socket and listens for an incoming connect.

  2. Local radio attempts a connection.

  3. Both sides disconnect.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • The connect or disconnect fail.

hct32.3.3.03 - Disconnect Order Test

This test verifies that multiple socket connections can be created and closed out of order.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on four sockets on the local radio host.

  2. Attempts connection on first socket and then closes that socket immediately upon connect.

  3. Attempts connection on remaining sockets.

  4. Closes remaining sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

hct32.3.3.04 - Local closes DLC Test

This test verifies that the local host can close a connection initiated by the remote.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Local host closes the socket.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

hct32.3.3.05 - Remote closes DLC Test

This test verifies that the remote host can close a connection initiated by the remote.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host closes the socket.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

hct32.3.3.06 - Local closes rfcomm session

This test verifies that the local host can close multiple socket connections initiated by the remote.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on two sockets on the local radio host.

  2. Remote host attempts to connect on both sockets.

  3. Local host closes the sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

hct32.3.3.07 - Remote closes rfcomm session

This test verifies that the remote host can close multiple socket connections initiated by the remote.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on two sockets on the local radio host

  2. Remote host attempts to connect on both sockets.

  3. Remote host closes the sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

hct32.3.4.01 - Connection test when non-connectable

This test verifies that the remote radio is able to initiate connect when in non-connectable mode. This test is identical to hct32.2.4.01.

Overview

The test performs the following steps:

  1. A connection is established and a small amount of data is transferred to validate the functionality between the two radios.

  2. The connection is disconnected.

  3. The remote radio is put into non-discoverable and non-connectable mode.

  4. A connection is established from the remote radio and a small amount of data is transferred.

  5. The connection is disconnected.

  6. A connection is attempted from the local radio and expected to fail.

  7. The remote radio is returned to discoverable and connectable mode.

  8. A final connection is established and a small amount of data transferred.

  9. The final connection is disconnected.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The radio fails to enter non-connectable mode.

  • A connection is made to the non-connectable radio.

  • The non-connectable radio cannot initiate a connection to another radio.

hct32.4.1.01 - Remote Xfer 10b w/ 1b chunk

This test verifies the transfer of 10 1-byte chunks of data from the remote radio.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host sends 10 bytes of data, in one byte chunks.

  4. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.02 - Complete recv after closesocket

This test verifies that data is still received by the local socket when the remote socket is closed immediately after sending the data. The functionality being tested by this case does not actually affect the radio.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host sends 1024 bytes of data, in 500 byte chunks.

  4. Remote host closes its socket immediately after sending data.

  5. Local host verifies that it received all data correctly.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.03 - Xfer 10 bytes w/ 1 byte chunk

This test verifies the transfer of 10 1-byte chunks of data from the local radio.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Local host sends 10 bytes of data, in one byte chunks.

  4. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.04 - Xfer 30000 bytes w/ 30000 byte chunk

This test verifies the transfer of one 30,000 byte chunk of data from the local radio.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Local host sends 30000 bytes of data, in one 30000 byte chunk.

  4. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.05 - Xfer 65535 bytes w/ 30000 byte chunk

This test verifies the transfer of 65,535 bytes of data in 30,000 byte chunks from the local radio.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Local host sends 65535 bytes of data, in 30000 byte chunks.

  4. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.06 - Xfer 0 bytes payload

This test attempts to send a 0 byte packet via winsock. The functionality being tested by this case does not actually affect the radio.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Local host attempts to send a zero byte packet.

  4. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.07 - Full Duplex Data Xfer Test, 1000 bytes total

This test verifies the transfer of 1,000 bytes of data in 100 byte chunks from the local radio.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Both local and remote hosts send 1000 bytes of data, in 100 byte chunks.

  4. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.08 - Read 1K bytes, 100 byte chunk, 2 parts

This test verifies that Windows is able to read socket data in multiple parts.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Local host sends 1000 bytes of data, in 100 byte chunks.

  4. Remote host reads data in 2 chunks.

  5. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.09 - Read 1K bytes, 100 byte chunk, 3 parts

This test verifies that Windows is able to read socket data in multiple parts.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Local host sends 1000 bytes of data, in 100 byte chunks

  4. Remote host reads data in 3 chunks.

  5. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.10 - Read 1K bytes, 100 byte chunk, 5 parts

This test verifies that Windows is able to read socket data in multiple parts.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Local host sends 1000 bytes of data, in 100 byte chunks.

  4. Remote host reads data in 5 chunks.

  5. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.12 - Async Xfer 10 byte, 1 byte chunk

This test verifies that Windows Bluetooth is able to send and receive data of different sizes.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host sends a total of 10 bytes, in 1 byte chunks.

  4. Local host reads data and then sends it back to the remote host.

  5. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.13 - Async Xfer 100 byte, 10 byte chunk

This test verifies that Windows Bluetooth is able to send and receive data of different sizes.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host sends a total of 100 bytes, in 10 byte chunks.

  4. Local host reads data and then sends it back to the remote host.

  5. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.14 - Async Xfer 1K byte, 10 byte chunk

This test verifies that Windows Bluetooth is able to send and receive data of different sizes.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host sends a total of 1000 bytes, in 10 byte chunks.

  4. Local host reads data and then sends it back to the remote host.

  5. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.15 - Async Xfer 10K byte, 100 byte chunk

This test verifies that Windows Bluetooth is able to send and receive data of different sizes.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host sends a total of 10000 bytes, in 10 byte chunks.

  4. Local host reads data and then sends it back to the remote host.

  5. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.16 - Async Xfer 30K byte, 10K byte chunk

This test verifies that Windows Bluetooth is able to send and receive data of different sizes.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host sends a total of 30000 bytes, in 10000 byte chunks.

  4. Local host reads data and then sends it back to the remote host.

  5. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.17 - Async Xfer 30K byte, 30K byte chunk

This test verifies that Windows Bluetooth is able to send and receive data of different sizes.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host sends a total of 30000 bytes, in a 30000 byte chunk.

  4. Local host reads data and then sends it back to the remote host.

  5. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.18 - Async Xfer 65535 byte, 30000 byte chunk

This test verifies that Windows Bluetooth is able to send and receive data of different sizes.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host sends a total of 65535 bytes, in 30000 byte chunks.

  4. Local host reads data and then sends it back to the remote host.

  5. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.19 - Async Xfer 65535 byte, 65535 byte chunk

This test verifies that Windows Bluetooth is able to send and receive data of different sizes.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host sends a total of 65535 bytes, in one 65535 byte chunk.

  4. Local host reads data and then sends it back to the remote host.

  5. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.4.1.20 - Overlapped I/O-Completion routine

This test verifies that Windows Bluetooth stack is properly installed. This test does not interact with the Bluetooth radio.

Overview

The test performs the following steps:

  1. Creates, binds, listens, and accepts on a socket on the local radio host.

  2. Remote host attempts a connect.

  3. Remote host sends a total of 1000 bytes, in 1 byte chunks.

  4. Local host reads data and then sends it back to the remote host.

  5. Repeat steps 3 and 4 nine more times.

  6. Both sides close their sockets.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the socket calls fail.

  • Data transfer fails.

hct32.5.1.01 - Slave role authenticate to Master role

This test verifies that the remote radio is able to authenticate to the local radio. This test is the same as hct32.3.3.01, except this test does not attempt a connection after the authentication.

Overview

The test performs the following steps:

  1. Unpair any previous pairing with remote radio.

  2. Remote radio initiates authentication to local radio.

  3. Both sides do an inquiry, local radio first.

  4. Both sides verify that the pairing was completed successfully.

  5. The two radios are unpaired.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Authentication attempt fails.

  • Disconnect fails.

hct32.5.2.01 - Master role authenticate to Slave role

This test verifies that the local radio is able to authenticate to the remote radio. This test is the same as hct32.3.3.02, except this test does not attempt a connection after the authentication.

Overview

The test performs the following steps:

  1. Unpair any previous pairing with remote radio.

  2. Local radio initiates authentication to remote radio.

  3. Both sides do an inquiry, remote radio first.

  4. Both sides verify that the pairing was completed successfully.

  5. The two radios are unpaired.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Authentication attempt fails.

  • Disconnect fails.

hct32.5.2.02 - Authenticate with multiple connections

This test verifies that the local radio is able to authenticate to the remote radio. Multiple data transfers are then completed on an authenticated link.

Overview

The test performs the following steps:

  1. Unpair any previous pairing with remote radio.

  2. Local radio initiates authentication to remote radio.

  3. Both sides do an inquiry, remote radio first.

  4. Both sides verify that the pairing was completed successfully.

  5. The local radio establishes an authenticated connection to the remote via 4 separate socket connections.

  6. The first socket is immediately closed.

  7. 1024 bytes of data is transferred on the second socket in one 1024 byte chunk and then the socket is closed.

  8. At the same time, 2048 bytes of data is transferred on the second socket in 1024 byte chunks and then the socket is closed.

  9. At the same time, 3072 bytes of data is transferred on the second socket in 1024 byte chunks and then the socket is closed.

  10. The link is disconnected.

  11. The two radios are unpaired.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Authentication attempt fails.

  • Post-authentication data transfers fail.

  • Disconnect fails.

Command Syntax

Command option | Description
mjolnir.exe -c HCT -l <logFileName> | Run this command on the primary computer.
mjolnir.exe -m <PrimaryMachineName> | Run this command on the secondary computer.


Bluetooth Remote Wake Test

Type: Automated Test

Overview

This test performs the basic validation of remote wake functionality supported by Bluetooth radio. The support for remote wake was enabled in the Windows Vista Feature Pack for Wireless and this test ensures the compliance with Bluetooth 2.1 specifications.

Details

The test comprises of a client and server applications which runs on two separate machines. The test installs the Bluetooth HID simulator on the server machine to simulate it as a keyboard device. The client pairs with the server (keyboard) and then sends a packet to the server to simulate a key press event after 60 seconds, The client machine then goes to S3 state and waits for the key press event from server. The test passes if key press event wakes the client from S3. However, if key press event is missed by client, the timer wakes the system up after 3 minutes and the test fails. In case timer wakes the system, the test application receives PBT_APMRESUMEAUTOMATIC event. If key press event wakes the system from S3, the test application first receives PBT_APMRESUMEAUTOMATIC event and then PBT_APMRESUMESUSPEND event.

Run Time: 25 minutes
Log File: bpclient.xml and bpserver.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows 7

Program: bpclient.exe and bpserver.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested

  • Two computers that meets the minimum software requirements. The system that runs the client application must support S3 state and its USB controller must provide power to the Bluetooth radio in S3 state

    Remote wake capable Bluetooth radio on the machine which runs the client application

  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 Remote Wake Test

<All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

When the test completes, review the logs to see if the test passed. The client machine should take between 60 seconds and 3 minutes to wake up. The test logs should have events PBT_APMRESUMEAUTOMATIC and PBT_APMRESUMESUSPEND in that order

The test might return SKIP if...>

Command Syntax

Command option | Description
bpclient.exe /? | Displays the usage information.
-s [server] | The name of server machine. This is a mandatory argument.
-c [filename] | The name of file containing the list of test cases to run.
bpserver.exe /? | Displays the usage information.
-m [k] | The mode supported by server, use "k" to simulate server as a keyboard device. This is a mandatory argument.

Code Tour

File Manifest

File | Location
bpclient.exe |
bpserver.exe |
rwlogolist.txt |
hidBthSim.sys |
hidBthSim.inf |
hidBthSim.cat |
pnputil.exe |


Bluetooth - Scatternet

Type: Automated Test

Overview

The Bluetooth - Scatternet test checks the Bluetooth's scatternet requirements and verifies that the system that you are testing is using valid Bluetooth specifications.

You can run this test manually by using the command-line options with three computers (one primary computer and two secondary computers), as follows:

On the primary computer, run mjolnir.exe -c Scatternet -S 2 -l <logFileName>.

On the secondary computers, run mjolnir.exe -m <PrimaryMachineName>.

To debug test failures, you will need complete log files. The test will generate a text log file that you specify (in the <logFileName> parameter). Please include this file with any questions about failing results. You might also need to include a kernel debugger remote session.

Details

The test succeeds or fails based on the result of each test case, which is printed in the log file at end of each test case. Each test case that is listed in the log file must pass for the overall result to be successful.

Run Time: 45 Mins

Log File:

System Restart Required: No

Test Category:

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 the test, start the test, wait for the test to finish, and examine the generated log file for results.

c6.1.1 - Basic scatternet 1 test with 512K data transfer

This test verifies that the radio under test is able to become the slave role in one piconet while already the master role in another and sustain these roles while transferring data.

Overview

The test performs the following steps:

  1. Remote 1 attempts to connect to the radio under test.

  2. Radio under test accepts, requesting the master role.

  3. Radio under test attempts to connect to Remote 2.

  4. Remote 2 accepts, requesting the master role.

  5. 1 MB of data (512 KB read and 512 KB written) to each of the remote radios.

  6. The links are disconnected.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the connection attempts fail.

  • Any radio is not in the expected role after the connections are established.

  • The data transfers do not complete successfully.

  • Disconnect fails.

c6.1.2 - Basic scatternet 1 test with inquiry

This test verifies that the radio under test is able to become the slave role in one piconet while already the master role in another and sustain these roles while inquiring for other devices.

Overview

The test performs the following steps:

  1. Remote 1 attempts to connect to the radio under test.

  2. Radio under test accepts, requesting the master role.

  3. Radio under test attempts to connect to Remote 2.

  4. Remote 2 accepts, requesting the master role.

  5. Radio under test inquires for Remote 1.

  6. Radio under test inquires for Remote 2.

  7. Remote radios 1 and 2 inquire for the radio under test.

  8. The links are disconnected.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the connection attempts fail.

  • Any radio is not in the expected role after the connections are established.

  • The inquiries fail to find the expected remote device.

  • Disconnect fails.

c6.2.1 - Basic scatternet 2 test with 512K data transfer

This test verifies that the radio under test is able to become the master role in one piconet while already the slave role in another and sustain these roles while transferring data.

Overview

The test performs the following steps:

  1. Radio under test attempts to connect to Remote 1.

  2. Remote 1 accepts, requesting the master role.

  3. Remote 2 attempts to connect to the radio under test.

  4. Radio under test accepts, requesting the master role.

  5. 1 MB of data (512 KB read and 512 KB written) to each of the remote radios.

  6. The links are disconnected.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the connection attempts fail.

  • Any radio is not in the expected role after the connections are established.

  • The data transfers do not complete successfully.

  • Disconnect fails.

c6.2.2 - Basic scatternet 2 test with inquiry

This test verifies that the radio under test is able to become the master role in one piconet while already the slave role in another and sustain these roles while inquiring for other devices.

Overview

The test performs the following steps:

  1. Radio under test attempts to connect to Remote 1.

  2. Remote 1 accepts, requesting the master role.

  3. Remote 2 attempts to connect to the radio under test.

  4. Radio under test accepts, requesting the master role.

  5. Radio under test inquires for Remote 1.

  6. Radio under test inquires for Remote 2.

  7. Remote radios 1 and 2 inquire for the radio under test.

  8. The links are disconnected.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the connection attempts fail.

  • Any radio is not in the expected role after the connections are established.

  • The inquiries fail to find the expected remote device.

  • Disconnect fails.

c6.3.1 - Basic scatternet 3 test with 512K data transfer

This test verifies that the radio under test is able to become the slave role in one piconet while already the slave role in another and sustain these roles while transferring data.

Overview

The test performs the following steps:

  1. Radio under test attempts to connect to Remote 1.

  2. Remote 1 accepts, requesting the master role.

  3. Radio under test attempts to connect to Remote 2.

  4. Remote 2 accepts, requesting the master role.

  5. 1 MB of data (512 KB read and 512 KB written) to each of the remote radios.

  6. The links are disconnected.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the connection attempts fail.

  • Any radio is not in the expected role after the connections are established.

  • The data transfers do not complete successfully.

  • Disconnect fails.

c6.3.2 - Basic scatternet 3 test with inquiry

This test verifies that the radio under test is able to become the slave role in one piconet while already the slave role in another and sustain these roles while inquiring for other devices.

Overview

The test performs the following steps:

  1. Radio under test attempts to connect to Remote 1.

  2. Remote 1 accepts, requesting the master role.

  3. Radio under test attempts to connect to Remote 2.

  4. Remote 2 accepts, requesting the master role.

  5. Radio under test inquires for Remote 1.

  6. Radio under test inquires for Remote 2.

  7. Remote radios 1 and 2 inquire for the radio under test.

  8. The links are disconnected.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Any of the connection attempts fail.

  • Any radio is not in the expected role after the connections are established.

  • The inquiries fail to find the expected remote device.

  • Disconnect fails.

Command Syntax

Command option | Description
mjolnir.exe -c Scatternet -S 2 -l <logFileName> | Run this command on the primary computer.
mjolnir.exe -m <PrimaryMachineName> | Run this command on the secondary computers.


Bluetooth - SCO

Type: Automated Test

Overview

The Bluetooth - SCO test checks the Bluetooth logo requirements and verifies that the system that you are testing is using valid Bluetooth specifications.

You can run this test manually by using the command-line options only after you install bthcsti (the test driver) and restart all of the computers. This test requires two computers (one primary computer and one secondary computer), and you can run the test as follows:

On the primary computer, run mjolnir.exe -c SCO_HCT -l <logFileName>.

On the secondary computer, run mjolnir.exe -m <PrimaryMachineName>.

To debug test failures, you will need complete log files. The test will generate a text log file that you specify (in the <logFileName> parameter). Please include this file with any questions about failing results. You might also need to include a kernel debugger remote session.

Details

The test succeeds or fails based on the result of each test case, which is printed in the log file at end of each test case. Each test case that is listed in the log file must pass for the overall result to be successful.

To install the bthcsti driver, do the following:

  1. Copy the bthcsti.inf, bthcsti.sys, bthcsti.cat, bthcstisetup.exe, and devcon.exe files into a directory and run the remaining steps from that directory.

  2. Run bthcstisetup.exe.

  3. Run devcon dp_add bthcsti.inf.

  4. Restart the computer.

  5. In Device Manager, verify that the bthcsti driver is installed.

Run Time: 45 Mins

Log File:

System Restart Required: Yes

Test Category:

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 the test, start the test, wait for the test to finish, and examine the generated log file for results.

SCO1.1.1.1 - Create and Close SCO Cxn Test

This test verifies that the radio is able to create a single SCO channel.

Overview

The test performs the following steps:

  1. Attempts to open a single SCO channel.

  2. Disconnects

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The SCO connection attempt fails.

  • The disconnect fails.

SCO1.1.1.3 - Create Two SCO Cxn and Close Test

This test verifies that the radio is able to support two active SCO channels at the same time.

Overview

The test performs the following steps:

  1. Attempts to open a SCO channel.

  2. If successful, attempts to open a second SCO channel.

  3. Disconnects both channels.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Either SCO channel attempt fails.

  • The disconnect fails.

SCO1.1.2.2 - Create and Close SCO Cxn with HV2 Packet Type

This test verifies that the radio is able to create a SCO channel that uses only HV2 packets.

Overview

The test performs the following steps:

  1. Attempts to open a SCO channel with HV2 only packets.

  2. Disconnects.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The SCO connection attempt fails.

  • The disconnect fails.

SCO1.1.2.3 - Create and Close SCO Cxn with HV3 Packet Type

This test verifies that the radio is able to create a SCO channel that uses only HV3 packets.

Overview

The test performs the following steps:

  1. Attempts to open a SCO channel with HV3 only packets.

  2. Disconnects.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The SCO connection attempt fails.

  • The disconnect fails.

SCO1.1.3.2 - Create SCO Cxn with SCO_CF_LINK_ENCRYPTED, Master Role Sets Flag

This test verifies that the radio under test is able to establish a SCO channel on top of an authenticate/encrypted link.

Overview

The test performs the following steps:

  1. Unpairs remote device if currently paired.

  2. Test master role attempts to create an ACL link.

  3. Test master role attempts to authenticate and encrypt the ACL link.

  4. Test master role attempts to open a SCO channel on the encrypted link.

  5. Disconnects.

  6. Unpairs remote device.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The SCO connection attempt fails.

  • The attempt to authenticate and/or encrypt the link fails.

  • The disconnect fails.

SCO1.2.3.2 - Create SCO Cxn with SCO_CF_LINK_ENCRYPTED, Slave Role Sets Flag

This test verifies that the radio under test is able to establish a SCO channel on top of an authenticate/encrypted link.

Overview

The test performs the following steps:

  1. Unpairs remote device if currently paired.

  2. Test master role attempts to create an ACL link.

  3. Test master role attempts to open a SCO channel.

  4. Test slave role attempts to authenticate and encrypt the link after accepting the SCO connection request.

  5. Disconnects.

  6. Unpairs remote device.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The SCO connection attempt fails.

  • The attempt to authenticate and/or encrypt the link fails.

  • The disconnect fails.

SCO2.3.3.1 - Disconnect Both Sides Simultaneously

This test attempts to disconnect the ACL link from both sides at the same time.

Overview

The test performs the following steps:

  1. Attempts to open a single SCO channel.

  2. Disconnects both sides simultaneously.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The SCO connection attempt fails.

  • The disconnect fails.

Note concerning the following data verification tests:

This information is provided to assist the qualifying customers in troubleshooting any failures they may experience in running these tests. In the following data verification tests, data being sent across the air conforms to the following, repeated, pattern:

typedef struct _TEST_UNIT

{

USHORT Header; // 0xDEAD

USHORT Size; // actual size of test unit, including data size from caller

USHORT Sequence; // identifier (count) for a stream of test units

USHORT Crc16; // not being used as CRC right now, just 1's complement of Sequence

USHORT Data; // variable size, starts with lower byte of sequence and gets incremented

USHORT Footer; // 0xBEEF

} TEST_UNIT, *PTEST_UNIT;

The sequence value is incremented for every test unit sent across the air. If necessary, these packets can be easily picked out in an air trace and decoded manually.

SCO1.5.5.1 - Full Duplex Read and Write Test, 700 kb, Clear Data

This test verifies that the radio under test is able to send and receive SCO data without error.

Overview

The test performs the following steps:

  1. Attempts to open a single SCO channel.

  2. Attempts to send approximately 700 kb of data while receiving an equal amount.

  3. The test validates the data after receipt.

  4. Disconnects.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The SCO connection attempt fails.

  • The amount of dropped data or errors is greater than 10% of the total transferred.

  • The average throughput of the data transmissions deviates from 64 kbps by more than 2 kbps.

  • The disconnect fails.

SCO1.5.11.2 - Full Duplex Read and Write Test with ACL data, 700 kb, mu-Law

This test verifies that the radio under test is able to send and receive SCO data without error while there is an active ACL link in the background also transmitting data.

Overview

The test performs the following steps:

  1. Creates a single L2CAP channel.

  2. Attempts to open a single SCO channel.

  3. Starts transferring L2CAP data back and forth in the background.

  4. Attempts to send approximately 700 kb of data while receiving an equal amount.

  5. The test validates the SCO data after receipt.

  6. Disconnects both L2CAP and SCO channels.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The SCO connection attempt fails.

  • The amount of dropped SCO data or errors is greater than 10% of the total transferred.

  • The average throughput of the SCO data transmissions deviates from 64 kbps by more than 2 kbps.

  • The L2CAP channel fails any data transfers or is prematurely lost.

  • The disconnect fails.

SCO1.5.13.3 - Full Duplex Read and Write Test on Two Channels, 700 kb, A-Law

This test verifies that the radio under test is able to send and receive data simultaneously on two SCO channels without error.

Overview

The test performs the following steps:

  1. Attempts to open a SCO channel.

  2. Attempts to open a second SCO channel.

  3. Attempts to send approximately 700 kb of data while receiving an equal amount on each channel.

  4. The test validates the data after receipt.

  5. Disconnects.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Either of the SCO connection attempts fail.

  • The amount of dropped data or errors is greater than 10% of the total transferred.

  • The average throughput of the data transmissions deviates from 64 kbps by more than 2 kbps.

  • The disconnect fails.

SCO1.5.14.1 - Full Duplex Read and Write Test with Inquiries, 700 kb, Clear Data

This test verifies that the radio under test is able to send and receive SCO data without error while the radio is inquiring for remote devices.

Overview

The test performs the following steps:

  1. Attempts to open a single SCO channel.

  2. Starts requesting inquiries, in a loop, on both master role and slave role radios.

  3. Attempts to send approximately 700 kb of SCO data while receiving an equal amount.

  4. The test validates the SCO data after receipt.

  5. Disconnects.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The SCO connection attempt fails.

  • The amount of dropped SCO data or errors is greater than 10% of the total transferred.

  • The average throughput of the SCO data transmissions deviates from 64 kbps by more than 2 kbps.

  • Any inquiry requests fail.

  • The disconnect fails.

SCO1.5.30.2 - Loopback Latency Measurement, 700 kb, mu-Law

This test verifies that the round trip latency of Bluetooth transfers using the radio under test are within an acceptable range.

Overview

The test performs the following steps:

  1. The slave role test machine is set up to receive SCO data and immediate reflect the same data back to the master role test machine.

  2. A single SCO channel is created.

  3. The master role side streams 10,000 72 byte blocks to the radio. Every 10th block consists entirely of a specific byte value (the "token" value) repeated over the 72 bytes. That token value is incremented for every 10th block (and wraps around after 255). All other blocks are zero. A timestamp is taken when each 10th block is sent. At the same time, the master role side is also listening for these token blocks in a separate thread and takes a timestamp when each is received. Take the time delta, divide by two, and you have the approximate latency in one direction. In a sniffer trace, you would see blocks of data that look like this (each byte is repeated 72 times, but it is just listed once here):

    01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 02, ...03, ...04, ...and then much later ...FF, ...01 etc...

    The receiving thread only waits to find a small chunk of this data (it doesn't care if all 72 bytes are not there) before taking the timestamp and incrementing the token.

  4. After receiving all 10,000 blocks, the links are disconnected.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The SCO connection attempt fails.

  • The amount of dropped token data packets is greater than 30% of the total transferred.

  • The average throughput of the SCO data transmissions deviates from 64 kbps by more than 2 kbps.

  • The one way latency is greater than 50 ms for any single token packet transfer.

  • The disconnect fails.

Command Syntax

Command option | Description
mjolnir.exe -c SCO_HCT -l <logFileName> | Run this command on the primary computer.
mjolnir.exe -m <PrimaryMachineName> | Run this command on the secondary computer.

Cautions

If you are having trouble with the SCO data tests failing due to higher than expected error rates, make sure that the radios have line of sight and are within a few feet of each other.


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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • If testing a CardBus bridge/controller, One CardBus card that complies with the requirements of the "Designed for Microsoft Windows" Logo Program for Hardware.
Processor
  • x86
  • x64
  • Itanium

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

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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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 Logo Kit (WLK) are used in several different test system configurations for 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Command Syntax

Command option | Description
Cbbridge.exe |

Code Tour

File Manifest

File | Location
Cbbridge.exe | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pcidll.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pcclib.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pciwdm.sys | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk

Test Assertions

14.2.1System 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-0008 Open HCI controller support IEEE 1394a -1999
14.2.2CardBus bridges must implement configuration header type 2.
Test Assertion GUID: b891202e-c33f-11da-94f3-00123f3a6b60
Windows Logo Program: BUSPORT-0006 Open HCI controller support IEEE 1394a -1999
14.2.5Device 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 Open HCI controller support IEEE 1394a -1999
14.2.6CardBus 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 Open HCI controller support IEEE 1394a -1999
14.2.7CardBus 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 Open HCI controller support IEEE 1394a -1999
14.2.8Bus 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 Open HCI controller support IEEE 1394a -1999
14.2.9CardBus 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 Open HCI controller support IEEE 1394a -1999
14.2.10CardBus 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 Open HCI controller support IEEE 1394a -1999
14.2.11CardBus 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 Open HCI controller support IEEE 1394a -1999
14.2.12CardBus 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 Open HCI controller support IEEE 1394a -1999
14.2.13CardBus 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 Open HCI controller support IEEE 1394a -1999
14.2.14CardBus 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 Open HCI controller support IEEE 1394a -1999
14.2.15CardBus 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 Open HCI controller support IEEE 1394a -1999
14.2.16CardBus bridges must implement Cap_Ptr register (offset 14h).
Test Assertion GUID: b891203a-c33f-11da-94f3-00123f3a6b60
Windows Logo Program: BUSPORT-0006 Open HCI controller support IEEE 1394a -1999
14.2.17CardBus Bridge Cap_Ptr offset must be DWORD-aligned.
Test Assertion GUID: b891203b-c33f-11da-94f3-00123f3a6b60
Windows Logo Program: BUSPORT-0006 Open HCI controller support IEEE 1394a -1999
14.2.18CardBus 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 Open HCI controller support IEEE 1394a -1999
14.2.19CardBus 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 Open HCI controller support IEEE 1394a -1999
14.2.21All 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 Open HCI controller support IEEE 1394a -1999


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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • If testing a CardBus bridge/controller, One CardBus card that complies with the requirements of the "Designed for Microsoft Windows" Logo Program for Hardware.
Processor
  • x86
  • x64
  • Itanium

Command Syntax

Command option | Description
cbcomsig.exe |

Code Tour

File Manifest

File | Location
cbcomsig.exe | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pcidll.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pcclib.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pciwdm.sys | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk

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
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
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
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
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
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
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
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


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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Command Syntax

Command option | Description
cbcreg.exe |

Code Tour

File Manifest

File | Location
cbcreg.exe | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pcidll.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pcclib.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pciwdm.sys | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk

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
14.6.2 CardBus cards must have a separate configuration space for each implemented function.
Test Assertion GUID: 959be3ea-c341-11da-94f3-00123f3a6b60
Windows Logo Program: CONNECT-0012 CardBus card is configured correctly
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
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
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
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
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
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
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


Check for HID Devices that Can't Wake the System

Type: Automated Test or Manual Test

Overview

This test is not required to get a logo (see details in "Running the Test" below). The test script enumerates all HID devices in the system by passing HID Device interface Class GUID. It then checks whether each HID device supports the following power capabilities:

  • PDO_WAKE_FROM_D0_SUPPORTED

  • PDO_WAKE_FROM_D1_SUPPORTED

  • PDO_ WAKE_FROM_D2_SUPPORTED

  • PDO_ WAKE_FROM_D3_SUPPORTED

If any HID device doesn't support these power capabilities, then the test case will fail.

Details

Run Time: 2 minutes
Log File: ValidateHIDDevices.wtl
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: cscript with TS8_ValidateHIDDevices.vbs

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • System to be tested that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy the script.

  3. Execute the test script.

  4. Uninstall the MSI.

Command Syntax

Command option | Description
TS8_ValidateHIDDevices.vbs | Script that checks for HID devices that cannot wake the system test.
/VID:[VID] /PID:[PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter.
/ID:[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.

Code Tour

File Manifest

File | Location
TS8_ValidateHIDDevices.vbs | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestScripts
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


Disable a Device's Controller Test

Type: Automated Test

Overview

This test is not required to get a logo (see details in "Running the Test" below). This test script takes the Device Instance Path or VID\PID of a device and number of iterations as command line parameters. It then finds the device and USB controller of that device. It disables and re-enables the USB controller of that device. It then checks whether the USB controller has the device as its child or not. If found, the test continues for the next iteration; otherwise the test fails and stops.

Details

Run Time: 2 minutes
Log File: DisableDevController.wtl
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: cscript.exe with TS4_DisableDevController.vbs

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Since this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy the script.

  3. Execute the test script.

  4. Uninstall the MSI.

Command Syntax

Command option | Description
TS4_DisableDevController.vbs | Script that runs the disable a device's controller test.
TS4_DisableDevController.vbs | Script that runs the disable a device's controller test.
/ID:[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.
/iter:[ITERATIONS] | The number of iterations for this test to run. The default is set to 3.

Code Tour

File Manifest

File | Location
TS4_DisableDevController.vbs | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestScripts
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


Disable Device Hierarchy Test

Type: Automated Test

Overview

This test is not required to get a logo (see details in "Running the Test" below). This test script takes the number of iterations as a parameter. It first enumerates the entire USB Host controller. The children and sub-children of each USB host controller are found and disabled, from the lowest child to the USB host controller recursively. Each USB host controller is re-enabled, and then its children and sub-children recursively. If any of the devices is not disabled or re-enabled, then the test is marked as failed; otherwise, the test will again disable and re-enable the devices in the next iterations.

Details

Run Time: 5 minutes
Log File: StressUSBDeviceTree.wtl
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: cscript with TS6_StressUSBDeviceTree.vbs

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • System to be tested that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see the How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy the script.

  3. Execute the test script.

  4. Uninstall the MSI.

Command Syntax

Command option | Description
TS6_StressUSBDeviceTree.vbs | Script that runs the disable device hierarchy test
/VID:[VID] /PID:[PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter.
/ID:[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.

Code Tour

File Manifest

File | Location
TS6_StressUSBDeviceTree.vbs | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestScripts
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


Disable Enable Composite Device

Type: Automated Test

Overview

This test is not required to get a logo (see details in "Running the Test" below). This test script takes Device Instance Path or VID/PID (Device Instance Path) of a composite device (i.e. a device having child devices) and number of iterations (N) as command line parameter. It finds the device and all its children and stores them in a list. It then disables and re-enables the device. After this operation, it again finds the children of the device and stores them in another list. The previous list is compared with that of the current list of devices. If both the lists are same, then the test is repeated until all of the N iterations are complete. During this process, if the base list and current list is not matched, then the test is marked as failed and is ended.

Details

Run Time: 1 minute
Log File: StressCompDev.wtl
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: cscript.exe with TS3_StressCompDev.vbs

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy the script.

  3. Execute the test script.

  4. Uninstall the MSI.

Command Syntax

Command option | Description
TS3_StressCompDev.vbs | Script that runs the stress enabling and disabling of a composite device test.
/VID:[VID] /PID:[PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter.
/ID:[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.
/iter:[ITERATIONS] | The number of iterations for this test to run. The default is set to 3.

Code Tour

File Manifest

File | Location
TS3_StressCompDev.vbs | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestScripts
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


Disable the Controller of a Disabled Device

Type: Automated Test

Overview

This test is not required to get a logo (see details in "Running the Test" below). This test script takes Device Instance Path or VID\PID of a device and number of iterations as command line parameters. It finds the device, checks its state (Attached or Enabled status), and disables it. It then finds the device's USB controller and disables it. It re-enables the USB controller and then re-enables the device. Finally, it checks whether the device is re-enabled in the same state as before. If not, the test is failed; otherwise, it continues for the next iteration.

Details

Run Time: 1 minute
Log File: StressDisabledCtller.wtl
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: cscript.exe with TS5_StressDisabledController.vbs

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Since this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM please see the How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy the script.

  3. Execute the test script.

  4. Uninstall the MSI.

Command Syntax

Command option | Description
TS5_StressDisabledController.vbs | Script that runs the disable a controller of a disabled device test.
/VID:[VID] /PID:[PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter.
/ID:[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.
/iter:[ITERATIONS] | The number of iterations for this test to run. The default is set to 3.

Code Tour

File Manifest

File | Location
TS5_StressDisabledController.vbs | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestScripts
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


DPWS WLK tests

Type: Automated

Overview

This test is designed to test basic discoverability and metadata exchange between the Windows operating system and a DPWS based device. This test includes some metadata retrieval and discover stress.

Details

There are 7 tests that are run the details of these tests are

DeviceBootShutdown

Timeout: 120000

Verify shutdown and bootup message sequences. This test verifies device boot up and shutdown sequences. This test expects the device to shutdown and boot back up during testing. The test itself displays a message "Waiting for the device to Send BYE...", it is after this that the device must shutdown appropriately. After this is complete the test will expect a startup sequence, this will be indicated by the message "Waiting for the device to send HELLO..."

DeviceResolve

Timeout: 120000

This test verifies that the DPWS device responds correctly to resolves and metatdata requests.

DeviceProbe

Timeout: 30000

Verifies that the DPWS device responds correctly to Probe and metadata requests

DeviceDirectedProbe

Timeout: 30000

Verifies that the DPWS device responds correctly to directed probe requests

Extensibility

Timeout: 30000

Verifies that the DPWS device responds correctly when there are extensibility sections

DeviceMetadataStress

Timeout: 1000000

Metadata request stress. Here we only hit the device with metadata requests

DeviceMetadataStress

Timeout: 1000000

Metadata request stress, including resolves. Here we only hit the device with the Resolve and Metadata Request pattern

ProbeFault

Timeout: 1000000

Verifies that the DPWS device responds correctly to an incorrect Probe.

MetadataFault

Timeout: 1000000

Verifies that the DPWS device responds correctly to an incorrect metadata request.

Run Time: 15 minutes
Log File: dpwswlk.trace.txt
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Server 2008

  • Windows 7

Program: dpwswlk.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86
  • x64
  • IA64

Running DPWSWLK tests

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

dpwswlk.exe /cfg dpwswlk.config deviceId=<deviceId>

Command option | Description
dpwswlk.exe | This is the executable that is run
/cfg | This will specify the config file to be used to run, the only one that is supplied is the dpwswlk.config file
/deviceId | This is the device Id of the device that is being tested.

Code Tour

File Manifest

File | Location
dpwswlk.exe.exe | [testbinroot]\nttest\basetest\ncd\wsd\
dpwswlk.config | [testbinroot]\nttest\basetest\ncd\wsd\


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.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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:
    • 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.
    • Validate the record header revision field (should be equal to 0x0002).
    • Validate the record header severity field (should be equal 0x0 or 0x1, which means a fatal error).
    • Validate the error record valid bits (should be larger than one).
    • Validate each section of the error record:
      • Validate section header revision field (should be equal to 0x0002).
      • Validate section header recovery info (should be equal to zero).
      • 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:
    • 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.
    • Validate the record header revision field (should be equal to 0x0002).
    • Validate the record header severity field (should be equal to 0x2, which means a corrected error).
    • Validate the error record valid bits (should be larger than one).
    • Validate each section of the error record.


PCI/PCI Express Compliance Test (PCIHCT)

Type: Automated Test

Overview

The PCI/PCI Express Compliance Test, or PCIHCT, is a test tool that verifies that PCI and PCI-compatible hardware device interfaces are implemented in compliance with published specifications by PCI-SIG and Microsoft.

Details

PCIHCT focuses on the software interface of a device (also known as the configuration space). The configuration space contains hardware registers that the software can access. This access enables hardware to expose its device type, device class, capabilities, state, status, and other information to the operating system. The operating system can also configure and control the device through the configuration space registers. Plug and Play (PnP) and power management use these extensively.

For proper operation and stability of the operating system and its base functions, it is crucial that the hardware operates as expected.

PCIHCT checks for errors in hardware implementations of the configuration space such as:

  1. Invalid values are specified in registers.

  2. Read-only registers can be written to.

  3. Writable registers cannot be written to.

  4. Registers that are supposed to clear on a write of 1 do not.

  5. Registers that are supposed to retain their values through a reset lose them.

  6. Writing certain values causes the device (and in some cases the system) to stop responding (that is, "hang").

  7. Not all features or capabilities are implemented as required by the specifications.

For more information, see the following specifications:

  • PCI Express Base Specification 1.0a

  • PCI Power Management 1.1

  • PCI-to-PCI Bridge Specification 1.2

  • PCI Local Bus Specification 2.3

  • PCI Express to PCI/PCI-X Bridge Specification 1.0

  • PCI-X Protocol Addendum to the PCI Local Bus Specification Revision 2.0a

Run Time: 10 minutes

Log File: PciHct.WTL

System Restart Required: Yes

Test Category:

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 (PCIHCT)

For Windows Vista or later operating systems, the PCI Hardware Compliance Test (PCIHCT) is automatically selected in 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 PCIHCT log after a test run, do the following:

  1. Open the Job Monitor window.

  2. Select the machine that ran the job.

  3. In the Job Execution Status pane, select the job.

  4. In the Task Execution Status pane, right-click the Process Logged Messages task, and click View Task Log.

  5. From the list at the top left of the window, select ContextTree. The log file will be displayed in an organized fashion according to PCI function and further organized into test sections.

  6. Expand or collapse sections by clicking on the nodes.


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 comply with industry standards for PCI devices as well as several specific Microsoft requirements for PCI devices that might 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 (for example, base classes 0h, Bh, or Eh) or a base class/subclass combination that does not need testing (for example, 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 run 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 (PnP) identifier (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.

For Server, the test checks whether Server and the base classes for Network and Storage are PCIe. If they are not, then the test will fail.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 the Microsoft Windows operating system, the PCI Hardware Compliance Test (PCITEST2_1) will be automatically selected in Driver Test Manager (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, do the following:

  1. Open the Job Monitor window.

  2. Select the machine that ran the job.

  3. In the Job Execution Status pane, select the job.

  4. In the Task Execution Status pane, right-click Run Test, and click View Task Log.

  5. From the list at the top left of the window, click ContextTree. The log file will be displayed in an organized fashion according to PCI function and further organized into test sections.

  6. Expand or collapse sections by clicking on the nodes.


Secure Digital Test

Type: Automated Test

Overview

The Secure Digital Test is designed to test Secure Digital (SD) host controllers. This test loads a test driver, sdhct.sys, that enables it access the SD host controller hardware directly.

Details

The SD Bus Host Controller software enables you to verify the correct operation of an SD controller on a Windows platform that has a logo. 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • SD Memory Card
  • SDIO Card
Processor
  • x86
  • x64
  • Itanium

Running Secure Digital Test

  1. Start the test from Driver Test Manager (DTM).

  2. Allow the machine 5 minutes to load the test driver and restart.

  3. Go to the test machine and follow the on-screen instructions to insert and remove the SD card.

To run the test manually, you must manually insert and remove SD cards. This activity will occur after the test has restarted the machine for the first time.

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

Test Assertions

PCI Standard conformance
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80101
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
byte-aligned access
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80102
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
word-aligned access
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80103
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
double word-aligned access
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80104
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
byte-aligned access
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80105
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
word-aligned access access
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80106
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
double word-aligned access
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80107
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
SDHC Version definition
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80108
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
voltage definition sufficient
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80109
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
base clock frequency sufficient
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8010A
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
current supply definition sufficient
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8010B
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
base clock supports high speed
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8010C
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
valid maximum block length
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8010D
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
valid HC timeout clock frequency
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8010E
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Card inserted - State set through Test Register
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80201
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Card NOT inserted - State set through Test Register
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80202
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Test Register generates card insert interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80203
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Test Register generates card remove interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80204
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Detect card insertion
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80205
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Card Present bit set
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80206
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Detect card removal
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80207
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Card Present bit NOT set
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80208
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Wake on card insertion
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80209
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Card present bit set
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8020A
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Wake on card removal
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8020B
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Card present bit NOT set
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8020C
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Inhibit wake on card insertion
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8020D
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Card present bit set
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8020E
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Inhibit wake on card removal
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8020F
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Card present bit NOT set
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80210
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Single block PIO read/write
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80301
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Multi-block PIO read/write
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80302
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Single block DMA read/write
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80303
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Multi-block DMA read/write
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80304
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Single block ADMA read/write
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80305
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Multi-block ADMA read/write
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80306
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Varying bus clock affects performance
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80401
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Varying data width affects performance
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80402
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Demonstrates high performance
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80403
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Correct power consumption reported
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80501
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Power consumption increased from P10 to P11
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80502
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Power consumption increased from P11 to P12
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80503
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Power consumption increased from P12 to P13
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80504
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Power consumption increased from P13 to P14
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80505
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force cmd timeout error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80601
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force cmd CRC error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80602
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force cmd end bit error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80603
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force cmd index error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80604
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force data timeout error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80605
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force data CRC error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80606
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force data end bit error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80607
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force current limit error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80608
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force Auto CMD12 not executed error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80609
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force Auto CMD12 timeout error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8060A
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force Auto CMD12 CRC error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8060B
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force Auto CMD12 end bit error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8060C
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force Auto CMD12 index error status
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8060D
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force cmd timeout error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8060E
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force cmd CRC error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8060F
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force cmd end bit error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80610
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force cmd index error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80611
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force data timeout error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80612
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force data CRC error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80613
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force data end bit error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80614
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force current limit error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80615
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force Auto CMD12 not executed error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80616
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force Auto CMD12 timeout error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80617
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force Auto CMD12 CRC error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80618
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force Auto CMD12 end bit error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e80619
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements
Force Auto CMD12 index error interrupt
Test Assertion GUID: 52ff1b1b-fe4f-4427-bc06-e0c118e8061A
Windows Logo Program: BUSPORT-0011 Secure Digital I/O (SDIO) host controllers comply with industry standards and Windows KMDF requirements


Stress Enabling and Disabling a Specific USB Device

Type: Automated Test

Overview

This test is not required to get a logo (see details in "Running the Test" below). The stress enable and disable test script takes the VID and PID of a device and number of iterations for stress as parameter. Alternatively, the test script also takes Device Instance Path of the device as cmdline parameter to find the device. First, the test gets the problem status and problem code, then it disables the device and re-enables the device. It then checks the problem status and problem code again. The status before and after disable/enable operation are compared again. If the comparison doesn't match, the test fails.

Details

Run Time: 2 minutes (for default of 3 iterations)
Log File: StressUSBDevice.wtl
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: cscript.exe with TS1_StressUSBDevice.vbs

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy the stress disable / enable script.

  3. Execute the test script.

  4. Uninstall the MSI.

Command Syntax

Command option | Description
TS1_StressUSBDevice.vbs | Script that runs the stress enabling and disabling test.
/VID:[VID] /PID:[PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter.
/ID:[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.
/iter:[ITERATIONS] | The number of iterations for this test to run. The default is set to 3.

Troubleshooting

Code Tour

File Manifest

File | Location
TS1_StressUSBDevice.vbs | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestScripts
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


Stress Selective Suspend

Type: Automated Test

Overview

This test is not required to run to get a logo (see details in "Running the Test" below). This test script takes the device instance path or the VID\PID of a device as a command line parameter. It finds the device, enables the selective suspend feature, and waits for the given device to be suspended (power state is kept to D3). After the device gets suspended, it disable the selective suspend feature and waits for the device to wake. It then obtains the power state of the given device. If the state is not equal to D0, then the test case fails.

Details

Run Time: 2 minutes
Log File: StressSelSusp.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: cscript.exe with TS2_StressSelectiveSusp.vbs

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy the script.

  3. Execute the test script.

  4. Uninstall the MSI.

Command Syntax

Command option | Description
TS2_StressSelectiveSusp.vbs | Script that runs the stress selective suspend test.
/VID:[VID] /PID:[PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter.
/ID:[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.

Code Tour

File Manifest

File | Location
TS2_StressSelectiveSusp.vbs | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestScripts
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


Test Stress Uninstall of all USB Controllers

Type: Automated Test

Overview

This test is not required to get a logo (see details in "Running the Test" below). This test finds all the USB controllers on a system and saves the controllers' information in an XML file as a base-controller list. Then, it uninstalls all the USB controllers and reboots the system. After the system restart, it finds all of the USB controllers available on the system and compares them with the base controller list. If the current controller list is matched with the base list, then the test passes.

Details

Run Time: 2 minutes
Log File: StressUSBCtrl.wtl
System Restart Required: Yes
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: TestUSBCtlrs.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • System with USB Host Controllers to be tested

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy over the app configuration file.

  3. Copy and execute TestUSBCtrls.exe.

  4. Restart the system.

  5. Run TestUSBCtrls.exe again.

  6. Uninstall the MSI.

Command Syntax

Command option | Description
TestUSBCtlrs.exe | Launches the test. To successfully launch, must be followed by the number of iterations to run.
[number] | Number of iterations for the test to run.

Code Tour

File Manifest

File | Location
DeviceTestConfig.xml | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestApps
TestUSBCtlrs.exe | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestApps
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


Test Power transition [S3 AND S4] supported for a device

Type: Automated Test

Overview

This test is not required to get a logo (see details in "Running the Test" below). This test takes the VID\PID for a device, a power state, and a number of iterations as command line parameter.

Using DevED, it finds the device and disables it. It then puts the system into the specified power state,

sets back to S0 power state, and enables the device. It validates whether the device is reenabled or not.

Details

Run Time: 3 minutes
Log File: DevicePowerTest.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: DevicePowerTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy the devicetestconfig.xml and DevicePowerTest.exe.

  3. Execute DevicePowerTest.exe.

  4. Uninstall the MSI.

Command Syntax

Command option | Description
DevicePowerTest.exe | Launches the device power state test. Will not work unless parameters are defined.
[VID] [PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter.
[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.
[S[3 or 4 or 5]] | Power state to cycle through.
[ITERATIONS] | The number of iterations for this test to run. The default is set to 3.

Code Tour

File Manifest

File | Location
DevicePowerTest.exe | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestApps
DeviceTestConfig.xml | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestApps
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


Test Power transition [S5] supported for a device

Type: Automated Test

Overview

This test is not required to get a logo (see details in "Running the Test" below). This test takes the VID\PID for a device, a power state, and a number of iterations as command line parameter.

Using DevED, it finds the device and disables it. It then puts the system into the specified power state (S5), sets back to S0 power state, and enables the device. It validates whether the device is re-enabled or not.

Details

Run Time: 3 minutes
Log File: DevicePowerTest.wtl
System Restart Required: Yes
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: DevicePowerTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy the devicetestconfig.xml and DevicePowerTest.exe.

  3. Execute DevicePowerTest.exe.

  4. Uninstall the MSI.

Command Syntax

Command option | Description
DevicePowerTest.exe | Launches the device power state test. Will not work unless parameters are defined.
[VID] [PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter.
[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.
[S[3 or 4 or 5]] | Power state to cycle through.
[ITERATIONS] | The number of iterations for this test to run. The default is set to 3.

Code Tour

File Manifest

File | Location
DevicePowerTest.exe | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestApps
DeviceTestConfig.xml | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestApps
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


Test Query Power Draw on a Disabled USB Device

Type: Automated Test

Overview

This test is not required to get a logo (see details in "Running the Test" below). The test script takes the Device Instance path or VID\PID of a USB hub as a command line parameter. The script finds the children of the Hub and disables them. It then queries for the power drawn by the USB hub to determine whether it is 0A or not. If the power drawn is 0A, then the test passes. To determine the amount of power drawn by a USB Hub, a component was developed that enumerates the specified USB hub ports and determines the power drawn by each hub. The component needs to be registered before running the test script.

Details

Run Time: 2 minutes
Log File: DevicePowerdraw.wtl
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: cscript with TS10_DevicePowerdraw.vbs

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy and register the PowerQuery component.

  3. Copy the script.

  4. Execute the test script.

  5. Uninstall the MSI.

Command Syntax

Command option | Description
TS10_DevicePowerdraw.vbs | Script that runs the query power draw on a Disabled USB device test.
/VID:[VID] /PID:[PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter.
/ID:[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.

Code Tour

File Manifest

File | Location
TS10_DevicePowerdraw.vbs | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestScripts
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


Test Uninstall a Disabled Device

Type: Automated Test or Manual Test

Overview

This test takes the VID\PID of a device as a command line argument. It finds the device and uninstalls it. It then reboots the system and validates whether the specified device is properly reinstalled or not. This process continues repeated continuously until the specified number of iterations. If during any one iteration the device is not reinstalled properly, then the test is failed and exited.

Details

Run Time: 2 minutes
Log File: DeviceUninstallTest.wtl
System Restart Required: Yes
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: TestDeviceUninstall.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy the devicetestconfig.xml and TestDeviceUninstall.exe.

  3. Execute TestDeviceUninstall.exe.

  4. Uninstall the MSI.

Command Syntax

Command option | Description
DevicePowerTest.exe | Launches the uninstall a disabled device test. Will not work unless parameters are defined.
[VID] [PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter.
[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.
[ITERATIONS] | The number of iterations for this test to run. The default is set to 3.

Code Tour

File Manifest

File | Location
DevicePowerTest.exe | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestApps
DeviceTestConfig.xml | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestApps
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


USB Address Description Test

Type: Automated Test

Overview

The USB Address Description Test runs a number of individual tests that verify various attributes and operations used by the function-specific portions of the test device. The tests also verify communications from the device through the bus interface to the host. The USB Address Description Test is based on the USBCV compliance test tool provided by the USB Implementers Forum, Inc. (USB-IF).

A USB device must respond correctly to all possible USB device addresses from 0 through 127. This test verifies that devices can respond correctly at their assigned addresses and that they do not respond at any other address.

Details

The test includes the following parts:

Setup

This test fails if the test device is more than one hub deep. Please note that test should be run with a device connected directly to a root hub of the system or with a USB-IF certified hub with less than seven ports.

Initialization

  • Select device to test

  • Open handle to host controller

  • Gather initial information:
    • Device descriptor
    • Configuration descriptor
    • String descriptors (if supported by device and test)

Address test #1 (repeat for all addresses)

  • Reset device port

  • Get descriptors (device, configuration, string) from address 0

  • Set device address (next address value not in use)

  • Get descriptors using address 0 (device should not respond)

  • Get descriptors using new address (device should respond)

  • Compare descriptors to initial information

Address test #2 (repeat for all addresses)

  • Reset device port (first time only)

  • Set address (next address value not in use)

  • Get descriptors from previous address (device should not respond)

  • Get descriptors from new address (device should respond)

  • Compare descriptors to initial information

Result

For success, a device must always respond with valid device, configuration, and string descriptors while not responding at its previous device address. Any failure is a test failure.

Results Interpretation

The test fails if:

  • Any standard device request is not properly handled by the device being tested.

  • Any standard device request does not meet the response time requirements as defined in the USB specification.

  • A device fails to respond to a request at its currently assigned address.

  • A device responds at an address other than its currently assigned address

Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller.
Processor
  • x86
  • x64
  • Itanium
Optional
  • One USB IF certified USB 2.0 hub to connect the system and the test USB device


USB Address Description Test with enhanced logging for debugging

Type: Manual Test

Overview

A USB device must respond correctly to all possible USB device addresses from 0 through 127. This test verifies that devices can respond correctly at their assigned addresses and that they do not respond at any other address.

This version of the USB Address Description Test incorporates ETW events generated in the USB PORT driver into the log for debugging purposes. This test is not required to get a logo. See "Log Interpretation" below for details on interpreting the additional log information.

Details

The test includes the following parts:

Setup

This test fails if the test device is more than one hub deep. The test should be run with a USB-IF certified hub with less than seven ports.

Note For embedded USB devices (for example, laptop devices) where it is impossible to meet the external hub connectivity requirement, follow these steps:

  1. Select the job USB Address Description Test with enhanced logging for debugging from the Available jobs pane in the Device Console.

  2. Click the Add Selected button on the Device Console. The selected job shows up in the bottom pane.

  3. Select this job from the bottom pane. Right-click it and select Edit Parameters.

  4. You will see the Parameter Edit window open, with parameters listed on the left and their values on the right.

  5. Change the value of IsEmbeddedUSBDevice parameter from FALSE to TRUE.

  6. To run this job, click the Schedule Jobs button on the Device Console.

Initialization

  1. Select device to test.

  2. Open handle to host controller.

  3. Gather initial information:
    • Device descriptor
    • Configuration descriptor
    • String descriptors (if supported by device and test)

Address test #1 (repeat for all addresses)

  1. Reset device port .

  2. Get descriptors (device, configuration, string) from address 0.

  3. Set device address (next address value not in use).

  4. Get descriptors using address 0 (device should not respond).

  5. Get descriptors using new address (device should respond).

  6. Compare descriptors to initial information.

Address test #2 (repeat for all addresses)

  1. Reset device port (first time only).

  2. Set address (next address value not in use).

  3. Get descriptors from previous address (device should not respond).

  4. Get descriptors from new address (device should respond).

  5. Compare descriptors to initial information.

Results

For success, a device must always respond with valid device, configuration, and string descriptors while not responding at its previous device address. Any failure is a test failure.

Results Interpretation

The test fails if any of the following occurs:

  • Any standard device request is not properly handled by the device being tested.

  • Any standard device request does not meet the response time requirements as defined in the USB specification.

  • A device fails to respond to a request at its currently assigned address.

  • A device responds at an address other than its currently assigned address.

Log Interpretation

Events logged:

  1. RAW_RESET_PORT_DISPATCH
    a. Occurs when a port reset is initiated
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
  2. RAW_RESET_PORT_STATUS1
    a. Indicates the status after SetFeaturePortPower
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
    • Port Status
  3. RAW_RESET_PORT_STATUS2
    a. Indicates the status after SetFeaturePortReset
    b. Includes the same data as STATUS1
  4. RAW_RESET_PORT_STATUS3
    a. Indicates the status after ClearFeaturePortResetChange
    b. Includes the same data as STATUS1
  5. RAW_RESET_PORT_COMPLETE
    a. Indicates the port reset has completed
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
    • USB Status
  6. SEND_ONE_PACKET_DISPATCH
    a. Occurs when a packet is sent to the device
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Packet Information:
      • Device Address
      • Endpoint Address
      • Maximum Packet Size
      • Timeout
      • USB Packet Flags
      • Data Length
      • Hub Device Address
      • Port TT Number
      • Usbd Status
  7. SEND_ONE_PACKET_DISPATCH_DATA
    a. Occurs after a packet dispatch to log the raw data in the transaction
    b. In addition to all the information in PACKET_DISPATCH, includes raw packet data in hexadecimal format
  8. SEND_ONE_PACKET_TIMEOUT
    a. Indicates that the request to the device timed out
    b. Includes the same data as PACKET_DISPATCH
  9. SEND_ONE_PACKET_COMPLETE
    a. Indicates the request completed
    b. Includes the same data as PACKET_DISPATCH and USB Status
  10. SEND_ONE_PACKET_COMPLETE_DATA
    a. Occurs after the packet completion to log any raw data in the transaction
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Packet info (see above)
    • Raw packet data in hexadecimal format

Timestamp Interpretation:

IMPORTANT The standard timestamp tag on the log entry does not accurately represent the time the ETW event occurred. Refer to the event timestamp logged with the data to get accurate timing information. There is a delay between when the ETW events occur and when they are published to the log. This creates a chronological disparity between the standard log entries and the ETW entries. When correlating events in the log, be sure to use the event timestamp when reconstructing the data.

Port Status Interpretation:

Refer to the following sections of "Universal Serial Bus Specification Revision 2.0" to interpret the port status:

  • 11.24.2.7 - Get Port Status

  • 11.24.2.7.1 - Port Status Bits

  • Table 11-21 - Port Status Field, wPortStatus

Run Time: 10 minutes
Log File: usbhct_a.log
System Restart Required: No
Supported operating systems for testing:

  • Windows 7

Program: usbhct.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

Command Syntax

Command option | Description
usbhct.exe | Without any options, displays usage text
-a | Specifies to run the address test
-d [VID/PID] | Specifies the device VID XXXX, and PID YYYY
-l [string] | Log file name. ex: "addrtest.log"
-w | Enable ETW tracing in the logs

Code Tour

File Manifest

File | Location
usbhct.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\
hctrans.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\
usbtree.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\
ETWCap.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\ETWCap\
USBRefresh.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\


USB Descriptor Test

Type: Automated Test

Overview

The USB Descriptor Test runs a number of individual tests that verify various attributes and operations used by the function-specific portions of the test device. The tests also verify communications from the device through the bus interface to the host. The test is based on the USBCV compliance test tool provided by the USB Implementers Forum, Inc. (USB-IF).

The USB Descriptor test is required only for Universal Serial Bus (USB) peripheral devices and hubs. It verifies the proper response of a USB device to standard descriptor requests.

The USB Descriptor test requests both the device descriptor and configuration descriptor with varying lengths. The test calculates the upper limit to be at least two maximum packet sizes larger than the actual size of the descriptor. If this calculated upper limit is less than 255 bytes, the test increases the upper limit to 255 bytes. The USB test device is expected to return valid descriptor information; however, the amount of information returned must be no larger than the length requested by the test. If the length requested is greater than the size of the descriptor, the device must return the whole descriptor with no additional data.

Details

The test includes the following parts:

Setup

The test fails if the test device is more than one hub deep.

Note: For embedded USB devices (for example, laptop devices) where it is impossible to meet the external hub connectivity requirement, you must follow the following steps:

  1. Select the job USB Descriptor Test from Available jobs pane in the Device Console.

  2. Click the Add Selected button on the Device Console. The selected job shows up in the bottom pane.

  3. Select this job from the bottom pane. Right-click it and select Edit Parameters

  4. You will see the Parameter Edit window open, with parameters listed on the left and their values on the right.

  5. Change this value of IsEmbeddedUSBDevice parameter from FALSE to TRUE.

  6. Click the Schedule Jobs button on the Device Console to run this job.

Initialization

  • Select device to test

  • Open handle to host controller

  • Gather the following initial information:
    • Device descriptor
    • Configuration descriptor
    • String descriptors (if supported by device and test)
    • Device qualifier descriptor (if this is a USB 2.0 high-speed capable device)

Descriptor test

  • Reset the device port

  • Repeat get descriptor requests for the device starting with a descriptor length of one up to the calculated upper bound in 1 byte increments

  • Repeat get descriptor requests for the configuration starting with a descriptor length of one up to calculated upper bound in 1 byte increments

  • Set the address to 2

  • Repeat get descriptor requests for the device starting with a descriptor length of one up to the calculated upper bound in 1 byte increments

  • Repeat get descriptor requests for the configuration starting with a length of one up to the calculated upper bound in 1 byte increments

Result

The test is successful if comparisons of the device and configuration descriptor pass for all iterations.

Results Interpretation

The test fails if:

  • Any standard descriptor request is not properly handled by the test device.

  • Any standard descriptor request does not meet the response time requirements as defined in the USB specification.

Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller.
  • One USB IF certified USB 2.0 hub to connect the system and the test USB device
Processor
  • x86
  • x64
  • Itanium


USB Descriptor Test with enhanced logging for debugging

Type: Manual Test

Overview

The USB Descriptor test is required only for Universal Serial Bus (USB) peripheral devices and hubs. It verifies the proper response of a USB device to standard descriptor requests.

The USB Descriptor test requests both the device descriptor and configuration descriptor with varying lengths. The test calculates the upper limit to be at least two maximum packet sizes larger than the actual size of the descriptor. If this calculated upper limit is less than 255 bytes, the test increases the upper limit to 255 bytes. The USB test device is expected to return valid descriptor information; however, the amount of information returned must be no larger than the length requested by the test. If the length requested is greater than the size of the descriptor, the device must return the whole descriptor with no additional data.

This version of the USB Descriptor Test incorporates ETW events generated in the USB PORT driver into the log for debugging purposes. This test is not required to get a logo. See "Log Interpretation" below for details on interpreting the additional log information.

Details

The test includes the following parts:

Setup

This test fails if the test device is more than one hub deep.

Initialization

  1. Select device to test.

  2. Open handle to host controller.

  3. Gather initial information:
    • Device descriptor
    • Configuration descriptor
    • String descriptors (if supported by device and test)
    • Device qualifier descriptor (if this is a USB 2.0 high-speed capable device)

Descriptor test

  1. Reset device port.

  2. Repeat get descriptor requests for the device starting with a descriptor length of one up to the calculated upper bound in 1 byte increments.

  3. Repeat get descriptor requests for the configuration starting with a descriptor length of one up to calculated upper bound in 1 byte increments.

  4. Set the address to 2.

  5. Repeat get descriptor requests for the device starting with a descriptor length of one up to the calculated upper bound in 1 byte increments.

  6. Repeat get descriptor requests for the configuration starting with a length of one up to the calculated upper bound in 1 byte increments.

Results

The test is successful if comparisons of the device and configuration descriptor pass for all iterations.

Results Interpretation

The test fails if any of the following occurs:

  • Any standard descriptor request is not properly handled by the test device.

  • Any standard descriptor request does not meet the response time requirements as defined in the USB specification.

Log Interpretation

Events logged:

  1. RAW_RESET_PORT_DISPATCH
    a. Occurs when a port reset is initiated
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
  2. RAW_RESET_PORT_STATUS1
    a. Indicates the status after SetFeaturePortPower
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
    • Port Status
  3. RAW_RESET_PORT_STATUS2
    a. Indicates the status after SetFeaturePortReset
    b. Includes the same data as STATUS1
  4. RAW_RESET_PORT_STATUS3
    a. Indicates the status after ClearFeaturePortResetChange
    b. Includes the same data as STATUS1
  5. RAW_RESET_PORT_COMPLETE
    a. Indicates the port reset has completed
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
    • USB Status
  6. SEND_ONE_PACKET_DISPATCH
    a. Occurs when a packet is sent to the device
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Packet Information:
      • Device Address
      • Endpoint Address
      • Maximum Packet Size
      • Timeout
      • USB Packet Flags
      • Data Length
      • Hub Device Address
      • Port TT Number
      • Usbd Status
  7. SEND_ONE_PACKET_DISPATCH_DATA
    a. Occurs after a packet dispatch to log the raw data in the transaction
    b. In addition to all the information in PACKET_DISPATCH, includes raw packet data in hexadecimal format
  8. SEND_ONE_PACKET_TIMEOUT
    a. Indicates that the request to the device timed out
    b. Includes the same data as PACKET_DISPATCH
  9. SEND_ONE_PACKET_COMPLETE
    a. Indicates the request completed
    b. Includes the same data as PACKET_DISPATCH and USB Status
  10. SEND_ONE_PACKET_COMPLETE_DATA
    a. Occurs after the packet completion to log any raw data in the transaction
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Packet info (see above)
    • Raw packet data in hexadecimal format

Timestamp Interpretation:

IMPORTANT The standard timestamp tag on the log entry does not accurately represent the time the ETW event occurred. Refer to the event timestamp logged with the data to get accurate timing information. There is a delay between when the ETW events occur and when they are published to the log. This creates a chronological disparity between the standard log entries and the ETW entries. When correlating events in the log, be sure to use the event timestamp when reconstructing the data.

Port Status Interpretation:

Refer to the following sections of "Universal Serial Bus Specification Revision 2.0" to interpret the port status:

  • 11.24.2.7 - Get Port Status

  • 11.24.2.7.1 - Port Status Bits

  • Table 11-21 - Port Status Field, wPortStatus

Run Time: 10 minutes
Log File: usbhct_g.log
System Restart Required: No
Supported operating systems for testing:

  • Windows 7

Program: usbhct.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

Command Syntax

Command option | Description
usbhct.exe | Without any options, displays usage text
-g | Specifies to run the descriptor test
-d [VID/PID] | Specifies the device VID XXXX, and PID YYYY
-l [string] | Log file name. ex: "descriptortest.log"
-w | Enable ETW tracing in the logs

Code Tour

File Manifest

File | Location
usbhct.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\
hctrans.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\
usbtree.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\
ETWCap.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\ETWCap\
USBRefresh.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\


USB Device Control Requests Test

Type: Automated Test

Overview

The USB Device Control Requests Test runs a number of individual tests that verify various attributes and operations used by the function-specific portions of the test device. The tests also verify communications from the device through the bus interface to the host. The test is based on the USBCV compliance test tool provided by the USB Implementers Forum, Inc. (USB-IF).

In the USB environment, all USB devices must respond correctly to all USB control requests after they have been reset. The control requests that must be supported are detailed in Chapter 9 of the USB Specification. This test validates that devices respond to those requests in the appropriate fashion at different addresses and at different times following a port reset. This test covers only USB peripheral devices and hubs.

Details

The system used for this test must have an available root hub port. If the test is to be run on a system in which the keyboard and mouse are attached using USB, and the system supports more than one root hub, these devices should be connected on one of the other root hubs. If the system has only one root hub, all other devices must be attached downstream of a secondary root hub port.

While the test runs, any devices connected to other ports on the same root hub might become unusable for a period of time.

Setup

This test fails if the test device is more than one hub deep.

Note For embedded USB devices (for example, laptop devices) where it is impossible to meet the external hub connectivity requirement, you must follow the following steps:

  1. Select the job USB Device Control Requests Test from Available jobs pane in the Device Console.

  2. Click the Add Selected button on the Device Console. The selected job shows up in the bottom pane.

  3. Select this job from the bottom pane. Right-click it and select Edit Parameters

  4. You will see the Parameter Edit window open, with parameters listed on the left and their values on the right.

  5. Change this value of IsEmbeddedUSBDevice parameter from FALSE to TRUE.

  6. Click the Schedule Jobs button on the Device Console to run this job.

Initialization

  • Select device to test

  • Open handle to host controller

    • Gather initial information

    • Device descriptor

    • Configuration descriptor

    • String descriptors (if supported by device and test)

Enumeration test (repeat n times) with no string descriptor support

  • Reset device port

  • Get device descriptor (first MPS with wLength value of FF)

  • Reset device port

  • Get device descriptor (full descriptor)

  • Set address (address not in use)

  • Get configuration descriptor

  • Compare device and configuration descriptors to initial ones

  • Set configuration to configuration zero

Enumeration test (repeat n times) with string descriptor support

  • Reset device port

  • Get device descriptor (first MPS with wLength value of FF)

  • Reset device port

  • Get device descriptor (full descriptor)

  • Set address (address not in use)

  • Get configuration descriptor

  • Compare device and configuration descriptors to initial ones

  • Set configuration to configuration zero

Result

The test is successful if comparisons of the device and configuration descriptor pass for all iterations.

Results Interpretation

The test fails if:

  • Any standard device request is not properly handled by the device under test.

  • Any standard device request does not meet the response time requirements as defined in the USB specification.

Run Time: 7 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller.
  • One USB IF certified USB 2.0 hub to connect the system and the test USB device
Processor
  • x86
  • x64
  • Itanium


USB Device Control Requests Test with enhanced logging for debugging

Type: Manual Test

Overview

In the USB environment, all USB devices must respond correctly to all USB control requests after they have been reset. The control requests that must be supported are detailed in Chapter 9 of the USB Specification. This test validates that devices respond to those requests in the appropriate fashion at different addresses and at different times following a port reset. This test covers only USB peripheral devices and hubs.

This version of the USB Device Control Requests Test incorporates ETW events generated in the USB PORT driver into the log for debugging purposes. This test is not required to get a logo. See "Log Interpretation" below for details on interpreting the additional log information.

Details

The system used for this test must have an available root hub port. If the test is to be run on a system in which the keyboard and mouse are attached using USB, and the system supports more than one root hub, these devices should be connected on one of the other root hubs. If the system has only one root hub, all other devices must be attached downstream of a secondary root hub port.

While the test runs, any devices connected to other ports on the same root hub may become unusable for a period of time.

This test fails if the test device is more than one hub deep.

Device Control Requests Test:

500 iterations, randomly choosing a different control request to complete during each iteration. There are 5 possible requests:

  • Reset Device Report

  • Get the Device Descriptor

  • Get the Configuration Descriptor

  • Get the Serial Number

  • Get the Device String Descriptor

Result

For success, a device must respond appropriately to any control request given in any sequence.

Results Interpretation

The test fails if any of the following occurs:

  • Any standard device control request is not properly handled by the device being tested.

  • Any standard device request does not meet the response time requirements as defined in the USB specification

  • A device fails to respond appropriately to any issued control request

  • A device returns data that does not match the initial data

  • A port status differs from the initial value after a port reset

Log Interpretation

Events logged:

  1. RAW_RESET_PORT_DISPATCH
    a. Occurs when a port reset is initiated
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
  2. RAW_RESET_PORT_STATUS1
    a. Indicates the status after SetFeaturePortPower
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
    • Port Status
  3. RAW_RESET_PORT_STATUS2
    a. Indicates the status after SetFeaturePortReset
    b. Includes the same data as STATUS1
  4. RAW_RESET_PORT_STATUS3
    a. Indicates the status after ClearFeaturePortResetChange
    b. Includes the same data as STATUS1
  5. RAW_RESET_PORT_COMPLETE
    a. Indicates the port reset has completed
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
    • USB Status
  6. SEND_ONE_PACKET_DISPATCH
    a. Occurs when a packet is sent to the device
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Packet Information:
      • Device Address
      • Endpoint Address
      • Maximum Packet Size
      • Timeout
      • USB Packet Flags
      • Data Length
      • Hub Device Address
      • Port TT Number
      • Usbd Status
  7. SEND_ONE_PACKET_DISPATCH_DATA
    a. Occurs after a packet dispatch to log the raw data in the transaction
    b. In addition to all the information in PACKET_DISPATCH, includes raw packet data in hexadecimal format
  8. SEND_ONE_PACKET_TIMEOUT
    a. Indicates that the request to the device timed out
    b. Includes the same data as PACKET_DISPATCH
  9. SEND_ONE_PACKET_COMPLETE
    a. Indicates the request completed
    b. Includes the same data as PACKET_DISPATCH and USB Status
  10. SEND_ONE_PACKET_COMPLETE_DATA
    a. Occurs after the packet completion to log any raw data in the transaction
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Packet info (see above)
    • Raw packet data in hexadecimal format

Timestamp Interpretation:

IMPORTANT The standard timestamp tag on the log entry does not accurately represent the time the ETW event occurred. Refer to the event timestamp logged with the data to get accurate timing information. There is a delay between when the ETW events occur and when they are published to the log. This creates a chronological disparity between the standard log entries and the ETW entries. When correlating events in the log, be sure to use the event timestamp when reconstructing the data.

Port Status Interpretation:

Refer to the following sections of "Universal Serial Bus Specification Revision 2.0" to interpret the port status:

  • 11.24.2.7 - Get Port Status

  • 11.24.2.7.1 - Port Status Bits

  • Table 11-21 - Port Status Field, wPortStatus

Run Time: 10 minutes
Log File: usbhct_c.log
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: usbhct.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

Command Syntax

Command option | Description
usbhct.exe | Without any options, displays usage text
-c | Specifies to run the device control requests test
-d [VID/PID] | Specifies the device VID XXXX, and PID YYYY
-l [string] | Log file name. ex: "ctrltest.log"
-w | Enable ETW tracing in the logs

Code Tour

File Manifest

File | Location
usbhct.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\
hctrans.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\
usbtree.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\
ETWCap.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\ETWCap\
USBRefresh.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\


USB Device Framework (CV) Test

Type: Automated Test

Overview

The device framework test runs a number of individual tests that verify various attributes and operations used by the function-specific portions of the test device. The tests also verify communications from the device through the bus interface to the host. The device framework test is based on the USBCV compliance test tool provided by the USB Implementers Forum, Inc. (USB-IF).

Details

This test verifies that the test device supports the commands set forth in Chapter 9, "USB Device Framework" of the Universal Serial Bus (USB) Specification Revision 2.0. It verifies that the test device responds correctly to device, configuration, and interface descriptor requests.

Setup

This test requires the test device to be connected through an intermediate USB 2.0 hub to the host system. If the test machine has two USB controllers, disable the controller that is not under test (or else the test fails).

Note For embedded USB devices (for example, laptop devices) where it is impossible to meet the external hub connectivity requirement, you must follow the following steps:

  1. Select the job USB Device Framework (CV) (Manual) from Available jobs pane in the Device Console.

  2. Click the Add Selected button on the Device Console. The selected job shows up in the bottom pane.

  3. Select this job from the bottom pane. Right-click it and select Edit Parameters

  4. You will see the Parameter Edit window open, with parameters listed on the left and their values on the right.

  5. Change this value of IsEmbeddedUSBDevice parameter from FALSE to TRUE.

  6. Click the Schedule Jobs button on the Device Console to run this job.

Device States

For these tests, three different device states are used: the default state, the address state, and the configured state. Many of the tests run with the test device in more than one state. This section describes the three states and the procedures used to put the device into each of the states. The device state information might help with debugging in cases in which the test device does not reach the required starting state for the test. The individual test descriptions mention which device states they are run on, but they do not repeat the setup procedure. A description of each device states follows:

Default State: In the default state, the test device is attached to the USB and is receiving power.

The device has been reset, but it has not been assigned a unique address. The device responds at the default address.

To put the device in the configured state, the test does the following:

  1. Issues a valid set configuration request to the device with configuration value of zero.

  2. Issues a valid get configuration request and verifies that the device responds with zero.

  3. Issues a valid set address request to the device with address zero.

Address State: In the address state, the device is attached to the USB and is receiving power. The device has been reset and has a unique device address. The device is not configured.

To put the device in the configured state, the test does the following:

  1. Issues a valid set configuration request to the device with configuration value of zero.

  2. Issues a valid get configuration request to the device and verifies that the device responds with zero.

Configured State: In the configured state, the device is attached to the USB and is receiving power.

The device has been reset and has a unique device address. The device is configured. The host can now use the function provided by the device.

Device enumeration routine

The test enumerates the devices on the bus using the following procedure.

  1. Get the device descriptor using a maximum packet size of 64 bytes. This causes a short packet for devices with a bMaxPacketSize0 field < 64.

  2. Issue a set address request with the next available USB address.

  3. Get the device descriptor again with the right maximum packet size.

  4. Get the configuration descriptor, asking for a number of bytes equal to the configuration descriptor size only.

  5. Issue a set configuration request for the first configuration supported by the device.

  6. Get the configuration descriptor again, asking for a number of bytes equal to the configuration descriptor size.

  7. Get the configuration descriptor using the total length of the entire descriptor.

If the descriptors indicate that the device is a hub, the test continues with the steps below:

  1. Get the hub class descriptor.

  2. Issue a SetPortFeature request with the hub class feature selector PORT_POWER for each port on the hub.

  3. Sleep for 1 second.

  4. Issue get port status requests for each port.

  5. If the connect bit is set in the port status, issue a port reset, and proceed to step 13. Otherwise, stop at this step.

  6. Sleep for 50 milliseconds.

  7. Check the port status to ensure that the enable bit has been set and then proceed to the enumerate device routine.

Test Cases

The USB Device Framework (CV) test runs the following test cases:

  • TD-9.25.1.1 Device Descriptor Test

  • TD-9.25.1.2 Device Qualifier Test

  • TD-9.25.1.3 Configuration Descriptor Test

  • TD-9.25.1.4 Interface Descriptor Test

  • TD-9.25.1.5 Endpoint Descriptor Test

  • TD-9.25.1.6 Halt Endpoint Test

  • TD-9.25.1.10 Remote Wakeup Test

  • TD-9.25.1.11 Set Configuration Test

TD-9.25.1.1 Device Descriptor Test

This test verifies that the test device responds to valid get descriptor requests and returns a descriptor in compliance with the specification.

Device States for Test

This test runs with the device in the default, address, and configured states.

Overview

The test performs the following steps:

  1. Places the device in the starting state (default, address, or configured).

  2. Issues a valid GET_DESCRIPTOR request for the device with a requested length of 18 bytes.

  3. Performs the following checks on the returned device descriptor value:

    bLength == 18

    bDescriptorType == DEVICE descriptor type

    bcdUSB.hibyte == (01 or 02)

    if (Device Speed == High) then bcdUSB.hibyte == 02

    if(bcdUSB.hibyte == 01) then bcdUSB.lowbyte == (01 or 10 or 00)

    if (bDeviceClass == 0) then bDeviceSubClass == 0

    if (Device Speed == Low) then bMaxPacketSize0 == 8

    If (Device Speed == Full) then bMaxPacketSize0 == (8 or 16 or 32 or 64)

    If (Device Speed == High) then bMaxPacketSize0 == 64

    Check that idVendor is in the list of valid entries maintained by the USB-IF

    bNumConfigurations != 0

    Check that the bDeviceClass == 0 or ==FFH or is on a list of assigned class codes maintained by the USB-IF

  4. Repeats steps 1, 2, and 3 with device in the other states (default, address, or configured).

Note

  • If the device supports multiple configurations, the test is repeated for each possible configuration.

  • If the device is a high-speed capable device, the test is run with the device in both high-speed and full-speed operation.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor, set address, set configuration, or get configuration requests fail for any reason.

  • Any of the device descriptor content checks fail.

TD-9.25.1.2 Device Qualifier Test

This test verifies that the test device responds to valid get descriptor request for a device qualifier and returns a descriptor in compliance with the USB specification.

Device States for Test

This test runs with the device in the default, address, and configured states.

Overview

The test performs the following steps.

  • Places the device in the starting state (default, address, or configured).

  • Issues a valid get descriptor request for a device qualifier with a requested length of 9 bytes.

  • Confirms the following on the device qualifier descriptor value:

    bcdUSB.hibyte == 02

    bLength == 10

    bDescriptorType == DEVICE_QUALIFER descriptor type

    If (bDeviceClass == 0) then bDeviceSubClass == 0

    If (Device Speed == High) then bMaxPacketSize0 == (8 or 16 or 32 or 64)

    If (Device Speed == Full) then bMaxPacketSize0 == 64

    BNumConfiguration != 0

    bReserved != 0

  • Repeats steps 1, 2, and 3 with device in the other two states (default, address, or configured).

Note

  • If the device supports multiple configurations, the test is repeated for the configured state for each possible configuration.

  • If the device is a high-speed capable device, the complete test must be run with the device in both full-speed and high-speed operation.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor, set address, set configuration, or get configuration requests fail for any reason.

  • Any of the device descriptor content checks fail.

TD-9.25.1.3 Configuration Descriptor Test

This test verifies that the test device responds to valid get configuration descriptor request and returns a descriptor in compliance with the USB specification.

Device States for Test

This test runs with the device in the default, address, and configured states.

Overview

The test performs the following steps.

  1. Places the device in the starting state (default, address, or configured).

  2. Issues a valid get descriptor request for a configuration descriptor with a length of 9 bytes.

  3. Confirms the configuration descriptor value:

    BLength == 9

    bDescriptorType == CONFIGURATION descriptor type (or OTHER_SPEED_CONFIGURATION type)

  4. Issues a valid get configuration descriptor request with a requested length of wTotalLength from the configuration descriptor.

  5. Parses the data returned and performs the following checks:

    Confirms that the first descriptor is a configuration descriptor as confirmed in step 3.

    Confirms that all other descriptors are endpoint, interface, or class descriptors.

    Counts the number of endpoint descriptors

    Counts the number of interface descriptors (alternate setting == 0)

    Sums the bNumEndPoint values from all interface descriptors.

  6. Confirms that the number of interface descriptors found equals the bNumInterfaces value in the configuration descriptor.

  7. Confirms that the total number of endpoint descriptors found match the sum of the bNumEndPoint values from each of the interface descriptors.

  8. Issues a valid get configuration descriptor request with a requested length of 9 bytes.

  9. Completes each of the following checks on the configuration descriptor value:

    bLength == 9

    bDescriptorType == Configuration descriptor type

    bNumInterface != 0

    bmAttributes bits D0 to D4 == 0

    bmAttributes bit D7 == 1

    if (bMaxPower == 0) bmAttributes D6 == 1

  10. If this is not an other_speed configuration test, the test issues a get status request for the device.

    If the status request indicates that the device is operating bus-powered, bMaxPower must be less than 500 mA

    If the status request indicates the device is operating self-powered, bMaxPower must be less than 100 mA

  11. If the test supports multiple configurations, the test repeats for each configuration descriptor.

Note If the device is a high-speed capable device, the test is run with the device in both high-speed and full-speed operation and is also run for the other_speed_configuration descriptor.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • Any of the device descriptor content checks fail.

TD-9.25.1.4 Interface Descriptor Test

This test verifies that the test device reports interface descriptors in compliance with the specification.

Device States for Test

This test runs with the device in the default, address, and configured states.

Overview

The test performs the following steps:

  1. Places the device in the starting state (default, address, or configured).

  2. Sends a valid get configuration descriptor request with a requested bLength of 9 bytes.

  3. Completes the following checks on the configuration descriptor value:

    bLength == 9

    bDescriptorType == CONFIGURATION descriptor type (or OTHER_SPEED_CONFIGURATION type)

  4. Issues a valid get configuration descriptor request with a requested length of wTotalLength from the configuration descriptor.

  5. If this is not an other_speed_configuration test, the test sends a set configuration request to set the configuration of the device to the one being tested. The test then issues a get configuration request to make sure the correct configuration is indicated.

  6. Completes the following bandwidth check for all interface and endpoint descriptors returned by the device:

    If a default interface (alternate setting zero) contains an isochronous endpoint with a maximum packet size greater than zero, the test fails.

    If a default interface (alternate setting zero) contains an interrupt endpoint with a maximum packet size greater than 64, the test fails.

  7. Confirms that there is at least one interface descriptor in the data returned.

  8. Confirms that the first interface descriptor returned has bInterfaceNumber and bAlternateSetting values of zero.

  9. Completes the following checks for each interface descriptor returned:

    If this is not the first interface descriptor (see step 8)

    If (current interface number == previous interface number)

    Then current alternate setting must be one greater

    Else

    Current interface number must be 1 greater than previous

    Current alternate setting must be zero

    Current interface number must be < total number interfaces

    bLength > 8

    bDescriptorType == INTERFACE descriptor type

    if (bInterfaceClass == 0) then check that bInterfaceSubClass == 0

    bNumEndpoints matches the number of endpoint descriptors

  10. If this is not an other_speed interface, the test completes the following additional checks:

    Call set interface for the current bInterfaceNumber and bAlternateSetting values.

    If the current interface has no alternate settings, the device may STALL the request. Otherwise the request must succeed.

    Call get interface for the current bInterfaceNumber and verify that the correct alternate setting value is returned.

  11. If the test supports multiple configurations, repeat the test for each configuration descriptor.

Note If the device is a high-speed capable device, the test is run with the device in both high-speed and full-speed operation and is also run for the other_speed_configuration descriptor.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • Valid set interface requests fail for any reason.

  • Valid get interface requests fail for any reason.

  • Any of the interface descriptor content checks fail.

TD-9.25.1.5 Endpoint Descriptor Test

This test verifies that the device under test reports endpoint descriptors in compliance with the specification.

Device States for Test

This test is run with the device in the default, address, and configured states.

Overview

The test performs the following steps:

  1. Places the device in the starting state (default, address, or configured).

  2. Issues a valid get descriptor request for the device configuration with a requested length of 9 bytes.

  3. Completes the following checks on the configuration descriptor value:

    bLength == 9

    bDescriptorType == CONFIGURATION descriptor type (or OTHER_SPEED_CONFIGURATION type)

  4. Issues a valid get configuration descriptor request with a requested length of wTotalLength from the configuration descriptor.

  5. If this is not an other speed configuration test, the test issues a set configuration request to set the configuration of the device to the one being tested. The test then issues a get configuration request to make sure the correct configuration is indicated.

  6. Issues a valid get device descriptor command to store the bcdUSB value.

  7. Completes the following checks for each endpoint descriptor found in the data returned from the get configuration descriptor request:

    bLength > 6

    bDescriptorType == ENDPOINT descriptor type

    bEndPointAddress != (0x00 or 0x80)

    bmAttributes D6-D7 must be zero.

    BmAttributes D2-D5 must be zero unless the endpoint is isochronous and

    bcdUSB is 0200 or greater.

    Note There is an exception made if bcdUSB is 0x0101 or 0x0110 and the endpoint is part of an audio interface.

    wMaxPacketSize bit D13 to D15 must be zero.

  8. The endpoint being tested is categorized according to the following logic:
    Current Device Speed Other Speed Descriptor Category

    LOW

    NA

    CV_LOW

    FULL

    YES

    CV_HIGH

    FULL

    NO

    CV_FULL_2X (bcdUSB)

    CV_FULL_1X

    HIGH

    NO

    CV_HIGH

    HIGH

    YES

    CV_FULL_2X

  9. Completes the following endpoint type and speed dependent checks for each endpoint descriptor:

    If wMaxPacketSize bits D11 to D12 are non-zero, the endpoint must be typeCV_HIGH with transfer type INTERRUPT or ISOCHRONOUS.

  10. Completes the following checks for control endpoints:

    CV_LOW wMaxPacketSize == 8

    CV_FULL (1x or 2x)wMaxPacketSize == (8 or 16 or 32 or 64)

    CV_HIGHwMaxPacketSize == 64

  11. Completes the following checks for bulk endpoints:

    CV_LOW FAIL - ILLEGAL

    CV_FULL (1x or 2x)wMaxPacketSize == (8 or 16 or 32 or 64)

    CV_HIGHwMaxPacketSize == 512

  12. Completes the following checks for interrupt endpoints.

    CV_LOWbInterval > 9

    wMaxPacketSize < 9

    CV_FULL_1XbInterval != 0

    wMaxPacketSize < 65

    CV_FULL_2XbInterval != 0

    wMaxPacketSize < 65

    CV_HIGHbInterval > 0 and bInterval < 16

    MULT 0wMaxPacketSize < 1025

    MULT 1wMaxPacketSize > 512 and wMaxSize < 1025

    MULT 2wMaxPacketSize > 682 and wMaxSize < 1025

  13. Completes the following checks for isochronous endpoints:

    CV_LOWFAIL - ILLEGAL

    CV_FULL_1XbInterval == 1

    wMaxPacketSize < 1024

    CV_FULL_2XbInterval > 0 and bInterval < 17

    wMaxPacketSize < 1024

    CV_HIGHbInterval > 0 and bInterval < 17

    MULT 0wMaxPacketSize < 1025

    MULT 1wMaxPacketSize > 512 and wMaxSize < 1025

    MULT 2wMaxPacketSize > 682 and wMaxSize < 1025

  14. Repeats the test for each configuration descriptor if the test supports multiple configurations.

Note If the device is a high-speed capable device, the test must be run with the device in both high-speed and full-speed operation and is also run for the other_speed_configuration descriptor.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • Any of the device descriptor content checks fail.

TD-9.25.1.6 Halt Endpoint Test

This test is similar to the interface descriptor test except that it also confirms that all bulk and interrupt endpoints can be programmatically halted.

Device States for Test

This test is run with the device in the configured state.

Overview

The test performs the following steps:

  1. Places the device in the configured state.

  2. Issues a valid get configuration descriptor request with a requested bLength of 9 bytes.

  3. Completes the following checks on the configuration descriptor value:

    bLength == 9

    bDescriptorType == CONFIGURATION descriptor type (or

    OTHER_SPEED_CONFIGURATION type)

  4. Issues a valid get configuration descriptor command with a requested length of wTotalLength from the configuration descriptor.

  5. If this is not another speed configuration test, the test issues a set configuration command to set the configuration of the device to the device being tested. The test then issues a get configuration command to make sure the correct configuration is indicated.

  6. Completes the following bandwidth check for all interface and endpoint descriptors returned by the device:

    If a default interface (alternate setting zero) contains an isochronous endpoint with a maximum packet size greater than zero, the test fails.

    If a default interface (alternate setting zero) contains an interrupt endpoint with a maximum packet size greater than 64, the test fails.

  7. Confirms that there is at least one interface descriptor in the data returned.

  8. Confirms that the first interface descriptor returned has bInterfaceNumber and bAlternateSetting values of zero.

  9. For each interface descriptor returned, completes the following checks:

    If this is not the first interface descriptor (see step 8)

    If (current interface number == previous interface number)

    Then current alternate setting must be one greater

    Else

    Current interface number must be 1 greater than previous

    Current alternate setting must be zero

    Current interface number must be < total number interfaces

    bLength > 8

    bDescriptorType == INTERFACE descriptor type

    if (bInterfaceClass == 0) then check that bInterfaceSubClass == 0

  10. If this is not an other_speed interface, the test makes the following additional checks:

    Call set interface for the current bInterfaceNumber and bAlternateSetting values.

    If the current interface has no alternate settings, the device may STALL the request. Otherwise it must succeed.

    Call get interface for the current bInterfaceNumber and verify that the correct alternate setting value is returned.

  11. For each endpoint associated with interface descriptor in step 10, the test completes the following checks if the endpoint is bulk or interrupt:

    Issues a valid Get Status request for the endpoint.

    If the endpoint is halted, issues a valid clear feature request with feature selector NDPOINT_HALT. Then the test issues a valid Get Status request for the endpoint and verifies that the endpoint no longer reports halt.

    Issues a valid set feature request with feature selector ENDPOINT_HALT.

    Issues a valid Get Status request for the endpoint.

    Verifies that ENDPOINT_HALT is reported in the status.

    Issues a valid clear feature request with feature selector ENDPOINT_HALT.

    Issues a valid Get Status request for the endpoint.

    Verifies that ENDPOINT_HALT is not reported in the status.

  12. If the test supports multiple configurations, the test is repeated for each configuration descriptor.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • Valid set interface requests fail for any reason.

  • Valid get interface requests fail for any reason.

  • Valid get status requests fail for any reason.

  • Valid set feature (ENDPOINT_HALT) requests fail for any reason.

  • Valid clear feature (ENDPOINT_HALT) requests fail for any reason.

  • Any of the device descriptor content checks fail.

TD-9.25.1.10 Remote Wakeup Test

This test checks each device configuration that supports remote wakeup to ensure that the device properly supports the set and clear feature requests with feature selector DEVICE_REMOTE_WAKEUP.

Device States for Test

This test is run with the device in the configured state. For each remote wakeup-capable configuration, the test is run with remote wakeup enabled (must work) and disabled (must not work).

Overview

The test performs the following steps:

  1. Issues a valid get configuration descriptor request with a requested bLength of 9 bytes.

  2. Completes the following checks on the configuration descriptor value:

    bLength == 9

    bDescriptorType == CONFIGURATION descriptor type

    bmAttributes bit D5 == 1 (Remote Wakeup)

  3. Repeats steps 2 and 3 for each configuration.

  4. If bit D5 is never set, there is nothing to test.

  5. If bit D5 is set for some configurations, the test issues a valid get configuration for the configuration that was set in step 1. If bit D5 is set, proceed with the Remote Wakeup Test; otherwise, there is nothing to test for this configuration.

Remote Wakeup Test

The test performs the following steps:

  1. Issues a valid set configuration command to set the device into the remote wakeup-capable configuration being tested (enabled or disabled).

  2. Issues a valid get configuration command and verifies that the device reports the configuration that was set in step 1.

  3. Issues a valid set feature command with feature selector DEVICE_REMOTE_WAKEUP.

  4. Issues a valid get status command and verifies that remote wakeup is reported.

  5. If this is a remote wakeup disabled test, the test issues a valid clear feature command with feature selector DEVICE_REMOTE_WAKEUP. The test then issues a valid get status command and verifies that remote wakeup is not reported.

  6. Suspends the parent port of the device under test.

  7. Sleeps for 1 second.

  8. Confirms that the parent port status has suspended.

  9. Prompts you to generate a remote wakeup event on the test device.

  10. Polls the parent port for up to 15 seconds, sending valid get port status requests, and checks to see when (if) the PORT_SUSPEND bit is cleared.

Note If the test supports multiple configurations, the test is repeated for each configuration descriptor. If the device is high-speed capable, the test repeats with the device operating at high-speed and full-speed.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • Valid get status requests fail for any reason.

  • Valid set feature (DEVICE_REMOTE_WAKEUP) requests fail for any reason.

  • Valid clear feature (DEVICE_REMOTE_WAKEUP) requests fail for any reason.

  • Device status does not properly indicate whether remote wakeup is enabled.

  • The device produces a remote wakeup event when remote wakeup is disabled.

  • The device does not produce a remote wakeup event when remote wakeup is enabled.

  • The device prevents its parent port from entering the suspend state.

TD-9.25.1.11 Set Configuration Test

This test checks each device configuration that can be set using the set configuration request and makes sure that the device properly reports its current configuration in response to the get configuration request.

Device States for Test

This test is run with the device starting in the address state.

Overview

The test performs the following steps:

  1. Places the device in the address state.

  2. Issues a valid get configuration descriptor command with a requested length of 9 bytes for configuration index zero.

  3. Issues a valid set configuration request using the bConfigurationValue obtained in step 2.

  4. Issues a valid get configuration request and verifies that the configuration set in step 3 is reported.

  5. Issues a valid get configuration descriptor command with a requested length of 9 bytes for the configuration to be tested.

  6. Issues a valid set configuration request using the bConfigurationValue obtained in step 5.

  7. Issues a valid get configuration request and verifies that the configuration set in step 6 is reported.

  8. Issues a valid set configuration request using configuration value zero.

  9. Issues a valid get configuration command and verifies that the device reports the configuration that was set in step 7.

  10. Issues a valid set configuration request using the bConfigurationValue obtained in step 5.

  11. Issues a valid get configuration request and verifies that the configuration set in step 10 is reported.

Note If the test supports multiple configurations, the test is repeated for each configuration descriptor. If the device is high-speed capable, the test repeats operating at high speed and full speed.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap9.log).

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • Valid get status requests fail for any reason.

  • Valid set feature (DEVICE_REMOTE_WAKEUP) requests fail for any reason.

  • Valid clear feature (DEVICE_REMOTE_WAKEUP) requests fail for any reason.

  • Device status does not properly indicate whether remote wakeup is enabled.

  • The device produces a remote wakeup event when remote wakeup is disabled.

  • The device does not produce a remote wakeup event when remote wakeup is enabled.

  • The device prevents its parent port from entering the suspend state.

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller
  • One USB IF certified USB 2.0 hub to connect the system and the test USB device
Processor
  • x86
  • x64
  • Itanium

Troubleshooting

The following list describes the USB Device Framework (CV) Test Assertions:

  • General Chapter 9 Command Assertions

    • 1.1.1 Devices must have a corresponding configuration value for a valid configuration index.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.2

    • 1.1.2 Devices must support being set to Addressed/Configured state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.1.1

    • 1.1.3 Devices must support a valid GetDescriptor(Device) request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.3

    • 1.1.4 Devices must support a valid GetDescriptor(String) request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.3, 9.6.7

    • 1.1.5 Devices must support a valid GetDescriptor(Configuration) request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.3

    • 1.1.6 High Speed Capable devices must support a valid GetDescriptor(OtherSpeedConfiguration) request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.3

    • 1.1.7 Devices must support a valid SetConfiguration request

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.7

    • 1.1.8 Device must support a valid GetDescriptor(DeviceQualifier) request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.7

  • HID Command Assertions

    • 1.1.9 HID devices must support a GetDescriptor(HIDDescriptor) request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 6.2, 7.1.1

    • 1.1.10 HID devices must support a valid SetProtocol(Report) request.

      Reference document: Universal Serial Bus Specification, Revision 1.1, Section 7.2.6

    • 1.1.11 HID devices must support a valid GetProtocol request.

      Reference document: Universal Serial Bus Specification, Revision 1.1, Section 7.2.5

    • 1.1.12 HID devices must support a valid SetProtocol(Boot) request.

      Reference document: Universal Serial Bus Specification, Revision 1.1, Section 7.2.6

    • 1.1.13 HID devices must support a valid GetDescriptor(Report) request.

      Reference document: Universal Serial Bus Specification, Revision 1.1, Section 6.2, 7.1.1

    • 1.1.14 HID devices that do not support a SetIdle request must respond with a request error.

      Reference document: Universal Serial Bus Specification, Revision 1.1, Section 7.2, 7.2.3

    • 1.1.15 HID devices that do not support a GetIdle request must respond with a request error.

      Reference document: Universal Serial Bus Specification, Revision 1.1, Section 7.2, 7.2.3

  • General Device Assertions

    • 1.1.20 Devices must respond with a Request Error to GetDescriptor requests that specify an invalid descriptor type.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.2.7 and 9.4.3.

    • 1.1.21 Devices must respond with a Request Error to SetFeature requests that specify an invalid feature selector.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.2.7 and 9.4.9.

    • 1.1.22 Devices must respond with a Request Error to ClearFeature requests that specify an invalid feature selector.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.2.7 and 9.4.1.

    • 1.1.22 Devices must respond with a Request Error to ClearFeature requests that specify an invalid feature selector.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.2.7 and 9.4.1.

    • 1.1.30 A suspended device must resume normal operation when resume signaling is seen on its upstream port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.1.7.7.

    • 1.1.100 Devices must support a GetStatus Standard Request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 1.1.101 Device Descriptors must use only class codes defined in the USB specification, or allocated and published by the USBIF.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.

    • Device Descriptor Assertions

      1.2.1 The descriptor returned in response to a GetDescriptor(Device) request must have a length of 0x12 (or appropriate length if less bytes are requested).

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.

    • 1.2.2 The descriptor returned in response to a GetDescriptor(Device) request must the have value of 0x01 in the Type field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.

    • 1.2.3 The descriptor returned in response to a GetDescriptor(Device) request must have the value of 0x01/0x02 in the high byte of the bcdUSB field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.

    • 1.2.4 The descriptor returned in response to a GetDescriptor(Device) request must have the value of 0x00/0x01/0x10 in the low byte of the bcdUSB field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.

    • 1.2.5 The descriptor returned in response to a GetDescriptor(Device) request must have a value of 0x00 in the device subclass field when the device.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.

    • 1.2.6 The MaxPacketSize of a control endpoint must be 0x40 for a USB device operating at High speed.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.

    • 1.2.7 The MaxPacketSize of a control endpoint must be 0x08 for a usb device operating at Low speed.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.

    • 1.2.8 The MaxPacketSize of a control endpoint must be one of 0x08/0x10/0x20/0x40 for a USB device operating at full speed.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.

    • 1.2.9 A device must have at least one configuration.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.

    • 1.2.10 The descriptor returned in response to a GetDescriptor(Device) request must have the value 0x02 in the high byte of the bcdUSB field for a high-speed device.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.

    • 1.2.20 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request cannot contain multiple descriptors of type configuration.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.

    • 1.2.21 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request cannot contain a descriptor of type device.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.

    • 1.2.22 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request cannot contain a descriptor of type device qualifier.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.

    • 1.2.23 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request cannot contain a descriptor of type other speed configuration.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.

    • 1.2.24 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request must contain the number of interfaces descriptors reported in the configuration descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.

    • 1.2.25 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request must contain the number of endpoint descriptors reported in the contained interface descriptors.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.26 The configuration descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request must have a length of 0x09.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Sections 9.6.3, 9.6.4.

    • 1.2.27 The descriptor returned in response to a GetDescriptor(Configuration) request must the value of 0x02 in the Type field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.

    • 1.2.28 The descriptor returned in response to a GetDescriptor(OtherSpeedConfiguration) request must the value of 0x07 in the Type field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.4.

    • 1.2.29 The number of interfaces cannot be a zero in a [OtherSpeed]Configuration descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Sections 9.6.4, 9.6.5

    • 1.2.30 Bits 0 through 4 must be set to zero in the bmAttributes field.of a [OtherSpeed]Configuration descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Sections 9.6.4, 9.6.4

    • 1.2.31 Bit 7 must be set to one in the bmAttributes field of a [OtherSpeed]Configuration descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Sections 9.6.3, 9.6.4

    • 1.2.32 A BUS-POWERED device cannot draw zero power.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.

    • 1.2.33 A SELF-POWERED device cannot draw more than 100ma from the USB bus.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.2.1.5.

    • 1.2.34 A BUS-POWERED device cannot draw more than 500ma.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.2.1.4.

    • Interface Descriptor

      1.2.40 An Isochronous endpoint present in alternate interface 0x00 must have a MaxPacketSize of 0x00

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 5.6.3.

    • 1.2.41 The first interface must have an interface number of 0x0 and an alternate setting of 0x0.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.42 The interface number cannot be greater than the number of interfaces reported in the configuration descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.43 An Interface must have at least one setting with an Alternate Setting set to zero.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.44 A device must support the SetInterface request if it has alternate settings for that interface.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.10.

    • 1.2.45 Alternate settings for a given interface must be in sequential order.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.46 Interface numbers must be in sequential order.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.47 An interface descriptor must have a length of 0x09.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.48 An interface descriptor must have a value of 0x04 in the Type field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.49 An interface descriptor must have a value of 0x00 in the interface subclass field when the interface class is 0x00.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.50 A device must support the GetInterface request if it has alternate settings for that interface.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.4.

    • 1.2.51 A successful GetInterface request must return the alternate setting set by a prior call to SetInterface.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.4.

    • 1.2.52 A high-speed interrupt endpoint present in alternate interface 0x00 must have a MaxPacketSize <= 0x40.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.53 An interface descriptor must have exactly the number of endpoint descriptors it specifies in the bNumEndpoints field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

  • Endpoint Descriptor

    • 1.2.60 An endpoint descriptor must have a length of 0x07.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.61 An endpoint descriptor must have a value of 0x05 in the Type field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.62 Only the default control endpoint can have an address of 0x00.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.63 Bits 6 and 7 must be set to zero in the bmAttributes field.of an Endpoint descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 5.3.1.1.

    • 1.2.64 Bits 4 and 5 cannot BOTH be set in the bmAttributes field.of an Isochronous Endpoint descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.65 Bits 2 through 5 must be set to zero in the bmAttributes field.of a non Isochronous Endpoint descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.66 Bits 13 through 15 must be set to zero in the wMaxPacketSize field.of an Endpoint descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.67 Legal mult values are 0x00/0x01/0x02 for a High speed Isochronous/Interrupt Endpoint descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.68 Bits 11 and 12 must be set to zero in the wMaxPacketSize field.of a Control/Bulk Endpoint descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.69 Bits 11 and 12 must be set to zero in the wMaxPacketSize field.of a non high-speed Endpoint descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.70 USB 1.x compliant devices must have a value of 0x01 in the bInterval field of an Isochronous Endpoint descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.71 USB 2.x compliant devices must have a value between 0x01 and 0x10 in the bInterval field of an Isochronous Endpoint descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.72 USB 2.x compliant devices must have a value between 0x01 and 0x10 in the bInterval field of a High speed Interrupt Endpoint descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.73 A device cannot have a value of 0x00 in the bInterval field of a Full/Low speed Interrupt Endpoint descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.74 A device operating at Low speed cannot have Isochronous endpoints.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 5.6.4.

    • 1.2.75 A Full speed Isochronous endpoint must have a MaxPacketSize between 0 and 1023.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 5.6.3.

    • 1.2.76 A High speed Interrupt/Isochronous endpoint must have a MaxPacketSize between 0 and 1024 when the mult value is zero.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 5.6.3.

    • 1.2.77 A High speed Interrupt/Isochronous endpoint must have a MaxPacketSize between 513 and 1024 and bInterval value of 1 when the Mult value is one.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.1.2.78 A High speed Interrupt/Isochronous endpoint must have a MaxPacketSize between 683 and 1024 and bInterval value of 1 when the mult value is two.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.

    • 1.2.79 A device operating at Low speed cannot have Bulk endpoints.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 5.8.3.

    • 1.2.80 A Full speed Bulk endpoint must have a MaxPacketSize of 0x08/0x10/0x20/0x40.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 5.8.3.

    • 1.2.81 A High speed Bulk endpoint must have a MaxPacketSize of 0x200.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 5.8.3.

    • 1.2.82 A Low speed Interrupt endpoint must have a MaxPacketSize less than or equal to 0x08.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 5.7.3.

    • 1.2.83 A Full speed Interrupt endpoint must have a MaxPacketSize less than or equal to 0x40.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.84 A Low speed Interrupt endpoint must have a value greater than 10 in the bInterval field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 5.7.4.

    • 1.2.90 The number of endpoint descriptors in an interface must match the number reported in the interface descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.

    • 1.2.91 A device that has Bulk/Interrupt endpoints must support the Halt Endpoint request on those endpoints.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.

  • Interface Descriptor

    • 1.2.100 A device that supports remote wakeup in a specific configuration must not fail a valid SetFeature(DEVICE_REMOTE_WAKEUP) command.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.

    • 1.2.101 A device that supports remote wakeup in a specific configuration must not fail a valid ClearFeature(DEVICE_REMOTE_WAKEUP) command.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.1.

    • 1.2.102 After a successful ClearFeature(DEVICE_REMOTE_WAKEUP) Bit 1 of status word returned in response to a GetStatus request must be set to a zero.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.5.

    • 1.2.103 After a successful SetFeature(DEVICE_REMOTE_WAKEUP) Bit 1 of status word returned in response to a GetStatus request must be set to a one.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.5.

    • 1.2.104 After a successful SetFeature(SUSPEND), a hub/host port's status must show 'suspended'.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 1.2.105 A device with remote wakeup disabled must not initiate a remote wakeup.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.1.

    • 1.2.106 A device with remote wakeup enabled must be able to initiate a remote wakeup on its suspended parent port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.

  • Device Qualifier Assertions

    • 1.2.120 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request cannot have a value of 0x00/0x01 in the high byte of the bcdUSB field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.

    • 1.2.121 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request must have a length of 0x0a.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.

    • 1.2.122 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request must the value of 0x06 in the Type field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.

    • 1.2.123 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request must have a value of 0x00 in the device subclass field when the device class is 0x00.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.

    • 1.2.123 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request must have a value of 0x00 in the device subclass field when the device class is 0x00.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.

    • 1.2.124 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request must have a value of 0x00 in the reserved field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.


USB Driver Level Re-Enumeration Test

Type: Automated Test

Overview

This test checks if a USB device connected to a system (but not directly to the root hub) can properly handle the IOCTL_INTERNAL_USB_CYCLE_PORT request. This request is basically another way to re-enumerate the driver of the USB device.

Details

This test checks whether the device is connected to the root hub. When it is ensured that a USB device is connected to the intermediate hub, perform an IOCTL_INTERNAL_USB_CYCLE_PORT request to all the USB hub ports. The test then sleeps for 15 seconds and finally compares the state and existence of the USB device before and after performing the IOCTL_INTERNAL_USB_CYCLE_PORT request on all ports. If the state and existence of the USB device(s) found are the same, then the test passes. If the device(s) do not match, then the test logs which device(s) were not found after the request (IOCTL_INTERNAL_USB_CYCLE_PORT) was performed.

Run Time: 3 minutes
Log File: USBVirtTest.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: USBVirtTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail.

To run this test:

  1. Install the DevED MSI.

  2. Copy the binaries.

  3. Install the driver.

  4. Run the USBVirtTest. Execute the application with or without parameters (you can specify the VID/PID as parameters in the command line syntax).

  5. Uninstall the driver:

  6. Uninstall the DevED MSI.

Command Syntax

Command option | Description
UsbVirtTest.exe | Without any options, the test runs for all USB devices attached to the system.
[VID] [PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter
[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter

Code Tour

File Manifest

File | Location
UsbVirtTest.exe | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\LogoKit\USBVirtTest
USBVirtTest.cat | WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\LogoKit\USBVirtTest
USBVirtTest.inf | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\LogoKit\USBVirtTest
USBVirtTest.sys | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\LogoKit\USBVirtTest
WTTlog.dll | [WTT\OSBinRoot]\WTT
devcon.exe | [WTT\OSBinRoot]\idw
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


USB Enable Disable Test

Type: Automated Test

Overview

The USB Enable Disable test is a stress test which stresses multiple disables and enable of a device. The test ensures that the device under test is in the attached and configured state after 100ms of being enabled.

Details

Test Initialization:

  • Select device to test

  • Gather initial information
    • Device VID and PID are used to obtain the device instance path

USB Enable Disable test

  • First the device under test is found in an equivalent way to finding it in the device manager, this ensures that the state of the device is both attached and configured. The test will fail if the device is not found.

  • Repeat these steps 20 times
    • The device is disabled
    • The device is then enabled
    • After waiting 100ms the device under test is sought for using the device instance path, to verify that it is both attached and configured. The test will fail if the device is not found

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
Processor
  • x86
  • x64
  • Itanium


USB Enumeration Stress Test

Type: Automated Test

Overview

The USB Enumeration Stress Test runs a number of individual tests that verify various attributes and operations used by the function-specific portions of the test device. The tests also verify communications from the device through the bus interface to the host. This test is based on the USBCV compliance test tool provided by the USB Implementers Forum, Inc. (USB-IF).

The USB Enumeration Stress test (USBENUM) verifies the proper functionality of a USB device when it is initially attached to a USB port. To properly enumerate in the Windows environment, a device must consistently provide valid information on its control pipe and properly respond to all standard device requests. This test repeats the enumeration process to make sure that devices will enumerate reliably in real-world scenarios. This test covers only USB peripheral devices and hubs.

Details

The system used for this test must have an available root hub port. If the test is to be run on a system on which the keyboard and mouse are attached by a USB and the system supports more than one root hub, these devices should be connected on one of the other root hubs. If the system has only one root hub, all other devices must be attached downstream of a secondary root hub port.

While the test runs, any devices connected to other ports on the same root hub might become unusable for a period of time.

This test includes the following parts:

Setup

Note that the test fails if there is more than one intermediate hub.

Note: For embedded USB devices (for example, laptop devices) where it is impossible to meet the external hub connectivity requirement, you must follow the following steps:

  1. Select the job USB Enumeration Stress Test from Available jobs pane in the Device Console.

  2. Click the Add Selected button on the Device Console. The selected job shows up in the bottom pane.

  3. Select this job from the bottom pane. Right-click it and select Edit Parameters

  4. You will see the Parameter Edit window open, with parameters listed on the left and their values on the right.

  5. Change this value of IsEmbeddedUSBDevice parameter from FALSE to TRUE.

  6. Click the Schedule Jobs button on the Device Console to run this job.

Initialization

  • Select device to test

  • Open handle to host controller

  • Gather initial information, such as:
    • Device descriptor
    • Configuration descriptor
    • String descriptors (if supported by device and test)

Enumeration Test (repeat n times) with No String Descriptor Support

  • Reset device port

  • Get device descriptor (first MPS with wLength value of FF)

  • Reset device port

  • Get device descriptor (full descriptor)

  • Set address (address not in use)

  • Get configuration descriptor

  • Compare device and configuration descriptors to initial ones

  • Set configuration to configuration 0

Enumeration Test (repeat n times) with String Descriptor Support

  • Reset device port

  • Get device descriptor (first MPS with wLength value of FF)

  • Reset device port

  • Get device descriptor (full descriptor)

  • Set address (address not in use)

  • Get configuration descriptor

  • Compare device and configuration descriptors to initial ones

  • Set configuration to configuration 0

Result

The test is successful if comparisons of the device and configuration descriptor pass for all iterations.

Results Interpretation

The test fails if:

  • Any standard device request is not properly handled by the device under test.

  • Any standard device request does not meet the response time requirements as defined in the USB specification.

  • Run Time: 10 minutes
  • Log File:
  • System Restart Required: No
  • Test Category:

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller.
  • One USB IF certified USB 2.0 hub to connect the system and the test USB device
Processor
  • x86
  • x64
  • Itanium


USB Enumeration Stress Test with enhanced logging for debugging

Type: Manual Test

Overview

The USB Enumeration Stress test (USBENUM) verifies the proper functionality of a USB device when it is initially attached to a USB port. To properly enumerate in the Windows environment, a device must consistently provide valid information on its control pipe and properly respond to all standard device requests. This test repeats the enumeration process to make sure that devices will enumerate reliably in real-world scenarios. This test covers only USB peripheral devices and hubs.

This version of the USB Enumeration Stress Test incorporates ETW events generated in the USB PORT driver into the log for debugging purposes. This test is not required to get a logo. See "Log Interpretation" below for details on interpreting the additional log information.

Details

The system used for this test must have an available root hub port. If the test is to be run on a system on which the keyboard and mouse are attached by a USB and the system supports more than one root hub, these devices should be connected on one of the other root hubs. If the system has only one root hub, all other devices must be attached downstream of a secondary root hub port.

While the test runs, any devices connected to other ports on the same root hub might become unusable for a period of time.

This test includes the following parts:

Setup

Note that the test fails if there is more than one intermediate hub.

Initialization

  1. Select the device to test.

  2. Open the handle to the host controller.

  3. Gather initial information, such as the following:
    • Device descriptor
    • Configuration descriptor
    • String descriptors (if supported by device and test)

Enumeration Test (repeat n times) with No String Descriptor Support

  1. Reset the device port.

  2. Get the device descriptor (first MPS with wLength value of FF).

  3. Reset the device port.

  4. Get the device descriptor (full descriptor).

  5. Set the address (address not in use).

  6. Get the configuration descriptor.

  7. Compare the device and configuration descriptors to the initial ones.

  8. Set the configuration to 0.

Enumeration Test (repeat n times) with String Descriptor Support

  1. Reset the device port.

  2. Get the device descriptor (first MPS with wLength value of FF).

  3. Reset the device port.

  4. Get the device descriptor (full descriptor).

  5. Set the address (address not in use).

  6. Get the configuration descriptor.

  7. Compare the device and configuration descriptors to the initial ones.

  8. Set the configuration to 0.

Result

The test is successful if comparisons of the device and configuration descriptor pass for all iterations.

Results Interpretation

The test fails if any of the following occurs:

  • Any standard device request is not properly handled by the device being tested.

  • Any standard device request does not meet the response time requirements as defined in the USB specification

Log Interpretation

Events logged:

  1. RAW_RESET_PORT_DISPATCH
    a. Occurs when a port reset is initiated
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
  2. RAW_RESET_PORT_STATUS1
    a. Indicates the status after SetFeaturePortPower
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
    • Port Status
  3. RAW_RESET_PORT_STATUS2
    a. Indicates the status after SetFeaturePortReset
    b. Includes the same data as STATUS1
  4. RAW_RESET_PORT_STATUS3
    a. Indicates the status after ClearFeaturePortResetChange
    b. Includes the same data as STATUS1
  5. RAW_RESET_PORT_COMPLETE
    a. Indicates the port reset has completed
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
    • USB Status
  6. SEND_ONE_PACKET_DISPATCH
    a. Occurs when a packet is sent to the device
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Packet Information:
      • Device Address
      • Endpoint Address
      • Maximum Packet Size
      • Timeout
      • USB Packet Flags
      • Data Length
      • Hub Device Address
      • Port TT Number
      • Usbd Status
  7. SEND_ONE_PACKET_DISPATCH_DATA
    a. Occurs after a packet dispatch to log the raw data in the transaction
    b. In addition to all the information in PACKET_DISPATCH, includes raw packet data in hexadecimal format
  8. SEND_ONE_PACKET_TIMEOUT
    a. Indicates that the request to the device timed out
    b. Includes the same data as PACKET_DISPATCH
  9. SEND_ONE_PACKET_COMPLETE
    a. Indicates the request completed
    b. Includes the same data as PACKET_DISPATCH and USB Status
  10. SEND_ONE_PACKET_COMPLETE_DATA
    a. Occurs after the packet completion to log any raw data in the transaction
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Packet info (see above)
    • Raw packet data in hexadecimal format

Timestamp Interpretation:

IMPORTANT The standard timestamp tag on the log entry does not accurately represent the time the ETW event occurred. Refer to the event timestamp logged with the data to get accurate timing information. There is a delay between when the ETW events occur and when they are published to the log. This creates a chronological disparity between the standard log entries and the ETW entries. When correlating events in the log, be sure to use the event timestamp when reconstructing the data.

Port Status Interpretation:

Refer to the following sections of "Universal Serial Bus Specification Revision 2.0" to interpret the port status:

  • 11.24.2.7 - Get Port Status

  • 11.24.2.7.1 - Port Status Bits

  • Table 11-21 - Port Status Field, wPortStatus

Run Time: 10 minutes
Log File: usbhct_e.log
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: usbhct.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs

Command Syntax

Command option | Description
usbhct.exe | Without any options, displays usage text
-e | Specifies to run the enumeration stress test
-d [VID/PID] | Specifies the device VID XXXX, and PID YYYY
-l [string] | Log file name. ex: "enumtest.log"
-w | Enable ETW tracing in the logs

Code Tour

File Manifest

File | Location
usbhct.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\
hctrans.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\
usbtree.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\
ETWCap.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\ETWCap\
USBRefresh.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\


USB Selective Suspend Test with enhanced logging for debugging

Type: Manual Test

Overview

This test is designed to test the selective suspend abilities of the USB. This feature allows a device's port to be suspended when the device is not in use to conserve power. To properly support this new feature, a device must maintain its internal state when its upstream port has been suspended and be able to function correctly when its upstream port is resumed. This test ensures that devices respond appropriately on its control pipe at its currently assigned device address following the suspend/resume cycle of a port. Depending on the class of the device, additional steps may be performed to ensure that the device responds correctly on other endpoints. This test runs only on devices and hubs.

This version of the USB Address Description Test incorporates ETW events generated in the USB PORT driver into the log for debugging purposes. This test is not required to get a logo. See "Log Interpretation" below for details on interpreting the additional log information.

Details

This test requires that the test device be connected through an intermediate USB 2.0 hub to the host system. This test fails if the test device is more than one hub deep.

Selective Suspend Test

100 test iterations:

  • Suspend Device Port

  • Sleep for 3000 ms

  • Resume Device Port

  • Get Device Descriptor and compare with initial value

  • Get Configuration Descriptor and compare with initial value

Results Interpretation

The test fails if any of the following occurs:

  • A device fails to respond correctly on its control pipe following the suspend/resume cycle.

  • A device fails to respond correctly on any other endpoints in its current configuration following the suspend/resume cycle.

Log Interpretation

Events logged:

  1. RAW_RESET_PORT_DISPATCH
    a. Occurs when a port reset is initiated
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
  2. RAW_RESET_PORT_STATUS1
    a. Indicates the status after SetFeaturePortPower
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
    • Port Status
  3. RAW_RESET_PORT_STATUS2
    a. Indicates the status after SetFeaturePortReset
    b. Includes the same data as STATUS1
  4. RAW_RESET_PORT_STATUS3
    a. Indicates the status after ClearFeaturePortResetChange
    b. Includes the same data as STATUS1
  5. RAW_RESET_PORT_COMPLETE
    a. Indicates the port reset has completed
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Port Number
    • USB Status
  6. SEND_ONE_PACKET_DISPATCH
    a. Occurs when a packet is sent to the device
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Packet Information:
      • Device Address
      • Endpoint Address
      • Maximum Packet Size
      • Timeout
      • USB Packet Flags
      • Data Length
      • Hub Device Address
      • Port TT Number
      • Usbd Status
  7. SEND_ONE_PACKET_DISPATCH_DATA
    a. Occurs after a packet dispatch to log the raw data in the transaction
    b. In addition to all the information in PACKET_DISPATCH, includes raw packet data in hexadecimal format
  8. SEND_ONE_PACKET_TIMEOUT
    a. Indicates that the request to the device timed out
    b. Includes the same data as PACKET_DISPATCH
  9. SEND_ONE_PACKET_COMPLETE
    a. Indicates the request completed
    b. Includes the same data as PACKET_DISPATCH and USB Status
  10. SEND_ONE_PACKET_COMPLETE_DATA
    a. Occurs after the packet completion to log any raw data in the transaction
    b. Includes the following data:
    • Timestamp
    • Host Controller Address
    • Packet info (see above)
    • Raw packet data in hexadecimal format

Timestamp Interpretation:

IMPORTANT The standard timestamp tag on the log entry does not accurately represent the time the ETW event occurred. Refer to the event timestamp logged with the data to get accurate timing information. There is a delay between when the ETW events occur and when they are published to the log. This creates a chronological disparity between the standard log entries and the ETW entries. When correlating events in the log, be sure to use the event timestamp when reconstructing the data.

Port Status Interpretation:

Refer to the following sections of "Universal Serial Bus Specification Revision 2.0" to interpret the port status:

  • 11.24.2.7 - Get Port Status

  • 11.24.2.7.1 - Port Status Bits

  • Table 11-21 - Port Status Field, wPortStatus

Run Time: 10 minutes
Log File: usbhct_s.log
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: usbhct.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

Command Syntax

Command option | Description
usbhct.exe | Without any options, displays usage text
-s | Specifies to run the selective suspend test
-d [VID/PID] | Specifies the device VID XXXX, and PID YYYY
-l [string] | Log file name. ex: "selstest.log"
-w | Enable ETW tracing in the logs

Code Tour

File Manifest

File | Location
usbhct.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\
hctrans.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\
usbtree.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\
ETWCap.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\ETWCap\
USBRefresh.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\


USB HIDView (CV) Test

Type: Automated Test

Overview

The primary use of a HID class device is to control the operation of the system. Examples of HID class devices include keyboards, pointing devices (such as mouse devices, trackballs, and joysticks), control devices (such as steering wheels, throttles, rudder pedals, and data gloves), and other devices that perform a similar function, such as bar code readers.

The USB HIDView (CV) test is based on the USBCV compliance test tool that the USB-IF provides. For information about the USB HID class, see the Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.11 available from the USB-IF on the USB Developers Web site.

Details

This test validates that USB human input devices (HID) comply with the functional and operational specifications for HID class USB devices. The test specifically validates the HID class-specific report descriptor. To run this test, you must attach a physical device to the system.

Note This test is required for USB-capable HID class devices.

Set Up:

This test requires the test device to be connected via an intermediate USB 2.0 hub to the host system. If the test machine has two USB controllers disable the controller that is not under test (or the test will fail).

Note For embedded USB Hubs with no Exposed Ports where it is impossible to manually run this test:

  1. Select the job USB HIDView (CV) Test from Available jobs pane in the Device Console.

  2. Click the Add Selected button on the Device Console. The selected job shows up in the bottom pane.

  3. Select this job from the bottom pane. Right-click it and select Edit Parameters

  4. You will see the Parameter Edit window open, with parameters listed on the left and their values on the right.

  5. Change this value of IsEmbeddedUSBDevice parameter from FALSE to TRUE.

  6. Click the Schedule Jobs button on the Device Console to run this job.

Note For embedded USB devices (for example, laptop devices) where it is impossible to meet this external hub connectivity requirement, you must follow these steps:

  1. In the Available jobs pane in Device Console, select the USB HIDView (CV) (Manual) job.

  2. Click Add Selected button from the Device Console window. The selected job shows up in the bottom pane.

  3. Right-click the job and click Edit Parameters. You will see the Parameter Edit window open, with parameters listed on the left and their values on the right.

  4. Change the value of the "IsEmbeddedUSBDevice" parameter to TRUE.

  5. Click Schedule Jobs button from Device Console to run this job

HID Class Algorithm

The USB HIDView (CV) test uses the following algorithm to verify that the test device is a HID class device:

  1. The test sends a valid get descriptor request to the device.

  2. For each configuration that the device supports, the test sends a valid GetDescriptor (Configuration) request with a bLength of 9 bytes. The test then sends a valid Get Configuration request with a blength equal to the wTotalLength field of the configuration descriptor.

  3. For each configuration descriptor obtained in step 2, the test parses the descriptor finding all interface descriptors. If any of the interface descriptors has a bDeviceClass value of 0x03 (HID_CLASS), the device is a HID device. The device is then tested.

Test Cases

The USB HIDView (CV) test runs a series of tests that verify the test device complies with the specifications for HID class devices.

  • TD-9.27.3.1 HID Descriptor Test

  • TD-9.27.3.2 HID Get/Set Idle Test

  • TD-9.27.3.3 HID Get/Set Protocol Test

  • TD-9.27.3.4 HID Report Descriptor Test

  • TD-9.27.3.5 HID Specification Version Test

TD-9.27.3.1 HID Descriptor Test

This test verifies that the device that is being tested responds to a valid Get HID Descriptor request and returns a descriptor in compliance with the HID specification. It also verifies that the HID descriptors in the configuration descriptor and the descriptors returned explicitly in response to the Get HID Descriptor request are identical.

This test is run with the device in the configured state.

The test performs the following steps:

  1. Issues a valid Set Configuration request for the configuration (unless it is an other_speed_configuration descriptor).

  2. Issues a valid Get Configuration request and verifies that the configuration has been set. (unless it is an other_speed_configuration descriptor).

  3. Issues a valid get configuration descriptor with a requested length of 9 bytes.

  4. Issues a valid get configuration descriptor with a requested length of the wTotalLength field from the descriptor obtained in step 3.

  5. For the configuration descriptor obtained in step 4, the test parses the descriptor to locate all interface descriptors.

  6. For each interface descriptor, the test checks to see if bInterfaceClass == 0x03 (HID_CLASS).

  7. Performs each of the following checks on the HID class interfaces:
  8. For each HID interface found in step 6, the test locates the HID descriptor as follows:
    • Issue a valid get configuration descriptor call requesting 9 bytes.
    • Issue a valid get configuration descriptor call requesting the full length.
    • Look at each interface descriptor in order until the interface and alternate setting numbers match the interface found in step 6
    • Confirm that bInterfaceClass == 0x03.
    • Search forward in the configuration descriptor from this interface descriptor until a HID class descriptor is found. If none are found, the test fails.

  9. If the HID class descriptor found in step 8 is for an interface with alternate setting zero and the configuration descriptor being tested is not an OTHER_SPEED_DESCRIPTOR, a valid Get HID descriptor is issued for the interface in question.

  10. The HID class descriptor(s) obtained in steps 8 and 9 are compared to ensure that they are identical (the test fails if they are different).

  11. For each HID class descriptor obtained in steps 9 and 10, the test performs the following checks:

       bLength > 8.

       bLength must be a multiple of 3.

       bLength == (9 + (bNumDescriptors -1)*3)

       bDescriptorType == HID descriptor type (0x21)

       bcdHID >= 0x100

       Each Additional bDescriptorType field must not be in the reserved range from 0x24 to 0x2F.

Note The test is repeated for each possible device configuration. For a high-speed capable device, the test is run with the device operating at both full speed and high speed. The test is also performed on the OTHER_SPEED_CONFIGURATION descriptor as described above.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • Any of the HID descriptor content checks fail.

  • Valid get HID descriptor requests fail for any reason.

TD-9.27.3.2 HID Get/Set Idle Test

This test verifies that the device being tested correctly supports the Get Idle request if it supports the Set Idle request.

This test is run with the device in the configured state.

The test performs the following steps:

  1. Issues a valid set configuration request for the configuration (unless it is an OTHER_SPEED_CONFIGURATION descriptor).

  2. Issues a valid get configuration request and verifies that the configuration has been set (if we are not testing an OTHER_SPEED_CONFIGURATION descriptor).

  3. Issues a valid get configuration descriptor request with a requested length of 9 bytes.

  4. Issues a valid get configuration descriptor request with a requested length equal to the value of the wTotalLength field from the configuration descriptor obtained in step 3.

  5. Parses the configuration descriptor obtained in step 4 in order to locate all interface descriptors.

  6. For each interface descriptor, the test checks to see if bInterfaceClass == 0x03 (HID_CLASS).

  7. For each interface found in step 6, the following descriptor parsing is performed:

    REPORT DESCRIPTOR PARSING

  8. Issues a valid get HID descriptor request for the interface being tested.

  9. Parses the HID descriptor to find the length of the report descriptor for this interface.

  10. Issues a valid get report descriptor request with a requested length equal to the length found in step 9.

  11. Counts the number of item tags in the report descriptor. The number of items tags must be at least 1.

  12. Counts the number of input tags in the report descriptor.

  13. Counts the number of report IDs in the report descriptor.

  14. If there are no report IDs the GET/SET Idle test is run with the value equal to 0x7F.

    If there are report IDs, the Get/Set Idle test is run with values equal to 0x00, 0x7F, and 0xFF for each report ID for an INPUT.

    GET/SET IDLE TEST

  15. Issues a valid set idle request for the report ID and duration being tested.

  16. Issues a valid get idle request for the report ID being tested.

  17. If both requests complete successfully, the test confirms that the get idle request returns the correct value that was set.

  18. The test is repeated for each possible device configuration.

Note For high-speed capable device, the test is run with the device operating at both full speed and high speed.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • Valid get HID descriptor requests fail for any reason.

  • Valid get HID report descriptor requests fail for any reason.

  • Set IDLE values do not match those returned by the Get IDLE request.

TD-9.27.3.3 HID Get/Set Protocol Test

This test verifies that a boot class HID interface correctly supports the Get and Set Protocol HID Requests.

This test is run with the device in the configured state.

The test performs the following steps:

  • Issues a valid set configuration request for the configuration (unless it is an OTHER_SPEED_CONFIGURATION descriptor).

  • If you are not testing an OTHER_SPEED_CONFIGURATION descriptor, the test issues a valid get configuration request and verifies that the configuration has been set.

  • Issues a valid get configuration descriptor request with a requested length equal to 9 bytes.

  • Issues a valid get configuration descriptor request with a requested length equal to the wTotalLength field from the configuration descriptor obtained in step 3.

  • For the configuration descriptor obtained in step 4, the test parses the descriptor to locate all interface descriptors.

  • For each interface descriptor, the test checks to see if bInterfaceClass == 0x03 (HID_CLASS).

  • For each HID interface descriptor, check the bInterfaceSubClass. If the bInterfaceSubClass == 0x01 and bAlternateSetting == 0, perform the following test:

    GET/SET PROTOCOL:

  • Issues a valid set protocol request for the report protocol.

  • Issues a valid get protocol request.

  • Verifies that the get protocol request returns a report protocol.

  • Issues a valid set protocol request for the boot protocol.

  • Issues a valid get protocol request for the boot protocol.

  • Confirms that the get protocol request returns boot protocol.

  • The test is repeated for each possible device configuration.

Note For a high-speed capable device, the test is run twice, once with the device operating at full speed, and once with the device operating at high speed.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • Valid get HID descriptor requests fail for any reason.

  • Valid get HID report descriptor requests fail for any reason.

  • Set protocol values do not match those returned by the get protocol request.

  • Valid get protocol or set protocol requests to a boot interface fail for any reason

TD-9.27.3.4 HID Report Descriptor Test

This test verifies that the device under test provides a report descriptor that meets the HID specification for each of its HID interfaces.

This test is run with the device in the configured state.

The test performs the following steps:

  1. Issues a valid set configuration request for the configuration (unless it is an OTHER_SPEED_CONFIGURATION descriptor).

  2. If you are not testing an OTHER_SPEED_CONFIGURATION descriptor, the test issues a valid get configuration request and verifies that the configuration has been set. ()

  3. Issues a valid get configuration descriptor request with a requested length equal to 9 bytes.

  4. Issues a valid get configuration descriptor request with a requested length equal to the wTotalLength field from the configuration descriptor obtained in step 3.

  5. For the configuration descriptor obtained in step 4, the test parses the descriptor to locate all interface descriptors.

  6. For each interface descriptor, the test checks to see if bInterfaceClass == 0x03 (HID_CLASS).

  7. For each interface found in step 6, the following descriptor parsing is performed:

    REPORT DESCRIPTOR PARSING

  8. Issues a valid get HID descriptor request for the interface being tested.

  9. Parses the HID descriptor to find the length of the report descriptor for this interface.

  10. Issues a valid get report descriptor request with a requested length equal to the length found in step 9.

  11. The test counts the number of item tags in the report descriptor. There must be at least one item tag.

  12. Parses the report descriptor according to section 6.2.2 of the HID specification.

  13. The test is repeated for each possible device configuration.

Note For a high-speed capable device, the test is run twice, once with the device operating at full speed, and once with the device operating at high speed.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • Valid get HID descriptor requests fail for any reason.

  • Valid get HID report descriptor requests fail for any reason.

  • A report descriptor does not comply with section 6.2.2 of the HID specification

TD-9.27.3.5 HID Specification Version Test

This test checks to see with which version of the HID specification the device is in compliance.

This test is run with the device in the configured state.

The test performs the following steps:

  1. Issues a valid set configuration request for the configuration (unless it is an OTHER_SPEED_CONFIGURATION descriptor).

  2. If you are not testing an OTHER_SPEED_CONFIGURATION descriptor, the test issues a valid get configuration request and verifies that the configuration has been set.

  3. Issues a valid get configuration descriptor request with a requested length equal to 9 bytes.

  4. Issues a valid get configuration descriptor request with a requested length equal to the wTotalLength field from the configuration descriptor obtained in step 3.

  5. For the configuration descriptor obtained in step 4, the test parses the descriptor to locate all interface descriptors.

  6. For each interface descriptor, the test checks to see if bInterfaceClass == 0x03 (HID_CLASS).

  7. For each interface found in step 6, the following descriptor parsing is performed:

    HID SPEC VERSION PARSING

  8. Starting at the HID descriptor found in step 6, the test parses forward in the configuration descriptor to locate each of the following items:
    • First HID descriptor after the HID interface.
    • Second HID descriptor after the HID interface.
    • First EndPoint descriptor after HID interface.
    • First interface descriptor (any kind) after the HID interface.

  9. Referring to step 8, if the location of A is greater than the location of D, the test fails.

  10. Referring to step 8, if the location of B is less than the location of D, the test fails.

  11. Referring to step 8, if the location of C is greater than the location of D, the test fails.

  12. Referring to step 8, if the location of A is less than C, the interface is HID specification 4 compliant. Otherwise, it is HID specification 3 compliant.

  13. The test is repeated for each possible device configuration.

Note For a high-speed capable device, the test is run twice, once with the device operating at full speed, and once with the device operating at high speed.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Device enumeration fails when following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • A HID interface does not have at least one endpoint.

  • Two HID descriptors describe a single HID interface.

  • A HID interface does not have a following HID descriptor before the next interface

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008

  • Windows Vista

  • Windows Server 2003

  • Windows XP

  • Software components included with the device that is being tested.

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller
  • One USB 1.1 or 2.0 hub to connect the system and the test USB device. If the test USB 2.0 device is high-speed, the additional USB 2.0 hub must also be high-speed. Use a USB IF certified hub when testing.
Processor
  • x86
  • x64
  • Itanium

Troubleshooting

The following list describes the USB HIDView (CV) Test Assertions:

  • General HID Assertions

    • 3.2.1 A HID class compliant Interface must have one HID descriptor associated with it.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.1.

    • 3.2.2 A HID class compliant Interface must have one Endpoint descriptor associated with it.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.1.

  • HID Descriptor Assertions

    • 3.2.20 A HID class compliant Interface must have a value of 0x00/0x01 in the bInterfaceSubClass field.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Appendix E.3.

    • 3.2.21 A HID class compliant Interface must have a value of 0x00/0x01/0x02 in the bInterfaceProtocol field.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Appendix E.3.

    • 3.2.22 A HID class compliant Interface must have a valid HID descriptor associated with it.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.1.

    • 3.2.23 The HID descriptors obtained from the configuration descriptor and one obtained by performing a GetDescriptor request for the same interface must match.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.1.

    • 3.2.24 The descriptor returned in response to a GetDescriptor(HIDDescriptor) request must have a length of at least 0x09 and in increments of 3 if more than 9.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.1.

    • 3.2.25 The descriptor returned in response to a GetDescriptor(HIDDescriptor) request must have a bNumDescriptors value that correlates with the length value.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.1.

    • 3.2.26 The descriptor returned in response to a GetDescriptor(HIDDescriptor) request must the value of 0x21 in the Type field.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.1.

    • 3.2.27 The descriptor returned in response to a GetDescriptor(HIDDescriptor) request must the value greater than 0x01 in the high byte of the bcdHID field.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.1.

    • 3.2.28 The descriptor returned in response to a GetDescriptor(HIDDescriptor) request must contain at least one entry containing of type report descriptor.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.1.

    • 3.27.3.2.29 The descriptor returned in response to a GetDescriptor(HIDDescriptor) cannot contain any optional descriptors with type field set to 0x24-0x2F.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.1.

  • HID Command Assertions

    • 3.2.40 The protocol returned in response to a GetProtocol request must match the protocol set by a successful previous call to SetProtocol.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.2.5.

    • 3.2.60 The number of items in a report descriptor must be greater than 0x0.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.2.

    • 3.2.61 The report descriptor returned in response to a GetDescriptor(Report) must be compliant with the HID specification.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.2.

    • 3.2.80 The idle rate returned in response to a GetIdle request must match the idle rate set by a successful previous call to SetIdle.

      Reference document: Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.2.3.


USB Host Controller Compliance

Type: Automated Test

Overview

This test checks for one or more valid UHCI, OpenHCI, or EHCI host controllers in the system. It performs basic register checks on the host controllers to determine the versions of the associated host controller specifications with which the host controllers are compliant.

Details

PCI Bus Enumeration

The PCI bus is also enumerated to search for the USB OpenHCI/UHCI/EHCI host controllers. The test scans a list of PCI devices and looks at the class code PCI configuration register of each to determine if it is an OpenHCI/UHCI/EHCI USB controller. The PCI Class Code register has the values shown in the following table for USB controllers.

Field | Bits | Read/Write | Description
PI | 7-0 | R | PROGRAMMING INTERFACE A constant value of '20h' Identifies the device being an EnhancedHCI Host Controller A constant value of '10h' Identifies the device being an OpenHCI Host Controller A constant value of '00h' Identifies the device as having no specific register level programming interface defined (UHCI)
SC | 15-8 | R | SUB CLASS A constant value of '03h' Identifies the device being a Universal Serial Bus
BC | 23-16 | R | BASE CLASS A constant value of '0Ch' Identifies the device being a Serial Bus Controller

If the base class is 0Ch and the sub class is 03h, the PCI device is a Universal Serial Bus controller. In this case, the programming interface is examined to determine the type of Universal Serial Bus controller.

Minimum OpenHCI/UHCI/EHCI Version Compliance

Each OpenHCI/UHCI/EHCI controller must meet a minimum version of the corresponding host controller specification. The version of the specification that each host controller supports is determined as follows:

EHCI - The HCIVERSION register at Offset 0x02 of the EHCI capability registers is read. This register contains a 16-bit BCD encoded version of the EHCI Specification to which the host controller conforms. It must be at least 0x0095 or the test fails.

OpenHCI - The test should check the HcRevision value in the operational registers on OCHI controllers for compliance with Open Host Controller Interface Specification v1.0a.

UHCI - The UHCI Specification does not define a version register for the version of the UHCI Specification that the host controller implements. Instead the PCI Serial Bus Release Number register at offset 0x60 in configuration space is read. This 8-bit register must be version 1.1 or the test fails (0x10 indicates version 1.1 of the UHCI Specification).

If any of the UHCI, OHCI, or EHCI controllers in the system do not meet the versions documented above, the host controller compliance test fails.

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • The number of UHCI, OHCI, and EHCI USB host controllers found by enumerating the PCI bus does not match the operating system information.

  • An EHCI host controller does not meet at least version .95 of the EHCI Specification.

  • An UHCI host controller does not meet at least version 1.10 of the UHCI Specification.

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller.
Processor
  • x86
  • x64
  • Itanium

Troubleshooting

  • 9.1.7 USB host controller meets either OpenHCI Specification or UHCI Specification.

    Reference documents: WLP# - B2.6.2; PC 99 System Design Guide - 7.6

  • 9.1.B1 USB host controllers must meet the OpenHCI Specification, or the UHCI Specification, or the EHCI Specification.

    Reference documents: WLP# - B2.6.2

  • 9.1.B2 EHCI USB host controllers must meet version .95 of the EHCI Specification.

    Reference documents: WLP# - B2.6.2; Enhanced Host Controller Interface Specification, Revision .95

  • 9.1.B4 UHCI USB host controllers must meet version 1.1 of the UHCI Specification.

    Reference documents: WLP# - B2.6.2; PC 99 System Design Guide - 7.6. Universal Host Controller Interface Specification, Revision 1.1


USB Host Controller Transfer Speed Test (Manual)

Type: Manual Test

Overview

The USB Host Controller Transfer Speed Test measures the maximum data throughput of the host controller. The test verifies that the controller's data transfer rate is at least 60% of the nominal bit rate, as defined in the respective USB specification.

Details

EHCI Testing (High Speed USB)

If the test is run in EHCI mode, it is a manual test. You create USB traffic to saturate the bus, and the test measures the throughput of the controller. The bus may be saturated with multiple devices attached to the same controller. Good sources of USB traffic are file transfers to external USB devices and/or streaming media devices.

XHCI Testing (SuperSpeed USB)

This portion of the test is not yet implemented. It will require a USB 3.0 compatible test device and will run automatically.

Run Time: 5 minutes
Log File: hcspeed.log
System Restart Required: No
Test Category: USB Host Controller
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: hcspeed.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • USB 3.0 Compliance Test Device (for XHCI testing only)

  • Any USB 2.0 device(s) capable of saturating EHCI bandwidth (for EHCI testing only)

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test log will include a trace of the observed transfer rates (in MB/s).

Command Syntax

Command option | Description
hcspeed.exe | Without any options, the test will not run. Prints help menu.
-2 | Runs the test in USB 2.0 (EHCI) mode.
-3 | Runs the test in USB 3.0 (XHCI) mode (not currently supported).
-w | Runs the test in WUSB (WHCI) mode (not currently supported).
-d [string] | Specifies the USB Controller Device ID.
-I [long] | Specify the sampling interval in ms. Defaults to 1000 ms.
-q | When running manual test, specifies to terminate when minimum rate is achieved.
regsvr32 /s etwcap.dll | Registers the dll for use during the test.

Code Tour

File Manifest

File | Location
Hcspeed.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\
Hcspeedetw.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\
ETWCap.dll | [WTT\TestBinRoot]\nttest\driverstest\usb\ETWCap\
WTTlog.dll | [WTT\OSBinRoot]\WTT\


USB Hub Basic Transfer Test

Type: Automated Test

Overview

A hub is a USB device that connects to a host system and provides additional USB attachment points. The USB hub contains three principal components: the hub repeater, the hub controller, and the transaction translator.

The USB Hub Basic Transfer Test focuses on the transaction translator and verifies compliance with the Universal Serial Bus Specification Revision 2.0 requirements and the Microsoft Windows Logo Program System and Device Requirements. A USB 2.0 hub provides support for high-speed, full-speed, and low-speed USB peripherals.

The USB High Speed Basic Transfer test comprises a number of individual tests based upon the USB 2.0 Transaction Translator and Hub Compliance Test Specification developed by the USB-IF. These tests are described in the following sections.

Details

The USB High Speed Hub Basic Transfer Test is required only for Universal Serial Bus (USB) revision 2.0 high-speed hubs. The test verifies that the hub responds correctly to various transaction translator requests, and that the hub correctly handles a variety of transactions with high-speed, full-speed, and low-speed peripheral devices.

Note Because the USB Hub Basic Transfer Test is only designed to evaluate USB 2.0 high-speed hubs (400 Mbps) and not full-speed or USB 1.1 hubs (11 Mbps), testers should set the IsEmbeddedFullSpeedHub schedule-time parameter to TRUE in the Device Console when scheduling this test if their hub is not high speed or for any embedded hub (full or high speed). This parameter lets DTM know that the hub is not actually a high-speed hub and will therefore skip the test entirely. The job will be recorded as passing afterwards.

TD-9.29.1.11 Clear TT Buffer Test

The Clear TT Buffer Test verifies that the hub responds correctly to the Clear_TT_Buffer request to clear the state of a non-periodic buffer that is associated with a given endpoint.

The hub connects to an EHCI host controller (high-speed capable port).

A full-speed compliance device is connected to an available downstream port of the test hub. The test configures the full-speed test device to have as many Bulk OUT endpoints as the test device will support.

The test issues a Bulk OUT transaction and sends an arbitrary packet to the test device for each of the endpoints in sequence. Software manipulation through a custom EHCI driver stack is used to prevent complete splits from being issued for any of these transactions. This prevention is done by having a separate queue head for each transaction with a final dummy queue head that loops back on itself.

While the non-periodic list spins on the dummy queue head, the other transaction states can be monitored. After all of the non-periodic buffers for the transaction translator are full, the OUT transactions will not be able to advance to the complete split stage.

At this point, the test sends a Clear_TT_Buffer request to one of the endpoints that has a pending transaction. After this request is issued the test sends another OUT transaction to this endpoint. The transaction must be completed successfully.

The same test process is repeated by using control endpoints instead of bulk endpoints.

If the hub implements multiple transaction translators, the test device must be moved and the test repeated for each of the hubs available downstream ports.

The test is repeated for IN transactions.

Results Interpretation

The test writes all results to a file.

The test fails if the Clear_TT_Buffer request does not enable a transaction to be sent to the cleared endpoint when all the non-periodic buffers are in the pending state

TD-9.29.1.12 Stop TT Test

The Stop TT Test verifies that the hub responds correctly to the Stop_TT request.

For this test, you connect the hub an EHCI host controller (high-speed capable port) and connect a full-speed test device to one of the available downstream ports of the hub.

The test issues a Stop TT request to the hub. The test then attempts to run loopback tests of each transfer type to verify that the TT is stopped. Next, the test software issues a Reset TT request. The test then verifies that the loopback tests will run successfully.

The test is repeated for each downstream port on the hub if the hub implements one TT per port.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A transaction translator continues to generate downstream non-periodic traffic after receiving a Stop_TT request.

  • A transaction translator continues to generate downstream periodic traffic after receiving a Stop_TT request.

  • Communication to the downstream device fails after a Reset_TT request.

TD-9.29.1.13 Reset TT Test

The Reset TT Test verifies that the hub responds correctly to the Reset TT request.

For this test, you connect the hub an EHCI host controller (high-speed capable port) and connect a full-speed test device to one of the available downstream ports of the hub.

The test configures the test device to support either as many bulk loopback endpoint pairs as the device is capable of supporting, or as many non-periodic buffers as the transaction translator supports (whichever is smaller). The maximum packet size for each endpoint is configured to be 64 bytes. Each endpoint is configured to count the number of transactions that are sent to it.

The test issues a series of Bulk OUT transactions for each of the OUT endpoints in the loopback pairs.

Through software manipulation, the test prevents the host controller from issuing complete-splits for any of these transactions. The test then issues a valid Reset TT request. The complete splits for each of the Bulk OUT transactions are then allowed to complete. Each of these transactions must result in a STALL.

Next, the test repeats the same process for IN transactions to each of the IN endpoints in the loopback pairs.

In addition, this entire test is repeated on each port if the hub uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A transaction translator continues to generate downstream non-periodic traffic after receiving a Reset_TT request.

  • A transaction translator continues to generate downstream periodic traffic after receiving a Reset_TT request.

  • The Reset_TT request does not clear all TT data/transaction buffers.

  • Communication to the downstream test device fails to work after the Reset_TT request is used.

TD-9.29.1.14 TT Think Time Test

The TT Think Time Test verifies that the hub correctly reports its worst-case think time to advance to the next transaction in the periodic pipeline.

For this test, you connect the hub an EHCI host controller (high-speed capable port) and connect a full-speed test device to one of the available downstream ports of the hub.

This test configures the test device to support the maximum number of isochronous OUT endpoints the test device will support.

The test sends the get descriptor request to the hub to obtain the hub descriptor. The test examines bits D6...D5 of the wHubCharacteristics field to verify the reported worst case TT Think Time of the hub. This is interpreted as follows:

  • 00: TT requires at most 8 FS bit times of inter-transaction gap.

  • 01: TT requires at most 16 FS bit times of inter-transaction gap.

  • 10: TT requires at most 24 FS bit times of inter-transaction gap.

  • 11: TT requires at most 32 FS bit times of inter-transaction gap.

The test device is configured to measure the time between transactions to any of its isochronous OUT endpoints.

The test sets up a periodic schedule to send the hub isochronous transactions. The device tracks the time between each transaction as they execute.

The test queries the device to determine the largest delay in FS bit times between the end of one isochronous OUT transaction and the start of the next.

The procedure is repeated for isochronous IN, interrupt IN, and interrupt OUT transactions (limited to the number of non-periodic buffers in the TT) and for combinations of periodic and non-periodic transactions and full- and low-speed transactions.

If the hub implements more than one transaction translator per port, this test is repeated for each of the available downstream ports on the hub.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • The hub does not respond to the get descriptor request for the hub descriptor.

  • There is a longer delay between transactions to the full-speed test device than the hub reports as its worst case TT think time.

TD-9.29.1.16 Multiple Hub Tier Split Traffic Test

The Multiple Hub Tier Split Traffic Test verifies that the hub correctly repeats all high-speed traffic that is received at its upstream port to all of its high speed enabled downstream ports. In particular, the hub must repeat all high-speed split traffic to ensure that it reaches the appropriate hub with the full/low speed target device attached.

For this test, you connect the hub to an EHCI host controller (high-speed capable port). Four additional hubs are then connected in series behind the first hub. You connect a full-speed test device to the last hub in the chain.

The test configures the full speed test device to support a loopback pair of bulk endpoints and a loopback pair of interrupt endpoints. A loopback pair of endpoints is an IN endpoint and an OUT endpoint. Data that is written to the OUT endpoint may be immediately read back from the IN endpoint.

The maximum packet size for both the bulk and interrupt endpoints is set to 64 bytes.

Next, the test continuously issues a series of bulk OUT and bulk IN and interrupt OUT and interrupt IN transactions to the endpoints. The transfer sizes and data patterns are varied. In every case, the data read back from the device is compared with the data sent.

The process is repeated with a low-speed test device for each TT in the hub. The process is also repeated with a high-speed test device and high-speed loopback traffic.

The process is also repeated for isochronous and control loopback.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A test device cannot be configured behind a chain of five hubs.

  • Any full-, low-, or high-speed transactions are unsuccessful behind a chain of five hubs.

TD-9.29.1.17 Number of Non-Periodic Buffers Test

The Number of Non-Periodic Buffers Test verifies that the transaction translator implements at least two non-periodic transaction buffers.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support as many bulk OUT/IN loopback endpoint pairs as the test device supports. The maximum packet size for the endpoints is set to 64 bytes.

Next, the test sets up a series of bulk OUT transactions to each of the endpoints. Using software manipulation through a custom EHCI test stack, the test allows the transactions to issue start splits but not to issue complete splits. This is done by using a separate queue head for each transaction and a dummy queue head and the end of the list, which loops back on itself. This keeps the non-periodic buffers in the pending state. After a transaction is not able to advance to the do-complete-split stage, the non-periodic transaction buffers of the TT have been filled and the number of non-periodic buffers can be calculated. The transactions are then allowed to complete normally. Bulk IN transactions are performed for each of the bulk OUT loopback pairs that were completed. The data sent must match the data received.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation. The procedure is also repeated using bulk IN transactions instead of bulk OUT transactions.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A transaction translator does not have at least two non-periodic buffers.

  • A transaction translator does not correctly NAK non-periodic start splits when its non-periodic buffers are filled with pending transactions. A NAK is a handshake packet that indicates a negative acknowledgement.

  • Data read back from a bulk IN loopback endpoint does not match the data sent to the bulk OUT endpoint.

TD-9.29.1.18 Control Transaction Retry Handling Test

The Control Transaction Retry Handling Test verifies that the transaction translator correctly handles a start split for a control transaction when it has a non-periodic buffer in the pending state with a transaction to the same endpoint. This condition can easily result when the host loses the ACK for a start split. An ACK is a handshake packet that indicates a positive acknowledgement.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support a control endpoint with a maximum packet size of 64 bytes. The device is first queried to obtain the current transaction count for the endpoint.

Next, the test sets up a pair of control OUT transactions to the same endpoint. Using software manipulation through a custom EHCI test stack, the test enables the transactions to issue start splits but not to issue complete splits. This situation keeps the non-periodic buffer used for the first transaction in the pending state. The transaction translator should treat the second transaction as a retry of the first and respond with an ACK but not buffer the transaction. The transactions are then allowed to complete normally.

The test again queries the device for the transaction count on the control endpoint. If more than one new transaction (or zero) has been attempted on the endpoint, the test fails.

If the test device does not support transaction counting the test may be performed by issuing two small control OUT transactions with different data patterns to the endpoint. If the data read back from the endpoint through a control IN contains both pieces of data, the test fails.

The test is repeated using control IN transfers. If the hub supports a multiple TT organization, the test is repeated on each port.

The retry testing is carried out for each stage of the control transaction.

Results Interpretation

The test writes all results to a file.

The test fails if a transaction translator does not correctly treat control transfers as retries when it already has a transfer pending for the same endpoint.

TD-9.29.1.19 Bulk Transaction Retry Handling Test

The Bulk Transaction Retry Handling Test verifies that the transaction translator correctly handles a start split for a bulk transaction when it has a non-periodic buffer in the pending or ready/x state with a transaction to the same endpoint and direction. This condition can easily result when the host loses the ACK for a start split.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support a pair of bulk endpoints that support loopback transfers. The maximum packet size for each endpoint is set to 64 bytes. The test first queries the device to obtain the current transaction count for the Bulk OUT endpoint.

Next, the test sets up a pair of bulk OUT transactions to the endpoint. Using software manipulation through a custom EHCI test stack, the test allows the transactions to issue start splits but not complete splits. This situation keeps the non-periodic buffer used for the first transaction in the pending or ready/x state. The transaction translator should treat the second transaction as a retry of the first and respond with an ACK but not buffer the transaction. The transactions are then allowed to complete normally.

The test again queries the device for the transaction count on the bulk OUT endpoint. If more than one new transaction (or zero) has been attempted on the endpoint, the test fails.

If the test device does not support transaction counting, the test may be performed by issuing two small bulk OUT transactions with different data patterns to the endpoint. If the data read back from the endpoint through a bulk IN transaction contains both pieces of data, the test fails.

The test is repeated by using bulk IN transfers. If the hub supports a multiple TT organization, the test is repeated on each port.

Results Interpretation

The test writes all results to a file.

The test fails if a transaction translator does not correctly treat bulk transfers as retries when it already has a transfer pending for the same endpoint.

TD-9.29.1.20 Control Transaction Protocol Test

The Control Transaction Protocol Test verifies that the transaction translator correctly handles various device protocol response cases for control transactions.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support four additional control endpoints. The maximum packet size for the endpoints is set to 64 bytes.

The test software configures one of the endpoints to respond with a STALL, one of the endpoints to respond with a NAK, and one of the endpoints to timeout (not respond). If the test device supports it, the remaining control endpoint is also configured to generate CRC errors.

Next, the test sends a series of control transactions to each of the endpoints. The result of the transaction must resolve to STALL for the STALL, timeout, and CRC error endpoints. The test aborts the transaction to the NAK endpoint after 1 second. The test software reads the transaction count from the NAK endpoint before and after this transaction attempt. If the count has not increased in a manner that indicates repeated transaction attempts, the test fails.

The test is repeated for transactions in both directions and all valid transfer sizes.

If the hub implements multiple TT units, the test must be repeated on each port of the hub.

The entire test procedure is repeated using a low-speed compliance device for all valid transfer sizes.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A transaction does not correctly report a STALL for an endpoint programmed to STALL, time out, or produce CRC errors.

  • A transaction for an endpoint programmed to respond with a NAK responds with a state other than NAK.

  • A transaction is not repeatedly retried for an endpoint programmed to NAK due to an error in hub behavior.

TD-9.29.1.21 Bulk Transaction Protocol Test

The Bulk Transaction Protocol Test verifies that the transaction translator correctly handles various protocol response cases for bulk transactions.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support four bulk OUT endpoints. The maximum packet size for the endpoints is set to 64 bytes.

The test configures one of the endpoints to respond with STALL, one of the endpoints to respond with NAK, and one of the endpoints to timeout (not respond). If the test device supports it, the remaining endpoint is configured to generate CRC errors.

Next, the test sets up a series of bulk transactions to each of the endpoints. The result of the transaction must resolve to STALL for the STALL, timeout, and CRC error endpoints. The test aborts the transaction to the NAK endpoint after 1 second. The test reads the transaction count from the NAK endpoint before and after this transaction attempt. If the count has not increased in a manner that indicates repeated transaction attempts, the test fails.

The test is repeated for all valid transfer sizes.

If the hub implements multiple TT units, the test must be repeated on each port of the hub.

The four endpoints are reconfigured as bulk IN endpoints and the same procedure is repeated.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A transaction does not correctly report a STALL for an endpoint programmed to STALL, timeout, or produce CRC errors.

  • A transaction attempt for an endpoint programmed to NAK responds with a state other than NAK.

  • A transaction is not repeatedly retried for an endpoint programmed to NAK due to an error in hub behavior.

TD-9.29.1.22 Control Transaction Loopback Test

The Control Transaction Loopback Test performs functional testing of control transfers by exercising concurrent streams of OUT and IN transfer pairs to control endpoints. The test sets up the compliance device to support as many control endpoints as possible. Transaction streams are initiated for each endpoint that sends data through control OUT transactions and then reads it back with control IN transactions. Transfer streams are run for all possible transfer sizes and all possible data patterns.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support as many control endpoints as the test device will support. The maximum packet size for the endpoints is set to 64 bytes.

Next, the test sets up a transfer stream for each control endpoint. Each stream repeatedly executes control OUT and control IN transfers. The test compares the data received (IN) with the data sent (OUT) to make sure they are identical.

The test is repeated for all valid transfer sizes for every possible data pattern.

The same procedure is repeated with a low speed compliance device. This procedure is repeated for each downstream port on the hub if it uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • The data returned by any control IN transfer is not identical to the data that was sent with a control OUT transfer.

  • A control transfer cannot be successfully completed to the test device.

TD-9.29.1.23 Bulk Transaction Loopback Test

The Bulk Transaction Loopback Test performs functional testing of bulk transfers by exercising concurrent streams of OUT and IN transfer pairs to bulk endpoints. The test sets up the compliance device to support as many bulk endpoints as possible. Transaction streams are initiated for each endpoint that sends data through bulk OUT transactions and then reads it back with bulk IN transactions. Transfer streams are run for all possible transfer sizes and all possible data patterns.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support as many bulk endpoint pairs as the test device will support. The maximum packet size for the endpoints is set to 64 bytes.

Next, the test sets up a transfer stream for each bulk endpoint pair. Each stream repeatedly executes bulk OUT and bulk IN transfers. The test compares the data received (IN) with the data sent (OUT) to make sure they are identical.

The test is repeated for all valid transfer sizes for every possible data pattern.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • The data returned by any bulk IN transfer is not identical to the data that was sent with a bulk OUT transfer.

  • A bulk transfer cannot be successfully completed to the test device.

TD-9.29.1.24 Control Transaction Unpaired Complete Split Test

The Control Transaction Unpaired Complete Split Test verifies that the transaction translator correctly handles the case where a complete split for a control transaction is received for an endpoint that does not currently have a non-periodic buffer assigned to it.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test device is configured to have only a default control endpoint.

Next, the test sets up a control OUT transaction to the control endpoint of the test device. Using software manipulation through a custom EHCI test stack, the test allows the transaction to issue a start split but not a complete split. The test software then issues a Clear_TT_Buffer request for the control endpoint of the test device. Once this request is completed, the transaction that has been in the ready/x state without issuing a complete split is allowed to complete. This transaction should result in a STALL on the control OUT endpoint for the test device.

The test is repeated for a control IN transfer.

If the hub implements multiple TT units, the test must run on each port of the hub.

Results Interpretation

The test writes all results to a file.

The test fails if a transaction translator does not return a STALL when it receives a control transaction for an endpoint and a direction that is not currently assigned to one of the non-periodic buffers.

TD-9.29.1.25 Bulk Transaction Unpaired Complete Split Test

The Bulk Transaction Unpaired Complete Split Test verifies that the transaction translator correctly handles the case where a complete split for a bulk transaction is received for an endpoint and direction that does not currently have a non-periodic buffer assigned to it.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test device is configured to have a pair of loopback bulk endpoints.

The test sets up a bulk OUT transaction to the bulk OUT endpoint of the test device. Using software manipulation through a custom EHCI test stack, the test allows the transaction to issue a start split but not allowed to issue a complete split. The test then issues a Clear_TT_Buffer request for the bulk OUT endpoint of the test device. Once this request is complete, the transaction that was in the ready/x state without issuing a complete split is allowed to complete. This transaction should result in a STALL.

The test is repeated for a bulk IN transfer.

If the hub implements multiple TT units the test must be repeated on each port of the hub.

Results Interpretation

The test writes all results to a file.

The test fails if a transaction translator does not return a STALL when it receives a bulk transaction for an endpoint and a direction that is not currently assigned to one of the non-periodic buffers

TD-9.29.1.26 Number of Local Retries Test

The Number of Local Retries Test verifies that the transaction translator performs local retries of non-periodic transactions if the transactions produce timeouts or CRC errors on the full/low speed bus. The test verifies the transactions are tried exactly three times.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full-speed test device to support two bulk OUT endpoints. The maximum packet size for the endpoints is set to 64 bytes. One endpoint is configured to timeout and the other to respond with CRC errors (if the device supports this mode). Both endpoints are configured to track and return a transaction count on request.

The test obtains the current transaction count for both endpoints.

Next, the test sets up two bulk OUT transactions to each of the endpoints. The transactions must produce a STALL response for the test to pass. Once the transactions are complete, the test reads the transaction count for both of the bulk endpoints. If either transaction count has not increased by three, the test fails.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

The procedure is repeated for endpoints that NAK and STALL. In this case, there must only be one local attempt per transfers.

The same tests are repeated for control endpoints.

The test is repeated for an isochronous endpoint for timeout mode only.

The test is repeated for interrupt endpoints. These cases are the same as bulk/control endpoints except for the timeout case, which must produce an ERR response. There must only be one local attempt per transfer for the periodic endpoints.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A transaction translator does not attempt local retries of a non-periodic transaction that resulted in a timeout or CRC error.

  • A transaction translator attempts a non-periodic transaction less than or more than three times when it consistently results in a timeout or CRC error.

  • The correct transfer status is not returned for any transfer.

  • The correct number of local transfers is not attempted for transfer to a fixed response endpoint.

TD-9.29.1.27 Start Split Pipeline Size Test

The Start Split Pipelie Size Test verifies that the transaction translator can successfully accept as many as 16 start-splits in a single microframe.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full speed test device to support 16 isochronous OUT endpoints (or as many as the test device supports). The maximum packet size for the endpoints is set to 1024 bytes. Each endpoint is configured to keep a transaction count. The test sets up a series of small isochronous OUT transactions to each of the endpoints. The test uses a custom EHCI test stack to allow complete control of transaction scheduling.

All of the transactions are scheduled for execution in the same microframe and then periodic transactions are enabled for the host controller. After a sufficient delay, the periodic list is disabled to prevent the host controller from attempting any of the transactions that were not able to execute in the specified microframe. The transaction descriptors are examined to see how many of the transactions were executed (the host sends a start-split transaction).

Next, the test queries the device to obtain the transaction count for each of the endpoints on the test device. If any endpoint has received more than one transaction or the total number of transactions received by the endpoints does not match the number of start-splits sent by the host controller, the test fails.

This procedure is repeated with the start-split transactions sent in each possible microframe (all except microframe 6).

If supported by the test device, the procedure is also repeated with one-byte isochronous OUT transfers. Each endpoint is sent a different byte. The device is required to assemble the bytes in the order that they were received. At the end of the test, the data is read back from the bytes. If all the bytes are not present and in the order they were sent, the test fails.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A transaction translator does not issue full/low-speed periodic transactions in the order start-splits were received.

  • A transaction translator does not handle receiving up to 16 start-splits in a single microframe.

TD-9.29.1.28 Interrupt Transaction Protocol Test

The Interrupt Transaction Protocol Test verifies that the transaction translator correctly handles various device protocol response cases for interrupt transactions.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support four interrupt OUT endpoints. The maximum packet size for the endpoints is set to 64 bytes. The endpoints are also configured to keep a transaction count. The current count for each endpoint is read.

The test software configures one of the endpoints to respond with STALL, one of the endpoints to respond with NAK, and one of the endpoints to timeout (not respond). If the test device supports CRC checks, the remaining interrupt endpoint is configured to generate CRC errors.

Next, the test sets up a series of interrupt OUT transactions to each of the endpoints. The test uses a custom EHCI test stack to allow complete control of the periodic schedule. In turn, the test sets up and runs periodic schedules that attempt 100 transactions to the current endpoint being tested. After the transaction attempts are made, the transaction count for each endpoint is read and must have increased by 100.

The result of the each transaction must resolve to STALL for the STALL endpoint. The transaction attempt to the NAK endpoint should eventually time out. The CRC and timeout endpoints should result in ERR responses.

The test is repeated for transactions in both directions and for all valid transfer sizes. If the hub implements multiple TT units, the test must be repeated on each port of the hub.

The entire test procedure is repeated using a low-speed compliance device for all valid transfer sizes.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A transaction translator attempts local retries of an interrupt transaction.

  • A transaction attempt completes for an endpoint programmed to NAK.

  • A transaction attempt to an endpoint programmed to respond with CRC errors or to timeout does not result in an ERR response.

TD-9.29.1.29 Isochronous Transaction Protocol Test

The Isochronous Transaction Protocol Test verifies that the transaction translator correctly handles various device protocol response cases for isochronous IN transactions.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support two isochronous IN endpoints. The maximum packet size for the endpoints is set to 1024 bytes. The endpoints are also configured to keep a transaction count. The current count for each endpoint is read.

The test configures one of the endpoints to not respond (timeout). If the test device supports it the remaining isochronous endpoint is configured to generate CRC errors.

Next, the test sets up a series of isochronous IN transactions to each of the endpoints. The test uses a custom EHCI test stack to allow complete control of the periodic schedule. In turn, the test sets up and runs periodic schedules that attempt 100 transactions to the current endpoint being tested. After the transaction attempts are made, the transaction count for each endpoint is read and must have increased by 100. Each transaction should result in an ERR response.

The test is repeated for transactions in both directions and for all valid transfer sizes.

If the hub implements multiple TT units, the test must be repeated on each port of the hub.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A transaction translator attempts local retries of an isochronous transaction.

  • A transaction attempt to an endpoint programmed to respond with CRC errors or to timeout does not result in an ERR response.

TD-9.29.1.30 Interrupt Transaction Loopback Test

The Interrupt Transaction Loopback Test performs functional testing of interrupt transfers by exercising concurrent streams of OUT and IN transfer pairs to pairs of interrupt endpoints. The test sets up the compliance device to support as many pairs of interrupt loopback endpoints as possible. Transaction streams are initiated for each endpoint that send data through interrupt OUT transactions and then read it back with interrupt IN transactions. Transfer streams are run for a variety of transfer sizes and with all possible data patterns for those sizes.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support as many interrupt loopback pairs of endpoints as the test device will support. The maximum packet size for the endpoints is set to 64 bytes. The bInterval value for each endpoint is set to the minimum allowable time.

Next, the test sets up a transfer stream for each pair of interrupt endpoints. Each stream repeatedly executes interrupt OUT and interrupt IN transactions. The test compares the data received from the IN transaction with the data sent with the OUT transaction to make sure the data is identical.

The test is repeated for all possible transfer sizes for every possible data pattern.

The data read by an interrupt IN transaction should always match the data sent by an interrupt OUT transaction.

The same procedure is repeated with a low speed compliance device.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • The data returned by any interrupt IN transfer is not identical to the data that was sent with an interrupt OUT transfer.

  • An interrupt transfer cannot be successfully completed to the test device.

TD-9.29.1.31 Isochronous Transaction Loopback Test

The Isochronous Transaction Loopback Test performs functional testing of isochronous transfers by exercising concurrent streams of OUT and IN transfer pairs to isochronous loopback endpoint pairs. The test sets up the compliance device to support as many pairs of isochronous loopback endpoints as possible. Transaction streams are initiated for each endpoint pair that sends data through isochronous OUT transactions and then reads it back with isochronous IN transactions. Transfer streams are run for a variety of transfer sizes and with all possible data patterns for those sizes.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support as many isochronous loopback pairs of endpoints as the test device supports. The maximum packet size for the endpoints is set to 1024 bytes (or the maximum supported by the test device). The bInterval value for each endpoint is set to the minimum allowable time.

Next, the test sets up a transfer stream for each pair of isochronous endpoints. Each stream repeatedly executes isochronous OUT and isochronous IN transactions. The test compares the data received from the IN transaction to the data sent with each OUT transaction to make sure the data is identical.

The test is repeated for all valid transfer sizes for every possible data pattern.

The data read by an isochronous IN transaction should always match the data sent by an isochronous OUT transaction.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • The data returned by any isochronous IN transfer is not identical to the data that was sent with an isochronous OUT transfer.

  • An isochronous transfer cannot be successfully completed to the test device

Run Time: 45 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller
  • One test USB 2.0 high-speed hub
  • One test USB 1.1 hub
  • One Functional Compliance test low-speed device (low-speed USB 2.0 Compliance test board)
  • One Functional Compliance test full-speed device (full-speed USB 2.0 Compliance test board)
  • One high speed compliance device
Processor
  • x86
  • x64
  • Itanium

Troubleshooting

The following list describes USB High Speed Hub Test Assertions.

  • Hub Connected Upstream to High Speed Capable Port

    • 1.1.1 When a hub's upstream port is connected to a high speed capable port, control of a full speed device connected to a downstream port must be routed to the transaction translator by the hub port routing logic.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.

    • 1.1.2 When a hub's upstream port is connected to a high speed capable port, control of a low speed device must be routed to the transaction translator by the hub port routing logic.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.

    • 1.1.3 When a hub's upstream port is connected to a high speed capable port, a USB-IF compliant full speed device must enumerate properly when connected to a downstream port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.

    • 1.1.4 When a hub's upstream port is connected to a high speed capable port, a USB-IF compliant low speed device must enumerate properly when connected to a downstream port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.1.1.5 When a hub's upstream port is connected to a high speed capable port, a USB-IF compliant high speed device must enumerate properly when connected to a downstream port.

  • Hub Connected Upstream to Full/Low Speed Only Capable Port

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.

    • 1.2.1 When a hub's upstream port is connected to a full/low speed only capable port, a USB-IF compliant high speed device must enumerate properly when connected to a downstream port (as a full speed device).

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.

    • 1.2.2 When a hub's upstream port is connected to a full/low speed only capable port, a USB-IF compliant full speed device must enumerate properly when connected to a downstream port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.

    • 1.2.3 When a hub's upstream port is connected to a full/low speed-only capable port, a USB-IF compliant low speed device must enumerate properly when connected to a downstream port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.

    • 1.2.4 When a hub's upstream port is connected to a full/low speed-only capable port, the transaction translator must be disabled and must not be used. The hub repeater must operate as a full/low speed repeater.

  • General Device Detection

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.

    • 1.3.1 Bit 9 of the Port Status Bits should be set to one If and only if a low speed device is attached to the downstream port of a hub.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 1.3.2 Bit 10 of the Port Status Bits should be set to one if, and only if, a high speed device is attached to the downstream port of a hub that is operating in a high speed environment.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

  • Port Indicators. The port indicators are optional for USB 2.0 hubs. However, if they are implemented all of the following assertions must be met.

    • 1.4.1 A hub must accurately indicate whether it supports port indicators through bit D7 of the wHubCharacteristics field of the hub class descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Sections 11.5.3, 11.23.2.1; TD-9.28.1.4 Port Indicator Automatic Mode Test

    • 1.4.2 If a high speed capable hub implements port indicators they must be as specified in the Universal Serial Bus Specification, Revision 2.0. Custom port indicators are not allowed.

      Reference document: Universal Serial Bus Specification, Revision 2.0; TD-9.28.1.4 Port Indicator Automatic Mode Test

    • 1.4.3 When a hub is suspended or not configured all of its port indicators must be off.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Sections 11.5.3, 11.23.2.1; TD-9.28.1.4 Port Indicator Automatic Mode Test

    • 1.4.4 When a hub makes the transition out of a not configured state, its port indicators must be in Automatic control mode (as defined in section 11.5.3 of the Universal Serial Bus Specification, Revision 2.0) by default.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3

    • 1.4.5 A hub port indictor must be off when it is under automatic control and the port is in the Suspended, Resuming, SendEOR, Restart_E, or Restart_S state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.6 A hub port indictor must be Green when it is under automatic control and the port is in the Enabled, Transmit, or TransmitR state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.7 A hub port indictor for a hub with Port Power Switching must be off when it is under automatic control and the port is in the Disconnected, Disabled, Not Configured, Resetting, or Testing state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.8 The following rule applies to a hub port indictor for a hub without Port Power Switching. It must be off or amber if there is an over-current condition when it is under automatic control and the port is in the Disconnected, Disabled, Not Configured, Resetting, or Testing state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.9 A hub port indictor for a hub with Port Power Switching must be off or amber if there is an over-current condition. This rule applies when it is under automatic control and the port is in the powered-off state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.10 A hub port indictor for a hub without Port Power Switching must be off when it is under automatic control and the port is in the powered-off state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.11 Bit 12 of a hub's Port Status bits must accurately indicate whether the port indicator is currently under Automatic or Software control.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.1; TD-9.28.1.4 Port Indicator Automatic Mode Test

    • 1.4.12 A port indicator must make the transition to manual mode and display amber in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 1.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 1.4.13 A port indicator must make the transition to manual mode and display green in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 2.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 1.4.14 A port indicator must make the transition to manual mode and display off in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 3.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 1.4.15 A port indicator must make the transition to automatic mode in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 0.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 1.4.16 A hub must respond to a Clear Port Feature command with feature selector PORT_INDICATOR by transitioning the port indicator for that port to Automatic Mode.

      Reference document: Universal Serial Bus Specification, Revision 2.0, 12/07/00 Errata.

Number of Transaction Translators

  • Reporting of Number of Transaction Translator in Implementation

    • 1.5.1 A hub must implement either one transaction translator or one transaction translator per downstream port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, 11.14.1.3.

    • 1.5.2 A hub operating at full/low speed must set the bDeviceProtocol field of its Device_Qualifer Descriptor to 1 if its implements a single transaction translator or 2 if it implements one transaction translator per port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.5.3 A hub operating at high speed must set the bInterfaceProtocol field of its Interface Descriptor to 0 if its implements a single transaction translator or 1 if it implements one transaction translator per port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.5.4 A hub operating at high speed that implements one transaction translator per port must provide an alternate setting for its interface with all fields identical to those for the default interface except for bInterfaceProtocol which must be set to 2.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.5.5 By default a hub with multiple transaction translators (1 per port) must only use one transaction translator (single TT mode by default).

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.5.6 A multiple transaction translator capable port (1 per port) must only use more than one transaction translator if its alternate interface setting is set through a SET_INTERFACE request. A hub with multiple transaction translators must support SET_INTERFACE when operating in a high-speed capable environment.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.5.7 A hub with multiple transaction translators (1 per port) must support GET_INTERFACE when operating in a high speed environment.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

Descriptors and Commands

  • Transaction Translator Commands and Transaction Translator Think Time

    • 1.6.1 A hub must implement its Device, Device Qualifier, Configuration, Interface, Other Speed Configuration, and Endpoint descriptors when connected in a full speed electrical environment as specified in the Universal Serial Bus Specification, Revision 2.0.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.6.2 A hub must implement its Device, Device Qualifier, Configuration, Interface, Other Speed Configuration and Endpoint descriptors when connected in a high speed electrical environment as specified in the Universal Serial Bus Specification, Revision 2.0.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.6.3 A hub must respond to a valid Get_TT_State request with bits 0 to 15 of the TT_Return_Flags field set to zero.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.8.

    • 1.6.4 A transaction translator must return to its initial state after configuration in response to the Reset_TT request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.9.

    • 1.6.5 A transaction translator must halt operation in response to a valid Stop_TT request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.

    • 1.6.6 A transaction translator that has been stopped via a Stop_TT request must only resume operation after being reset through a Reset_TT request or an overall reset of the hub.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.

    • 1.6.7 A transaction translator must clear an asynchronous (non-periodic) buffer associated with the given endpoint in response to a valid Clear TT Buffer request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.

    • 1.6.8 A transaction translator must treat an otherwise correct Clear_TT_Buffer response that specifies a non-existent transaction as a functional no-op.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.

    • 1.6.9 A transaction translator must accurately indicate its worst case Think Time to advance to the next full/low speed transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.

    • 1.6.10 A multi-TT hub must respond with a Request Error to a Clear TT Buffer, Stop TT, Reset TT, or Get TT State request with an invalid port number. A single TT hub must respond with a Request Error to a Clear TT Buffer or Get TT State request with an invalid port number. A single TT hub may ignore the port number in Stop TT and Reset TT requests.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.

    • 1.6.11 A hub must respond with a Request Error to a Clear TT Buffer, Stop TT, Reset TT, or request with an incorrect wLength field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.

    • 1.6.12 A hub must support the PING protocol on its control endpoint. This includes the possibility of a host that PINGs before attempting an OUT transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 8.5.1.1.

    • 1.6.13 The bHubContrCurrent field in the hub descriptor must indicate the current draw of the hub circuitry from VBUS. It must not include the current draw of any embedded downstream devices.

      Reference document: WLP# B2.6.4.6. Note: This is currently a proposed erratum to the Universal Serial Bus Specification, Revision 2.0. The current (as of 3/29/02) specification does not clearly define the meaning of this field.

    • 1.6.14 A TT that has been stopped with a Stop TT command must continue to generate SOFs to enabled downstream ports under its control.

  • USB 2.0 Test Modes Assertions

    Reference document: WLP# B2.6.4.6. Note: This document is currently a proposed erratum to the Universal Serial Bus Specification, Revision 2.0. The current (as of 3/29/02) specification does not clearly define the meaning of this field.

    • 1.7.1 A hub must place its upstream port in test mode TEST_J in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_J.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.

    • 1.7.2 A hub must place its upstream port in test mode TEST_K in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_K.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.

    • 1.7.3 A hub must place its upstream port in test mode TEST_SEO_NAK in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_SEO_NAK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.

    • 1.7.4 A hub must place its upstream port in test mode TEST_PACKET in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_Packet.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.

    • 1.7.5 A hub must respond with a request error to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_Force_Enable.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9, 7.1.20.

    • 1.7.6 Once a hub has its upstream port in a test mode it must only exit the test mode if the power is cycled for the hub.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.

    • 1.7.7 A hub must transition a downstream port out of test mode in response to a reset.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.8 A hub with a downstream port in a test mode must still report port disconnects or port resume status changes for all other downstream ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.9 A downstream facing port that has been placed in a test mode may only exit the mode when the hub is reset.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.

    • 1.7.10 A hub must place the designated downstream facing port in test mode TEST_J in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_J.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.11 A hub must place the designated downstream facing port in test mode TEST_K in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_K.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.12 A hub must place the designated downstream facing port in test mode TEST_SEO_NAK in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_SE0_NAK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.13 A hub must place the designated downstream facing port in test mode TEST_PACKET in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_Packet.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.14 A hub must place the designated downstream facing port in test mode TEST_Force_Enable in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_Force_Enable.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.15 A downstream port in test mode Test_Force_Enable must still indicate disconnect events.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.

    • 1.7.16 A hub must respond with a request error (STALL) to a CLEAR_FEATURE command with feature selector TEST_MODE.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.1.

    • 1.7.17 A hub must respond with a request error (STALL) to a CLEAR_PORT_FEATURE command with feature selector PORT_TEST.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.

Miscellaneous

  • Hub and Transaction Translator Requirements

    • 1.8.1 If a transaction translator is receiving a packet at EOF2 of the downstream facing bus it must disable the downstream facing port that is currently transmitting.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.

    • 1.8.2 If the transaction translator is transmitting a packet near EOF1 of the downstream facing bus it must force and abnormal termination sequence as defined in Section 11.3.3 of the Universal Serial Bus Specification, Revision 2.0 and stop transmitting.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.

    • 1.8.3 A port with a high-speed device connected must still indicate high-speed operation through descriptors when it is suspended and the device reverts to full speed terminations.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.1.9.

    • 1.8.4 If a hub misses Start-of-Frame (SOF) packets for three consecutive microframes when operating in a high speed environment it also loses synchronization for its full speed timers. Any transaction translators in operation must stop generating full speed SOF packets until synchronization is regained.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.5 Frame timers used by transaction translator units in hubs must maintain synchronization unless the hub microframe timer loses synchronization.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.6 If a hub misses Start-of-Frame (SOF) packets for three consecutive microframes when operating in a high speed environment it loses synchronization for its microframe timer and all related frame timers used by transaction translators.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.7 If a hub loses microframe synchronization its transaction translators must respond to periodic complete splits with results buffered in the periodic complete split pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.8 If a hub loses microframe synchronization its transaction translators must abort any buffered periodic start-split transactions in the periodic start split pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.9 If a hub loses microframe synchronization its high speed handler must ignore any high-speed periodic start splits.

    • 1.8.10 If a hub loses microframe synchronization its transaction translators must stop issuing low speed keep alive on any low speed enabled ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.11 If a hub loses microframe synchronization, its transaction translators must stop issuing full speed SOFs on any full speed enabled downstream ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.12 If a hub loses microframe synchronization, its transaction translators must not start issuing any subsequent periodic full/low speed transactions.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.13 If a hub loses microframe synchronization, its high-speed handler must respond to any high speed start splits for bulk/control transactions normally. (NAK if buffers full - place transactions in available non-periodic buffers as it normally would.)

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.14 If a hub loses microframe synchronization it must respond normally to any complete splits for bulk/control transactions.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.15 If a hub loses microframe synchronization it must not issue any pending bulk/control transactions on the full/low speed bus. It must preserve the buffers for these transactions until synchronization is regained.

    • 1.8.16 A hub must repeat all high speed traffic, including start and complete splits, to all high speed enabled downstream ports. In particular, a hub may not prevent split traffic from reaching a hub further downstream with a full or low speed device connected.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

Bulk and Control (Non-Periodic) Transfers. The following assertions use the notation described in the Universal Serial Bus Specification, Revision 2.0 to describe the possible states of a buffer for a bulk or control transfer being executed through a transaction translator.

  • | General

    • 2.1.1 A transaction translator must have at least two bulk/control transaction buffers. Each one must be capable of holding the Start Split and related data for an OUT or data from the full/low speed bus for an IN.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.

    • 2.1.2 If the transaction translator has an available Non-Periodic buffer (not in the Ready/X or Pending state) the high speed handler must accept the Start Split for a bulk or control transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.

    • 2.1.3 If the transaction translator does not have an available Non-Periodic buffer (not in the Ready/X or Pending state) the high speed handler must NAK the start split for a bulk or control transfer.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.

    • 2.1.4 If the high speed handler for a transaction translator times out or receives a CRC error anywhere in the <Start Split - Token - Data> sequence for a bulk or control transfer it must timeout and not buffer the transaction in one of its non-periodic buffers.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.

    • 2.1.5 If the high speed handler for a transaction translator times out or receives a bad CRC anywhere in the <Complete Split - Token> sequence it must time out and not respond.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.1.6 If a full or low speed non-periodic transaction results in a NAK, STALL, or ACK response the transaction translator must update the transaction buffer to the corresponding status and must not retry the transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.1.7 A full or low speed non periodic transaction that produces a timeout or transaction error must be retried locally by the transaction translator.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.1.8 A full or low speed non-periodic transaction must not be tried more than three times locally by the transaction translator.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.1.9 A full or low speed non periodic transaction that has been tried three times locally by the transaction translator without success must be resolved to a STALL response.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.1.10 The integrity of all data associated with non periodic transactions must be preserved as it is transferred into and out of any of the non-periodic buffer space used by the transaction translator.

  • Control Transactions

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.1 The high-speed handler for a transaction translator receives a Start Split for a control transfer to an endpoint. There is already a control transaction for that endpoint whose non-periodic buffer is in the pending or ready/x state. In this case, the transaction translator must respond with an ACK but disregard the information.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.2 If the high speed handler for a transaction translator receives a Start Split for a control transfer and already has a non-periodic buffer in the old/x state for the same endpoint it must re-use the same buffer for the new transaction.

    • 2.2.3 If the high speed handler for a transaction translator receives a Complete Split for a control transfer and has a non-periodic buffer for the same endpoint in the pending state it must respond with a NYET handshake.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.4 If the high speed handler for a transaction translator receives a complete split for a control transfer and does not have a non-periodic buffer for that endpoint it must respond with a STALL.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.5 The high-speed handler for a transaction translator receives a complete split for a control transfer. If it has a non-periodic buffer for the same endpoint in the ready/STALL state, it must return STALL and transition the buffer to the old/STALL state.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.6 If the high speed handler for a transaction translator receives a complete split for a control transfer and has a non periodic buffer for the same endpoint in the old/STALL state it must return STALL.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.7 The high speed handler for a transaction translator receives a complete split for a control OUT transfer. If it has a non-periodic buffer for the same endpoint in the ready/ACK state it must return ACK and transition the buffer to the old/ACK state.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.8 If the high speed handler for a transaction translator receives a complete split for a control OUT transfer and has a non-periodic buffer for the same endpoint in the old/ACK state it must return ACK.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.9 The high speed handler for a transaction translator receives a complete split for a control IN transfer. If it has a non-periodic buffer for the same endpoint in the ready/DataX state it must return DataX and transition the buffer to the old/DataX state.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.10 If the high speed handler for a transaction translator receives a complete split for a control IN transfer and has a non periodic buffer for the same endpoint in the old/Data state it must return Data.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.11 The high speed handler for a transaction translator receives a complete split for a control transfer. If it has a non-periodic buffer for the same endpoint in the ready/NAK state it must return NAK and transition the buffer to the old/NAK state.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.12 If the high-speed handler for a transaction translator receives a complete split for a control transfer and has a non periodic buffer for the same endpoint in the old/NAK state, it must return NAK.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.13 A transaction translator must correctly handle full speed control transfers in both directions of up to 64 bytes.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.14 A transaction translator must correctly handle low speed control transfers in both directions of up to 8 bytes.

    Note The USB core specification stipulates that direction should not be checked as part of buffer matching for control endpoints. Some vendors have implemented checking that does not match for Setup/In, Setup/Out, Out/In mismatches. These implementations are also acceptable.

  • Bulk Transactions

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.1 The high speed handler for a transaction translator receives a Start Split for a bulk transfer. If there is already a buffer for that endpoint and direction already in the pending or ready/x state it must respond with an ACK but disregard the information.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.2 The high speed handler for a transaction translator receives a Start Split for a bulk transfer. If it already has a non-periodic buffer for that endpoint and direction in the old/x state it must re-use the same buffer for the new transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.3 The high speed handler for a transaction translator receives a Complete Split for a bulk transfer. If it already has a non-periodic buffer for the same endpoint and direction that is in the pending state it must respond with a NYET handshake.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.4 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it does not have a non-periodic buffer for that endpoint and direction it must respond with a STALL.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.5 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/STALL state it must return STALL and transition the buffer to the old/STALL state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.6 If the high speed handler for a transaction translator receives a complete split for a bulk transfer and has a non periodic buffer for the same endpoint and direction in the old/STALL state it must return STALL.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.7 The high speed handler for a transaction translator receives a complete split for a bulk out transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/ACK state it must return ACK and transition the buffer to the old/ACK state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.8 If the high speed handler for a transaction translator receives a complete split for a bulk out transfer and has a non periodic buffer for the same endpoint and direction in the old/ACK state it must return ACK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.9 I The high speed handler for a transaction translator receives a complete split for a bulk in transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/Data state it must return Data and transition the buffer to the old/Data state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.10 If the high speed handler for a transaction translator receives a complete split for a bulk in transfer and has a non periodic buffer for the same endpoint and direction in the old/DataX state it must return DataX.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.11 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/NAK state it must return NAK and transition the buffer to the old/NAK state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.12 If the high speed handler for a transaction translator receives a complete split for a bulk transfer and has a non periodic buffer for the same endpoint and direction in the old/NAK state it must return NAK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.13 A transaction translator must correctly handle full speed bulk transfers in both directions of up to 64 bytes.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 5, 11.

  • Isochronous and Interrupt (Periodic) Transfers

    In the following assertions, the high-speed bus microframes are referenced as follows:

    | Y0 | Y1 | Y2 | Y3 | Y4 | Y5 Y6 | Y7 |

    Frame X-1 Frame X

    • 3.1.1 A transaction translator must be able to receive and correctly buffer up to 16 start splits for periodic transfers in a single microframe.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.4.

    • 3.1.2 When the high speed handler of a transaction translator receives a valid Start Split for a periodic transaction, it must place the start split into the start split pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.4.

      9.29.1.29 Isochronous Transaction Protocol Test, TD-9.29.1.30 Interrupt Transaction Loopback Test

    • 3.1.3 The high speed handler must accept and handle all valid Start Splits for periodic transfers received in any microframe except during microframe Y6.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.

    • 3.1.4 The transaction translator must not start any periodic transaction on the full/low speed bus during the same microframe the Start Split for that transaction arrived.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.

    • 3.1.5 The transaction translator (high speed handler) must never send any response packet to a periodic start split.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.

    • 3.1.6 The transaction translator (high speed handler) must place periodic start splits in the start split pipeline in the order in which they are received.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.3.

    • 3.1.7 The transaction translator (high speed handler) must execute periodic transactions on the full/low speed bus in the same order as the start splits in the microframe pipeline.

  • Abort Rules - Section 11.18.6.1

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.3.

    • 3.2.1 If a full or low speed periodic transaction is in progress when EOF occurs, it must be aborted by the transaction translator.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.

    • 3.2.2 If an interrupt transaction is in progress and the microframe timer indicates microframe X+4, where X is the microframe in which the start split for the transaction arrived, it must be aborted.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.

    • 3.2.3 If a periodic transaction is aborted it must not have a complete split response in the complete split stage pipeline. This means that the transaction translator will respond with a NYET to any Complete Splits for the transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.

    • 3.2.4 When a transaction translator aborts a periodic IN transaction, it must not issue the handshake packet for the transaction on the full/low speed bus.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.

    • 3.2.5 When a transaction translator aborts an OUT transaction and is in the middle of a DATA packet, it must stop issuing data bytes and force a bit stuffing error on the downstream facing bus.

  • Free Rules - Section 11.18.6.2

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.

    • 3.3.1 If a periodic start split received in microframe X has still not been executed when the microframe timer indicates the X+4 microframe it must be removed from the start split pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.2.

    • 3.3.2 All start splits in the start split pipeline for unexecuted transfers, except those received in microframe Y7 must be removed from the start split pipeline at the beginning of a new full speed frame.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.2.

    • 3.3.3 The entry for a transaction in the periodic Complete Split pipeline must only live for one microframe after the transaction is executed on the full/low speed bus. At the beginning of the second microframe after the execution the buffer space in the complete split transaction pipeline must be freed for re-use.

  • Complete-Split Pipeline Search Rules - Section 11.18.8

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.7.

    • 3.4.1 If the high speed handler for a transaction translator receives a periodic complete split that matches the first entry of the complete split pipeline the handler must respond with the indicated data and/or status.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.2 The high speed handler for a transaction translator receives a periodic complete split that matches the first entry in the complete split pipeline multiple times. In this case it must continue to respond with the indicated data and/or status until it receives a periodic complete split for a different transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.3 If the high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline it must search all other entries in the complete split pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.4 The high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline and does not find a match in the pipeline. In this case it must return the pipeline to its state at the start of the search and return NYET.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.5 If the high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline it must search all other entries. If it finds a match it must advance the pipeline to the matching transaction and free all entries it passes in the advance. It must return the status and/or data for the matching entry.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.6 If the high-speed handler receives a first periodic complete split for a transaction and has not finished searching the periodic complete split pipeline for a match, it must not respond to the complete split and continue to search for the match. It must respond correctly to the next complete split for the transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.7 The transaction translator must not start a periodic transaction until it has space available in the complete split pipeline stage to hold the results of the transaction.

  • Interrupt Transactions - Sections 11.20.x

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.3.

    • 3.5.1 A transaction translator must never locally retry an interrupt transfer on the full/low speed bus.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.

    • 3.5.2 If the high speed handler for a transaction translator receives a complete split for an interrupt transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/NAK state it must return NAK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.3 If the high speed handler for a transaction translator receives a complete split for an interrupt transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/STALL state it must return STALL.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.4 The high speed handler for a transaction translator receives a complete split for an interrupt transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/trans_err state it must return ERR.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.5 If the high speed handler for a transaction translator receives a complete split for an interrupt OUT transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/ACK state it must return ACK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.6 The high speed handler for a transaction translator receives a complete split for an interrupt IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/DATAX state it must return DATAX.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.7 The high speed handler for a transaction translator receives a complete split for an interrupt IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/MDATA state it must return MDATA.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.8 If the full/low speed CRC check fails, an ERR handshake must be returned to the host for the transaction by the transaction translator. No data can be returned for the current microframe.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.9 The full/low speed CRC must not be returned in response to a complete split for an interrupt IN transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.10 The full/low speed interrupt IN transaction is still in progress at a microframe boundary and at least 3 data bytes have been received. In this case, the transaction translator must update the appropriate complete split pipeline entry with the current data except the latest two bytes and place the entry in the old/MDATA state. It must not perform a full/low speed CRC check. The transaction translator is allowed to carry forward up to the last 6 bytes in the microframe (2 bytes for the potential CRC plus up to an additional 4 bytes).

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)

    • 3.5.11 The full/low speed interrupt IN transaction is still in progress at a microframe boundary and less than 3 data bytes have been received. In this case the transaction translator must return NYET to the corresponding complete split. The transaction translator may return NYET and carry forward up to the first 6 data bytes.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)

    • 3.5.12 A transaction translator returns MDATA for the complete split for an Interrupt IN. It must return the remaining data with the appropriate DATA0/1 PID or ERR if the CRC check fails in response to the next complete split for that endpoint and direction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4.

    • 3.5.13 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout in the Start Split - IN sequence for an interrupt IN transaction. In this case it must disregard the start split and not place it into the Start Split microframe pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.5.14 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout in the Start Split - OUT - DATA/X sequence for an interrupt OUT transaction. In this case it must disregard the start split and not place it into the Start Split microframe pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.5.15 If the full/low speed transaction completes before the end of a microframe (no matter how close to the end) the transaction translator must return all data in response to the complete split in the next microframe.

  • Isochronous Transactions - Sections 11.21.x

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.6.1 A transaction translator must never locally retry an isochronous transfer on the full/low speed bus.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.6.2 The high speed handler for a transaction translator receives a timeout, bit stuffing error, or CRC error in the Start Split-all - OUT - DATA sequence for an isochronous OUT. In this case it must disregard the start split and not attempt the transaction on the full/low speed bus.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.6.3 If the high speed handler for a transaction translator receives a timeout, bit stuffing, or CRC error anywhere in the Start Split-begin - OUT - DATA sequence for an isochronous OUT it must disregard the Start Split and not attempt the transaction on the full/low speed bus.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.4 The high speed handler receives an error or times out in the Start Split-begin - OUT - DATA sequence. In this case it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.5 The transaction translator must generate the full/low speed CRC for all Isochronous OUT transactions that it generates.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.6 If the transaction translator receives a Start Split-begin for an Isochronous OUT transaction it must start the transaction on the full/low speed bus and continue to look for isochronous OUT start splits to the same endpoint in each subsequent microframe.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.7 The transaction translator does not receive a Start Split-middle or Start Split-end in a successive microframe after receiving a Start Split-begin for an isochronous OUT endpoint. In this case, it must force a bit stuff error in full/low speed transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.8 The high speed handler does not receive a Start Split-middle or Start Split-end in an expected microframe. In this case it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.9 The transaction translator receives a Start Split-middle or Start Split-end with a bad CRC in a successive microframe after receiving a Start Split-begin for an isochronous OUT endpoint. In this case it must force a bit stuffing error on the full/low speed transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.10 If the high speed handler receives a Start Split-middle or Start Split-end with an error it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.11 The high speed handler receives a Start Split-middle or Start Split-end for an Isochronous OUT transaction and does not already have a full/low speed transaction pending for that endpoint. In this case, it must disregard that Start Split and any subsequent Start-Split middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.12 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout anywhere in the Start Split - IN sequence for an isochronous IN transaction it must disregard the start split and not place it into the Start Split microframe pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.6.13 The transaction translator must never return the full/low speed CRC as part of the data for an isochronous IN transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.4.

    • 3.6.14 The high speed handler for a transaction translator receives a complete split for an isochronous IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/DATAX state it must return DATAX.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.6.15 The high speed handler for a transaction translator receives a complete split for an isochronous IN transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/Trans_err state. It must return ERR.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.6.17 A full speed isochronous IN transaction is still in progress at a microframe boundary and at least three data bytes have been received. In this case, the transaction translator must update the appropriate complete split pipeline entry with the current data except the latest two bytes and place the entry in the old/MDATA state. It must not perform a full speed CRC check. The transaction translator is allowed to carry forward up to the last 6 bytes in the microframe (2 bytes for the potential CRC plus up to an additional 4 bytes).

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)

    • 3.6.18 A full speed isochronous IN transaction is still in progress at a microframe boundary and less than 3 data bytes have been received. The transaction translator must return NYET to the corresponding complete split. The transaction translator may return NYET and carry forward up to the first 6 data bytes.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)

    • 3.6.19 If the full/low speed transaction completes before the end of a microframe (no matter how close to the end) the transaction translator must return all data in response to the complete split in the next microframe.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.6.20 The TT high-speed handler must return isochronous data with the same data toggle used by the device. Alternately, the TT high speed handler may always use DATA0.

      Reference document: Universal Serial Bus Specification, Revision 2.0, proposed errata as of 3/29/02.

General Transaction Translator (HUB) Data Integrity

  • General Host Controller Interaction Assertions

    • 3.7.1 A USB 2.0 hub must not corrupt data moving from a host system to any USB device.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.

    • 3.7.2 A USB 2.0 hub must not corrupt data moving from any USB device into the host.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.

Transaction Translator Full/Low Speed Transaction Scheduling

  • Transaction Scheduling Assertions

    • 3.8.1 The transaction translator full/low speed handler must start executing the next periodic full/low speed transaction for the current microframe whenever it is idle.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.14.2.3.

    • 3.8.2 Whenever the transaction translator full/low speed handler is idle, and there are no periodic transactions available, it must execute an available non-periodic transaction selected in round robin fashion. It must only execute a non-periodic transaction if it can be finished before the end of the current full speed frame. For IN transactions this calculation must be made using the maximum transaction size.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.14.2.3.

Multiple Stream Interoperability

  • Transaction Scheduling Assertions

    • 3.9.1 The transaction translator must correctly process all valid combinations of periodic and non-periodic transactions running in unison.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.

    • 3.9.2 The transaction translator must correctly process all valid combinations of non-periodic transactions running in unison.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.

    • 3.9.3 The transaction translator must correctly process all valid combinations of periodic transactions running in unison.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.


USB Hub Compliance (CV) Test

Type: Automated Test

Overview

The USB Hub Compliance test verifies that the hub responds correctly to hub descriptor and remote wake requests. This test is based upon the USBCV compliance test tool provided by the USB-IF.

The USB hub provides additional connectivity for USB peripherals. The hub also provides power to attached peripherals, and recognizes dynamic attachment and removal of peripheral devices.

Details

This test verifies that the Universal Serial Bus (USB) hub complies with Chapter 11 of the Universal Serial Bus Specification Revision 2.0.

Setup

This test requires the test device to be connected through an intermediate USB 2.0 hub to the host system. This test fails if the test device is more than one hub deep. If the test machine has two USB controllers disable the controller that is not under test (or else the test fails).

Note

The USB Hub Compliance (CV) test requires a high-speed USB Enhanced Host Controller Interface (EHCI) controller.

For embedded USB Hubs with no Exposed Ports in which you cannot manually run this test, do the following:

  1. In DTM Studio, select the USB Hub Compliance (CV) Test job from the Available jobs pane in the Device Console.

  2. Click the Add Selected button on the Device Console. The selected job shows up in the bottom pane.

  3. Select this job from the bottom pane. Right-click this job and click Edit Parameters. You will see the Parameter Edit window open, with parameters listed on the left and their values on the right.

  4. Change this value of IsEmbeddedUSBDevice parameter from FALSE to TRUE.

  5. Click the Schedule Jobs button on the Device Console to run this job.

Note If the test hub is other than a high speed hub, this test fails. You can then manually overturn it.

Test case

The USB Hub Compliance test runs the following test cases:

  • TD-9.26.2.1 Detach Device From Enabled Port Test

  • TD-9.26.2.2 Detach Device From Suspended Port

  • TD-9.26.2.3 Disable The Enabled Port Test

  • TD-9.26.2.4 Hot Plug Device Port Test

  • TD-9.26.2.5 Power Off Suspended Port Test

  • TD-9.26.2.6 Power Off and On Port Test

  • TD-9.26.2.7 Remote Wakeup Port Test

  • TD-9.26.2.8 Reset Enabled Port With Device Connected Port Test

  • TD-9.26.2.9 Reset Disabled Port With Device Connected Port Test

  • TD-9.26.2.10 Reset Suspended Port Test

  • TD-9.26.2.11 Resume Port Test

  • TD-9.26.2.12 Suspend Port Test

  • TD-9.26.2.13 Suspend and Ignore Connect

  • TD-9.26.2.14 Suspend and Ignore Disconnect

  • TD-9.26.2.15 Suspend and Disconnect Device

  • TD-9.26.2.16 Suspend and Connect Device

  • TD-9.26.2.17 Suspend and Remote Wakeup

  • TD-9.26.2.18 Hub Descriptor Test

TD-9.26.2.1 Detach Device From Enabled Port Test

This test verifies that if a device is detached from an enabled hub port, the port status correctly shows a connect change and that port power is still set.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps:

  1. Enumerates the USB bus.

  2. Checks to verify that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the Clear Port Feature command.

  4. Issues a get port status request on each port and stores the initial port status values.

  5. Prompts you to disconnect the device from the test port.

  6. Checks the port status by running the Status Change Endpoint test.

  7. Issues a get port status command on the test port.

  8. Checks that the port state is as follows:
    • PORT_CONNECTIONMUST BE ZERO
    • PORT_ENABLEMUST BE ZERO
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDIGNORE
    • PORT_HIGH_SPEEDIGNORE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE SET
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  9. Issues a get port status request on all non-test ports.

  10. Verifies that there were no changes in the port status on any of the non-test ports.

  11. Repeats Steps 1 through 10 with the remaining ports that have not been tested.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid Clear Port Feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the port under test does not change as described.

TD-9.26.2.2 Detach Device From Suspended Port

This test verifies that if a device is detached from a suspended hub port, the port status correctly shows a connect change and that port power is still set.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Checks to verify that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the Clear Port Feature command.

  4. Issues a get port status request on each port and stores the initial port status values.

  5. Issues a set port feature request to suspend the port.

  6. Issues a get port status command to the port under test to verify it is suspended and continues making calls until suspend is indicated or one second elapses.

  7. Prompts you to disconnect the device from the test port.

  8. Checks the port status by running the Status Change Endpoint test.

  9. Issues a get port status command on the test port.

  10. Checks that the test port state is as follows:
    • PORT_CONNECTIONMUST BE ZERO
    • PORT_ENABLEMUST BE ZERO
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDIGNORE
    • PORT_HIGH_SPEEDIGNORE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE SET
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  11. Calls get port status on all non-test ports.

  12. Verifies that there were no changes in the port status on any of the non-test ports.

  13. Repeats Steps 1 through 12 with each of the remaining ports.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid Clear Port Feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the port under test does not change as described.

  • A valid set port feature request does not suspend the test port.

TD-9.26.2.3 Disable the Enabled Port Test

This test verifies that if an enabled port is programmatically disabled, no port change bits are set. The test also verifies that the connect and power status bits remain set.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Checks to verify that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature command.

  4. Issues a get port status request on each port and stores the initial port status values.

  5. Issues a clear port feature command with feature selector PORT_ENABLE to disable the port under test.

  6. Issues a get port status command on the test port.

  7. Checks that the port under test state is as follows:
    • PORT_CONNECTIONMUST BE ZERO
    • PORT_ENABLEMUST BE ZERO
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDMUST NOT CHANGE
    • PORT_HIGH_SPEEDMUST NOT CHANGE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  8. Calls the get port status requests on all non-test ports.

  9. Verifies that there were no changes in the port status on any of the non-test ports.

  10. Repeats Steps 1 through 9 with each of the remaining ports.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the port under test does not change as described.

TD-9.26.2.4 Hot Plug Device Port Test

This test verifies that when you connect a device to a port of the test hub, the status bits in the port are updated appropriately.

Starting Configuration

Test Port: No DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature command.

  4. Calls get port status on each port and stores the initial port status values.

  5. Prompts you to connect a device to the test port.

  6. Checks the port status by running the Status Change Endpoint test.

  7. Issues a get port status command on the port under test.

  8. Checks that the test port is configured as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ENABLEMUST BE ZERO
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDIGNORE
    • PORT_HIGH_SPEEDIGNORE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE SET
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  9. Calls get port status on all non-test ports.

  10. Verifies that there were no changes in the port status on any of the non-test ports.

  11. Repeats Steps 1 through 10 with each of the remaining ports.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the port under test does not change as described.

TD-9.26.2.5 Power Off Suspended Port Test

This test verifies that if a suspended port is powered off, the port correctly indicates all zeros for the port status.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature command.

  4. Issues a get port status request on each port and stores the initial port status values.

  5. Issues a set port feature command with feature selector PORT_SUSPEND.

  6. Issues a get port status command on the port under test. Continues making calls until suspend is indicated or 1 second has elapsed.

  7. Checks that the port status for the port under test is as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ENABLEIGNORE
    • PORT_SUSPENDMUST BE SET
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDIGNORE
    • PORT_HIGH_SPEEDIGNORE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  8. Issues a clear port feature command with feature selector PORT_POWER.

  9. Issues a get port status command on the test port.

  10. Checks that the state of the test port is as follows:
    • PORT_CONNECTIONIGNORE
    • PORT_ENABLEIGNORE
    • PORT_SUSPENDIGNORE
    • PORT_OVER_CURRENTIGNORE
    • PORT_RESETIGNORE
    • PORT_POWERMUST BE ZERO
    • PORT_LOW_SPEEDIGNORE
    • PORT_HIGH_SPEEDIGNORE
    • PORT_TESTIGNORE
    • PORT_INDICATORIGNORE
    • C_PORT_CONNECTIONIGNORE
    • C_PORT_ENABLEIGNORE
    • C_PORT_SUSPENDIGNORE
    • C_PORT_OVER_CURRENTIGNORE
    • C_PORT_RESETIGNORE

  11. Issues a get port status request on all non-test ports.

  12. Verifies that there were no changes in the port status on any of the non-test ports.

  13. Repeats Steps 1 through 12 with each of the remaining ports.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the port under test does not change as described.

TD-9.26.2.6 Power Off and On Port Test

This test verifies that a hub reports the port status correctly when the power to the port is turned on and off with and without devices connected.

Starting Configuration

Test Port: Any Device/No DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature command.

  4. Issues a get port status request on each port and stores the initial port status values.

  5. Issues a clear port feature command with feature selector PORT_POWER.

  6. Issues a get port status command to the test port.

  7. Checks that the port status for the test port is configured as follows:
    • PORT_CONNECTIONIGNORE
    • PORT_ENABLEIGNORE
    • PORT_SUSPENDIGNORE
    • PORT_OVER_CURRENTIGNORE
    • PORT_RESETIGNORE
    • PORT_POWERMUST BE ZERO
    • PORT_LOW_SPEEDIGNORE
    • PORT_HIGH_SPEEDIGNORE
    • PORT_TESTIGNORE
    • PORT_INDICATORIGNORE
    • C_PORT_CONNECTIONIGNORE
    • C_PORT_ENABLEIGNORE
    • C_PORT_SUSPENDIGNORE
    • C_PORT_OVER_CURRENTIGNORE
    • C_PORT_RESETIGNORE

  8. Issues a set port feature command with feature selector PORT_POWER.

  9. Checks the port status by running the Status Change Endpoint test.

  10. Issues a get port status command for the test port.

  11. Checks that the state of the test port is as follows:
    • PORT_CONNECTION SET (if device on test port)
    • PORT_ENABLEMUST BE ZERO
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDMUST NOT CHANGE (Step 2)
    • PORT_HIGH_SPEEDMUST NOT CHANGE (Step 2)
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE SET (if device)
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  12. Sends a get port status to all non-test ports.

  13. Verifies that there were no changes in the port status on any of the non-test ports.

  14. Repeats Steps 1 through 13 with each of the remaining ports, with and without a device on the test port.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the test port does not change as described.

TD-9.26.2.7 Remote Wakeup Port Test

This test verifies that if a device connected to a port of the test hub issues a remote wakeup, the port status is updated appropriately.

Starting Configuration

Test Port: Remote Wakeup Capable DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature command.

  4. Calls get port status on each port and stores the initial port status values.

  5. Issues a set port feature command with feature selector PORT_SUSPEND to suspend the test port.

  6. Sends a get port status command to the test port, and continues issuing calls until suspend is indicated or until one second has elapsed.

  7. Checks the test port state as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ ENABLEIGNORE
    • PORT_SUSPENDMUST BE SET
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDIGNORE
    • PORT_HIGH_SPEEDIGNORE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  8. Prompts you to issue a remote wakeup on the device attached to the test port.

  9. Checks the port status by running the Status Change Endpoint test.

  10. Issues a get port status command on the test port.

  11. Checks the state of the test port as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ENABLEMUST BE SET
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_ SPEEDMUST NOT CHANGE
    • PORT_HIGH_ SPEEDMUST NOT CHANGE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE SET
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  12. Verifies that there were no changes in the port status on any of the non-test ports.

  13. Repeats Steps 1 through 12 with each of the remaining ports.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the port under test does not change as described.

TD-9.26.2.8 Reset Enabled Port With Device Connected Port Test

This test verifies that if a device is connected to a port of the hub under test, the status bits in the port are updated appropriately when a port reset is performed.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature command.

  4. Calls get port status on each port and stores the initial port status values.

  5. Issues a set port feature command with feature selector PORT_RESET for the test port.

  6. Checks the port status by running the Status Change Endpoint test.

  7. Issues a get port status command to the test port.

  8. Checks that the port under test state is as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ENABLEMUST BE SET
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_ SPEEDMUST NOT CHANGE
    • PORT_HIGH_ SPEEDMUST NOT CHANGE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE SET

  9. Calls get port status for all non-test ports.

  10. Verifies that there were no changes in the port status on any of the non-test ports.

  11. Repeats Steps 1 through 10 with each of the remaining ports.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the port under test does not change as described

TD-9.26.2.9 Reset Disabled Port With Device Connected Port Test

This test verifies that if a device is connected to a disabled port of the hub under test, the status bits in the port are updated appropriately when a port reset is performed.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature command.

  4. Calls get port status on each port and stores the initial port status values.

  5. Issues a clear port feature command with feature selector PORT_ENABLE for the test port.

  6. Issues a get port status command on the test port.

  7. Checks the state of the port as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ENABLEMUST BE ZERO
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_ SPEEDMUST NOT CHANGE
    • PORT_HIGH_ SPEEDMUST NOT CHANGE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE SET
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  8. Issues a set port feature command with feature selector PORT_RESET for the test port.

  9. Checks the port status by running the Status Change Endpoint test.

  10. Issues a get port status command on the test port.

  11. Checks that the port under test state is as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ENABLEMUST BE SET
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_ SPEEDMUST NOT CHANGE
    • PORT_HIGH_ SPEEDMUST NOT CHANGE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE SET

  12. Calls get port status on all non-test ports.

  13. Verifies that there were no changes in the port status on any of the non-test ports.

  14. Repeats Steps 1 through 13 with each of the remaining ports.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the test port does not change as described.

TD-9.26.2.10 Reset Suspended Port Test

This test verifies that if a device is connected to a suspended port of the test hub, the status bits in the port are updated appropriately when a port reset is performed.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature command.

  4. Calls get port status on each port and stores the initial port status values.

  5. Issues a set port feature command with feature selector PORT_SUSPEND for the test port.

  6. Issues a get port status command on the test port. The test continues to send get port status requests until suspend is indicated or until one second has elapsed.

  7. Checks that the port state is as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ ENABLEIGNORE
    • PORT_SUSPENDMUST BE SET
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_ SPEEDMUST NOT CHANGE
    • PORT_HIGH_ SPEEDMUST NOT CHANGE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  8. Issues a set port feature command with feature selector PORT_RESET for the test port.

  9. Checks the port status by running the Status Change Endpoint test.

  10. Issues a get port status command on the test port.

  11. Checks that the port state is as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ENABLEMUST BE SET
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_ SPEEDMUST NOT CHANGE
    • PORT_HIGH_ SPEEDMUST NOT CHANGE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE SET

  12. Calls get port status on all non-test ports.

  13. Verifies that there were no changes in the port status on any of the non-test ports.

  14. Repeats Steps 1 through 13 with each of the remaining ports.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the port under test does not change as described.

TD-9.26.2.11 Resume Port Test

This test verifies that if a device is connected to a suspended port of the hub, the status bits in the port are updated appropriately when a port resume is performed.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using Get port status.

  3. Clears all port change bits using the clear port feature command.

  4. Issues get port status requests on each port and stores the initial port status values.

  5. ssues a set port feature request with feature selector PORT_SUSPEND for the test port.

  6. Issues a get port status command on the test port, and then continues to send get port status requests until suspend is indicated or one second has elapsed.

  7. Checks that the port state is as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ ENABLEIGNORE
    • PORT_SUSPENDMUST BE SET
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_ SPEEDMUST NOT CHANGE
    • PORT_HIGH_ SPEEDMUST NOT CHANGE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  8. Delays for one second to ensure the suspend operation has completed.

  9. Issues a clear port feature request with feature selector PORT_SUSPEND for the test port.

  10. Checks the port status by running the Status Change Endpoint test.

  11. Issues a get port status request on the test port, and then continues to send get port status requests until suspend is cleared or one second has passed.

  12. Checks that the port state is as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ENABLEMUST BE SET
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_ SPEEDMUST NOT CHANGE
    • PORT_HIGH_ SPEEDMUST NOT CHANGE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE SET
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE SET

  13. Calls get port status on all non-test ports.

  14. Verifies that there were no changes in the port status on any of the non-test ports.

  15. Repeats Steps 1 through 14 with each of the remaining ports.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the test port does not change as described.

TD-9.26.2.12 Suspend Port Test

This test verifies that a hub correctly responds to a suspend port request.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature request.

  4. Calls get port status on each port and stores the initial port status values.

  5. Issues a set port feature request with feature selector PORT_SUSPEND for the test port.

  6. Issues a get port status request on the test port, and then continues to send get port status requests until suspend is indicated or one second has elapsed.

  7. Checks that the port state is as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ ENABLEIGNORE
    • PORT_SUSPENDMUST BE SET
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_ SPEEDMUST NOT CHANGE
    • PORT_HIGH_ SPEEDMUST NOT CHANGE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  8. Calls get port status on all non-test ports.

  9. Verifies that there were no changes in the port status on any of the non-test ports.

  10. Repeats Steps 1 through 9 with each of the remaining ports.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the test port does not change as described.

TD-9.26.2.13 Suspend and Ignore Connect

This test disables remote wakeup for the hub and verifies that the hub correctly ignores connect events when it is suspended.

Starting Configuration

Test Port: No DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature request.

  4. Calls get port status on each port and stores the initial port status values.

  5. Issues the clear feature request with feature selector DEVICE_REMOTE_WAKEUP to disable remote wakeup for the test hub.

  6. Suspends the parent port for the test hub.

  7. Gets the port status of the parent port of the hub to verify that the suspended state has occurred. The test continues to send get port status requests to the parent port until suspend is indicated or one second has elapsed.

  8. Prompts you to connect a device to the test port.

  9. Verifies the parent port of the hub is still suspended.

  10. Issues a clear port feature request with feature selector PORT_SUSPEND to the parent port of the hub.

  11. Reads the status change endpoint of the test hub.

  12. Verifies that the hub reports a status change only on the test port.

  13. Issues a get port status request for the test port.

  14. Checks that the port state is as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ ENABLEMUST BE ZERO
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDIGNORE
    • PORT_HIGH_SPEEDIGNORE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE SET
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  15. Calls get port status on all non-test ports.

  16. Verifies that there were no changes in the port status on any of the non-test ports.

  17. Repeats Steps 1 through 16 with each of the remaining ports. The test is also repeated with the non-test ports initially having a device connected (GROUP).

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the test port does not change as described.

  • A valid clear feature request is not accepted.

TD-9.26.2.14 Suspend and Ignore Disconnect

This test disables remote wakeup for the hub under test and verifies that the hub correctly ignores disconnect events when it is suspended.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature request.

  4. Calls get port status on each port and stores the initial port status values.

  5. Issues the clear feature request with feature selector DEVICE_REMOTE_WAKEUP to disable remote wakeup for the test hub.

  6. Suspends the parent port for the test hub.

  7. Issues a get port status request for the parent port to verify the suspended state occurred. The test continues to send get port status requests to the parent port of the hub until suspend is indicated or one second has elapsed.

  8. Prompts you to disconnect the device from the test port.

  9. Checks the parent port of the hub to make sure it is still suspended.

  10. Issues a clear port feature with feature selector PORT_SUSPEND to the parent port of the hub.

  11. Reads the status change endpoint of the hub.

  12. Verifies that the hub reports a status change only on the test port.

  13. Issues a get port status request for the test port.

  14. Checks that the port state is as follows:
    • PORT_CONNECTIONMUST BE ZERO
    • PORT_ ENABLEMUST BE ZERO
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDIGNORE
    • PORT_HIGH_SPEEDIGNORE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE SET
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  15. Calls get port status on all non-test ports.

  16. Verifies that there were no changes in the port status on any of the non-test ports.

  17. Repeats Steps 1 through 16 with each of the remaining ports. The test is also repeated with the non-test ports initially having a device connected (GROUP).

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the port under test does not change as described.

  • A valid clear feature request is not accepted.

TD-9.26.2.15 Suspend and Disconnect Device

This test suspends the hub under test and verifies that a remote wakeup occurs when a device is disconnected from the hub under test.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature request.

  4. Calls get port status on each port and stores the initial port status values.

  5. Issues the set feature request with feature selector DEVICE_REMOTE_WAKEUP to enable remote wakeup for the test hub.

  6. Suspends the parent port for the test hub.

  7. Issues a get port status request for the parent port to verify the suspended state occurred. The test continues to send get port status requests to the parent port of the hub until suspend is indicated or one second has elapsed.

  8. Prompts you to disconnect the device from the test port.

  9. Polls the status of the parent port of the hub until it is no longer suspended.

  10. Checks the port status by running the Status Change Endpoint test.

  11. Issues a get port status request for the test port.

  12. Checks that the port state is as follows:
    • PORT_CONNECTIONMUST BE ZERO
    • PORT_ ENABLEMUST BE ZERO
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDIGNORE
    • PORT_HIGH_SPEEDIGNORE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE SET
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  13. Calls get port status on all non-test ports.

  14. Verifies that there were no changes in the port status on any of the non-test ports.

  15. Repeats Steps 1 through 14 with each port of the remaining ports. The test is also repeated with the non-test ports initially having a device connected (GROUP).

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the test port does not change as described.

  • A valid clear feature request is not accepted.

TD-9.26.2.16 Suspend and Connect Device

This test suspends the hub and verifies that a remote wakeup occurs when a device is connected to the hub.

Starting Configuration

Test Port: Any DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature request.

  4. Calls get port status on each port and stores the initial port status values.

  5. Issues the set feature request with feature selector DEVICE_REMOTE_WAKEUP to enable remote wakeup for the test hub.

  6. Suspends the parent port for the test hub.

  7. Issues a get port status request for the parent port to verify the suspended state occurred. The test continues to send get port status requests to the parent port of the hub until suspend is indicated or one second has elapsed.

  8. Prompts you to connect the device to the test port.

  9. Polls the status of the parent port of the hub until it is no longer suspended.

  10. Checks the port status by running the Status Change Endpoint test.

  11. Verifies that the hub reports a status change only on the test port.

  12. Issues a get port status request for the port.

  13. Checks that the port state is as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ ENABLEMUST BE ZERO
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDIGNORE
    • PORT_HIGH_SPEEDIGNORE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE SET
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE ZERO
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  14. Calls get port status on all non-test ports.

  15. Verifies that there were no changes in the port status on any of the non-test ports.

  16. Repeats Steps 1 through 15 with each port of the remaining ports. The test is also repeated with the non-test ports initially having a device connected (GROUP).

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the test port does not change as described.

  • A valid clear feature request is not accepted.

  • A remote wakeup is not produced by the hub under test in response to a connect event.

TD-9.26.2.17 Suspend and Remote Wakeup

This test suspends the hub under test and verifies that a remote wakeup occurs when a remote wakeup is initiated from a downstream device connected to the hub.

Starting Configuration

Test Port: Remote Wakeup Capable DevicePort Enabled

Other Ports: No DevicePort Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.

  2. Verifies that the ports are in the proper starting configuration using get port status.

  3. Clears all port change bits using the clear port feature request.

  4. Calls get port status on each port and stores the initial port status values.

  5. Issues the set feature request with feature selector DEVICE_REMOTE_WAKEUP to enable remote wakeup for the test hub.

  6. Suspends the parent port for the test hub.

  7. Issues a get port status request for the parent port to verify the suspended state occurred. The test continues to send get port status requests to the parent port of the hub until suspend is indicated or one second has elapsed.

  8. Prompts you to initiate a remote wakeup from the device on the port.

  9. Polls the status of the parent port of the hub until it is no longer suspended.

  10. Checks the port status by running the Status Change Endpoint test.

  11. Issues a get port status request for the port.

  12. Checks that the port state is as follows:
    • PORT_CONNECTIONMUST BE SET
    • PORT_ENABLEMUST BE SET
    • PORT_SUSPENDMUST BE ZERO
    • PORT_OVER_CURRENTMUST BE ZERO
    • PORT_RESETMUST BE ZERO
    • PORT_POWERMUST BE SET
    • PORT_LOW_SPEEDMUST NOT CHANGE
    • PORT_HIGH_SPEEDMUST NOT CHANGE
    • PORT_TESTMUST BE ZERO
    • PORT_INDICATORMUST BE ZERO
    • C_PORT_CONNECTIONMUST BE ZERO
    • C_PORT_ENABLEMUST BE ZERO
    • C_PORT_SUSPENDMUST BE SET
    • C_PORT_OVER_CURRENTMUST BE ZERO
    • C_PORT_RESETMUST BE ZERO

  13. Calls get port status on all non-test ports.

  14. Verifies that there were no changes in the port status on any of the non-test ports.

  15. Repeats Steps 1 through 14 with each port of the remaining ports. The test is also repeated with the non-test ports initially having a device connected (GROUP).

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Valid get port status requests fail for any reason.

  • Valid clear port feature requests fail for any reason.

  • A known good device fails to enumerate for any reason.

  • Any port status bits change on the non-test ports during the course of the test.

  • The port status for the port under test does not change as described.

  • A valid clear feature request is not accepted.

  • A remote wakeup is not produced by the hub under test in response to a connect event.

TD-9.26.2.18 Hub Descriptor Test

This test verifies that the test device responds to valid get hub descriptor request and returns a descriptor in compliance with the specification.

Device States For Test

This test is run with the device in the Configured state.

Overview

The test performs the following steps.

  1. Issues a valid get configuration descriptor request with a requested length of 9 bytes.

  2. Issues a valid set configuration request with the bConfiguration value from the configuration descriptor.

  3. Issues a valid get hub descriptor request with a requested length of 9 bytes.

  4. Performs the following checks on the device descriptor value:

    bLength == 9 (Note: If the bNbrPorts field is > 7, the length must be longer).

    If bLength > 9, the get hub descriptor is issued again with the indicated length.

    bDescriptorType == HUB descriptor type.

    If wHubCharacteristics D2 == 1, the Device Removable bitmask must have at least one bit set.

    wHubCharacterstics D0 to D1 == (00 or 01).

    wHubCharacteristics D3 to D4 == (00 or 01).

    If wHubCharacteristics D3 to D4 != (00 or 01), issue a Get Status request to the hub. (The status must indicate bus powered).

    If bcdUSB.hibyte < 2, wHubCharateristics D5 to D7 == 0

    wHubCharacteristics D8 t o D15 == 0.

    Bit zero in the DeivceRemovableBitMask must be zero. The remaining bits are checked against the user-supplied information on non-accessible ports.

    All bits in the PortPwrCtrlMask must be one.

    The bHubContrCurrent must be <= 100 mA for self-powered hubs.

  5. If the hub supports multiple configurations, repeat the test for each possible configuration.

  6. If the hub is a high-speed capable device, the test must be run with the hub in both high-speed and full-speed operation.

Results Interpretation

The test creates a log file that shows whether the test passed or failed.

The test fails if:

  • Device enumeration fails following the method described in this specification.

  • Valid get descriptor requests fail for any reason.

  • Valid set address requests fail for any reason.

  • Valid set configuration requests fail for any reason.

  • Valid get configuration requests fail for any reason.

  • Any of the hub descriptor content checks fail.

Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller.
  • One USB 1.1 or 2.0 hub (different from the test hub). If the test USB 2.0 hub is high-speed, the additional USB 2.0 hub must also be high-speed. The hub should be USB IF certified.
  • Various USB devices. The number of required USB devices varies. Connect a USB device to every available port on the test USB hub.
Processor
  • x86
  • x64
  • Itanium

Troubleshooting

The following list describes the USB Hub Compliance (CV) Test Assertions. These test assertions are tested in the TD-9.26 USB Hub Compliance (CV) Test.

  • Hub General Command Assertions

    • 2.1.1 Hubs must support Get_Port_Status requests on all ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 2.1.2 Hubs must support Clear_Port_Feature(PortPower) requests on all ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.

    • 2.1.3 Hubs must support Set_Port_Feature(PortPower) requests on all ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 2.1.4 Hubs must support Set_Port_Feature(Suspend) requests on all ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 2.1.5 Hubs must support Clear_Port_Feature(Enabled) requests on all ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.

    • 2.1.6 Hubs must support Set_Feature(RemoteWakeup) requests.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 2.1.7 Hubs must support Clear_Feature(RemoteWakeup) requests.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.

    • 2.1.8 Hubs must support Set_Port_Feature(Reset&Enable) requests on all ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 2.1.9 Hubs must support Clear_Port_Feature(C_PORT_RESET) requests on all ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.

    • 2.1.10 Hubs must support Clear_Port_Feature(Suspend) requests on all ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.

    • 2.1.11 Hubs must support a GetDescriptor(HUB_Descriptor) request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.5.

  • Hub Port Status Change Assertions

    • 2.2.1 The state of Hub ports that are suspended, disconnected or enabled must not change when an event (connect, disconnect, suspend, resume, or remote wakeup) happens on another port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 2.2.2 After receiving a Clear_Port_Feature(PortPower), a hub port's status must show "not powered."

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 2.2.3 After receiving a Set_Port_Feature(PortPower), a hub port's status must show "powered."

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.

    • 2.2.4 After receiving a Set_Port_Feature(Suspend), a hub port's status must show "suspended."

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 2.2.5 After receiving a Clear_Port_Feature(Enable), a hub port's status must show "not enabled."

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 2.2.6 After notification that a Reset&Enable request is complete, a hub port's status must show "enabled."

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 2.2.7 After notification that a Host-Initiated Resume request is complete, a hub port's status must show "enabled."

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 2.2.20 After a Disconnect Event on an enabled port, the hub port status must indicate Not Connected, Not Enabled, Not Suspended, Not OverCurrent, Not Reset, and Powered and the port change status must indicate Connect change, No Suspend change, No Overcurrent change, and No Reset change.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 2.2.21 After a Disconnect Event on a suspended port, the hub port status must indicate Not Connected, Not Enabled, Not Suspended, Not OverCurrent, Not Reset, and Powered and the port change status must indicate Connect change, No Suspend change, No Overcurrent change, and No Reset change.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 2.2.22 After a Connect Event on a port, the hub port status must indicate. Connected, Not Enabled, Not Suspended, Not OverCurrent, Not Reset, and Powered and the port change status must indicate Connect change, No Enable/Disable change, No Suspend change, No Overcurrent change, and No Reset change.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 2.2.23 After a Remote Wakeup Event on a suspended port, the hub port status must indicate Connected, Enabled, Not Suspended, Not OverCurrent, Not Reset, and Powered and the port change status must indicate No Connect change, No Enable/Disable change, Suspend change, No Overcurrent change, and No Reset change.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.

    • 2.2.40 Hub port events that cause a hub port change bit to transition from a zero to a one (connect, disconnect, reset complete, resume complete) must cause the appropriate notification data to be sent to the host at the next poll of the hub's change notification pipe.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.4.

    • 2.2.41 Data returned from a hub's change notification pipe must indicate which ports had a change in status.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.4.

    • 2.2.60 A suspended hub that is not enabled for remote wakeup must not signal remote wakeup when a connect or disconnect happens on one of its ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.1.

    • 2.2.61 A suspended hub that is enabled for remote wakeup must signal remote wakeup when a connect or disconnect happens on one of its ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.

    • 2.2.62 A suspended hub that is enabled for remote wakeup must propagate remote wakeup from downstream ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.

  • Hub Descriptor Assertions

    • 2.3.1 The descriptor returned in response to a GetDescriptor(Hub_Descriptor) request must have the value of 0x29 in the bDescriptorType field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.

    • 2.3.2 The descriptor returned in response to a GetDescriptor(Hub_Descriptor) request must have a value of 0x0 or 0x1 in the Logical Power Switching Mode subfield of the wHubCharacteristics field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.

    • 2.3.3 Self-powered Hubs MUST provide Over-Current Protection.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.

    • 2.3.4 Reserved bits in the Hub Descriptor must read as zeros.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.

    • 2.3.5 Bit 0 of the Device Removable bitmask is reserved and must read as a zero.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.

    • 2.3.6 All bits in the Hub Descriptors' PortPwrCtrlMask field must be 1's.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.

    • 2.3.7 The value in the bHubContrCurrent field must not exceed 100mA (0x64).

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.


USB-IF Test Certification ID Check

Type: Automated Test

Overview

This test checks the USB-IF test ID provided after passing the USB-IF test. For more information on how to obtain this, visit the following Microsoft Web site: http://www.microsoft.com/whdc/connect/usb/WLK_USB-IF_CertReq.mspx

Details

This test collects the USB-IF test ID (TID) from the user at the time of scheduling the test as part of the editable parameters. If no test ID is entered, the test will fail.

To enter the USB-IF TID, follow these steps:

  1. In the Device Console, select USB-IF Test Certification ID Check from the Available Jobs list. Screen shot of the Device Console with USB-IF Test Certification ID Check from the Available Jobs list selected

  2. Right-click the job and select Edit Parameters. Screen shot of the Device Console with Edit Parameters selected

  3. Select OK.

    Screen shot of the Parameters dialog box with the test ID circled

  4. Schedule the job normally.

    This test ID will now be applied each time the test is scheduled for the submission.

Run Time: 1 minute
Log File: USBtidCheck.xml
System Restart Required: No
Test Category: USB_Connectivity
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: USBtidCheck.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Command Syntax

Command option | Description
USBtidCheck.exe | Without any options, the test will fail.
-d [VID]/[PID] | Use VID/PID combination if running this test for a device. Do not use this option if running for a USB Host Controller.
-i [TESTID] | 0

Code Tour

File Manifest

File | Location
USBtidCheck.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\logokit


USB Isochronous Alternate Interface Presence

Type: Automated Test

Overview

This test verifies that when any device has an interface that consumes isochronous bandwidth, that device supports multiple alternate settings for that interface. In addition, the alternate setting zero does not consume isochronous bandwidth. The requirement for alternate setting zero can be provided by an interface that has no endpoints, an interface with isochronous endpoints that do not carry a payload, or an alternate interface that has non-isochronous endpoints. The test software looks for these capabilities by recursively examining the configurations, interfaces, and endpoints that a device supports.

Details

Overview of Test Steps

The USB peripheral device must be attached to a port on the root hub. The test software places the ports on the root hub in the powered on state. The test software then places the port in the enabled state and communication with the target device is initiated. A get descriptor request is issued to the target device. The number of configurations supported by the device is returned in the field bNumConfigurations. The number of configurations is stored by the test software to be used to drive an iterative examination of all configurations. For each device configuration, a get configuration request is issued to the target device. The number of interfaces supported by the configuration is returned in the field bNumInterfaces. The descriptor for the interfaces and endpoints for those interfaces are returned in the body of the configuration descriptor.

The interface descriptors for a configuration are parsed using the bInterfaceNumber and bAlternateSetting fields as keys. Groups of alternative interfaces share the same bInterfaceNumber field with incrementing bAlternateSetting fields. For each interface with the bAlternateSetting field equal to zero and the bNumEndpoints field greater than zero, the endpoint descriptors are parsed. The bmAttributes of the endpoint descriptor are examined to determine whether the endpoint is using an isochronous transfer type. If the transfer type is isochronous, the wMaxPacketSize is examined. If the wMaxPacketSize is greater than zero, the device is consuming isochronous bandwidth inappropriately and it does not meet the Windows Logo Program requirement (B2.6.4.4.2). The interface is appropriately flagged as out of compliance. If the transfer type is isochronous with a wMaxPacketSize equal to zero or is not isochronous, the interface is in compliance.

If an isochronous interface has a descriptor with bAlternateSetting of one or greater, the interface provides multiple alternate settings and is in compliance with the Windows Logo Program requirements.

Results Interpretation

If the connected device does not support isochronous transfer type, the test is skipped and reports the results as pass.

Individual pass/fail indication is provided for each test category of USB peripheral device support for the power management requirements.

The following conditions cause test failures:

  • Alternate interface zero consumes isochronous bandwidth.

  • An interface supported by the device consumes isochronous bandwidth and does not provide more than one alternate setting.

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • The system must be configured with a USB host controller that is compliant with Universal Serial Bus Specification 1.1 and Windows Logo Program requirements.
Processor
  • x86
  • x64
  • Itanium

Troubleshooting

  • 9.1.11 Devices and drivers support maximum flexibility of hardware interface options.

    Reference documents: WLP# - B2.6.4.4; PC 99 System Design Guide - 7.5

  • 9.1.12 Devices and drivers must provide multiple alternate settings for interfaces with endpoints that consume isochronous bandwidth.

    Reference documents: WLP# - B2.6.4.4, PC 99 System Design Guide - 7.5.1

  • 9.1.13 Devices and drivers must not use isochronous bandwidth in alternate setting zero of interfaces that use isochronous bandwidth.

    Reference documents: WLP# - B2.6.4.4, PC 99 System Design Guide - 7.5.2


USB Selective Suspend

Type: Automated Test

Overview

This test is designed to test the selective suspend abilities of the USB. This feature allows a device's port to be suspended when the device is not in use in order to conserve power. To properly support this new feature, a device must maintain its internal state when its upstream port has been suspended and be able to function correctly when its upstream port is resumed. This test will ensure that devices respond appropriately on its control pipe at its currently assigned device address following the suspend/resume cycle of a port. Depending on the class of the device, additional steps may be performed to ensure that the device responds correctly on other endpoints. This test runs only on devices and hubs.

Details

This test requires the test device to be connected through an intermediate USB 2.0 hub to the host system. This test fails if the test device is more than one hub deep.

Note: For embedded USB devices (for example, laptop devices) where it is impossible to meet the external hub connectivity requirement, you must follow the following steps:

  1. Select the job USB Selective Suspend (Automated) from the Available jobs pane in the Device Console.

  2. Click the Add Selected button on the Device Console. The selected job shows up in the bottom pane.

  3. Select this job from the bottom pane. Right-click the job and select Edit Parameters. You will see the Parameter Edit window open, with parameters listed on the left and their values on the right.

  4. Change this value of the IsEmbeddedUSBDevice parameter from FALSE to TRUE.

  5. Click the Schedule Jobs button on the Device Console to run this job.

Results Interpretation

The test fails if:

  • A device fails to respond correctly on its control pipe following the suspend/resume cycle.

  • A device fails to respond correctly on any other endpoints in its current configuration following the suspend/resume cycle.

Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • One four-port USB hub for use as a self-powered hub. This hub must comply with the Universal Serial Bus Specification, Revision 1.1 and support the suspension of a port.
  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller.
Processor
  • x86
  • x64
  • Itanium

Troubleshooting

9.20.1 When suspended, the USB device maintains any internal status including its address and configuration.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.6

9.20.2 Attached devices must be prepared to be suspended at any time that they are powered, whether they have been assigned a non-default address or are configured.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.6

9.20.3 A USB device exits suspend mode when there is bus activity.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.6

9.20.4 After a port is resumed, a device attached to that port must respond to data transfers within 10ms of the resume signaling.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.2

9.20.6 After the bus is initialized, the test must find an appropriate USB test device. The device is appropriate if it does not have more than one external hub between it and the host. The device and the hub must be running at the highest speed the device is capable of operating.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.2

9.20.7 After the USB device is initialized, the device must be accessible using any device address from 1 to 127.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.2


USB Self-powered Hub

Type: Automated Test

Overview

The test queries all non-root USB hubs in the system to determine whether they are bus-powered or self-powered. This includes both USB hubs that are used internally in the system and USB hubs that are supplied externally as part of the system. Every hub in the system that is not part of an integrated keyboard device or integrated into a mobile system is required to be self-powered. The test enumerates the USB bus through the USB software stack. Each hub in the system is queried to determine whether it is bus-powered or self powered. If a bus-powered hub is found that is not part of an integrated keyboard device or integrated into a mobile system, the test fails.

Details

The test enumerates the USB bus through the USB software stack to find all of the non-root USB hubs in the system. To locate the hubs, the test software issues a get descriptor request to each device in the system. The following field is examined to determine if the device is a hub:

Offset | Field | Description
1 | bDescriptorType | 29h indicates a hub descriptor

The test queries the USB hubs through the USB software stack to determine whether they are bus-powered or self-powered. The test software issues get descriptor configuration requests to get the configured capabilities of the hubs. The following fields are returned and examined:

Offset | Field | Description
8 | MaxPower | Maximum power consumption of the device from USB hub
7 | bmAttributes | D6: Self-powered

The test software also issues a GET_STATUS request to the hub. Bit zero of the returned status word is the self-powered bit of the device status. Taken together, these three pieces of information have the following interpretation:

Case | Maxpower | Selfpowered | Hub devicestatus (D0) | Explanation
1 | 0 | 0 | 0 or 1 | N/A. This is an illegal set of information.
2 | 0 | 1 | 0 | N/A. A device that is only self-powered, but does not have local power cannot connect to the bus and communicate.
3 | 0 | 1 | 1 | Self-powered only hub and local power supply is good.
4 | >0 | 0 | 0 or 1 | Bus-powered only hub.
5 | >0 | 1 | 0 | Hub-capable of both self-powered and bus-powered operating modes. It is currently only available as a bus-powered hub.
6 | >0 | 1 | 1 | Hub-capable of both self-powered and bus-powered operating modes. It is currently available as a self-powered hub.

Note Some hubs are self-powered for the power that they supply to their ports but take their own operating power from the USB bus. These hubs are allowed.

If case 1 or 2 is discovered, the hub is reporting an illegal configuration and the test fails. If case 3 or 6 is discovered, the hub is operating as a self-powered hub and test requirements are met.

In case 4 or 5, the hub is operating in bus powered mode. This is only allowed if the hub is part of an integrated keyboard. To determine if this is the case, the test software issues a hub GetDescriptor to get the capabilities of the hub. The following field is returned and examined:

Offset | Field | Description
3 | wHubCharacteristics | D2:Identifies a compound device 0:Hub is not part of a compound device 1:Hub is part of a compound device

If a hub operating in bus-powered mode is not part of a compound device, the test fails.

Each bus-powered hub in the system must have a keyboard connected to one of its downstream ports. The USB keyboard is a HID device that must conform to Device Class Specification for Human Interface Devices. To find the keyboards in the system, the test queries all devices and their interfaces. The following values indicate a keyboard device:

Interface Class

Class code | Device type | Description
03h | HID | Generic HID interface

Interface Protocol Class

Class code | Device type | Description
01h | Keyboard | Keyboard HID device

If a bus-powered hub does not have a keyboard as a downstream child, the test fails.

Results Interpretation

The test transcribes all results to a text-based log file.

The test fails if:

  • A hub is located which is not self-powered and is not part of a keyboard device or integrated into a mobile system.

  • A hub with an illegal set of power attributes is discovered.

Note Because the USB Self Powered Hub Test is only designed to evaluate hubs with exposed ports and not fully embedded hubs (with no exposed ports), testers should set the isEmbeddedWithNoExposedPorts schedule-time parameter to TRUE in the Device Console when scheduling this test if their hub does not expose any ports. This parameter lets DTM know that the hub does not expose any ports and will therefore skip the test entirely. The job will be recorded as passing afterwards.

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller
  • Various USB devices. The number of required USB devices varies. Connect a USB device to every available port on the test USB hub (not required for systems testing).
Processor
  • x86
  • x64
  • Itanium

Troubleshooting

9.1.C2 An external hub must operate in a self-powered configuration unless it is integrated into a USB keyboard or into a mobile system.

Reference document: WLP# - B2.6.4.8; USB Specification, Revision 1.1.


USB Serial Number

Type: Automated Test

Overview

The USB Serial Number test verifies that the serial number on the test device is unique.

Details

Universal Serial Bus (USB) device serial numbers are optional, but if they are implemented, they are required to be unique.

If the serial number feature is implemented, the test setup requires two identical devices with different serial numbers in order to pass this test.

If the serial number is not implemented, this test is skipped and is reported as pass.

Note For embedded USB devices (for example, laptop devices) where it is impossible to meet the external hub connectivity requirement, you must follow the following steps:

  1. Select the job USB Serial Number from Available jobs pane in the Device Console.

  2. Click the Add Selected button on the Device Console. The selected job shows up in the bottom pane.

  3. Select this job from the bottom pane. Right-click it and select Edit Parameters

  4. You will see the Parameter Edit window open, with parameters listed on the left and their values on the right.

  5. Change this value of IsEmbeddedUSBDevice parameter from FALSE to TRUE.

  6. Click the Schedule Jobs button on the Device Console to run this job.

Note If the device goes into selective suspend rapidly, then you may have to disable the power management option in the device manager for the hub to which the device is connected.

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements

  • Device to be tested
  • Two identical test devices with different serial numbers (if the serial number feature is supported).
  • Keyboard-video-mouse switch testing requires one test device, two identical keyboards, and two identical input pointing and drawing devices.

Processor

  • x86
  • x64
  • Itanium


USB Specification Compliance

Type: Automated Test

Overview

This test verifies that the descriptors on all Universal Serial Bus (USB) devices and hubs that are attached to a system comply with either the Universal Serial Bus Specification 1.1 or the Universal Serial Bus Specification 2.0.

The test enumerates the USB bus through the USB software stack. The target device or hub is queried to determine which level of the USB specification is supported.

For devices and hubs that support USB Specification version 1.1, some differences between the 1.1 and 1.0 descriptors are checked.

Details

All USB hubs and devices that are part of the system should be connected. The test software enumerates the USB bus through the USB software stack. The test software issues a device GetDescriptor call for each device and hub present and interprets the bcdUSB field as follows:

BcdUSB | Explanation
0x0100 | Compliant with version 1.0 of the specification
0x0110 | Compliant with version 1.1 of the specification
0x0200 | Compliant with version 2.0 of the specification

If any device or hub is not compliant with version 1.1 or 2.0 of the USB specification, the test fails.

USB 1.1 Specification Descriptor Checks

For each device or hub that indicates Universal Serial Bus 1.1 Specification Compliance, the following descriptor checks are made.

Note This is not in intended to be a full 1.1 Specification Compliance Test. It only checks a few descriptor differences between the 1.1 and 1.0 Specifications that can be checked readily through software.

  • The software enumerates through all of the configuration descriptors. If bit D7 in the bmAttributes field is not set to one as required by the USB 1.1 Specification, the test fails.
  • The test queries the hub for its hub descriptor. The following fields in the hub descriptor are examined by the test software:
    • wHubCharacteristics: Bits D0 and D1 must indicate that the hub supports Ganged or Individual port power switching. If bits D0 and D1 are 1X, the test fails.
    • PortPwrCtrlMask: All bits in this field must be set to one to maintain compatibility with software written for USB 1.0 devices. If any of these bits are set to zero, the test fails.

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • The device descriptor indicates that the device does not support Universal Serial Bus Specification, Revision 1.1 or 2.0.
  • The device descriptor indicates that the device supports USB Specification, Version 1.1 but the D7 bit in the bmAttributes field of a configuration descriptor is not set to one.
  • The hub indicates that it supports the USB Specification, Version 1.1, but its Logical Power Switching Mode in wHubCharacteristics is not set to Ganged or Individual port power switching.
  • The hub indicates that it supports the USB Specification, Version 1.1, but not all bits in its PortPwrCtrlMask are set to one.

Run Time: 3 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Windows Logo Program-compliant USB host controller and supporting drivers.
  • The test requires that the following hardware and software be installed, if they are part of the system undergoing the test. A) Windows Logo Program compliant USB hub(s) and supporting drivers B) Windows Logo Program compliant USB cables C) Windows Logo Program compliant USB devices and supporting drivers.
Processor
  • x86
  • x64
  • Itanium

Troubleshooting

  • 9.1.3 All USB hardware complies with USB 1.0 Specification.

    Reference documents: WLP# - B2.6.2.3; PC 99 System Design Guide - 7.3

  • 9.1.8 USB hubs comply with the USB 1.1 Specification. (Recommended only)

    Reference documents: WLP# - B2.6.2.3; PC 99 System Design Guide - 7.8

  • 9.1.C1 USB field of each hub's Device Descriptor reports revision 1.1 or 2.0.

    Reference documents: WLP# - B2.6.2; USB Specification, Revisions 1.1, and 2.0

  • 9.1.C3 A hub that reports USB version 1.1 must fully comply with the USB 1.1 Specification.

    Reference documents: WLP# - B2.6.2; USB Specification, Revision 1.1

  • 9.1.C3.1 A hub that reports USB version 1.1 must set all bits to one in the PortPwrCtrlMask in the hub descriptor.

    Reference documents: WLP# - B2.6.2; USB Specification, Revision 1.1, Section 11.15.2.1

  • 9.1.C3.2 A hub that reports USB version 1.1, must report Ganged or Individual port power switching in the wHubCharacteristics field of the hub descriptor.

    Reference documents: WLP# - B2.6.2; USB Specification, Revision 1.1, Section 11.15.2.1

  • 9.1.16 USB field of each peripheral's Device Descriptor reports revision 1.1 or 2.0.

    Reference documents: WLP# - B2.6.2; USB Specification, Revisions 1.1, and 2.0

  • 9.1.23 A USB device that reports USB version 1.1 must fully comply with the USB 1.1 Specification.

    Reference documents: WLP# - B2.6.2; USB Specification, Revision 1.1

  • 9.1.24 A USB device that reports USB version 1.1, must set bit D7 to one (Bus Powered) in the bmAttributes field of its configuration descriptors.

    Reference documents: WLP# - B2.6.2; USB Specification, Revision 1.1, Section 9.6.2


USB System Suspend Resume Test

Type: Automated Test

Overview

The USB System Suspend Resume test verifies that a USB device continues to appear in the device manager after the system awakens from the S3 sleep state.

Details

This test is designed to remove a hot fix that prompts the USB Host Controller to reset upon resume (for more information on this fix, please read A USB device may no longer work correctly after Windows Vista resumes from sleep or from hibernation). The test sends the system into S3 and then resumes the system, upon resume the device under test is sought in the device manager, thus verifying that it is both present and functional. The suspend and resume cycle repeats 20 times, and if the device under test is found upon resume each time the test passes. If the device under test is no longer found in device manager the test will fail. Following the test the hot fix is put back into the registry only for the Host Controller keys from which it was removed.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
Processor
  • x86
  • x64
  • Itanium


USB Host Controller Enable Disable Test

Type: Automated

Overview

This is an automated test that disables and re-enables the USB host controller(s) and checks to see whether all of the devices are still present on the system.

Details

A list of USB devices is compiled at the beginning of the test, as well as a list of all the USB host controllers. The test performs five disable/enable cycles of the host controllers. All of the USB host controllers are disabled and enabled simultaneously. After re-enabling the controllers, the test gathers a list of the current devices attached to the system. This list is compared to the original device list. If at any time the list of current devices does not match the original device list, the missing devices are listed, and the test fails and exits.

Run Time: 3 minutes
Log File: HostCtrlTest
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows Server 2008

  • Windows Vista

  • Windows 7

Program: HostCtrlTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • At least one device attached to the system/host controller under test.
Processor
  • x86
  • x64
  • IA64

Running USB Host Controller Enable Disable Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures. If a device that was attached to a host controller at the beginning of the test is not found after the host controller is reenabled then the test fails, lists which device(s) were not found and exits.

Command Syntax

Command option | Description
hostctrltest.exe | Without any options, the test will test only USB Host Controllers
[GUID] | The GUID for any type of host controller, if more than one then separate by a space

Code Tour

File Manifest

File | Location
hostctrltest.exe | [WTT\TestBinRoot]\nttest\driverstest\usb\LogoKit\HostController\HOSTCTLRTEST.exe
WTTlog.dll | [WTT\OSBinRoot]\WTT\WTTlog.dll
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\DevEDInstaller.msi


USB Controller Power State Test (and USB Controller Power State Test for Server)

Type: Automated

Overview

This test cycles through all of the system-supported power states. It verifies that the host controller continues to function properly and that all of the devices attached to the host controller reappear upon resuming. Sleep states S3 and S4 must be implemented; all other power states will only be tested if the system supports them.

Details

This test first checks that the system under test supports both S3 and S4 sleep states. For the systems test, the only difference is that the test does not fail if S3 and S4 are not supported. A list of all devices attached to the host controller is created. The test then cycles through all of the supported power states five times, and it checks that all the devices are still present upon resume from each power state. If a device is missing, the test fails and exits, and it lists the device which was not found. In Windows 7, the test also checks that the host controller is not reset upon resume from S1, S2, or S3.

Run Time: 30 minutes
Log File:PowerTest
System Restart Required:Yes
Supported operating systems for Logo or Signature testing:

  • Windows Server 2008

  • Windows Vista

  • Windows 7

Program:PowerTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • At least one USB 2.0 device attached to the system or controller being tested
Processor
  • x86
  • x64
  • IA64

Running USB Controller Power State Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures. After reboot test is launched again and will check the configuration file to see where if it is the test being initially launched or coming back from reboot.

Understanding the Errors

The following errors can occur while trying to resume the controller after a sleep cycle.

Error | Meaning
USBPort EHCI HC Miniport Resume Complete Error 1 | HC Operational Register is NULL.
USBPort EHCI HC Miniport Resume Complete Error 2 | HcHalted bit not set upon resume.
USBPort EHCI HC Miniport Resume Complete Error 3 | Configuration flags were reset.
USBPort EHCI HC Miniport Resume Complete Error 4 | Port power on root ports is zero.
USBPort EHCI HC Miniport Resume Complete Error 5 | Port ownership switched between EHCI and companion controller.
USBPort OHCI HC Miniport Resume Complete Error 1 | Hc Operational Register is NULL.
USBPort OHCI HC Miniport Resume Complete Error 2 | HcControl Register has invalid values. Indicates the controller has been reset or a transfer list has been disabled.
USBPort OHCI HC Miniport Resume Complete Error 3 | HcHCCA Physical Address has changed.
USBPort UHCI HC Miniport Resume Complete Error 1 | Controller hardware is not present.
USBPort UHCI HC Miniport Resume Complete Error 2 | Controller is not in suspend mode. Most likely indicates that the controller was reset or lost power.
USBPort UHCI HC Miniport Resume Complete Error 3 | Controller is still in resume state after resuming.
USBPort UHCI HC Miniport Resume Complete Error 4 | Controller failed to resume.

Command Syntax

Command option | Description
PowerTest.exe | Without any options, the test will test only USB Host Controllers
[GUID] | The GUID for any type of host controller, if more than one then separate by a space
UpdateConfigFile.exe | With parameters "PowerTestConfig.xml SelfRestart 0" will set the test configuration file to the beginning of the test
regsvr32 /s etwcap.dll | Register the dll for use by the test executable.

Code Tour

File Manifest

File | Location
 | [WTT\TestBinRoot]\nttest\driverstest\usb\LogoKit\HostController\POWERTEST.exe
 | [WTT\TestBinRoot]\nttest\driverstest\usb\LogoKit\HostController\PowerTestConfig.xml
 | [WTT\TestBinRoot]\nttest\driverstest\usb\LogoKit\HostController\UpdateConfigFile.exe
 | [WTT\OSBinRoot]\WTT\WTTlog.dll
 | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\DevEDInstaller.msi
 | [WTT\TestBinRoot]\nttest\driverstest\usb\ETWCap\ETWCap.dll


USB WDF Compliance Check

Type: Automated

Overview

This test checks that a USB device's driver is a WDF driver (either KMDF or UMDF).

Details

The USB WDF Compliance Check test uses gatherer data found during the submission process to determine whether the driver is a KMDF or UMDF driver.
Run Time: 1 minute
Log File: No log file

System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: There is no test binary, this test checks gatherer data

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

The test will pass if the DTM gatherer reports that the device "isWDF." It will fail if the device does not have this attribute in the gatherer.


Validate USB Tree Supports Sleep States

Type: Automated Test

Overview

This test is not required to get a logo (see details in "Running the Test" below). The test script enumerates all USB devices in the system by passing in USB Device interface Class GUID. It checks whether each USB device supports the D3 Power capability i.e., PDO_D3_SUPPORTED. If any of the USB devices doesn't support the mentioned power capability, then the test case fails.

Details

Run Time: 1 minute
Log File: ValidateUSBSleepState.wtl
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: cscript with TS7_ValidateUSBSleepSate.vbs

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • System to be tested that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return Pass or Fail. Because this test is not required to run to get a logo, it will not show up in device console when making a submission. To run this test in the DTM, please see How to Manually Schedule USB DTM Jobs.

To manually run this test:

  1. Install the DevED component installer.

  2. Copy the script.

  3. Execute the test script.

  4. Uninstall the MSI.

Command Syntax

Command option | Description
TS7_ValidateUSBSleepSate.vbs | Script that runs the validate USB tree Supports Sleep States test.
/VID:[VID] /PID:[PID] | The Vendor ID and Product ID of the device under test, where [VID] and [PID] are replaced by the actual Vid and Pid of the device. This parameter can be replaced by using the Device Instance ID parameter.
/ID:[Device Instance Path] | The device instance path of the device to be tested. This parameter can be used instead of the VID PID parameter.

Code Tour

File Manifest

File | Location
TS7_ValidateUSBSleepSate.vbs | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED\TestScripts
DevEDInstaller.msi | [WTT\TestBinRoot]\NTTEST\DRIVERSTEST\usb\DevED


Codec Offload Hardware

For more information, please see RemoteFX Hardware Encoder - (Stress Test, Multiple Encoding Test, Scenario Test, Interoperability Test, Color Test, Hardware Detection Test, Encoding Test).


RemoteFX Hardware Encoder - (Stress Test, Multiple Encoding Test, Scenario Test, Interoperability Test, Color Test, Hardware Detection Test, Encoding Test)

Type: Automated test

Overview

The new category for Codec Offload Hardware defines a set of requirements and tests for a new category of devices that allow the encoding of screen data for RemoteFX virtual machines (VMs) to be offloaded from the CPU/GPU to dedicated hardware. This enables higher levels of scalability on a RemoteFX server. These tests ensure fidelity and compatibility.

Details

Encoding Test

This test verifies core functionality of the RemoteFX codec library interaction with RemoteFX-enabled encoder hardware. These tests are designed to ensure that all supported resolutions can be handled by the device under test, and that the quality of compression is within the functional requirements needed for Remote Desktop Virtualization. All combinations of the following test parameters must be executed against each of the tile usage scenarios:

Test Parameters
Codec Library Flags: ENC_TYPE_CPU_HW, ENC_TYPE_DX10_HW
User Scenarios: Desktop, Internet Explorer – MSN, Internet Explorer – MLB, Excel, Word, PowerPoint, Visual Studio, Virtual Earth, Movie, Combination
Resolutions: 640x480, 800x600, 1024x768, 1152x864, 1280x800, 1280x1024, 1400x1050, 1600x1050, 1600x1200, 1920x1200, 2560x1600, 4096x2048
Quality: ENC_QUALITY_HI, ENC_QUALITY_MED_HI, ENC_QUALITY_MED_LO
Scenario (Tiles Changing (1280x1024 Example))
Full Screen: 80
Single Tile: 1
Random Tiles: 20
Random Rectangles (Non-aligned): ~20
Contiguous: ~20
Run time: 48 hours
Log file: RemoteFX_Qualify_Encoder_Codec_Encoding.wtl

Stress Test

This test verifies that the Calista-enabled encoder hardware under stress scenarios designed to ensure the hardware can handle abnormal usages.

Test Encoder Type

12 Hour Stress Test ENC_TYPE_CPU_HW

Run time: 12 hours
Log file: RemoteFX_Qualify_Encoder_Codec_Stress.wtl

Multiple Encoding Test

This test verifies the functionality of the Calista-enabled encoder hardware when used in parallel. Each instance is selected from the possible combinations in the Encoder Functionality test category.

Test Encoder Type

32 Tests from Encoder Static Images In Parallel, ENC_TYPE_CPU_HW

32 Tests from Encoder Static Images In Parallel, ENC_TYPE_DX10_HW

Run time: 1 hour
Log file: RemoteFX_Qualify_Encoder_Codec_Encoding_Multiple.wtl

Scenario Test

This test verifies the Calista-enabled encoder hardware under end-to-end data scenarios that is seen in Remote Desktop Virtualization deployments. The tests are designed to verify the quality throughout the entire playback of the scenarios.

Scenario Encoder Type

Windows Interaction ENC_TYPE_CPU_HW

PowerPoint ENC_TYPE_CPU_HW

Windows Interaction ENC_TYPE_DX10_HW

PowerPoint ENC_TYPE_ DX10_HW

Run time: 1 hour
Log file: RemoteFX_Qualify_Encoder_Codec_Scenario.wtl

Interoperability Test

This test verifies the interoperability between RemoteFX-enabled encoder hardware and the different software decoder implementations. The following uses a subset of the tests from the Encoder Functionality test category:

Test Parameters
User Scenarios: Desktop, Internet Explorer – MSN
Tile Change Scenarios: Full Screen, Single Tile, Random Tiles, Random Rectangles, Contiguous
Encoder Type Decoder Type
ENC_TYPE_DX10_HW DEC_TYPE_DX9
ENC_TYPE_DX10_HW DEC_TYPE_CPU
ENC_TYPE_CPU_HW DEC_TYPE_DX9
ENC_TYPE_CPU_HW DEC_TYPE_CPU
Run time: 1 hour
Log file: RemoteFX_Qualify_Encoder_Codec_Interoperability.wtl

Color Test

This test verifies that the color conversion algorithms implemented in the hardware meet the specifications and requirements of Remote Desktop Virtualization usage of the RemoteFX-enabled encoder hardware.

Test Encoder Type

Codec Color Verification ENC_TYPE_CPU_HW

Run time: 1 minute
Log file: RemoteFX_Qualify_Encoder_Codec_Color.wtl

Hardware Detection Test

These tests verify the hardware’s compatibility with the Remote Desktop Virtualization software stack.

Test Encoder Type

API Codec Capabilities Hardware Detection ENC_TYPE_DX10_HW

API Codec Capabilities Hardware Detection ENC_TYPE_CPU_HW

Run time: 5 minutes
Log file: RemoteFX_Qualify_Encoder_Codec_Hardware_Detection.wtl

General

System restart required: Yes (Driver Verifier enable/disable)
Test category: Codec Offload Hardware\RemoteFX\Encoder
Supported operating systems for logo or signature testing: Windows Server 2008 R2
Program: Codec Offload Hardware\RemoteFX\Encoder

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested
  • Graphics processing unit (GPU) that can handle DirectX 9 and DirectX 10
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard disk drive with a minimum of 20 GB available on partition C:
Processor
  • x64

Running the Test

Each validation category test launches an instance of the CodecTest executable, which encodes test data by calling the Hardware Encoder Driver. This compressed data is then decoded using Software Decoder implementation, and then verified using PSNR. After completing each validation category test, the test produces a log file. This log file is the same content displayed in the console. It can be used to review the results of the validation category and shows PASS/FAIL and SKIPPED results.

Command Syntax

Usage: CodecTest.exe [[option, ...] [test case],..]

Options:
Encoder Settings:
/encoderType <ENC_TYPE_[DX10|DX10_HW|CPU|CPU_HW]> = Specifies which encoder type is used
/encoderUsage <ENC_USAGE_[SYSMEM|VIDMEM]> = Specifies which encoder usage is used
/encoderQuality <ENC_QUALITY_[HI|LO|MED_HI|MED_LO]> = Specifies the encoding quality
Decoder Settings:
/decoderType <DEC_TYPE_[DX9|CPU|HW]> = Specifies which decoder type is used
/decoderUsage <DEC_USAGE_[SYSMEM|VIDMEM]> = Specifies which decoder decode usage is used
Other Settings:
/hwMode = Set encoder/decoder to use hardware wireformat
/screenWidth <width> = Encode/decode images width
/screenHeight <height> = Encode/decode images height
Qualify Tests:
/qualify = Runs all qualification tests required for hardware validation
Encoder Tests:
Qualify_Encoder_Encoding
Qualify_Encoder_Encoding_Multiple
Qualify_Encoder_Hardware_Detection
Qualify_Encoder_Interoperability
Qualify_Encoder_Scenario
Qualify_Encoder_Stress
Qualify_Encoder_Codec_Color
To run the Hardware Encoder Qualification test:
CodecTest.exe /qualify /whql true /logFilename RemoteFX_Qualify_Encoder_[TestToRun] Qualify_Encoder_[TestToRun]
Where [TestToRun] = Stress | Encoding_Multiple | Scenario | Interoperability | Color | Hardware_Detection | Encoding

Code Tour

The files in the test package are listed in the table below. CodecTest.exe is the main test executable and contains the test logic. It calls into CommonLib.dll, CommonNativeLib.dll, DecoderWrapper.dll, and EncoderWrapper.dll for various functionality. D3ddx10_42.dll is required for the DirectX functionality used in the tests. Images.zip contains all the reference images against which the images encoded using the target device are compared. Unzip.vbs is used to unzip the reference images from Images.zip.

File Manifest

File | Location
CodecTest.exe | [WTT\TestBinRoot]\NTTEST\TERMSRVTEST\Termsrv\Calista\Codec\External\bin
CommonLib.dll | [WTT\TestBinRoot]\NTTEST\TERMSRVTEST\Termsrv\Calista\Codec\External\bin
CommonNativeLib.dll | [WTT\TestBinRoot]\NTTEST\TERMSRVTEST\Termsrv\Calista\Codec\External\bin
DecoderWrapper.dll | [WTT\TestBinRoot]\NTTEST\TERMSRVTEST\Termsrv\Calista\Codec\External\bin
EncoderWrapper.dll | [WTT\TestBinRoot]\NTTEST\TERMSRVTEST\Termsrv\Calista\Codec\External\bin
d3dx10_42.dll | [WTT\OsBinRoot]\d3dsdk\bin
Images.zip | [WTT\TestBinRoot]\nttest\termsrvtest\termsrv\Calista\Codec\External\images
Unzip.vbs | [WTT\TestBinRoot]\NTTEST\TERMSRVTEST\Termsrv\Calista\Codec\Tools


Communication Testing

Communication Testing Overview
Preparing for Communication Testing
Running Communication Tests
Communication Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Communication Testing Overview

The procedures that are presented in this section outline the process for testing your Communication device for correct functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that 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 Communication Logo program is intended for testing all communications centric devices with both audio and video capture functions, such as a USB webcam with microphone.

(NOTE: Any audio devices which are used for scenarios beyond communication such as desktop speakers, entertainment headphones, Bluetooth devices that support Advanced Audio Distribution Profile - A2DP - should be submitted through Audio Device logo program.)

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 Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Communication Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested.

Run time: 1 hours

Hardware Requirements

The following hardware is required for Communication 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.

  • The device to be dested.
  • A computer with the following:

    • One x86-based or x64-based processor with a minimum speed of 450 MHz

    • 512 MB of RAM

    • One AGP or PCI display adapter

  • One 17-inch monitor with at least 1024x768x24 bits per pixel (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.

Software Requirements

The following software is required to run the Communication tests:

  • Windows 7

  • Any drivers that are not shipped with the operating system

  • The current release of the Windows Logo Kit (WLK)

Tester Knowledge Requirements

To run the Communication tests, testers must know how to accomplish the following tasks:

  • Install the Communication hardware

  • Install the manufacturer-supplied device driver, if necessary.

  • Install the operating system from the product DVD.

  • Install the WLK.


Preparing for Communication 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 Communication Device Testing Overview.

Many of the tests in the Windows Logo 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 How to turn on automatic logon in Windows XP.

Test System Configuration

To configure the test system for Communication device testing:

  1. Install the appropriate Microsoft Windows operating system on the test system.

  2. Install the hardware to be tested on the test system.

  3. Install the manufacturer-supplied device driver, if necessary, on the test system.

  4. Set up the device configuration that is specified in the Fidelity Test Setup section.

  5. Check that the capture device functions properly on the test system.

  6. If appropriate, enable autologon functionality.

  7. Set up DTM.

  8. After you set up the DTM controller and create a machine pool, move the client machine into that pool.


Running the Communication Tests

To run the logo tests and create a submission cabinet file to send to WHQL for logo approval, either run the logo tests from a previously saved device job schedule file, or create a new submission. These procedures are as follows:

Run the Logo Tests from a Previously Saved Device Job Schedule File

  1. Open a Device Console window from the Explorers menu.

  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.

Use the Create New Submission Wizard to Select and Run Logo Tests

  1. Open a Device Console window from the Explorers menu.

  2. Select your DTM controller from the drop-down box at the upper left of the Device Console window.

  3. Click the Submission option button in the View By section.

  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 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 a Device Submission, then select the logo program "Communication", 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 systems to use for the submission, and then click Next.
    6. If the device has its own drivers, select the location in the Driver Install File control and then click Finish.

  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 that you selected.

  7. 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 button.
  8. Monitor logo test progress:
    1. Observe logo test progress by using Job Monitor, and manually intervene if required by test.
    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.

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


Communication Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


Audio Logo Test-Verify Communications Device

Type: Automated Test

Overview

This test verifies that all endpoints on the audio device are declared to be communication endpoints.

Details

Run Time: 1 minute
Log File: AudioLogo.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: AudioLogo.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running Audio Logo Test-Verify Communications Device

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return PASS if all audio endpoints on the device are defined to be communication endpoint. Please refer to WDK documentation for the INF setting specific to this requirement.

Command Syntax

Command option | Description
AudioLogo.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to be tested.
logo_win7_audiologo.pro | The .profile file of test cases to be run.

Code Tour

File Manifest

File | Location
AudioLogo.exe | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\


Display Testing

This section describes how to test display devices in order to qualify them for the Windows logo.

Display Adapter and Chipset Testing

CRT Display Testing Overview

Flat Panel Display Testing Overview

Plasma Display Testing Overview

Projector Display Testing Overview

Display Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Display Adapter and Chipset Testing Overview

The procedures that are presented in this section outline the process for testing your display adapter and chipset device for correct functionality with the Microsoft Windows operating system. These procedures test your product for correct 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 DTM identifies as required for the device.

If the device that you are testing is multifunctional, you must complete the test procedures for each functionally independent, logical device. For example, a display adapter device that contains video input capability must complete the display tests and the video capture tests.

The test procedures in this section 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 Windows logo testing.

  • Running: The test procedure topics describe how to run to run each test in the WDK using the DTM.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Display Adapter Tests

The list of tests you must 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 display adapter category under $\WDK\Display\ in Job Explorer of the DTM.

Hardware Requirements

The following hardware is required in the machine pool for display adapter and chipset testing. This specific hardware fulfills the diversity requirements that demonstrate the stability of display drivers and chipsets:

  • At least two systems for every Discrete ASIC family in the INF file that is obtaining the logo. These systems must contain:
    • At least one AMD microprocessor system.
    • At least one Intel system with a dual microprocessor (such as the Intel Hyper-Threading microprocessor).
    • A linked display adapter (LDA) configuration to be used in the test bed for relevant display adapters.

    Note Mobile and Integrated display adapters and chipsets are exempt from this requirement.

  • A minimum of two adapters for every ASIC family that is supported in the INF file. One of the adapters must support dual view and have a monitor attached and enabled.

  • A multi-sync display data channel standard, level 2B (DDC2B)-capable monitor with EDID 1.3 support on the test systems.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

  • All display adapters and chipsets must be running the same driver version that is being submitted for a logo.

  • The DisplayGroups.xml file that is located on the DTM controller must match the agreed upon Display/Chipset ASIC grouping and must be placed on each client system that you are using for the submission. For Premium logos, at least one ASIC family in DisplayGroups.xml must contain devices that all can pass the Premium tests.

  • To run the Fast User Switching (FUS) tests, make sure that the test system is not part of a domain. To verify this, right-click My Computer and click Properties. In the Computer Name tab, 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 and password protection before you start the testing.

  • For Microsoft Windows Server 2003 submissions, the client system must have the Hardware Acceleration slider set to full and be restarted before starting a submission.

  • Install Microsoft Windows Media Player 10 on Windows XP systems before you run the tests.

    Note While you are installing Windows Media Player 10, the test system cannot be attached to a debugger or have debugging enabled. You can obtain Windows Media Player 10 from the Windows Media Player 10 Web site, and you can automate the setup for Windows Media Play 10 with the following command: mp10setup.exe /q.

  • Microsoft Windows Server 2008 R2 is supported.

Tester Knowledge Requirements

  • Install the operating system from the product CD.

  • Extend the desktop to a secondary display.

This section includes:

Preparing for Display Adapter and Chipset Testing

Running the Display Adapter and Chipset Tests


Preparing for Display Adapter and Chipset Testing

Before you run the Display Adapter and Chipset tests on a test computer or computers, you must install and configure the computer hardware, choose the target Microsoft Windows operating system, and install and configure Driver Test Manager (DTM). This section summarizes the requirements and procedures for display adapter and chipset testing. For information about how to install and configure DTM, see Driver Test Manager.

Test System Configuration

Use the following procedure to configure the test computers to test display adapters for your target operating system.

  1. Install the test devices on two (or more) test computers that are configured differently from each other. For more information about minimum system requirements, see Display Adapter and Chipset Testing.

  2. Install the multi-sync display data channel standard, level 2B (DDC2B)-capable monitor with EDID 1.3 support on the test computers.

    Note The secondary head of a multiple headed Display Adapter/Chipset must be connected to a monitor and enabled before you start testing. Not all devices that are able to support multiple heads have to be enabled, but at least one device for each ASIC family that is listed in the INF file must be enabled. To test outside of the submission process, make sure that all secondary heads are connected to a monitor and enabled; otherwise, when a test is selected for the unattached secondary head, it will run on the primary head.

  3. On each test computer, install the target Microsoft Windows operating system.

    Note If the target operating system is Microsoft Windows XP, you must also install Microsoft Windows Media Player 10.

  4. Install the test device driver on each computer.

  5. On each test computer, install the DTM client. For information, see Driver Test Manager.

  6. On the DTM Controller, edit the Displaygroups.xml file to match the agreed-upon ASIC family breakout. The file is located in <InstallationDrive>\Program Files\Microsoft Driver Test Manager\Tests\x86fre\nttest\windowstest\graphics

  7. After you have installed the DTM client software, copy the updated DisplayGroups.xml file to the <InstallationDrive>\Program Files\Microsoft Driver Test Manager\client folder on the client computer, and restart the computer.

  8. Disable any active applications that, by default, are the top window. Examples of such applications are pop-up balloons or on-screen keyboards for Tablet PCs.

  9. If you are testing on Windows Vista, the client system must have the Windows 7 transition pack installed before testing. To install the pack, go to http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e1199d12-5b23-4769-b1e0-210ee147ce15

The Display Adapter/Chipset logo program has manual logo jobs, and you must configure a client computer to accept these jobs. For any jobs with (Manual) in the title, you must pick a test machine in the machine pool that meets all the requirements to run the manual tests. Make sure that this machine can run all manual tests that are required for a logo. Depending on the type of submission, you might need the following features or configurations:

  • TV-out support

  • Multimon

  • Hot plug detection support

For additional requirements for each test, see the individual test descriptions.

Because the manual jobs require user intervention, you should schedule them together, either before or after the automated jobs are run. This helps to make sure that the manual jobs are sent to the specified client computer instead of having them mixed in with the automated jobs.

For the manual jobs to run, apply the following constraints to the machine that you intend to run the jobs on:

  • Display\PrimaryMachine = True

To set this dimension for the manual jobs, you can do one of the following:

  • From a Command Prompt window, type WTTCmd.exe /ConfigReg /Add /Value:Display\PrimaryMachine /Data:"True" and then press Enter.

  • Complete this procedure:
    1. Open DTM Studio.
    2. In the Job Monitor window, right-click the appropriate machine in the pool, and then click Edit .
    3. Add the "Display\PrimaryMachine" dimension to the list.
    4. Click Save.

Before you start a display test, close any active application (including Windows Explorer and Microsoft Internet Explorer) on the test computer.


Running the Display Adapter and Chipset Tests

After you have installed the test devices and drivers in the test clients and have set up the DTM controller, DTM Studio, and clients, you can run the logo tests.

To use DTM to run the Display Adapter and Chipset logo tests, do the following:

  1. Open DTM studio.

  2. On the Explorers menu, click Job Monitor.

  3. Create a machine pool to use for the submission.

  4. Move all test systems to this newly created machine pool and make sure that the machine status is set to Reset.

  5. Make sure that the DisplayGroup.xml file is updated with the proper ASIC grouping. You can find this file on the DTM controller under \\<controllername>\tests\x86fre\nttest\windowstest\graphics

  6. Schedule the Update DisplayGroups.xml on Test Machine job to run on all test clients. This job copies the DisplayGroups.xml file that was edited to the %INSTALLATIONDRIVE%\Program Files\Microsoft Driver Test Manager\Client folder on the client test systems. This job can be found in the Job Explorer (on the Explorers menu, click Job Explorer, and then click the Feature tab).

  7. The Display Adapter -> Codec jobs content is going to be provided outside of the DTM because of the size of its content. Go into the CODEX folder and place a copy of everything in this folder into the \x86fretest\bin\NTTEST\MULTIMEDIATEST\CDSPTEST\ folder, on the DTM Controller.

  8. On the Explorers menu, click Device Console. (You can also switch to the Device Selection window by clicking the Device Console tab in the lower left corner of DTM Studio.)

  9. In the Submission list, click <New Submission>.

  10. Complete the Submission wizard. When you are finished, a list of jobs will be displayed.

    Note If you are submitting multiple INF files, you must load all INF files during the submission wizard.

    Note You must run all of the jobs that appear, but you can choose which order you run them in. We recommend that you schedule all of the jobs that have (Manual) in the title at the same time to ensure they are sent to one system instead of any system in the pool.

  11. Select the jobs that you want to run, and then click Add Selected. The jobs selected will appear in the bottom window.

    Note You might see multiple instances of the same job in the bottom window; this behavior is expected. The customer scheduler for display uses the answers that you give in the Submission wizard, display devices that are listed in the INF file, devices that are actually in the machine pool, the Displaygroups.xml file, and attributes of the jobs to determine which of the tests and how many get scheduled.

  12. When you are ready to run the jobs, click the Schedule button.

  13. Use Job Monitor to track the progress of jobs while they are run.

  14. When testing is complete, click the Status button in the Device Console window and review the information that is provided.

  15. If there are any issues, correct them.

  16. After you verify the status information, right-click the summary icon in the Available Devices pane of Device Console, and then click Create Submission Package. This process might take a few minutes to complete.


Troubleshooting Display Adapter and Chipset Tests

The following list describes some common troubleshooting tips for display tests:

  1. Problem The Display logo tests might fail if a window that is set to always be on top ("always-on-top") is open during the test.

    Solution Disable any active applications that force themselves to be the top window while you execute any graphics-related test content. Examples of such applications are balloon pop-up messages, on-screen keyboards, or Tablet Input Panel (TIP) for tablet PCs.

  2. Problem A Timeout Detection Recovery (TDR) task (the WDDM TDR Verify Test) has been added to the Display Tests. This is to ensure that the graphic drivers do not have a "soft crash" while testing, thus increasing the stability of the graphic driver.

    Solution Should a display job fail because the TDR Task reports a failure, please contact the graphic IHV for assistance.


Hybrid Graphics Testing Overview

The procedures that are presented in this section outline the process for testing your Hybrid Graphics solution for correct functionality with the Microsoft Windows operating system. These procedures test your product for correct functionality by using the Windows Logo Kit (WLK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that DTM identifies as required for the device.

If the device that you are testing is multifunctional, you must complete the test procedures for each functionally independent, logical device. For example, a display adapter device that contains video input capability must complete the display tests and the video capture tests.

The test procedures in this section 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 Windows logo testing.

  • Running: The test procedure topics describe how to run to run each test in the WLK using the DTM.

Note In order for your driver to pass testing and obtain a logo, you must use the latest version of the WLK to compile your driver.

Hybrid Graphics Tests

Tests that are required to run are located under $\WDK\Display\Hybrid Graphics in Job Explorer of the DTM.

The test should run with the system in the default configuration that it will be shipping in (iGPU or dGPU); however, it is also recommend that these tests be run in other modes. For logo, only one mode will be test in the submission.

Hardware Requirements

None.

Software Requirements

None.

Tester Knowledge Requirements

Basic understanding of how to start and complete a submission with the DTM.


Preparing for Hybrid Graphics Testing

Before you run the Hybrid Graphics tests on a test computer or computers, you must install and configure the computer hardware, choose the target Microsoft Windows operating system, and install and configure Driver Test Manager (DTM). This section summarizes the requirements and procedures for Hybrid Graphic testing. For information about how to install and configure DTM, go to Install.htm - Automated Installation Guide.

Test System Configuration

Use the following procedure to configure the test computers to test display adapters for your target operating system:

  1. Install the test device driver on each computer.

  2. On each test computer, install the DTM client. For more information, go to Install.htm - Automated Installation Guide.


Running the Hybrid Graphics Tests

After you have installed the test devices and drivers in the test clients and have set up the DTM controller, DTM Studio, and clients, you can run the logo tests.

To use DTM to run the Hybrid Graphics logo tests, follow these steps:

  1. Open DTM studio.

  2. On the Explorers menu, click Job Monitor.

  3. Create a machine pool to use for the submission. For more information, go to Grouping Client Computers into Machine Pools

  4. Move all test systems to this newly created machine pool, and make sure that the machine status is set to Reset.

  5. On the Explorers menu, click Device Console. (You can also switch to the Device Selection window by clicking the Device Console tab in the lower left corner of DTM Studio.)

  6. In the Submission list, click <New Submission>.

  7. Complete the Submission wizard. When you are finished, a list of jobs will be displayed.

  8. To make sure all the tests work properly (like infchk), select the physical device in Device Console after the submission has been created before scheduling any of the tests.

  9. Select the jobs that you want to run, and then click Add Selected. The jobs selected will appear in the bottom window.

  10. When you are ready to run the jobs, click the Schedule button.

  11. Use Job Monitor to track the progress of jobs while they run.

  12. When testing is complete, click the Status button in the Device Console window and review the information that is provided.

  13. If there are any issues, correct them as needed.

After you verify the status information, right-click the summary icon in the Available Devices pane of Device Console, and then click Create Submission Package. This process might take a few minutes to complete.


CRT Display Testing Overview

The procedures that are presented in this section outline the process for testing your display monitor device for correct functionality with the Microsoft Windows operating system. These procedures test your product for correct functionality by using the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that DTM identifies as required 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 device that also provides external USB ports must also complete the USB tests.

Monitors with multiple connection types only need to submit logs with one connection tested. For flat panel or plasma monitors that support digital (DVI or HDMI) and analog (DSUB) connections the logs must be generated using the digital connection. You can test CRT monitors under any connection type that is supported. Microsoft highly recommends that the additional connections are tested under the same circumstances using the relevant monitor tests, but no logs are required for submission at this time. At a future time, the DTM might be changed to allow testing for multiple connection types within the same submission/log set. At this time, the policy will be updated to require testing all connections available on a monitor.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Hardware Requirements

There are no hardware requirements; however, it is a good idea that two different display adapters (adapters that use different IHV drivers) are tested with the CRT display.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

The following software is required to run the display monitor testing component of the WDK:

  • Any drivers that are not shipped with the operating system.

  • A setup information file (INF) for the device that you are testing.

  • An Image Color Management (ICM) file, if applicable.

Tester Knowledge Requirements

To run the display monitor tests, testers must know how to:

  • Connect the test monitors to both test systems.

  • Install the display adapters.

  • Install the INF files, if necessary.

  • Install the ICM file, if necessary.

This section includes the following topics:

Preparing for CRT Display Testing

Running the CRT Display Tests


Preparing for CRT Display Testing

Before running the display monitor tests on a test system or systems, you must install and configure the system hardware, choose the target Microsoft Windows operating system, and then install and configure Driver Test Manager (DTM). This section summarizes the display monitor requirements and procedures. For information about installing and configuring DTM, see Setting Up DTM.

For the premium logo, monitors must pass color quality tests, so your test lab must have a color measurement device that meets the E805-01a Standard Practice for Identification of Instrumental Methods of Color or Color-Difference Measurement of Materials standard from ASTM International. You can find out more about this standard on the ASTM Web site. These types of measurement devices are available from multiple manufactures. Follow the manufacturer's instructions to set up and operate the device. For more detailed information about the color tests, see the WinColorKit: Windows Color Quality Test Kit for Device OEMs Web page on the Windows Hardware Developer Central (WHDC) Web site.

In addition, the testing area must meet the recommended operating guidelines that are set by the manufacturer of the color measurement device and the manufacturer of the color device that you are measuring.

Test System Configuration

To configure the test systems for display monitor testing, do the following:

  1. Install the appropriate operating system on both test systems.

  2. Install the display adapters and their drivers. For the requirements of the display adapters, see CRT Display Testing Overview.

  3. Connect identical test display monitors on both test systems.

  4. If appropriate, enable autologon functionality.

  5. Install the DTM client on both test systems.


Running the CRT Display Tests

After you have installed the test devices and drivers on the test clients and have set up the DTM controller, DTM Studio, and DTM clients, you can begin running the logo tests.

To run the display monitor logo tests using DTM

  1. Open DTM Studio.

  2. On the Explorers menu, click Job Monitor.

  3. Create a machine pool to which you can add the client systems. See the Create a machine pool topic for further details.

  4. Move the client systems to the newly created machine pool.

    Note It is expected that the machine pool will have two monitors that are run from different display adapters. See the testing overview topic for further clarification.

  5. On the Explorers menu, click Device Selection.

  6. InView By, click Submission.

  7. From the Submission drop-down list, click New Submission.

  8. Follow the steps in the Submission Wizard. When you complete the wizard, a set of jobs is displayed.

  9. In the Available Devices pane, click one of the display monitor devices.

  10. In the Available Jobs pane, click the main job tree to run all the jobs listed or click the jobs individually, and then click Add Selected.

  11. When you are ready to run the jobs, click Schedule.

  12. Repeat steps 11-13 for the other display monitor devices in the Available Devices pane.

  13. Use Job Monitor to track the progress of the jobs as they are run.

  14. After testing is complete, click the status button in Device Console and review the information provided. Make corrections as necessary.

  15. After you verify the status information, right-click the summary icon in the Available Devices pane of Device Console, and then click Create Submission Package.


Flat Panel Display Testing Overview

The procedures that are presented in this section outline the process for testing your flat panel device for correct functionality with the Microsoft Windows operating system. These procedures test your product for correct functionality by using the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that DTM identifies as required for the device.

If the test device is multifunctional, you must complete the test procedures for each functionally-independent logical device. For example, a Flat Panel that also provides external USB ports must complete the USB tests.

Flat panel's with multiple connection types need only to submit logs with one connection tested. For flat panel and plasma monitors that support digital (DVI or HDMI) and analog (DSUB) connections, the logs must be generated using the digital connection. You can test CRT monitors under any connection type that is supported. Microsoft highly recommends that the additional connections are tested under the same circumstances using the relevant monitor tests, but no logs are required for submission at this time. At a future time, DTM might be changed to allow testing for multiple connection types within the same submission/log set. At this time, the policy will be updated to require testing of all connections available on a monitor.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Hardware Requirements

There are no hardware requirements; however, it is a good idea that two different display adapters (adapters that use different IHV drivers) are tested with the flat panel display.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

The following software is required to run the flat panel testing component of the WDK:

  • Any drivers that are not shipped with the operating system.

  • A setup information file (INF) for the device that you are testing.

  • An Image Color Management (ICM) file, if applicable.

Tester Knowledge Requirements

To run the flat panel tests, testers must know how to:

  • Connect the flat panels to both test systems.

  • Install the display adapters.

  • Install the INF files, if necessary.

  • Install the ICM file, if necessary.

This section includes the following topics:

Preparing for Flat Panel Display Testing

Running the Flat Panel Display Tests


Preparing for Flat Panel Display Testing

Before running the flat panel tests on a test system or systems, you must install and configure the system hardware, choose the target Microsoft Windows operating system, and then install and configure Driver Test Manager (DTM). This section summarizes the flat panel requirements and procedures. For information about installing and configuring DTM, see Setting Up DTM.

For the premium logo, monitors must pass color quality tests, so your test lab must have a color measurement device that meets the E805-01a Standard Practice for Identification of Instrumental Methods of Color or Color-Difference Measurement of Materials standard from ASTM International. You can find out more about this standard on the ASTM Web site. These types of measurement devices are available from multiple manufactures. Follow the manufacturer's instructions to set up and operate the device. For more detailed information about the color tests, see the WinColorKit: Windows Color Quality Test Kit for Device OEMs Web page on the Windows Hardware Developer Central (WHDC) Web site.

In addition, the testing area must meet the recommended operating guidelines that are set by the manufacturer of the color measurement device and the manufacturer of the color device that you are measuring.

Test System Configuration

To configure the test systems for flat panel testing, do the following:

  1. Install the appropriate operating system on both test systems.

  2. Install the display adapters and their drivers. For the requirements of the display adapters, see Flat Panel Display Testing Overview.

  3. Connect identical test flat panels on both test systems.

  4. If appropriate, enable autologon functionality.

  5. Install the DTM client on both test systems.


Running the Flat Panel Display Tests

After you have installed the test devices and drivers on the test clients and have set up the DTM controller, DTM Studio, and DTM clients, you can begin running the logo tests.

To run the flat panel logo tests using DTM

  1. Open DTM Studio.

  2. On the Explorers menu, click Job Monitor.

  3. Create a machine pool to which you can add the client systems. See the Create a machine pool topic for further details.

  4. Move the client systems to the newly created machine pool.

    Note It is expected that the machine pool will have two monitors, that are run from different display adapters. See the testing overview topic for further clarification.

  5. On the Explorers menu, click Device Selection.

  6. In View By, click Submission.

  7. From the Submission drop-down list, click New Submission.

  8. Follow the steps in the Submission Wizard. When you complete the wizard, a set of jobs is displayed.

  9. In the Available Devices pane, click one of the flat panel devices.

  10. In the Available Jobs pane, click the main job tree to run all the jobs listed or click the jobs individually, and then click Add Selected.

  11. When you are ready to run the jobs, click Schedule.

  12. Repeat steps 11-13 for the other flat panel devices in the Available Devices pane.

  13. Use Job Monitor to track the progress of the jobs as they are run.

  14. After testing is complete, click the status button in Device Console and review the information provided. Make corrections as necessary.

  15. After you verify the status information, right-click the summary icon in the Available Devices pane of Device Console, and then click Create Submission Package.


Plasma Display Testing Overview

The procedures that are presented in this section outline the process for testing your plasma device for correct functionality with the Microsoft Windows operating system. These procedures test your product for correct functionality by using the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that DTM identifies as required for the device.

If the test device is multifunctional, you must complete the test procedures for each functionally-independent logical device. For example, a plasma device that also provides external USB ports must also complete the USB tests.

Plasma displays with multiple connection types need only to submit logs with one connection tested. For flat panel or plasma monitors that support digital (DVI or HDMI) and analog (DSUB) connections, the logs must be generated using the digital connection. You can test CRT monitors under whatever connection type is supported. Microsoft highly recommends that the additional connections are tested under the same circumstances using the relevant monitor tests, but no logs will be required for submission at this time. At a future time a change may be made to the DTM that will allow testing for multiple connection types within the same submission/log set at which time the policy will be updated to require testing all connection available on a monitor.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Hardware Requirements

There are no hardware requirements; however, it is a good idea to test two different display adapters (adapters that use different IHV drivers) with the plasma display.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

The following software is required to run the plasma testing component of the WDK:

  • Any drivers that are not shipped with the operating system.

  • A setup information file (INF) for the device that you are testing.

  • An Image Color Management (ICM) file, if applicable.

Tester Knowledge Requirements

To run the plasma tests, testers must know how to:

  • Connect the test plasma devices to both test systems.

  • Install the display adapters.

  • Install the INF files, if necessary.

  • Install the ICM file, if necessary.

This section includes the following topics:

Preparing for Plasma Display Testing

Running the Plasma Display Tests


Preparing for Plasma Display Testing

Before running the plasma tests on a test system or systems, you must install and configure the system hardware, choose the target Microsoft Windows operating system, and then install and configure the Device Test Manager (DTM). This section summarizes the plasma requirements and procedures. For information about installing and configuring the DTM, see Setting Up DTM.

Test System Configuration

To configure the test systems for plasma testing, do the following:

  1. Install the appropriate operating system on both test systems.

  2. Install the display adapters and their drivers. For the requirements of the display adapters, see Plasma Display Testing Overview.

  3. Connect identical test plasma devices on both test systems.

  4. If appropriate, enable autologon functionality.

  5. Install the DTM client on both test systems.


Running the Plasma Display Tests

After you have installed the test devices and drivers in the test clients and have set up the DTM controller, DTM studio, and DTM clients, you can begin running the logo tests.

To use DTM to run the plasma logo tests, do the following.

  1. Open DTM Studio.

  2. On the Explorers menu, click Job Monitor.

  3. Create a machine pool to which you can add the client systems. See the Create a machine pool topic for further details.

  4. Move the client systems to the newly created machine pool.

  5. On the Explorers menu, click Device Selection.

  6. In View By, click Submission.

  7. From the Submission drop-down list, click New Submission.

  8. Follow the steps in the Submission Wizard. When you complete the wizard, a set of jobs is displayed.

  9. In the Available Devices pane, click one of the plasma devices.

  10. In the Available Jobs pane, click the main job tree to run all the jobs listed or click the jobs individually, and then click Add Selected.

  11. When you are ready to run the jobs, click Schedule.

  12. Repeat Steps 11-13 for the other plasma devices in the Available Devices pane.

  13. Use Job Monitor to track the progress of the jobs as they are executed.

  14. After testing is complete, click the status button in Device Console and review the information provided. Make corrections as necessary.

  15. After you verify the status information, right-click the summary icon in the Available Devices pane of Device Console, and then click Create Submission Package.


Projector Display Testing Overview

The procedures presented in this section outline the process for testing your projector device for correct functionality with the Microsoft Windows operating system. These procedures test your product for correct functionality by using the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that DTM identifies as required for the device.

If the test device is multifunctional, you must complete the test procedures for each functionally independent, logical device. For example, a projector device that also provides external USB ports must also complete the USB tests.

Projectors with multiple connection types need only to submit logs with one connection tested. For flat panel and plasma monitors that support digital (DVI or HDMI) and analog (DSUB) connections, the logs must be generated using the digital connection. You can test CRT monitors under whatever connection type is supported. Microsoft highly recommends that the additional connections be tested under the same circumstances using the relevant monitor tests, but no logs are required for submission at this time. At a future time, DTM might be changed to allow testing for multiple connection types within the same submission/log set. At that point, the policy will be updated to require that you test all connections available on a monitor.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Hardware Requirements

There are no hardware requirements; however, it is a good idea to test two different display adapters (adapters that use different IHV drivers) with the projector display.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

The following software is required to run the projector testing component of the WDK:

  • Connect the test monitors to both test systems.

  • Install the display adapters.

  • Install the INF files, if necessary.

  • Install the ICM file, if necessary.

Tester Knowledge Requirements

To run the projector tests, testers must know how to:

  • Connect the test projector to both test systems.

  • Install the display adapters.

  • Install the INF files, if necessary.

  • Install the ICM file, if necessary.

This section includes the following topics:

Preparing for Projector Display Testing

Running the Projector Display Tests


Preparing for Projector Display Testing

Before running the projector tests on a test system or systems, you must install and configure the system hardware, choose the target Microsoft Windows operating system, and then install and configure Driver Test Manager (DTM). This section summarizes the projector requirements and procedures. For information about installing and configuring DTM, see Setting Up DTM.

Test System Configuration

To configure the test system for projector testing, do the following:

  1. Install the appropriate operating system on both test systems.

  2. Install the display adapters and their drivers. For the requirements of the display adapters, see Projector Display Testing Overview.

  3. Connect identical test projector devices on both test systems.

  4. If appropriate, enable autologon functionality.

  5. Install the DTM client on both test systems.


Running the Projector Display Tests

After you have installed the test devices and drivers in the test clients and have set up the DTM controller, DTM Studio, and DTM clients, you can begin running the logo tests.

To run the display monitor logo tests using DTM

  1. Open DTM Studio.

  2. On the Explorers menu, click Job Monitor.

  3. Create a machine pool to which for the client systems to goyou can add the client systems. See the Create a machine pool topic for further details.

  4. Move the client systems to the newly created machine pool

  5. On the Explorers menu, click Device Selection.

  6. In View By, click Submission.

  7. From the Submission drop-down list, click New Submission.

  8. Follow the steps in the Submission Wizard. When you complete the wizard, a set of jobs is displayed.

  9. In the Available Devices pane, click one of the projector devices.

  10. In the Available Jobs pane, click the main job tree to run all of the jobs that are listed or click the jobs individually, and then click Add Selected.

  11. When you are ready to run the jobs, click Schedule.

  12. Repeat steps 11-13 for the other projector devices in the Available Devices pane.

  13. Use the Job Monitor window to track the progress of jobs as they are run.

  14. After testing is complete, click the status button in Device Console and review the information that is provided. Make corrections as necessary.

  15. After you verify the status information, right-click the summary icon in the Available Devices pane of Device Console, and then click Create Submission Package.


Display Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


AES 128 And Session key Refresh Test (32-bit)

Type: Automated Test

Overview

DXVA2 Decode of Mpeg2 and H.264 streams which are AES128 encrypted. The test queries the driver for AES 128 support and if available it will use the Authenticated Channel and the Cryptosession APIs to inform the driver the encryption applied on the video data being decoded.

Details

Mpeg2 Decoding tests support AES128 for all three modes (i.e., IDCT MoComp and VLD).

H.264 Decoding test supports AES128 for VLD mode only.

Both of the above tests support Session Key refresh and partial Encryption if exposed by the driver.
Run Time: 5-7 minutes
Log File: shellrunner.wtl
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: shellrunner.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Graphics card to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the graphics chipset doesn't support Standardized Aes128 decryption.

Command Syntax

Command option | Description
Shellrunner.exe | Without any options, the test enumerates devices.
-c AES128AndSessionkeyRefreshTest.pro | Starts the application and runs the test cases that are specified in the .profile file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to be tested.
AES128AndSessionkeyRefreshTest.pro | The .profile file of test cases to be run.

Code Tour

File Manifest

File | Location
Shellrunner.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\COMMON\WDK
DXVA_H264Filters.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\streaming\DXVA
DXVA2PlaybackTests.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\streaming\DXVA
DXVADecoderBase.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\streaming\DXVA
AES128AndSessionkeyRefreshTest.pro | [testbinroot]\NTTEST\MULTIMEDIATEST\streaming\DXVA
input_h264.avc | [testbinroot]\NTTEST\MULTIMEDIATEST\streaming\DXVA
input.dva | [testbinroot]\NTTEST\MULTIMEDIATEST\streaming\DXVA


Alpha Blended Cursor (Manual)

Overview

The Alpha Blended Cursor test tool displays an icon on a window and enables the tester to decide if the icon has been drawn correctly or not.

Details

This tool creates a window and loads a cursor from a resource file. This cursor is then painted on the window by using AlphaBlend. The window then waits for the tester to look at the drawn cursor.

Requirements

Software Requirements

The test tool requires the following software:

  • Windows 7
  • Windows Vista
  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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)

Run Alphacur.exe from a Command Prompt window. A dialog box will appear with instructions about how to run this test.

You must have the following support files:

  • Alphacur.scr

  • Earth.cur

  • Circle.cur

  • Ntlog.dll

Copy all of the support files to a directory and run Alphacur.exe.


Automatic Stereo

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the Automatic Stereo test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select individual tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

The Automatic Stereo test ensures that the DirectDraw graphics adapter reports that stereo caps are consistent and that stereo flipping can be enabled and disabled.

To run this test, use the Fnddraw.exe executable file.

The Stereo Vision feature of DirectDraw was originally designed to take advantage of LCD flicker glasses on supported video cards. This feature has not been widely adopted by hardware or applications and is not supported by Microsoft Direct3D version 8 or Direct3D version 9.

Run Time: 00:00:10
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • Microsoft DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running Automatic Stereo

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_ster.pro -l"fnswtt.dll" -r -c -p"m%MONITOR%" | Replace the %MONITOR % parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Blt - Color Key - System Memory to Primary Memory

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the Blt - Color Key - System Memory to Primary Memory test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

You do not need Fnswtt.dll to run this test. It is used only for WTT logging.

Details

This test ensures that display drivers that 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 by using either GDI operations or the test's internal software blitter. Images are expected to match exactly.

This test consists of the following Fnddraw cases:

  • BLT, single DESTKEY, System to Primary

  • BLT, single SRCKEY, System to Primary

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:20:40
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running Blt - Color Key - System Memory to Primary Memory

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_vvb.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Blt - Color Key - Video Memory to Primary Memory

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the Blt - Color Key - Video Memory to Primary Memory test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test performs color-keyed blts from offscreen video memory to the primary memory. Blt results are compared against a simulation by using either GDI operations or the test's internal software blitter. Images are expected to match exactly.

Drivers must support source color key blts between video memory surfaces. Destination color key blts and "space" blts are optional.

This test consists of the following Fnddraw cases:

  • BLT, DESTKEY Space, VMem to Primary

  • BLT, single DESTKEY, VMem to Primary

  • BLT, SRCKEY Space, VMem to Primary

  • BLT, single SRCKEY, VMem to Primary

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:10:10
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running Blt - Color Key - Video Memory to Primary Memory

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw_dct.exe ..\pro\dd_ckvv.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Blt - Exotic

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the Blt - Exotic test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test analyzes the GetBltStatus, Zbuffer Blt, Blt FOURCC, and Copy FOURCC functions.

The following group of tests evaluates a variety of miscellaneous Blt operations:

  • "3D_Depth Fill Blt Test" performs a Z-Fills operations on both 16 and 32 bits per pixel (bpp) z-buffers.

  • "BLT_OffscreenOverlap" performs blts on a variety of offscreen surfaces where the source and destination surface are the same. Blt rectangles are chosen so that they overlap. The blts are simulated by the tests' internal software blitter and compared. Because the blts are simple copies, the real blt and simulation should 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 them.

  • "BLT, FourCC to FourCC" performs simple copy blts between a variety of offscreen surface formats, including FourCC formats. FourCC formats are tested only 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 surface. This test is run only if the driver sets the DDCAPS_BLTFOURCC flag.

  • "BLT, FourCC to RGB stretch" performs Stretched Blts from YUV (FOURCC) surfaces to an RGB primary surface. This test is run only if the driver sets the DDCAPS_BLTFOURCC and DDCAPS_BLTSTRETCH flags.

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:08:26
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running Blt - Exotic

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_ob.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Blt - Raster Ops - Vid Mem

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the Blt - Raster Ops - Vid Mem test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test ensures that the display driver correctly performs all reported Microsoft DirectDraw Blt Raster Operations. Only SRCCOPY is required.

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:00:25
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running Blt - Raster Ops - Vid Mem

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_rop.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Blt - Stretch - System Memory to Primary Memory

Overview

The Blt - Stretch - System Memory to Primary Memory test is part of the Fnddraw.exe suite of tests for evaluating the Microsoft DirectDraw features of a display driver.

Details

This test ensures that the DirectDraw graphics adapter can process a variety of DirectDraw stretch (and shrink) blts from system memory to the primary surface.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

This test consists of the following Fnddraw cases:

  • BLT, Stretch (Wx2, Hx.75), SysMem to Primary

  • 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

To run this test, use the Fnddraw.exe executable file.

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


Blt - Stretch & Color Key - Video Memory to Primary Memory

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the Blt - Stretch & Color Key - Video Memory to Primary Memory test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test ensures that the DirectDraw graphics adapter can process combinations of stretched (and shrunk) blts and SOURCE and DESTINATION color key blts from video memory to the primary surface.

This test consists of the following Fnddraw cases:

  • BLT,Stretch(width only), SRCKEY, VMem to pri

  • BLT,Stretch, SRCKEY, VMem to primary

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:12:30
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or laters
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running Blt - Stretch & Color Key - Video Memory to Primary Memory

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_sckvv.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Blt - Textures

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the Blt - Textures test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test verifies 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 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 that are 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 offscreen surfaces (that is, textures). However, the results are copied to the screen to help you with debugging. (Some details are likely lost in converting from the texture pixel format to the pixel format of the primary.)

Currently, the test will tolerate a driver that returns DDERR_UNSUPPORTED on the blt call and will not consider it a failure. This tolerance might change in the future.

Failures might occur from drivers that allow textures to be created in unsupported pixel formats. Drivers should fail the CanCreateSurface function for all non-system memory textures whose pixel formats the drivers 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.

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:01:00
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running Blt - Textures

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_txblt.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Blt Basic - System Memory to Primary Memory

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the Blt Basic - System Memory to Primary Memory test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test performs a simple DirectDraw Blt from a system memory surface to the primary surface.

The test compares the resulting image against its own simulation. Because this test is a simple one-to-one 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 surface, you can visually inspect the results. Use the <Pause> key to give yourself more time.

DirectDraw can perform this Blt operation in its 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 structure.

Support for system-to-video blts is not required. If the driver does not report the appropriate caps, the DCT will not run this test.

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:02:10
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe ..\pro\dd_svb.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Blt Basic - Video Memory to Primary Memory

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the Blt Basic - Video Memory to Primary Memory test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test performs a variety of Blt tests where both the source and destination are in video memory. Drivers must support these blts. Support is expressed by means of the DDCAPS_BLT flag.

The test compares the Blt results against its own simulation. Because the tests are simple one-to-one copy blts, the test expects the DirectDraw Blt and the simulation to match exactly.

This test consists of the following Fnddraw cases:

  • "BLT_OnscreenOverlap" performs blts where the source and destination are on the same surface. To make this test more complicated, 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" is the original overlapping blt test. From a driver standpoint, this test is a simpler version of the "Blt_OnscreenOverlap" test that is mentioned above.

  • "BLT Basic, VMem to Primary" performs a basic blt from an offscreen video memory surface to the primary surface. 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.

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:02:10
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running Blt Basic - Video Memory to Primary Memory

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_vvb.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


BLT Unused Pixel Bits

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the BLT Unused Pixel Bits test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because 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 32 bits per pixel [bpp] modes) should not be included in the color key comparison.

This test consists of the following Fnddraw case:

  • BLT, SRCKEY (from VMem) with unused pixel bits set

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:03:15
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running BLT Unused Pixel Bits

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_bupbs.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


CDS_VIDEOPARAMETERS

Overview

The CDS_VIDEOPARAMETERS test checks a driver's ability to handle the ChangeDisplaySettingsEx function with the CDS_VIDEOPARAMETERS flag.

Details

This test checks a display driver's ability to handle a call to the ChangeDisplaySettingsEx function with the CDS_VIDEOPARAMETERS flag and checks for MacroVision support if available.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:


Check Resource

Overview

The Check Resource Tests uses the D3D9Ex API to verify the user-mode display driver's QueryResourceResidency function.

Details

QueryResourceResidency is used by applications to determine if the operating system will incur a stall at draw time to make the resource CPU-accessible. The test cycles on resource types of Textures, Cube Texture, Volume Texture, Surface, VB, and IBs.
For each resource type the test will create the resource, use the resource in a rending operation, and then check its residency. If the resource is not resident (fully or in shared memory) the test will fail.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Server 2008

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


Color Fill

Type: Automated Test

Overview

The Color Fill test verifies proper implementation of the driver functionality that supports the IDirect3DDevice9::ColorFill Microsoft Direct3D9 method.

Details

The test cases are defined in terms of a Cartesian product of several sets of attributes:

  • The type of destination surface for the ColorFill operation. Valid types are:
    • Render targets
    • Offscreen plain surfaces in the D3DPOOL_DEFAULT memory pool.
    • Surfaces that belong to render target textures.

      Note The destination surface is always in the D3DPOOL_DEFAULT memory pool.

  • The format of the destination surface.

  • The destination rectangle, including rectangles that vary by size, aspect ratio, and location and includes horizontal and vertical lines.

  • The 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


Conformance ECP [-]

Overview

The Conformance ECP [-] 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 a driver's implementation is valid. The operations include 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.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


Conformance ECP [1]

Overview

The Conformance ECP [1] 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 functions within the OpenGL 1.1 library. The tests passes specified valid and invalid parameters 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. The operations include 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 requires the following software:

  • Windows 7
  • Windows Vista
  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


Conformance ECP [2]

Overview

The Conformance ECP [2] 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. The operations include 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 requires the following software:

  • Windows 7
  • Windows Vista
  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


Conformance ECP [3]

Overview

The Conformance ECP [3] 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. The operations include 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 requires the following software:

  • Windows 7
  • Windows Vista
  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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
  • x63


COPPTest

Type: Automated Test

Overview

The COPPTest tests run Certified Output Protection Protocol (COPP) commands to test display drivers for COPP compatibility.

Details

There are three assertions for this test:

  • The display driver must support COPP driver interfaces.

  • The display driver must support CGMS-A and APS.

  • The display driver must support HDCP.

For all of the assertions, the COPPTest test will go through the COPP initialization protocol. If initialization fails, all of the assertions will fail. The tests will not actually verify each protection schema but will only query the driver for the availability.

Run Time: 5 minutes
Log File: shellrunnerapp.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • On Windows Vista, if the graphics card supports a digital connector (DVI or HDMI), you must connect and enable an HDCP-enabled monitor.
  • On Windows Vista, if the graphics card supports an analog connector (component, composite, or S-Video), you must connect and enable the connector.
Processor
  • x86
  • x64

Running COPPTest

On Windows Vista, if the graphics card supports a digital connector (DVI or HDMI), you must connect and enable an HDCP-enabled monitor.

On Windows Vista, if the graphics card supports an analog connector (component, composite, or S-Video), you must connect and enable the connector.

Command Syntax

Command option | Description
ShellRunnerApp.exe -x [basic/premium] -c [Profile_Name] | Specify the SKU and profile variation.

Test Assertions

GRAPHICS-0001 Display adapter supports output connectors with content protection features and provides control via PVP and COPP DDIs
Test Assertion GUID: E486D7C9-997E-4778-8553-72C4FFFB92CC
Windows Logo Program: GRAPHICS-0001 Display adapter supports output connectors with content protection features and provides control via PVP and COPP DDIs
Additional Information: This assertion tests whether the driver can finish the COPP initialization protocol.
1.2 The display driver must support CGMS-A and APS
Test Assertion GUID: AE3ACD54-E11B-4968-8516-D076E37D3EB8
Windows Logo Program: GRAPHICS-0001 Display adapter supports output connectors with content protection features and provides control via PVP and COPP DDIs
Additional Information: On Windows Vista, if the driver supports an analog connector (S-Video, Component, and Composite), you must connect and enable corresponding monitors. For this assertion to be run successfully, driver needs to pass the COPP protocol. After the protocol, the test will start going through the connectors that the driver reports, looking for an analog video adapter. If there are no analog display adapters available, the test will skip. If the test application finds an analog display adapter, CGMS-A and APS must be supported on that adapter. If not, the test will fail for premium SKUs (and skip for basic SKUs).
1.3 The display driver must support HDCP
Test Assertion GUID: 2ECA271F-59E9-4206-9471-D698B28A1A71
Windows Logo Program: GRAPHICS-0001 Display adapter supports output connectors with content protection features and provides control via PVP and COPP DDIs
Additional Information: On Windows Vista, if the driver supports a digital connector (DVI or HDMI), you must connect and enable an HDCP-enabled connector.For this assertion to be run successfully, the driver must pass the OPM protocol. After the protocol, the test will start going through the connectors that the driver reports, looking for an analog video adapter. If there are no analog display adapters available, the test will skip. If the test application finds an analog display adapter, HDCP must be supported on that adapter. If not, the test will fail for premium SKUs (and skip for basic SKUs).


CopyRects Functionality

Type: Automated Test

Overview

The CopyRects Functionality test automatically verifies the functionality that the IDirect3DDevice8::CopyRects method provides by comparing surfaces that tested operations generate with reference surfaces that the test itself generates.

Details

For each Microsoft Direct3D version 8 format, the test uses IDirect3D8::CheckDeviceFormat to determine the surface types, if any, that the driver supports. 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 that the test generates.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Test Assertions

Automatic Verification of IDirect3DDevice8::CopyRects.
Test Assertion GUID: 5.13.1
Windows Logo Program: Anonymous


CRASH Test

Type: Automated Test

Overview

The CRASH test is a system stability test that runs for a specified time. If the system does not stop responding (hang) or encounter bug check during this specified time, the test is considered a Pass.

Details

The Comparative Reliability Analysis of Software and Hardware (CRASH) test runs a specified length of time based on the profiles that are provided. The Windows 7 profiles include more information than others, but the main difference between the profiles is the amount of time set aside for the test to run.

During the CRASH test, several applications start and stop repeatedly. The applications do not need to survive the given time frame to have the overall test be considered a Pass. However, the graphic adapter must not TDR while the test is running. If a failure happens during a test that is related to a TDR, the failure information is captured in the cleanup task TDRWatch. Additional information about the CRASH test, including information about how to run it outside of the Device Test Manager (DTM) test harness, can be found in the CRASH folder. This folder is located on the DTM Controller under: %TestBinRoot%\tests\x86fre\nttest\windowstest\graphics\tests\CRASH.

CRASH Jobs

The Windows Logo Kit (WLK) includes four different versions of the CRASH job. Only a few are attributed for logo. The main difference between the CRASH versions is the length of runtime, which is indicated in the title:

  • CRASH - Display Stress 2-Hour WDDM Profile

  • CRASH - Display Stress 4-Hour WDDM Profile

  • CRASH - Display Stress 12-Hour WDDM Profile (Not included in any logo program)

  • CRASH - Legacy Display Stress

Run Time: 1-12 hours

Log File: CrashOutput.wtl

System Restart Required: No

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Server 2008

  • Windows Vista

  • Windows Server 2008

Requirements

Software Requirements

The test tool requires the following software:

  • One of the supported operating systems in the previous list
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested.
  • Computer that meets the minimum software requirements.
  • Windows keyboard.
  • Two-button pointing device.
  • Color display monitor that has at 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

Troubleshooting CRASH Test Failures

To determine the profile that was run, review the first statement of the test log to find out how long it took for the test to run.

  1. To do this, go to the log file and locate the start time of the test, which is about 15 lines from the top.

  2. Next, scroll to the bottom of the log and locate the end time, which is the last line above the Runtime row. If the total time is less than what you expected for the profile to be run, the system stopped responding (hung) or rebooted during the test. To resolve the problem, connect the system to a debugger and rerun the test.

CRASH log oddities

In log files for failed tests, the following messages will be displayed:

  • TRIAGE: Unable to create path for dump archive. Error Code: 3 - The system cannot find the path specified.

  • TRIAGE: Bad Dump file archive path specified. Using CRASH.exe location.

  • TRIAGE: Dump file archive folder already exists.

  • No dump file found, result = Hung.

These messages are in error and do not contribute to the actual failure of the test. In addition, the CrashDump file is not included in the results.

The CRASH test should run for 1 to12 hours, depending on the job being executed. A test pass either runs to completion or not. If it does not, it is either because the system stopped responding (hung) or generated a bug check with no warning. If the system generates a bug check, there will be a .dmp file generated by the system. The CRASH test looks this .dmp file in the location that is specified by the system. If there is no .dmp file, either the system stopped responding (hung), the user rebooted with no warning, or the system generated a bugcheck but a user interrupted the .dmp generation. There is no way for the CRASH test to determine what the user did, so the test responds as if the system stopped responding. To determine what is causing the test to stop prematurely and fail, run the test under a kernel mode debugger.


CreateSurface

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the CreateSurface test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.
The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.
You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test validates that display drivers gracefully handle CreateSurface calls for all pixel formats that the DirectDraw hardware emulation layer (HEL) supports. Drivers are not required to support the entire pixel format list. Drivers can choose to fail any format that you do not want them 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 can 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 The preceding 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 640 x 480 resolution.

To run this test, use the Fnddraw.exe executable file. with the dd_surf.pro profile.

Run Time: 00:00:10
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running CreateSurface

There are no specific steps to follow for this test. You should run Fnddraw.exe with the dd_surf.pro profile.

Command Syntax

Command option | Description
fnddraw.exe dd_surf.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Cross Process Resource Sharing

Type: Automated Test

Overview

This test is designed to verify that resources created in WDDM must be able to be shared across different process boundaries, in the correct cases.

Details

For this test, WDDM drivers should be installed on the test machine. The test must also be run as an Administrator because, in some of the tests, administrator level privileges are required to allow communication between user processes in different sessions.

The main test process will read from a configuration file, Crossproc.ini, to determine which tests must be run. Depending on the test, it may create one or more processes. These other processes will either create a new resource or be the user of a resource previously created by the main process. Communication between processes will occur through an area of mapped memory, and synchronization will be done with both mutexes and events.

Test Cases:

Tex_Basic_CreateOpen - Creates a shared texture resource with the main process and then shares the handle to that resource with a newly created 'user' process. The 'user' process attempts to open the shared texture.

Tex_OwnerTriesToLock - The creating process should be able to lock the shared resource at any time. This test has the owner attempt to lock this resource, once with no other references to the resource, and once with other references.

Tex_OwnerGoesAway - This test has the 'user' process create a shared resource, and then the main process opens it. Once the main process opens the resource, the creating process is killed off. The using process in this scenario should still have a reference to a valid resource.

Tex_UserTriesToLock - The using process should not be able to lock a shared resource. This test attempts to lock the resource on a non-owning process. It is expected to fail.

Tex_ValidateTexture - This test validates that the using process has a handle to the same resource as was created by the owner. The owner colorfills a shared texture and then the using process opens the texture and blits it to a new surface. The surface is then checked for conformity against the colorfill texture.

Tex_MultiUser_Scenario - This test creates a shared resource with the main process and then several new processes are created and simultaneously try to access the resource.

Tex_RoundRobin - This test creates a shared resource with the main process, then user processes are created in round robin style one at a time. Each new user process opens the shared resource and the previous user process is closed. This test attempts to check for race conditions.

Tex_CrossAdapterNotShare - This test creates a shared resource (texture) on one adapter. It then attempts to open the shared resource on a different adapter in the system. The shared resource should not be accessible on the adapter that did not create the resource. If there are less than two adapters (the adapter must be attached to a desktop to be counted as present), the test will be skipped.

Tex_CrossSessionNotShare - This test creates a shared resource in a process in one user session, it then uses Fast User Switching (FUS) to get to another user session on the computer (the test will automatically create the new user) and launches another process that tries to access the shared resource created in a different session. The process in the second session should not be able to access the shared resource created in the first user session. This test requires the FUS framework to be installed on the user's computer. If FUS is not installed, the DTM tool will install it before the test is run. If the FUS framework is not installed and the user attempts to run this test, the test will be skipped.

Run Time: 5 minutes
Log File: Crossproc.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • In order to run the CrossAdapterNotShare test, two graphics adapters are required, and a monitor must be attached to each adapter.
Processor
  • x86
  • x64


D3D9 Overlay - CheckDeviceOverlayType

Type: Automated Test.

Overview

This test executes multiple test cases targeting IDirect3D9ExOverlayExtension::CheckDeviceOverlayType with different sizes of both valid and invalid display modes, including rotated modes.

Details

CheckDeviceOverlayType:

  • Verify failure if Adapter index is out range.

  • Verify a NULL pDisplayMode returns the same results as a pDisplayMode filled in with the current display mode.

  • Verify D3DERR_UNSUPPORTEDOVERLAYFORMAT by finding a successful overlay type and cycling on OverlayFormats.

  • Verify D3DERR_UNSUPPORTEDOVERLAY will be returned for an invalid width and height by finding a successful overlay type and cycling on non-standard overlays sizes.

CheckDeviceOverlayType with CreateDeviceEx interaction:

  • Verify that a successful call to CheckDeviceOverlayType can result in a successful call to CreateDeviceEx.

    Note This will always be the case until driver support is added.

  • Verify that a failed call to CheckDeviceOverlayType will result in a failed call to CreateDeviceEx.

    Note This test case will fail until driver support is added.

Run Time: 1-5 minutes
Log File: D3D9OverlayTest.xml
System Restart Required: No
Test Category: D3D9/Functional
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: D3D9OverlayTest.exe CheckDeviceOverlayType

Requirements

  • D3D9 support exposing D3DCAPS_OVERLAY

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Driver that supports D3DCaps9.Caps D3DCAPS_OVERLAY

  • Computer that meets the minimum software requirements

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

The test calls into CheckDeviceOverlayType with valid and invalid parameters and attempts to check the largest overlay size, as well as the smallest reported as supported by the driver.

The test might return SKIP if the driver does not expose D3DCAPS_OVERLAY. Some cases might skip if the back buffer format or mode is not supported during d3d device creation.

Command Syntax

Command option | Description
D3D9OverlayTest.exe CheckDeviceOverlayType | Without any options, the test enumerates all but some extreme invalid argument test cases.
TestCasePriority:[0, 1, 2] | Specifies the priority of the test cases to run. 0 will run BVT level test cases 1,2 more aggressive test cases.
LogLevel[0, 1, 2] | The test has the ability to be very verbose in its logging methods. By default, level 0 is set; however, level one will gather increased logging info per test cases including many stream states/blt states set. Level 2 will gather all adjusted stream states and blt states, as well as any configuration information.

File Manifest

File | Location
D3D9OverlayTest.exe | [testbinroot]\nttest\windowstest\graphics\d3d\func\


D3D9 Overlay - CreateAdditionalSwapChain

Type: Automated Test.

Overview

This test executes multiple test cases targeting IDirect3D9Ex::CreateDevice with IDirect3D9ExDevice::CreateSwapChain with different sizes of both valid and invalid display modes/flags and overlay sizes. It also tests different types of swap chain creation FLIP w/ Overlay Overlay w/ Discard, etc.

Details

CreateDeviceEx:

  • Verify successful creation of non-RGB backbuffer if non-RGB overlay is supported.

  • Verify swapeffect fails full screen and is successfully windowed.

  • Verify swapeffect fails when using interface other than D3D9OverlayExtended.

  • Verify that Multisampling fails.

  • Test case where a D3D9Ex overlay device has been created by one process and then another process attempts to create another D3D9Ex swapchain.

  • Verify CreateDeviceEx with D3DPRESENTFLAG_OVERLAY_LIMITEDRGB successfully limits color range during present time to 16...235 if supported by the driver. See PresentEx tests below.

  • Verify CreateDeviceEx with D3DPRESENTFLAG_OVERLAY_YCbCr_BT709 successfully increases luma and chroma sampling, as well as limiting the RGB values to 16...235 during present time if supported by the driver. See PresentEx tests below.

  • Verify CreateDeviceEx with D3DPRESENTFLAG_OVERLAY_YCbCr_xvYCC successfully increases RGB color range to 1...255 during present time if supported by the driver. See PresentEx tests below.

  • Verify CreateDeviceEx with unsupported D3DPRESENTFLAG (fails ? succeeds)

CreateAdditionalSwapChain:

  • Verify creation of additional swapchains fails both through CreateAdditionalSwapChain and Reset of a swapchain that already exists.

Run Time: 1-5 minutes
Log File: D3D9OverlayTest.xml
System Restart Required: No
Test Category: D3D9/Functional
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: D3D9OverlayTest.exe CreateAdditionalSwapChain

Requirements

  • D3D9 support exposing D3DCAPS_OVERLAY

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Driver that supports D3DCaps9.Caps D3DCAPS_OVERLAY

  • Computer that meets the minimum software requirements

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

This test calls into CreateAdditionalSwapChain with valid and invalid parameters and attempts to check the largest overlay size, as well as the smallest reported as supported by the driver. The test simply executes create calls; nothing is presented to the screen. The test might return SKIP if the driver does not expose D3DCAPS_OVERLAY. Some cases might skip if the back buffer format or mode is not supported during d3d device creation.

Command Syntax

Command option | Description
D3D9OverlayTest.exe CreateAdditionalSwapChain | Without any options, the test enumerates all but some extreme invalid argument test cases.
TestCasePriority:[0, 1, 2] | Specifies the priority of the test cases to run. 0 will run BVT level test cases 1,2 more aggressive test cases.
LogLevel[0, 1, 2] | The test has the ability to be very verbose in its logging methods. By default, level 0 is set; however, level one will gather increased logging info per test cases including many stream states/blt states set. Level 2 will gather all adjusted stream states and blt states, as well as any configuration information.

File Manifest

File | Location
D3D9OverlayTest.exe | [testbinroot]\nttest\windowstest\graphics\d3d\func\


D3D9 Overlay - CreateDeviceEx

Type: Automated Test.

Overview

This test executes multiple test cases targeting IDirect3D9Ex::CreateDeviceEx with different sizes of back buffer and formats, with and without invalid flags and multisampling. Both valid and invalid display modes including rotated modes.

Details

CreateDeviceEx:

  • Verify successful creation of non-RGB backbuffer if non-RGB overlay is supported.

  • Verify swapeffect fails full screen and is successfully windowed.

  • Verify swapeffect fails when using interface other than D3D9OverlayExtended.

  • Verify that Multisampling fails.

  • Test case where a D3D9Ex overlay device has been created by one process, and then another process attempts to create another D3D9Ex swapchain.

  • Verify CreateDeviceEx with D3DPRESENTFLAG_OVERLAY_LIMITEDRGB successfully limits color range during present time to 16...235 if supported by the driver. See PresentEx tests below.

  • Verify CreateDeviceEx with D3DPRESENTFLAG_OVERLAY_YCbCr_BT709 successfully increases luma and chroma sampling, as well as limiting the RGB values to 16...235 during present time if supported by the driver. See PresentEx tests below.

  • Verify CreateDeviceEx with D3DPRESENTFLAG_OVERLAY_YCbCr_xvYCC successfully increases RGB color range to 1...255 during present time if supported by the driver. See PresentEx tests below.

  • Verify CreateDeviceEx with unsupported D3DPRESENTFLAG (fails ? succeeds).

CreateDeviceEx with ResetEx:

  • Verify CreateDeviceEx with specified D3DPRESENTFLAG is successfully overridden when a different D3DPRESENTFLAG is specified during ResetEx of the device.

  • Verify ResetEx with unsupported D3DPRESENTFLAG (fails ? succeeds).

Run Time: 1-5 minutes
Log File: D3D9OverlayTest.xml
System Restart Required: No
Test Category: D3D9/Functional
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: D3D9OverlayTest.exe CreateDeviceEx

Requirements

  • D3D9 support exposing D3DCAPS_OVERLAY

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Driver that supports D3DCaps9.Caps D3DCAPS_OVERLAY

  • Computer that meets the minimum software requirements

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

The test calls into CreateDeviceEx with valid and invalid parameters and attempts to check the largest overlay size, as well as the smallest reported as supported by the driver. The test does not present any frames to the screen and simply iterates over test cases and produces pass/fail.

The test might return SKIP if the driver does not expose D3DCAPS_OVERLAY or if the back buffer format or mode is not supported during d3d device creation.

Command Syntax

Command option | Description
D3D9OverlayTest.exe CreateDeviceEx | Without any options, the test enumerates all but some extreme invalid argument test cases.
TestCasePriority:[0, 1, 2] | Specifies the priority of the test cases to run. 0 will run BVT level test cases 1,2 more aggressive test cases.
LogLevel[0, 1, 2] | The test has the ability to be very verbose in its logging methods. By default, level 0 is set; however, level one will gather increased logging info per test cases including many stream states/blt states set. Level 2 will gather all adjusted stream states and blt states, as well as any configuration information.

File Manifest

File | Location
D3D9OverlayTest.exe | [testbinroot]\nttest\windowstest\graphics\d3d\func\


D3D9 Overlay - PresentEx

Type: Automated Test.

Overview

This test executes multiple test cases targeting IDirect3D9DeviceEx::PresentEx. There are specific test cases around dest rect movement resize, colorkey all with and without DWM enabled. There are cases around hiding the overlay and changing modes during presentation. Presenting overlays overtop of existing flip content. If supported, both RGB and non-RGB overlays are tested in common context modes meaning (480p/i, 720p, 1080i, etc.)

Details

PresentEx:

  • Verify that moving, resizing, un-occluding, and changing dest rects for a window will update color key data appropriately. Cycle with DWM on/off.

  • Verify that moving a window after calling PresentEx with D3DPRESENT_UPDATEOVERLAYONLY will not cause an actual flip, and that the position and colorkey data will update. Cycle with DWM on/off.

  • Verify that if the device or swapchain is destroyed without first using D3DPRESENT_HIDEOVERLAY to turn off the overlay, that the overlay is somehow cleaned up. DxgKrnl is expected to cleanup, but d3d9 will handle cleanup in most cases.

  • Verify that D3DPRESENT_HIDEOVERLAY turns off the overlay

  • Addition of a device parameter to allow test cases to be run on either device/monitor, as well as different configurations (Clone/Extended/etc.)

PresentEx:

  • Verify present of non-overlay frame in current mode while an overlay frame is already presented is successful. Then, upon release, the subsequent overlay present call results in a successfully presented image.

  • Verify present of non-overlay frame in a mode other than current desktop mode while an overlay frame is already presented is successful. Then, upon release, the subsequent overlay present call results in a successfully presented image.

  • Verify present of non-overlay frame windowed while an overlay frame is already presented is successful. Then, upon release, the overlay is still the correctly presented image.

PresentStatistics:

  • Validate that present statistics are not available/supported.

Power Management:

  • Verify all sleep states.

Frame Capture and comparison implementation:

  • Implementing comparison of a SW reference frame and the HW rendered overlay will constitute a testable unit. This implementation will provide the ability to compare a SW rendered reference frame with the HW rendered frame providing a PSNR with specified level of tolerance. This tolerance must be higher than lower due to having to utilize the HW Frame capture device. On analog connections, this device can cause color ranges to be compressed/stomped, which produces an increased difference between rendered frame and actual displayed frame.

  • When developed, this comparison can be implemented on each parameterized test case, including the different D3DFORMATs. It then validates each frame when rendered.

Valid Cases:

These cases must be tested in combination. Automated verification is achieved using VGA/DVI image capture and compared against a compatible reference image.

  • Verify RGB and non-RGB format with range of supported overlay sizes (specifically commonly used 720p, 1080i, etc.)

  • Verify RGB Overlay formats 32bit.

  • Verify Display mode formats for 5:6:5, 8:8:8 and 2:10:10:10.

  • Verify all non-RGB YUV, UYVY, YUY2, NV11, P208, and etc.

  • Verify Refresh rate (smallest, middle, and largest).

  • If D3DOVERLAYCAP STRETCHX is exposed:

    • Verify that stretching to an arbitrary size greater than the source surface width but less than MaxOverlayDisplayWidth is supported.

      Note Size will be non-multiple of 2.

    • Verify that stretching on the x axis is successful at MaxOverlayDisplayWidth.

    • Verify that shrinking on the x axis is successful at a reasonable size smaller than the source surface width.

      Note Size will be non-multiple of 2.

    • Verify that shrinking is successful down to 1 pixel width.
    • Verify that a source surface greater than MaxOverlayDisplayWidth can be displayed shrunk at MaxOverlayDisplayWidth (or smaller, depending on display mode resolution).
  • If D3DOVERLAYCAP STRETCHY is exposed:

    • Verify that stretching to an arbitrary size greater than the source surface height but less than MaxOverlayDisplayHeight is supported.

      Note Size will be non-multiple of 2.

    • Verify that stretching on the Y axis is successful at MaxOverlayDisplayHeight.

    • Verify that shrinking on the Y axis is successful at a reasonable size smaller than the source surface height.

      Note Size will be non-multiple of 2.

    • Verify that shrinking is successful down to 1 pixel height.
    • Verify that a source surface greater than MaxOverlayDisplayHeight can be displayed shrunk at MaxOverlayDisplayHeight (or smaller, depending on display mode resolution).
  • If D3DOVERLAYCAP STRETCHY and If D3DOVERLAYCAP STRETCHX is exposed:
    • Verify that stretching to an arbitrary size greater than the source surface width and height but less than MaxOverlay Width and MaxOverlayDisplayHeight is supported. Note Size will be non-multiple of 2.

    • Verify that shrinking on the X and Y axis is successful at a reasonable size smaller than the source surface width and height.

      Note Size will be non-multiple of 2

  • Test all supported color ranges: D3DPRESENTFLAG_OVERLAY_YCbCr_xvYCC, D3DPRESENTFLAG_OVERLAY_YCbCr_BT709, D3DPRESENTFLAG_OVERLAY_LIMITEDRGB

Run Time: 20-45 minutes (depending on formats supported and size constrictions)
Log File: D3D9OverlayTest.xml
System Restart Required: No
Test Category: D3D9/Functional
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: D3D9OverlayTest.exe PresentEx

Requirements

  • D3D9 support exposing D3DCAPS_OVERLAY

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Driver that supports D3DCaps9.Caps D3DCAPS_OVERLAY

  • Computer that meets the minimum software requirements

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

The test presents color bars similar to those seen on television in different sizes and modes. The frames presented are few between 1-10 and in many cases are not visible without stepping through the test. The reason for this is because internal testing requires frame capture devices, and capturing screen contents can be quite slow and validating more than 1-10 frames is taxing.

The test might return SKIP if the driver does not expose D3DCAPS_OVERLAY or if the back buffer format or mode is not supported during d3d device creation.

Command Syntax

Command option | Description
D3D9OverlayTest.exe PresentEx | Without any options, the test enumerates all but some extreme invalid argument test cases.
TestCasePriority:[0, 1, 2] | Specifies the priority of the test cases to run. 0 will run BVT level test cases 1,2 more aggressive test cases.
LogLevel[0, 1, 2] | The test has the ability to be very verbose in its logging methods. By default, level 0 is set; however, level one will gather increased logging info per test cases including many stream states/blt states set. Level 2 will gather all adjusted stream states and blt states, as well as any configuration information.

File Manifest

File | Location
D3D9OverlayTest.exe | [testbinroot]\nttest\windowstest\graphics\d3d\func\


D3D Content Protection - CPAuthChannelAPI (32-bit) D3D Content Protection - CrossProc (32-bit) D3D Content Protection - CryptoSession (32-bit) D3D Content Protection - DriverProtections (32-bit)

Type: Automated Test.

Overview

Starts the test app and runs the test group specified on the command line.

Test Groups for D3Dprotection.exe.

CPAuthChannelapi: Query/Configure the driver using Authenticated channel tests.

Cryptosession: Encryption and Decryption Blt tests

DriverProtections: ReadbacK protection tests.

Details

Run Time: 5 minutes
Log File:D3DProtection.log
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program:D3DProtection.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the feature is not implemented.

Command Syntax

Command option | Description
CrossProcShare_Pro.exe | Without any options, the test enumerates devices.
D3DProtection.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.

Code Tour

File Manifest

File | Location
D3DProtection.exe | [testbinroot]\nttest\WINDOWSTEST\Graphics\d3d\conf\
ContentProtection_CrossProc.exe | [testbinroot]\nttest\WINDOWSTEST\Graphics\d3d\conf\


D3D Cross Process Sharing

Overview

The D3D Cross Process Sharing test verifies support for Microsoft Direct3D version9 cross-process resource sharing.

Details

This test includes the following test cases:

  • CONF:Create - Create shared resource.

  • CONF:Open - Create and open a shared resource in the same process.

  • CONF:ClientOpen - Create a shared resource in Proccess1 and open that resource in Process2

  • CONF:Verify - Process2 verifies that the opened resource's content is correct.

  • CONF:Fill - Process2 fills the open resource and Process1 verifies the content.

  • CONF:Lock - Process1 locks the resource, Process2 locks the resource (this attempt should fail), Process2 unlocks the resource (this attempt should fail), Process1 unlocks the resource, Process2 locks the resource (this attempt should fail), Process2 unlocks the resource (this attempt should fail), and Process1 unlocks the resource(this attempt should fail).

  • CONF:ReleaseSourceUseOpen - Process1 creates a resource, Proccess2 opens the resource, Proccess2 verifies the content of the resource, Proccess1 releases the resource, Process2 uses the resource, Process1 opens the resource, and Process1 updates the resource content.

The test cycles on resources types or you can control lock onto just one resource type by using the command line. To run with only one resource type use -ResourceType:<ResourceType>.

You can use the following resource types:

  • OFFSCREENPLAIN

  • DEPTHSTENCIL

  • RENDERTARGET

  • TEXTURE

  • VOLUMETEXTURE

  • VERTEXBUFFER

  • INDEXBUFFER

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


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 Microsoft Direct3D functions.

Details

The D3D Invalid Parameters test calls the Direct3D function with invalid parameters. Most of these invalid parameters are passed on to the display driver. Display drivers must validate parameters on data that user-mode clients generate to ensure that the system does not stop responding (that is, "crash" or "hang").

Run Time: 45 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

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


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 memory pointers are passed to the Microsoft Direct3D functions.

Details

The D3D Invalid Parameters - Bad Pointers test calls the Direct3D function with invalid memory pointers. Some of these invalid pointers are passed on to the display driver. Display drivers must validate parameters on data that user-mode clients generate to ensure that the system does not stop responding (that is, "crash" or "hang").

Run Time: 45 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


D3DQuery Conformance Test

Overview

The D3DQuery Conformance Test checks for driver support for Microsoft DirectX 9.0 asynchronous notifications.

Details

This test validates the functional and operational specifications for the 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 run either synchronously (that is, the application waits) or asynchronously (that is, the application does not wait). The asynchronous notification API consists of the IDirect3DDevice9::CreateQuery, IDirect3DDevice9::Issue, and IDirect3DDevice9::GetData methods.

The Microsoft Direct3D API defines a fixed set of query types, and the driver supports the query types that it chooses during setup. This test validates only the query types that the driver supports. All other query types are not validated.

This test requires Microsoft DirectX 9.0.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

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 check is performed by counting the number of iterations that are 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 typically involve verifying that the data that a query returns 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.

Return value

The driver returns D3DERR_NOTAVAILABLE if the query type is not supported.

Interpreting results

The test writes the test results to D3DQuery.xml log file and displays on-screen pass or fail compliance. The test log is written to the %windir%\dxlogs directory.

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
  • Microsoft DirectX 9.0
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running D3DQuery Conformance Test

There is no special setup or configuration to run this test.

To run this test, run D3DQuery.exe.


DDraw AGP Memory Tests

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the DDraw AGP Memory test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

The DDraw AGP Memory test ensures that the DirectDraw graphics adapter creates basic AGP surfaces.

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:03:05
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running DDraw AGP Memory Tests

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_agp.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Ddraw Blt - Basic - AGP to Primary

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the DDraw Blt - Basic - AGP to Primary test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.
The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test ensures that the FNDDRAW blt function for the DirectDraw graphics adapter can handle several conversion blts from various memory surfaces.

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:05:05
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running DDraw Blt - Basic - AGP to Primary

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_avb.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Ddraw Blt - Color Key - AGP to Primary

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the DDraw Blt - Color Key - AGP to Primary test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test ensures that the DirectDraw graphics adapter can process Color key blts from AGP surfaces to the primary surface.

To run this test, use the Fnddraw.exe executable file.

Run Time: 00:06:40
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running DDraw Blt - Color Key - AGP to Primary

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_ckav.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Ddraw Blt - ColorFill - AGP

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the DDraw Blt - ColorFill - AGP test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

The purpose of the DDraw Blt - ColorFill - AGP tests is to verify that the graphics adapter can successfully perform color fill blt operations 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 so that a variety of sizes and memory alignments are tested. The results of the color fills are compared against a reference image that is generated by using GDI.

Drivers are not required to support color fill operations on AGP surfaces. DirectDraw can perform these operations in its emulation layer. Flags that are passed to DirectDraw indicate whether or not a display driver supports color fill operations on AGP surfaces. If the driver sets flags that indicate support, the generated image must match the reference image exactly.

The Microsoft Windows Driver Kit (WDK) documents which flags a driver sets to indicate support for AGP color fills.

To run this test, use the Fnddraw.exe executable file with the BLT Color Fill AGP Mem test case.

Run Time: 00:01:50
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running DDraw Blt - ColorFill - AGP

There are no specific steps to follow for this test. You should run Fnddraw.exe with the BLT Color Fill AGP Mem test case.

Command Syntax

Command option | Description
fnddraw.exe dd_acf.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


DDraw Blt - ColorFill - System Memory

Overview

The DDraw Blt - ColorFill - System Memory test checks for color fill operations on System memory surfaces.

Details

This test verifies that a graphics adapter can successfully perform color fill blt operations on system memory surfaces.

The test performs a series of color fill operations directly onto an offscreen system memory surface. Fill regions (RECTs) are chosen so that a variety of sizes and memory alignments are tested. The results of the color fills are compared against a reference image that is generated by using GDI.

Display drivers must support hardware-accelerated color fills. Drivers indicate this support by setting the DDCAPS_BLTCOLORFILL flag.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running DDraw Blt - ColorFill - System Memory

To run this test, use the Fnddraw.exe executable file with the BLT Color Fill System Memory test case.

To run this test manually, run fnddraw dd_scf.pro -r.


DDraw Blt - ColorFill - Video Memory

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the DDraw Blt - ColorFill - Video Memory test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test verifies that a graphics adapter can successfully perform color fill blt operations on video memory surfaces.

The test performs a series of color fill operations directly onto the primary surface. Fill regions (RECTs) are chosen so that a variety of sizes and memory alignments are tested. The results of the color fills are compared against a reference image that is generated by using GDI.

Display drivers must support hardware-accelerated color fills. Drivers indicates this support by setting the DDCAPS_BLTCOLORFILL flag.

Run Time: 00:02:50
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running DDraw Blt - ColorFill - Video Memory

There are no specific steps to follow for this test. You should run Fnddraw.exe with the BLT Color Fill Primary test case.

Command Syntax

Command option | Description
fnddraw.exe dd_vcf.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


DDraw Blt - Stretch - AGP to Primary

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the DDraw Blt - Stretch - AGP to Primary test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test ensures that the DirectDraw graphics adapter can process blts that are stretched from AGP surfaces to the primary surface.

Run Time: 00:28:32
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running DDraw Blt - Stretch - AGP to Primary

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_sbav.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


DDraw Blt - Stretch & Color Key - AGP to Primary

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the DDraw Blt - Stretch & Color Key - AGP to Primary test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test ensures that the DirectDraw graphics adapter can process various combinations of stretch and color key blts from AGP surfaces to the primary surface.

Run Time: 00:12:40
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running DDraw Blt - Stretch & Color Key - AGP to Primary

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_sckav.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


DDRAW Cubic

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the DDRAW Cubic test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test attempts to create a variety of valid and invalid cubic maps and verifies the driver handles it properly. This test runs only if the driver supports cubic environment maps for 3-D.

Run Time: 00:00:05
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running DDRAW Cubic

There are no specific steps to follow for this test. You should run Fnddraw.exe.

Command Syntax

Command option | Description
fnddraw.exe dd_cube.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen applications can cause failures, so you should avoid them.

Reference Documentation

Microsoft 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


Depth Stencil Readback

Overview

The Depth Stencil Readback test checks for WLP 3.0 - GRAPHICS-0014 and verifies the Microsoft Direct3D version 9 Depth Stencil Read/Write capability.

Details

This test checks for GRAPHICS-0014, verifies D3D9 Depth Stencil Read/Write capability, and verifies that video memory depth buffer contents can be copied to and from lockable system memory formats.

The driver must support:

  • D3DFMT_S8_LOCKABLE

  • At least one of the following:
    • D3DFMT_D16_LOCKABLE
    • D3DFMT_D32F_LOCKABLE
    • D3DFMT_D32_LOCKABLE

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


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 requires the following software:

  • Windows 7
  • Windows Vista
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • 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.
Processor
  • x86
  • x64

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 | ??


DirectDraw Test

Type: Automated Test

Overview

Subset of the DirectDraw tests for system testing. This test used to be part of the HCT kit.

Details

The DirectDraw test is a subset of the DirectDraw tests from the Display Driver test kit. It tests bltting, locking, overlays, and memory management.

Tests exercise the video adapter and verify basic DirectDraw compatibility.

To run the test outside of the DTM, use:
fnddraw.exe dx_wdk.pro -r

Run Time: 3 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Cautions

Test runs under assumption that it has an almost complete control of the system. Background processes that steal focus or change modes can cause false failures.

Troubleshooting

Some of the blt tests respond to the PAUSE key, giving you more time to view the results. This can aid in debugging blt failures.

Most of the blt tests will also log additional info about mismatching pixels if you increase the logging level from 1 to 2. You will need to run the test outside of the DTM to do this. Launch the test outside of the DTM.

fnddraw dx_wdk.pro

Select Set Logging from the Options menu. This will bring up the logging dialog. Use this dialog to change the logging level.


Display Power Test

Type: Automated Test

Overview

The Display Power Test (Apmdisp.exe) verifies that a display device still maintains its refresh rate at all supported low-power states.

Details

This test uses the undocumented WM_MONITORPOWER message to initiate power management state setting code for User.exe. This code is the same code that is run when a suspend/resume cycle is initiated. This code causes the main VDD to set the display card into the D0, D2, or D3 state.

On a transition from any sleep state that is greater than D0 to D0, the test polls the refresh rate by using an IDirectDraw, IDirectDraw4, or IDirectDraw7 interface coupled with GetMonitorFrequency (which fails on Windows NT only), GetVerticalBlackStatus, and WaitForVerticalBlanck. The test then compares the results against each other with a tolerance of 1 Hz.

Run Time:
Log File: apmdisp
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

To run this test, you must install Microsoft Windows XP and Microsoft DirectX version 8 or later.

Driver Test Manager (DTM) runs the Display Power test with the following options:

apmdisp.exe /a /is5 /ts60

In the preceding code example, /a is auto start state, /is5 sets the maximum test interval to 5 seconds, and /ts60 sets the maximum test time in seconds.

In a Command Prompt window, you can run apmdisp.exe /? to show the list of command-line options for running this test.

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0006 Display adapter or chipset complies with power management specifications


Display-Tests for Media Center

Type: Automated Test

Overview

The Display-Tests for PCs with Tuners test is run by the TvWLPGraphicsTests application that calls up to four Microsoft DirectShow filters.

This test verifies that a system can support Media Center TV playback functionality. The test covers the GRAPHICS-0001, GRAPHICS-0043, and GRAPHICS-0055 tests.

Details

TvWLPGraphicsTests is a command-line application that Driver Test Manager (DTM) calls and that verifies most of the Media Center requirements. Failure on any requirement will cause the whole job to fail.

This test verifies the following requirements:

  • GRAPHICS-0001 tests the content protection portion of this requirement.

    Title: Test Display Adapter Supports and Exposes Video Output Connector

    Success: This test will succeed if any of the following conditions are true:

    • The display adapter supports APS or Macrovision copy protection.
    • The display adapter exposes required timings.
    • The test can switch TV-out to TV playback mode while TV-out is connected to TV Display device, and, while in this mode, the display adapter disables flicker filter and overscan compensation.
    • The TV is in the proper TV standard (that is NTSC, PAL, or SECAM).
    • The test can successfully switch a TV in proper TV standard to Win Graphics mode while TV-out is connected to VGA Display device.
    • The display adapter has TV standard set to WIN VGA

    Failure: This test will fail if any of the following conditions are true:

    • You stop the test.
    • The display adapter does not support APS or Macrovision copy protection.
    • The display adapter does not expose required timings.
    • The test cannot switch TV-out to TV playback mode while TV-out is connected to TV Display device.
    • The display adapter does not disable flicker filter and overscan compensation while in TV playback mode.
    • The display adapter does not report proper TV standard such as NTSC, PAL, SECAM.
    • The driver fails to report required values that are used to determine if it is in the proper mode and has disabled flicker filter and overscan compensation.
    • The test cannot switch to Win Graphics mode while TV-out is connected to VGA Display adapter and if it does not have WIN VGA TV standards on TV-out while in this mode.
    • The test fails to set TV Standards and playback modes.
    • The 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 all the required timings and modes shown in the following table.

    Failure: This test will fail if the display adapter does not support one or more of the required timings or modes shown in the following table.

    Width Height Frequency Interlaced

    1920

    1080

    60

    True

    1920

    1080

    59

    True

    1920

    1080

    50

    True

    1920

    1080

    30

    True

    1920

    1080

    29

    True

    1920

    1080

    25

    True

    720

    480

    59

    False

    720

    576

    50

    False

    1280

    720

    60

    False

    1280

    720

    59

    False

    1280

    720

    50

    False

  • GRAPHICS-0055

    Title: Test Display Sub-System Supports Digital TV Resolution and Timing

    Success: This test will succeed if the display device has digital interfaces and supports all the required digital timings and modes shown in the preceding table. It will also succeed if the display adapter does not have a digital interface, because this test does not require timings and modes to be checked for display adapters that do not have a digital interface.

    Failure: This test will fail if a display adapter with a digital interface does not support one or more of the required digital timings or modes shown in the preceding table.

Run Time: 5 minutes
Log File: TvWLPLog.xml
System Restart Required: No
Supported operating systems for Windows logo testing:

  • Windows Vista and Windows 7

Requirements

Software Requirements

  • Software components included with the device under test (DUT)

  • Display Driver

  • The test tool running a supported Windows operating system:
    • Windows Vista
    • Windows 7

Hardware Requirements

  • Device to be tested

  • Test computer that meets the following minimum software requirements:
    • 1 GHz processor
    • 1 GB of system RAM
    • 40 GB free hard drive space
    • Audio support
    • Windows keyboard
    • Two button pointing device
    • Minimum Graphics Card and Display Support:
      • DirectX 9 or Greater support
      • Supported WDDM Driver
      • 128 MB of on-board graphics card memory
      • Pixel Shader 2.0 support
      • 32 bits per pixel or greater support

Processor

The following processor architectures:

  • x86

  • x64

Running Display-Tests for Media Center

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

  1. Run this test to iterate and test each of the requirements listed earlier.

  2. Handle prompts as they occur.

Command Syntax

Command option | Description
tvwlpgraphicstests.exe <test case ID> "<Device ID of device you want to test>" | Executes tvwlpgraphicstests.exe using the Test Case ID and the Device ID specified.

Code Tour

File Manifest

File | Default Location
tvwlpgraphicstests.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest\

Test Assertions

Test Assertion GUID:

  • GRAPHICS-0001: C1ACAFC7-7B01-494B-9790-E6EC65DAA711

  • GRAPHICS-0043: 877827BC-D6A1-463F-9FCB-11899B7FA5F0

  • GRAPHICS-0055: 4892A09B-905F-490C-A112-15444A3EABE7

Windows Logo Program: Windows Logo program


Driver Scenario

Type: Automated Test

Overview

The Driver Scenario test verifies that the display adapter can meet the minimum Microsoft Direct 3D requirements. For the full list of minimum requirements, refer to the latest Windows Logo Program (WLP) documentation.

Details

The test composes a Direct 3D scene that includes all of the relevant elements from the WLP minimum requirements, such as Gouraud shading, basic alpha blending, Bi-Linear filtering, specific texture formats, and so on. The test then renders the scene with the display adapter and with the reference rasterizer.

The test does a pixel comparison of the rendered images and determines if the test passed or failed based on that comparison (allowing the standard 15% difference).

Run Time:
Log File: scenario.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapter with Direct 3D capabilities
Processor
  • x86
  • x64
  • Itanium

Running Driver Scenario

Run scenario.exe with the -WHQL command line option.

Reference Documentation

Microsoft DirectX SDK


DX10 Graphics Enforcement Test

Type: Automated Test

Overview

This job verifies that DX10 is supported by the Display Adapter, as it is a requirement of Vista Premium and Windows 7 submissions (Graphics-0020).

Details

Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2008

Program:D3D10MiscDevice.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

This test verifies whether DirectX10 is supported by the Display Adapter. It will return a Pass or a Fail.

File Manifest

File | Location
Test.exe | [testbinroot]\nttest\windowstest\graphics\d3d\api\


DXGI - Frame Statistics

Overview

The DXGI - Frame Statistics test verifies support for DXGI's Frame Statistics.

Details

This test verifies the DXGI_FRAME_STATISTICS buffer for calls to the DXGISwapChain::GetFrameStatistics and DXGIOutput::GetframeStatistics functions. PresentCounts should be updated according to the DXGISwapChain::Present function.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


DXGI Gamma Ramps

Type: Automated Test

Overview

The DXGI Gamma Ramps and DXGI Gamma Ramps Multihead tests cycle setting and reads a variety of gamma options using the DXGI output's SetCammaControl function.

Details

The DXGI Gamma Ramps test has three tests cases: Curve, Offset, and Scaling. Each group modifies the individual component of the DXGI_GAMMA_CONTROL struct and then sets it using SetGammaControl.
typedef struct DXGI_GAMMA_CONTROL

{

DXGI_RGB Scale;

DXGI_RGB Offset;

DXGI_RGB GammaCurve[ 1025 ];

} DXGI_GAMMA_CONTROL;
Run Time: 5 minutes
Log File: DXGIGammaVM.xml
System Restart Required: No
Test Category: Display
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows 7

Program: DXGIGammaVM.exe

Requirements

Software Requirements

  • Supported operating system (see list above).

Hardware Requirements

  • Video card with support for DXGI.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the DXGI GammaCapabilities cap ScaleAndOffsetSupportd is not set.

Command Syntax

Command option | Description
DXGIGammaVM.exe | Without any options, the test enumerates all outputs and tries to set the gamma on each.
-? | Show all commands lines options
-Step | Run one case a time. This allows quick debugging and jumping to test cases

Code Tour

File Manifest

File | Location
DXGIGammaVM.exe | [testbinroot]\NTTEST\WINDOWSTEST\Graphics\d3d\conf


DXGI - GetAdapterIdentifier and Output Enumeration

Type: Automated Test

Overview

The DXGI - GetAdapterIdentifier and Output Enumeration test verifies that the IDXGIAdapter::GetAdapterIdentifier and IDXGIAdapter::EnumOutputs methods are correctly implemented.

Details

This test simply compares the results that DXGI generates with the results that the corresponding Microsoft Direct3D 9 methods generated.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


DXGI GDI Interop (D3D10.1/11 and all associated feature levels)

Type: Automated Test

Overview

This test verifies that video adapters/drivers can support DXGI/GDI interop well. This feature is served as infrastructure of D2D.

Details

DXGI/GDI interop is supported by D3D10.1 or later on Windows 7 IP and Windows 7. This test should be run on video adapters/drivers for D3D10.1 and later, as well as associated feature levels.

Run Time: 28 minutes for all tests
Log File: dxgigdiinterop.xml.
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: dxgigdiinterop.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

During testing, windows will pop up, which are filled with red, green, blue, white, and black colors. Sometimes lines are drawn or text is displayed.

After testing, all windows should be closed. Check the log files to make sure that no test case has failed. All test cases should either be passed or skipped (for unsupported features).

Command Syntax

Command option | Description
dxgigdiinterop.exe | 1) -DX10.1 // test drivers supporting native D3D10.1 2) -DX10.1 -featurelevel:9.x // x=1,2,and 3. test all drivers supporting D3D10.1 on featurelevel:9.x 3) -DX10.1 -featurelevel:10.0 // test all drivers supporting D3D10.1 featurelevel:10.0 4) -DX11.0 // test drivers supporting native D3D11. Change 10.1 in 2) and 3) to 11 to test D3D11 on different feature levels.
-c [string] | N/A
-h [string] | N/A
wdk_test.pro | N/A

Code Tour

File Manifest

File | Location
dxgigdiinterop.exe | [WTT\TestBinRoot]\nttest\windowstest\graphics\d3d\Integration\DXGIGDIInterop


DXGI - Mode Enumeration

Type: Automated Test

Overview

The DXGI - Mode Enumeration test verifies that the IDXGIOutput::FindClosestMatchingMode method is correctly implemented.

Details

This test generates a predetermined set of target modes, enumerates the available modes, and, for each target mode, predicts the mode that the FindClosestMatchingMode method should return. In accordance with the DXGI specification, when the test is seeking a match, the test prioritizes mode attributes according to the following order:

  • Format bit depth

  • Width

  • Height

  • Refresh rate

The test reports a failure if the mode that the method returns does not match the predicted mode, or if the method fails when a matching mode does exist. A recent addition is the DXGI - Mode Enumberation - Multihead job; the only difference is that it targets display adapters that expose dualview capabilities.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


DXGI - Presentation testing

Type: Automated Test

Overview

The DXGI - Presentation testing is an automated test that verifies that the IDXGISwapChain::Present method is correctly implemented.

Details

This test automatically verifies several aspects of the implementation of IDXGISwapChain::Present.

The test creates both windowed and full-screen swap chains. It also creates back buffers in all supported back buffer formats, by using dimensions that match or differ from those of the output window. Because of this variety, the test 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 that the different DXGI swap effects are implemented correctly and uses timing-based test cases to verify the correct implementation of presentation intervals.

The test automatically verifies presented images by using the IDXGIOutput::GetDisplaySurfaceData method 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 Logo or Signature testing:

  • Windows Vista

  • Windows 7

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Command Syntax

Test | Command Line
DXGI Presentation testing - FSPresentMS - multihead (32-bit) | dxgipresent.exe fspresentms -whql -logclean -bvt
DXGI Presentation testing - FSPresentMS - multihead (64-bit) | dxgipresent.exe fspresentms -whql -logclean -bvt
DXGI Presentation testing - FSPresentMS (32-bit) | dxgipresent.exe fspresentms -whql -logclean
DXGI Presentation testing - FSPresentMS (64-bit) | dxgipresent.exe fspresentms -whql -logclean
DXGI Presentation testing - Other - multihead (32-bit) | dxgipresent.exe winpresent fspresent fspresentrotation fspresentmulti -whql -logclean -bvt
DXGI Presentation testing - Other - multihead (64-bit) | dxgipresent.exe winpresent fspresent fspresentrotation fspresentmulti -whql -logclean -bvt
DXGI Presentation testing - Other (32-bit) | dxgipresent.exe winpresent fspresent fspresentrotation fspresentmulti -whql -logclean
DXGI Presentation testing - Other (64-bit) | dxgipresent.exe winpresent fspresent fspresentrotation fspresentmulti -whql -logclean
DXGI Presentation testing - WinpresentMS - multihead (32-bit) | dxgipresent.exe winpresentms -whql -logclean -bvt
DXGI Presentation testing - WinpresentMS - multihead (64-bit) | dxgipresent.exe winpresentms -whql -logclean -bvt
DXGI Presentation testing - WinpresentMS (32-bit) | dxgipresent.exe winpresentms -whql -logclean
DXGI Presentation testing - WinpresentMS (64-bit) | dxgipresent.exe winpresentms -whql -logclean


DXGI SCDest Buffer (D3D10.0/10.1/11 and all associated feature levels)

Type: Automated Test

Overview

This test verifies whether drivers can support API UpdateSubresource well, API UpdateSubresource takes the swap chain as the destination buffer.

Details

This test should be run against drivers for D3D10.1 and later, as well as associated feature levels.

Run Time: About 18 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: DXGISCDestBuffer.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

During testing, windows filled with black and white colors appear. After testing, all windows should be closed. Check the log files to make sure that no test case is failed and all test cases are either passed or skipped (unsupported features).

Command Syntax

Command option | Description
DXGISCDestBuffer.exe | 1) D3D10.0: dxgigdiinterop.exe -DX10.0 2) D3D10.1: dxgigdiinterop.exe -DX10.1 [-FeatureLevel:9.x/10.0] 3) D3D11.0: dxgigdiinterop.exe -DX11.0 4) D3D11 on feature levels: dxgigdiinterop.exe -DX11 -FeatureLevel:9.x/10.0
-c [string] | N/A
-h [string] | N/A
wdk_test.pro | N/A

Code Tour

File Manifest

File | Location
DXGISCDestBuffer.exe | [WTT\TestBinRoot]\nttest\windowstest\graphics\d3d\Integration\DXGIGDIInterop


DXGI Swapchain Scaling (D3D10.1), (D3D10.1 on feature levels 9.1 and 10.0) and (D3D11 on feature levels 9.1 and 10.0)

Type: Automated Test

Overview

This test verifies whether video adapters/driver/monitors can support scaling modes for DXGI full screen swap chains well. Most scaling features were added in Windows 7.

Details

This test should be run on video adapters/drivers/monitors for D3D10.1 and later, as well as associated important feature levels.

Run Time: Up to 60 minutes
Log File: dxgiswapchainscaling.xml.
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: dxgiswapchainscaling.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

During testing, full screen windows appear with different scalings, such as centered or stretched. After testing, all windows should be closed. Check the log files to make sure that no test case is failed and all test cases are either passed or skipped (scaling not supported).

Command Syntax

Command option | Description
dxgiswapchainscaling.exe | 1) D3D10.1: dxgiswapchainscaling.exe -DX10.1 2) D3D10.1: dxgiswapchainscaling.exe -DXGI:1.1 -DX10.1 -Featurelevel:9.1 3) D3D10.1: dxgiswapchainscaling.exe -DX10.1 -Featurelevel:10.0 4) D3D11: dxgiswapchainscaling.exe -DX11 -Featurelevel:9.1 5) D3D11: dxgiswapchainscaling.exe -DXGI:1.1 -DX11 -Featurelevel:10.0
-c [string] | N/A
-h [string] | N/A
wdk_test.pro | N/A

Code Tour

File Manifest

File | Location
dxgiswapchainscaling.exe | [WTT\TestBinRoot]\nttest\windowstest\graphics\d3d\Integration\DXGISwapchainScaling]


DXVA Display Test

Type: Automated Test

Overview

The DXVA Display Test verifies that a display driver can comply with the DXVA 1.0 MPEG2 decode acceleration specification.

Details

The DXVA Display Test simulates an MPEG2 decoder and makes calls through the display subsystem to exercise the MPEG2 decode acceleration characteristics of the display driver. This test will try each of the minimal interoperability configuration set that is defined in the DXVA specification and whatever the driver's recommended profile is. The driver must support at least one member of the minimal set.

The test will run in automated mode through Driver Test Manager (DTM). The output from the display driver is compared to a reference image. If there are failures, a bitmap of the failing data will be saved and a reference to the file logged.

Run Time: under 1 minute
Log File: DXVADisplayTest.log and DXVADisplayTest.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 DXVA Display Test

The test consists of an executable file (DXVADisplayTest.exe) and a source filter (DXVASourceTest.dll). The source filter needs to be registered before you run the test. The test also requires the presence of the source content (DXVAStream.dva and DXVAStreamMpeg1.dva) in the same directory as the test.

One of the test cases tests the ability of the decoder to work while the screen resolution is changed. This test case requires the presence of the ModeChange.exe utility to be present somewhere in the executable path. This tool is part of the display subset of the Microsoft Windows Driver Kit (WDK).

Command Syntax

Command option | Description
DXVADisplayTest -A | Automated mode.
DXVADisplayTest -9 | Force VMR9 connection.
DXVADisplayTest -? | Displays (a simplistic) help message box.

Cautions

None

Troubleshooting

None

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0025 Display driver supports the DirectX VA 2.0 Video Decoder DDI

Additional Information: This test verifies that DXVA2 supporting devices can support DXVA1 calls properly. It is also used for logos for Microsoft Windows XP.


DXVA2 API Test

Type: Automated Test

Overview

The DXVA2 API Test is a comprehensive test of DXVA2 support. This test covers driver robustness and correctness for the generic DXVA2 API and covers the video processing capabilities.

Details

The test is a set of fully independent test cases, each addressing a specific API usage (or other scenario). The test cases are wrapped in a dynamic load library (DLL) that the ShellRunner framework uses. The ShellRunner application is user interface-based, enabling automatic and manual operation.

As the selected test cases run, logging is displayed in the main application window and any eventual output images are rendered to separate, test case-dependent windows.

For logo certification purposes, this test uses specific profiles that contain all of the relevant test cases.

The test also contains the ReferenceVideoProcessor.dll component, which needs to be present in the same directory as the test. As the name implies, this component contains the implementation of a software, reference video processor, that outputs reference frames and images, as required by the test cases. These output images are compared against those that driver generates and differentiated, a peak Signal-to-Noise Ratio being computed (PSNR). If the PSNR is within a reasonable margin (currently it is 20dB), the test case passes. Otherwise, bitmaps are generated from both outputs and saved in the current directory. Please note that repeated runs of the test can consume quickly a significant amount of disk space.

Run Time: depends, can take up to 30 min
Log File: Profile-dependent, each profile will generate its own profile. By default, the framework outputs to shellrunnerapp.log/.wtl.
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 DXVA2 API Test

Run the test with the desired profile as a command-line parameter.

If you are running the test without a profile (automated mode), you need to select test cases (on the Tests menu, click Select Tests) and run the selection (on the Tests menu, click Run Tests). The test cases are grouped on the affected interface or method or, in the case of Microsoft Windows Driver Kit (WDK) profiles, on the Windows Logo Program (WLP) requirement that is being enforced.

Command Syntax

Command option | Description
(there are many command line options, only listing those with immediate impact on the WDK runs) |
-x premium | Signals a Premium logo run (requirements might be different).
-c [profile name] | Specifies the profile to run.

Cautions

None

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0032 Display WDDM driver supports the DirectX VA 2.0 Video Processor DDI

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0024 Display WDDM driver supports the DirectX VA 2.0 Video Processor DDI


DXVA2 Display Test

Type: Automated Test

Overview

The DXVA2 Display test verifies that a display driver can comply with the DXVA 2.0 MPEG2 decode acceleration specification.

Details

The DXVA2 Display test simulates an MPEG2 decoder and makes calls through the display subsystem to exercise the MPEG2 decode acceleration characteristics of the display driver. This test will try each of the minimal interoperability configuration sets that is defined in the DXVA 2.0 specification and whatever the driver's recommended profile is. The driver must support at least one member of the minimal set.

The test will run in automated mode through Driver Test Manager (DTM). The output from the display driver is compared to a reference image. If there are failures, a bitmap of the failing data will be saved and a reference to the file logged.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 DXVA2 Display Test

The test consists of a framework (ShellRunner) used by other DXVA2 or display tests, and a test .dll file that contains the proper test cases. The source filter must be registered before you run the test. The test also requires the presence of the source content (DXVAStream.dva and DXVAStreamMpeg1.dva) in the same directory as the test.

One of the test cases tests the ability of the decoder to work while the screen resolution is changed. This test case requires the presence of the ModeChange.exe utility to be present somewhere in the executable path. This tool is part of the display subset of the Microsoft Windows Driver Kit (WDK).

Test Assertions

Test Assertion GUID:

Windows Logo Program: DEVFUND-0014 Device drivers support x64 versions of Windows


Dynamic Resources

Type: Automated Test

Overview

The Dynamic Resources test creates dynamic resources (vertex buffers, index buffers, and textures) and uses them with various lock flags.

Details

This test renders an image and compares pixels in the source image to an image that the Microsoft Direct3D reference (software rasterizer) creates. 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Test Assertions

5.85.1 The driver must successfully handle the CreateVertexBuffer method when dynamic usage (D3DUSAGE_DYNAMIC) is specified.

Test Assertion GUID:

Windows Logo Program: Anonymous

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:

Windows Logo Program: Anonymous

5.85.3 The drivers must correctly render dynamic vertex buffers, even when they are locked multiple times per frame.

Test Assertion GUID:

Windows Logo Program: Anonymous

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:

Windows Logo Program: Anonymous


DXVAHD VideoProcessing - Create Device

Type: Automated Test

Overview

Executes multiple test cases targeting IDXVAHD_CreateDevice with a handful of different IDirect3D9DeviceEx interface devices. The permutations consist of multiple different content descriptions including (but not limited to) different sizes of content, different frame rates, and different frame formats.

Details

DXVAHD_CONTENT_DESC Tested output rates and input rate permutations additional output rates may be added depending on the output device attached.

Tested Output Rates | Input Rates
120Hz | 60p 60i 30p 24p
75Hz | 60p 60i 30p 24p
60Hz | 60p 60i 30p 24p
59Hz | 60p 60i 30p 24p
50Hz | 60p 60i 30p 24p
30Hz | 60p 60i 30p 24p
29Hz | 60p 60i 30p 24p
25Hz | 60p 60i 30p 24p

Verify all permutations of output and input rates. Keeping a table of capabilities exposed per rate configuration. Only executing across other test cases on rates that caused the device to expose different capabilities.

Verify correct scaling between input and output frame descriptions, Invalid Frame rate rational should default to 0/1 and 0/* should result in 0 rate.

  • InputFrameRate with valid numerator/denominator values

  • InputFrameRate with invalid numerator/denominator values

  • Valid InputFrameRate with matching OutputFrameRate

  • Valid InputFrameRate with different valid OutputFrameRate

  • Valid InputFrameRate with different invalid OutputFrameRate

  • Zeroed out FrameRate values both Input and Output

  • Use a FrameFormat of Interlaced value, and then use progressive content.

  • Use a FrameFormat of Progressive value, and then use interlaced content.

typedef enum _DXVAHD_DEVICE_USAGE

{

DXVAHD_DEVICE_USAGE_PLAYBACK_NORMAL = 0,

DXVAHD_DEVICE_USAGE_OPTIMAL_SPEED = 1,

DXVAHD_DEVICE_USAGE_OPTIMAL_QUALITY = 2

} DXVAHD_DEVICE_USAGE;

DXVAHD_DEVICE_USAGE

  • Verify Output is of higher quality frame DXVAHD_DEVICE_USAGE_OPTIMAL_QUALITY than that of the normal playback usage.

  • Verify optimal performance processes frames more quickly DXVAHD_DEVICE_USAGE_OPTIMAL_SPEED than that of the normal playback usage.

  • Top two cases should prove out NORMAL playback is of more typical playback than that of the other two instances.

Verify successful handle to SW Plugin when valid pPlugin is passed and SW VP is available.

Validate on failure that ppDevice is NULL.

Attempt to create multiple devices from separate threads both with D3DCREATE_MULTITHREADED D3D9Ex Device and without.

Run Time: 5 to 10 minutes
Log File:DXVAHDVideoProcessing.xml
System Restart Required: No
Test Category: VideoProcessing/Functional
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program:DXVAHDVideoProcessing.exe CreateDevice

Requirements

  • D3D9 support exposing D3DCAPS3_DXVAHD

  • Required Output Formats: D3DFMT_X8R8G8B8, D3DFMT_A8R8G8B8

  • Required Input Formats: D3DFMT_X8R8G8B8, D3DFMT_A8R8G8B8, D3DFMT_YUY2, D3DFMT_AYUV and Any Decode Render targets supported.

Software Requirements

The test tool requires the following software:

  • Supported operating system: Windows 7

  • dxvahdsw.dll

Hardware Requirements

The test tool requires the following hardware:

  • Driver that supports D3D9Caps.Caps3 D3DCAPS3_DXVAHD

  • Computer that meets the minimum software requirements

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on OS partition

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test will perform a few mode changes, but for the most part just a ticker-like window incrementing pass fail counts and showing which test case variables are being iterated upon.

The test might return SKIP if the driver does not expose D3DCAPS3_DXVAHD. In some cases it might fail if back buffer format or mode is not supported during d3d device creation.

Command Syntax

Command option | Description
DXVAHDVideoProcessing.exe CreateDevice | Without any options, the test enumerates all but some extreme invalid argument test cases.
TestPriority:[0, 1, 2] | By default, tests at a priority 1 level; however, priority 2 will test every permutation, including extreme invalid arg test cases. 0 is for BVT level.
SoftwareOnly | Tests only the software implementation of the video processor. This was mainly used for initial testing before drivers supported the test cases.
SaveAllFrames | The test has hard coded save count of invalid frames set to 100. If you want all of them saved, then use this flag. Good for high frame count test case failures.
LogLevel:[0, 1, 2] | The test has the ability to be very verbose in its logging methods. By default level 0 is set, however; level one will gather increased logging info per test cases including many stream states/blt states set. Level 2 will gather all adjusted stream states and blt states as well as any configuration information.

File Manifest

File | Location
DXVAHDVideoProcessing.exe | [testbinroot]\nttest\windowstest\graphics\d3d\func\
Dxvahdsw.dll | [osbinroot]\nttest\windowstest\graphics\dxva\


DXVAHD VideoProcessing - CreateVideoProcessor

Type: Automated Test

Overview

Executes test cases across IDXVAHD_Device::GetVideoProocessorCaps, IDXVAHD_Device::GetVideoProcessorCustomRates, IDXVAHD_Device::GetVideoprocessorFilterRange, IDXVAHD_Device::CreateVideoProcessor. Both valid and invalid calls to the api entry points, verify the proper return values match up to those exposed by the capabilities. As well as the ability to successfully create a video processor and failure with an invalid VP guid.

Details

  • IDXVAHD_Device::GetVideoProcessorCaps
    • Use a valid number of VPs from DXVAHD_VPDEVCAPS.VideoProcessorCount.
    • Use both a number less than the VPs count and a number greater than VPs Count verify result is E_INVALIDARG.
    • Validate pCaps is Empty on Failure.
    • Verify VPGuid for given device works successfully with GetVideoProcessorCustomRates.
    • Verify CustomRateCount corresponds and works properly with GetVideoProcessorCustomRates.
    • Verify that PastFrames and FutureFrames (Counts) work accordingly with DXVAHD_STREAM_DATA expected counts.
  • IDXVAHD_Device::GetVideoProcessorCustomRates
    • With the valid VP Guid for this device, then a valid Guid from another DXVAHD Device if another device can be found with a different Guid.
    • With an invalid zeroed out Guid.
    • Verify pRates is successfully filled when valid pVPGuid and Count are used.
    • Use both a number less than the DXVAHD_VPCAPS.CustomRateCount and a number greater than DXVAHD_VPCAPS.CustomRateCount resulting in E_INVALIDARG.
    • Validate pRates is Empty on Failure.
  • IDXVAHD_Device::GetVideoProcessorFilterRange
    • Iterate over all filters validating on any failures that pRange is NULL.
    • Out of range filter value and validate E_INVALIDARG.
    • Verify Empty pRange on failure.
    • Verify maximum value is greater than minimum.
    • Verify the default value is within minimum and maximum values.
  • IDXVAHD_Device::CreateVideoProcessor
    • With the valid VP Guid for this device, then a valid Guid from another DXVAHD Device if another device can be found with a different Guid.
    • With an invalid zeroed out Guid.
    • Verify ppVideoProcessor is NULL upon any failures.
Run Time: 1 to 5 minutes
Log File:DXVAHDVideoProcessing.xml
System Restart Required: No
Test Category: VideoProcessing/Functional
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program:DXVAHDVideoProcessing.exe CreateVideoProcessor

Requirements

  • D3D9 support exposing D3DCAPS3_DXVAHD

  • Required Output Formats: D3DFMT_X8R8G8B8, D3DFMT_A8R8G8B8

  • Required Input Formats: D3DFMT_X8R8G8B8, D3DFMT_A8R8G8B8, D3DFMT_YUY2, D3DFMT_AYUV and Any Decode Render targets supported.

Software Requirements

The test tool requires the following software:

  • Supported operating system: Windows 7

  • dxvahdsw.dll

Hardware Requirements

The test tool requires the following hardware:

  • Driver that supports D3D9Caps.Caps3 D3DCAPS3_DXVAHD

  • Computer that meets the minimum software requirements

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on OS partition

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test will for the most part just show a ticker-like window incrementing pass fail counts and showing which test case variables are being iterated upon.

The test might return SKIP if the driver does not expose D3DCAPS3_DXVAHD. In some cases, it might skip if another device is not available to query other VP Guids from.

Command Syntax

Command option | Description
DXVAHDVideoProcessing.exe CreateVideoProcessor | Without any options, the test enumerates all but some extreme invalid argument test cases
TestPriority:[0, 1, 2] | By default, tests at a priority 1 level; however, priority 2 will test every permutation, including extreme invalid arg test cases. 0 is for BVT level.
SoftwareOnly | Tests only the software implementation of the video processor. This was mainly used for initial testing before drivers supported the test cases.
SaveAllFrames | The test has hard coded save count of invalid frames set to 100. I you want all of them saved, then use this flag. Good for high frame count test case failures.
LogLevel:[0, 1, 2] | The test has the ability to be very verbose in its logging methods. By default level 0 is set, however; level one will gather increased logging info per test cases, including many stream states/blt states set. Level 2 will gather all adjusted stream states and blt states, as well as any configuration information.

File Manifest

File | Location
DXVAHDVideoProcessing.exe | [testbinroot]\nttest\windowstest\graphics\d3d\func\
Dxvahdsw.dll | [osbinroot]\nttest\windowstest\graphics\dxva\


DXVAHD VideoProcessing - CreateVideoSurface

Type: Automated Test

Overview

Executes calls to GetVideoProcessorDeviceCaps, then using those caps, generates multiple test cases based on default memory pool width size of the content from the generated dxvahd device. The test case also iterates over each devices supported input and output formats verifying that a surface can be created for each input and output surface, as well as failure with an unknown format. The test case will also verify creation of multiple surfaces for each format as well.

Details

  • Verify Success with valid pointer to DXVAHD_VPDEVCAPS.
    • Verify OutputFormat and InputFormat Counts are correct and function properly with associated get routines.
    • Verify VideoProcessorCount correctly maps to number of video processors.
    • Verify MaxInputStreams greater than zero.
    • Verify MaxStreamStates greater than zero.

  • Verify success when DXVAHD_VPDEVCAPS.InputFormatCount is used.

  • Verify failure when less than and greater than InputFormatCount is used.

  • Verify that D3DFMT_X8R8G8B8 is supported.

  • Verify success when DXVAHD_VPDEVCAPS.InputFormatCount is used.

  • Verify failure when less than and greater than InputFormatCount is used.

  • Verify that D3DFMT_X8R8G8B8, D3DFMT_A8R8G8B8, D3DFMT_YUY2, and AYUV (FourCC) are reported as supported.

  • Verify that all decode render target formats report as supported as well.

  • Create Surface with Width Height that of the content description input width height.

  • Create Surface with Width Height different both larger and smaller of the content description input width height.

  • Create Surface with D3DPOOL type from DXVAHD_VPDEVCAPS.InputPool then with a different InputPool verify during Processing VPBltHD returns E_INVALIDCALL.

  • Verify any usage value other than 0 results in return value (E_INVALIDARG).

  • Create a surface of DXVAHD_SURFACE_TYPE_VIDEO_INPUT and attempt to manipulate it some way with D3D9 API validate success. (Off screen plain.)
    • Iterate over all supported input d3dformats obtained by IDXVAHD_Device::GetVideoProcessorInputFormats then an unsupported d3dformat.
  • Create a surface of DXVAHD_SURFACE_TYPE_VIDEO_INPUT_PRIVATE and validate manipulation via the D3D9 api returns failure. (Off screen plain.)
    • Iterate over all supported input d3dformats obtained by IDXVAHD_Device::GetVideoProcessorInputFormats, then an unsupported d3dformat.
  • Create a surface of DXVAHD_SURFACE_TYPE_VIDEO_OUTPUT and validate as a render target.
    • Iterate over all supported input d3dformats obtained by IDXVAHD_Device::GetVideoProcessorOutputFormats, then an unsupported d3dformat.

  • Attempt to create a single surface and then verify ppSurfaces only contains one surface.

  • Create multiple surfaces 2 or more and verify the number of surfaces equates to the number of surfaces represented by NumSurfaces passed.

  • Validate if failure ppSurfaces are NULL.

Run Time: 5 to 10 minutes
Log File:DXVAHDVideoProcessing.xml
System Restart Required: No
Test Category: VideoProcessing/Functional
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program:DXVAHDVideoProcessing.exe CreateVideoSurface

Requirements

  • D3D9 support exposing D3DCAPS3_DXVAHD

  • Required Output Formats: D3DFMT_X8R8G8B8, D3DFMT_A8R8G8B8

  • Required Input Formats: D3DFMT_X8R8G8B8, D3DFMT_A8R8G8B8, D3DFMT_YUY2, D3DFMT_AYUV and Any Decode Render targets supported.

Software Requirements

The test tool requires the following software:

  • Supported operating system: Windows 7

  • dxvahdsw.dll

Hardware Requirements

The test tool requires the following hardware:

  • Driver that supports D3D9Caps.Caps3 D3DCAPS3_DXVAHD

  • Computer that meets the minimum software requirements

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on OS partition

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test will for the most part just show a ticker like window incrementing pass fail counts and showing which test case variables are being iterated upon.

The test might return SKIP if the driver does not expose D3DCAPS3_DXVAHD. In some cases, it might skip if certain surface formats are not-supported.

Command Syntax

Command option | Description
DXVAHDVideoProcessing.exe CreateVideoSurface | Without any options, the test enumerates all but some extreme invalid argument test cases
TestPriority:[0, 1, 2] | By default, tests at a priority 1 level; however, priority 2 will test every permutation, including extreme invalid arg test cases. 0 is for BVT level.
SoftwareOnly | Tests only the software implementation of the video processor. This was mainly used for initial testing before drivers supported the test cases.
SaveAllFrames | The test has hard coded save count of invalid frames set to 100. If you want all of them saved, then use this flag. Good for high frame count test case failures.
LogLevel:[0, 1, 2] | The test has the ability to be very verbose in its logging methods. By default level 0 is set; however ,level one will gather increased logging info per test cases, including many stream states/blt states set. Level 2 will gather all adjusted stream states and blt states, as well as any configuration information.

File Manifest

File | Location
DXVAHDVideoProcessing.exe | [testbinroot]\nttest\windowstest\graphics\d3d\func\
Dxvahdsw.dll | [osbinroot]\nttest\windowstest\graphics\dxva\


DXVAHD VideoProcessing - VideoProcessing

Type: Automated Test

Overview

Executes test cases across IDXVAHD_VideoProcessor::SetVideoProcessBltState, IDXVAHD_VideoProcessor::GetVideoProcessBltState, IDXVAHD_VideoProcessor::SetVideoProcessStreamState, IDXVAHD_VideoProcessor::GetVideoProcessStreamState, and IDXVAHD_VideoProcessor::VideoProcessBltHD. There are too many permutations to list in the Overview, but the Details section details all of the test cases tested. Most test cases present to the screen while the frames are being post processed by our comparison utility. Most test cases enforce a > 20.0f PSNR between software and hardware processed frames, but for some test cases, the threshold is lowered due to lack of support of some filters and features in the software implementation.

Details

After each SetVideoProcessBltState, call the corresponding GetVideoProcessBltState. The call will be made to ensure proper reporting, then processed and presented compared to the reference frames for accuracy. Most BltStates will be cycled across for each full cycle of a given BltSate, then again for each valid StreamState. However, some permutations are not necessary, much like DXVAHD_BLT_STATE_PRIVATE_DATA can be interated over each test case independantly of most other blt states.

  • Verify Invalid Datatypes passed to SetVideoProcessBltState and GetVideoProcessBltState return E_INVALIDARG.

  • DXVAHD_BLT_STATE_TARGET_RECT_DATA
    • Verify Limiting Data to rect smaller than output surface results in correct scaling.
    • Verify a rect larger than the output surface results in a expanded frame.
    • Verify when target rect data is set and Enable flagged as false, that the entire surface is used.
    • Process one frame with target rect data and Enable set to false. Then process another frame with target rect data shrunken/expanded/moved and Enable is true. Verify the surface Scales/moves accordingly.
    • Verify Default no data set results in entire surface being used.
  • DXVAHD_BLT_STATE_BACKGROUND_COLOR_DATA
    • Verify Default is RGB Black.
    • If YCbCr is set to true, verify correct color range for background is actually presented.
    • Verify RGB Orange (255,165, 0) along with default black value with alpha values for both RGB and YcbCr.
    • with DXVAHD_BLT_STATE_OUTPUT_COLOR_SPACE_DATA
      • Verify that if Background Color of YCbCr is used and ColorSpaceData is of Full RGB_Range, that Full range RGB is ignored and the correct limited range is used per the specified Matrix and xvYCC setting.
    • with DXVAHD_BLT_STATE_ALPHA_FILL
      • Verify the alpha value of given background color when DXVAHD_ALPHA_FILL_MODE_BACKGROUND is used across different background colors.
  • DXVAHD_BLT_STATE_OUTPUT_COLOR_SPACE_DATA
    • Verify Default Usage, RGB_Range, YCbCr_Matrix, and YCbCr_xvYCC are all set to 0.
    • Verify Limiting RGB_Range successfully limits color range to 16..235.
    • Verify BT.709 correctly increase luma and chroma accordingly.
    • xvYCC successfully extends color range. This will be a special case validation because the reference video processor will not support any output surface other than XRGB. Validation of this is difficult and the process will be documented at a later time.
    • Verify if DXVAHD_VPDEVCAPS.DeviceCaps does not have DXVAHD_DEVICE_CAPS_xvYCC. Validate YCbCr_xvYCC does not adjust any settings and is truly ignored.
    • Tolerance will be flexible initially, but starting percentage of pixel precision will be 90% accuracy.
  • DXVAHD_BLT_STATE_ALPHA_FILL_DATA
    • Verify that output surfaces not of Alpha format are unchanged.
    • Verify that output surfaces of Alpha format successfully applies alpha values to the color.

    • Verify default Mode adjusts Background Alpha values correctly.

      Test Input Surface of NonAlpha Format with an output surface of Alpha Format. Validate alpha correctness with again flexible precision, initially will be 90% accuracy.

  • DXVAHD_BLT_STATE_CONSTRICTION_DATA
    • Due to lack of support in the Reference driver for the course of M2 constriction, test cases will have to be validated outside of direct 1:1 comparison for valid down sampled sizes.
    • Verify correct down-sampling to the output surface.
    • Verify if size is greater than target that constriction is limited to the size of the target rect.
    • Attempt to set sizes to 0,* and *, 0 validate return value E_INVALIDARG.
    • If DXVAHD_VPDEVCAPS.FeatureCaps does not expose DXVAHD_FEATURE_CAPS_CONSTRICTION,then verify that error E_INVALIDARG is returned when Constriction is attempted to be set.
    • Verify thatDefault Value represents disabled. If disabled is flagged and a size is specified, the size value is ignored.
  • DXVAHD_BLT_STATE_PRIVATE_DATA
    • Pass invalid Guid/DataSize/pData validate driver handles accordingly.
    • Null pData retrieves correct size of the private blt state.

After each SetVideoProcessStreamState, call the corresponding GetVideoProcessStreamState. The call will be made to ensure proper reporting, then processed and presented then compared to the reference frames for accuracy. Most Stream States will be cycled across for each full cycle of a given Stream Sate. However, some permutations will not be necessary. Much like DXVAHD_STREAM_STATE_PRIVATE_DATA can be iterated over each test case independantly of most other stream states.

  • Verify Invalid Datatypes passed to SetVideoProcessStreamState and GetVideoProcessStreamState return E_INVALIDARG.

  • DXVAHD_STREAM_STATE_D3DFORMAT_DATA
    • Validate all supported formats reported by GetVideoProcessorInputFormats.
    • Validate a format which is not reported as supported by GetVideoProcessorInputFormat.s
    • Validate default D3DFORMAT is D3DFMT_UNKNOWN.
  • DXVAHD_STREAM_STATE_FRAME_FORMAT_DATA
    • Verify Default value is PROGRESSIVE.
    • Verify Progressive and Interlaced formats are presented accordingly
    • Verify if DXVAHD_INPUT_FORMAT_CAPS_RGB_INTERLACED is not reported as supported by DXVAHD_VPDEVCAPS.InputFormatCaps that using DXVAHD_FRAME_FORMAT_INTERLACED_* defaults to using PROGRESSIVE.
  • DXVAHD_STREAM_STATE_INPUT_COLOR_SPACE_DATA
    • Verify Default values.
    • Verify Limiting RGB_Range successfully limits color range to 16..235.
    • Verify that if DXVAHD_VPDEVCAPS.InputFormatCaps does not report support for DXVAHD_INPUT_FORMAT_CAPS_RGB_LIMITED_RANGE that when RGB_Range is 1 it is ignored and FullRange is used.
      • Limited range validation will not be possible with a 1:1 comparison with the reference and some loose validation of whites and blacks may be possible to validate the color range has been limited accordingly.
    • Verify BT.709 correctly increase luma and chroma sampling.
    • xvYCC successfully extends color range
    • Verify that if DXVAHD_VPDEVCAPS.DeviceCaps does not report support for xvYCC.
    • If possible validate increased color conversion performance if Processing is specified.
    • Verify if DXVAHD_VPDEVCAPS.DeviceCaps does not have DXVAHD_DEVICE_CAPS_xvYCC validate YCbCr_xvYCC does not adjust any settings and is truly ignored.
  • DXVAHD_STREAM_STATE_OUTPUT_RATE_DATA
    • Test and validate default values (specifically Interpolation occurs).
    • Test both NormalRate and HalfRate verifying that NormalRate is 2:1 interlaced to progressive and HalfRate 1:1 interlaced to progressive.
    • Verify all CustomRates if GetVideoProcessorCustomRates exposes any.
      • Specifically Inverse Telecine Rates
        • ITELECINE support will not be available in the reference video processor thus 1:1 comparison will not be possible. The idea for validation is that a telecine frame will be generated and passed to the reference then the non-telecine frame that of 60fps or whichever is decided is processed and compared to that of the frames provided by the telecine frame processed by the reference VP.
    • Test unsupported CustomRate both Interpolated and repeated.
    • Test unsupported CustomRate with at both NormalRate and HalfRate verifying error E_INVALIDARG is returned.
    • Validate that supported CustomRates are not successfully set unless DXVAHD_OUTPUT_RATE_CUSTOM is specified.
  • DXVAHD_STREAM_STATE_SOURCE_RECT_DATA
    • Verify Limiting Data to rect smaller than input surface results in correct scaling.
    • Verify a rect larger than the input surface results in the clipped areas being transparent.
    • Verify when source rect data is set and Enable flagged as false the entire surface is used.
    • Verify once one frame is processed with source rect data and Enable is false then a second frame is processed with source rect data and Enable is true surface is visible and scales according to the rect size to the input surface.
    • Verify Default no data set results in entire surface being used.
  • DXVAHD_STREAM_STATE_DESTINATION_RECT_DATA
    • Verify Limiting Data to rect smaller than output surface results in correct scaling.
    • Verify a rect larger than the output surface results in the clipped areas being clipped.
    • Verify when destination rect data is set and Enable flagged as false the entire surface is used.
    • Verify once one frame is processed with destination rect data and Enable is false then a second frame is processed with destination rect data and Enable is true output surface is visible and scales according to the rect size to the output surface.
    • Verify Default no data set results in entire surface being used.
  • DXVAHD_STREAM_STATE_ALPHA_DATA
    • All Alpha test cases will require more than one video stream there for multiplying these test cases by two.
    • Verify default values alpha is disabled.
    • Verify Low, Mid, High range alpha blending and verify transparency.
    • Verify out of range float alpha value, will result in failure during processing.
    • 10% Tolerance level for pixel precision. Precision should be greater than or equal to 90% accuracy.
  • DXVAHD_STREAM_STATE_PALETTE_DATA
    • Validate Null value returns zero with no palette entries set.
    • Validate Null value returns expected number of palette entries equal to the number set.
    • Test both 4-bit and 8-bit palletized fourCC formats.
    • Set both ARGB and AYUV mixed array of palette entries validate success.
    • Verify when used with alpha blending correct blending occurs.
    • 10% Tolerance level for pixel precision. Precision should be greater than or equal to 90% accuracy.
  • DXVAHD_STREAM_STATE_CLEAR_RECT_DATA
    • If DXVAHD_VPDEVCAPS. FeatureCaps not exposes DXVAHD_FEATURE_CAPS_CLEAR_RECT verify error E_INVALIDARG is returned when an attempt to use ClearRects occurs.
    • Verify Default CLEAR RECT State is disabled and not visible.
    • Verify CLEAR_RECT Outside the destrect is not visible.
    • Verify CLEAR_RECT Outside the destrect is successfully clipped.
  • DXVAHD_STREAM_STATE_LUMA_KEY_DATA
    • If DXVAHD_VPDEVCAPS. FeatureCaps not exposes DXVAHD_FEATURE_CAPS_LUMA_KEY verify error E_INVALIDARG is returned.
    • Verify when RGB input stream is used and DXVAHD_VPDEVCAPS. FeatureCaps not exposes DXVAHD_FEATURE_CAPS_RGB_LUMA_KEY that no luma is ignored.
    • Verify if Enable is set to false luma is ignored.
    • Verify out of range values for lower and upper results in failure during Set state (E_INVALIDARG).
    • Verify default is Luma disabled and values for Lower/Upper are 0.
    • 10% Tolerance level for pixel precision. Precision should be greater than or equal to 90% accuracy.
  • DXVAHD_STREAM_STATE_FILTER_DATA
    • Verify default values (Disabled and DXVAHD_FILTER_RANGE_DATA.Default).
    • Verify when Enabled and Level is Default that presented stream has no cahnge from that when the filter is enabled.
    • Verify Level less than and greater than GetVideoProcessorFilterRange reported. Greater than should fail with E_INVALIDARG.
    • 10% Tolerance level for pixel precision. Precision should be greater than or equal to 90% accuracy.
  • DXVAHD_STREAM_STATE_PRIVATE_DATA
    • Pass invalid Guid/DataSize/pData validate driver handles accordingly.
    • Null pData retrieves correct size of the private blt state.

Verify VideoProcessBltHD to pOutputSurface of surface types below are successful

  • Default Surface used will be a swapchain since most apps will use a swapchain of some sort.

  • DXVAHD_SURFACE_TYPE_VIDEO_OUTPUT

  • RENDERTARGET

  • An Overlay swapchain

  • Swapchains of all other types.

  • Standard supported output and input surface pixel formats (YUY2, AYUV, UYVY, etc... ) as well as output and input surface formats reported as supported (GetVideoProcessorOutputFormats, GetVideoProcessorInputFormats) for the given device.

Verify a OutputFrame value of 1 or higher before frame 0 has been processed results in E_INVALIDARG.

Validate Processing of OutputFrame 0 twice in a row without any stream data changes results in a paused frame.

Validate Processing of OutputFrame 0 twice with stream data changes still results in the cached data being presented (paused frame).

Verify Processing of Max Mid and Min Number of streams is successful.

Verify StreamCount Greater than or Less than the number of pStreams results in E_INVALIDARG.

Verify StreamCount of zero results in E_INVALIDARG.

DXVAHD_STREAM_DATA: Progressive normal/half rate, Progressive at 2/1, Interlaced at normal rate, Interlaced at half rate, Interlaced at 4/5

  • Enable one stream verify presented contents.

  • Two streams, main stream enabled with sub stream disabled. Verified presented contents.

  • Two streams, main stream and sub stream enabled. Verify presented contents.

  • Three streams, two streams used to compose main stream both enabled, and the third stream as the sub stream disabled. Verify presented content.

  • Three streams, two streams used to compose main stream one enabled one disabled and the third stream as the sub stream disabled. Verify presented content.

  • Three streams, two streams used to compose main stream both enabled, and the third stream as the sub stream enabled as well. Verify presented content.

  • Three streams, two streams used to compose main stream one enabled one disabled and a third stream as the sub stream enabled. Verify presented content.

  • Out of range PastFrames and FutureFrames

  • Invalid PastFrames and FutureFrames according to given PastSurfaces and FutureSurfaces

  • Null PastSurfaces and FutureSurfaces with non-zero PastFrames with FutureFrames.

  • All permutations of DXVAHD_SURFACE_TYPE_VIDEO_INPUT, DXVAHD_SURFACE_TYPE_VIDEO_INPUT_PRIVATE, Decode RenderTarget, and an off screen plain surface across ppPastSurfaces, pInputSurfaces, ppFutureSurfaces

  • Validate that ppPastSurfaces, pInputSurfaces, ppFutureSurfaces of an un-supported SurfaceType returns E_INVALIDARG

  • Validate Surfaces allocated to memory pool of type other than DXVAHD_VPDEVCAPS.InputPool results in E_INVALIDARG?

Run Time: 1 to 5 minutes
Log File:DXVAHDVideoProcessing.xml
System Restart Required: No
Test Category: VideoProcessing/Functional
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program:DXVAHDVideoProcessing.exe VideoProcessing

Requirements

  • D3D9 support exposing D3DCAPS3_DXVAHD

  • Required Output Formats: D3DFMT_X8R8G8B8, D3DFMT_A8R8G8B8

  • Required Input Formats: D3DFMT_X8R8G8B8, D3DFMT_A8R8G8B8, D3DFMT_YUY2, D3DFMT_AYUV and Any Decode Render targets supported.

Software Requirements

The test tool requires the following software:

  • Supported operating system: Windows 7

  • dxvahdsw.dll

Hardware Requirements

The test tool requires the following hardware:

  • Driver that supports D3D9Caps.Caps3 D3DCAPS3_DXVAHD

  • Computer that meets the minimum software requirements

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on OS partition

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test will for the most part just show a ticker-like window incrementing pass fail counts and showing which test case variables are being iterated upon.

The test might return SKIP if the driver does not expose D3DCAPS3_DXVAHD other test cases will skip based on stream state support, inverse telecine caps, filter caps, feature caps, and formats supported.

Command Syntax

Command option | Description
DXVAHDVideoProcessing.exe VideoProcessing | Without any options, the test enumerates all but some extreme invalid argument test cases
TestPriority:[0, 1, 2] | By default tests at a priority 1 level however priority 2 will test every permutation including extreme invalid arg test cases. 0 is for BVT level.
SoftwareOnly | Tests only the software implementation of the video processor. This was mainly used for initial testing before drivers supported the test cases.
SaveAllFrames | The test has hard coded save count of invalid frames set to 100 if you want all of them saved then use this flag. Good for high frame count test case failures.
LogLevel:[0, 1, 2] | The test has the ability to be very verbose in its logging methods. By default level 0 is set however level one will gather increased logging info per test cases including many stream states/blt states set. Level 2 will gather all adjusted stream states and blt states as well as any configuration information.

File Manifest

File | Location
DXVAHDVideoProcessing.exe | [testbinroot]\nttest\windowstest\graphics\d3d\func\
Dxvahdsw.dll | [osbinroot]\nttest\windowstest\graphics\dxva\


EDID 1.3 and DDC

Type: Automated Test

Overview

The EDID 1.3 and DDC test checks for the compliance of a monitor's extended-display identification data (EDID).

Details

This test retrieves extended-display identification data (EDID) data from monitor software key fields and verifies key fields that are associated with the EDID structure that is based on the VESA Enhanced Extended Display Identification Data Standard Version 1.3.

Run Time: Under a minute
Log File: EDIDTESTV2.log
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Test Assertions

B4.2.4.1-1 Display device implements the EDID data structure

Test Assertion GUID:

Windows Logo Program: DISPLAY-0065 Display device implements the EDID data structure


Fast User Switching - D3DTest

Overview

The Fast User Switching - D3DTest test checks video drivers when Microsoft Direct3D 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 Direct3D application on one of the users. Without logging off the user, the test will switch to another user through Fast User Switching and start the Direct3D application on that user as well.

During the test, user switching will occur multiple times. Test failures indicate problems such as a failure to switch the user or a failure to launch a Direct3D application on a user. The purpose of the test is to make sure that video drivers do not cause bug checks while user switching occurs.

Requirements

Software Requirements

The test tool requires the following software:

  • Windows 7
  • Windows Server 2008 R2
  • Windows Vista
  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Test Assertions

Test Assertion GUID:

Windows Logo Program: DEVFUND-0009 Device functions properly before, during, and after fast user switching or a Microsoft Terminal Services session


Fast User Switching - DdrawTest

Overview

The Fast User Switching - DdrawTest test checks video drivers when Microsoft DirectDraw 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 DirectDraw application on one of the users. Without logging off the user, the test will switch to another user through Fast User Switching and start a DirectDraw application on that user as well.

During the test, user switching will occur multiple times. Test failures indicate problems such as a failure to switch the user or a failure to opena DirectDraw application on a user. The purpose of the test is to make sure that video drivers do not cause bug checks while user switching occurs.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Windows Vista
  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Test Assertions

Test Assertion GUID:

Windows Logo Program: DEVFUND-0009 Device functions properly before, during, and after fast user switching or a Microsoft Terminal Services session

Additional Information:


Fast User Switching - DVDTest

Overview

The Fast User Switching - DVDTest test checks 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 off the user, the test will switch to another user through Fast User Switching and start DVD playback on that user as well.

During the test, user switching will occur multiple times. Test failures indicate problems such as a failure to switch the user or a failure to start a DVD playback on a user. The purpose of the test is to make sure that video drivers do not cause bug checks while user switching occurs.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Windows Vista
  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Test Assertions

Test Assertion GUID:

Windows Logo Program: DEVFUND-0009 Device functions properly before, during, and after fast user switching or a Microsoft Terminal Services session

Additional Information:


Fast User Switching - VideoTest

Overview

The Fast User Switching - VideoTest test checks 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 off the user, the test will switch to another user through Fast User Switching and start MPEG video playback on that user as well.

During the test, user switching will occur multiple times. Test failures indicate problems such as a failure to switch the user or a failure to start an MPEG video playback on a user. The purpose of the test is to make sure that video drivers do not cause bug checks while user switching occurs.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Windows Vista
  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Test Assertions

Test Assertion GUID:

Windows Logo Program: DEVFUND-0009 Device functions properly before, during, and after fast user switching or a Microsoft Terminal Services session

Additional Information:


Fpo_Check

Type: Automated Test

Overview

The Fpo_Check command line binary validates that the stack records generated in event traces (for stackwalk) can be traversed through the video driver code. In other words, frame point optimization is turned off in video code so that we can debug who called(s) the video code when a fault occurs.

Details

Run Time: 20 seconds.
Log File: fpo_check.xml
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: fpo_check.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • The video driver installed for testing. (The test specifically looks at the video driver in kernel mode. If there is no video driver, the test will not fail.)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

When the test is run, the screen flashes a few times and it outputs an fpo_check.xml file. In the bottom of that file, it will log a pass or fail. When running, the test sets up a listener for ETW events and then performs video 'work'. During this time, it processes the profile event logged by the kernel with stackwalk events enabled. For each event, it looks to see if the video kernel is on the stack. If so, it walks the stack looking for the OS routine that called the video driver. If it is able to successfully find the OS component (module) that called the video driver (in every case) the test will pass. Otherwise, it will fail.

Command Syntax

Command option | Description
Test.exe | Without any options, the test enumerates devices.

Code Tour

List all files: fpo_check.exe

File Manifest

File | Location
fpo_check.exe | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\


Garttest

Type: Automated Test

Overview

The Garttest test checks for compliance with the 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. The test confirms support for a GART and write-combining (WC) memory (for processors that provide WC memory) and the integrity of the GART allocation/alignment and allocation/free. The test also verifies uncached memory mapping of the graphics aperture for processors that do not support WC.

Run Time: 15 minutes
Log File: Garttest.wlt
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0057 Display adapter or chipset interfaces with the system over a high-speed connection that supports sufficient bandwidth


GDI Functional Test

Type: Automated Test

Overview

The test implements the functional verification for covering new code paths of GDI rendering, including BitBlt/ColorFill, StretchBlt, TransparentBlt, AlphaBlend and Textout that are applied in hardware implementation in Win7 builds with using device bitmaps, as well as LineTo, StrokePath and etc that are optimized for improving performance with using device bitmaps on Win7 builds.

Details

The test cases include BitBlt/ColorFill with with appropriate ROPs, TransparentBlt, StretchBlt with different ratios including mirror StretchBlt, AlphaBlend with per-pixel and non-per-pixel blending, Textout with ClearType and Anti-aliased fonts, LineTo with different pens, StrokePath for drawing lines and curves with pens applying different colors, widths and styles.

The comparison depends on per-pixel match. With using -tolerance option, the match can be relaxed to tolerance the influence of different precision in OS and drivers.

The clipping regions for each test case are applied when use the option of -clipping.

Run Time: < 1 min
Log File: GDITEST_HW.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7 build with WDDM v1.1 driver

Program: Gditest_hw.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested: Display cards that support WDDM v1.1 driver

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running GDI Functional Test

The device bitmap is not applied.

Command Syntax

Command option | Description
Gditest_hw.exe | Without any options, the test enumerates devices.
-tolerance | Add tolerance in the comparison of reference image and resulting image on the screen to tolerance the precision problem.
-clipping | Apply each test case with using clipping regions.
-all | Run all test cases

Code Tour

File Manifest

File | Location
Gditest_hw.exe | [testbinroot]\NTTEST\WINDOWSTEST\Graphics\wddm\bin\


GetRenderTargetData - Backbuffer and Render Target

Overview

The GetRenderTargetData - Backbuffer and Render Target test verifies that the IDirect3DDevice9::GetRenderTargetData method (Microsoft Direct3D 9) can be used to extract the contents of back buffers and basic render targets.

Details

This test validates the functional and operational specifications for the IDirect3DDevice9::GetRenderTargetData method. The GetRenderTargetData method provides a way 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 you must meet 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 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) that is created with POOL_SYSTEMMEM.

  • The source and destination surfaces must be the same dimension and format.

The following table shows the matrix of surface combinations that this test covers and the command options that the test uses to select the type of surface.

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

The test first creates the source and destination surfaces. The test then 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.

To run this test, you must have Microsoft DirectX 9.0.

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 %USERPROFILE%\dxlogs directory.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running GetRenderTargetData - Backbuffer and Render Target

There is no special setup or configuration that you need to complete to run this test.

Command Syntax

Command option | Description
getrendertargetdata.exe [ option ] | Options for specific surfaces. For more information about which option to use, see the table earlier in this topic.


GetRenderTargetData - Mip Texture and Cube Texture

Overview

The GetRenderTargetData - Mip Texture and Cube Texture test verifies that you can use the IDirect3DDevice9::GetRenderTargetData method (Microsoft Direct3D 9) to extract the contents of Render Target Mipmaps and Cubemaps.

Details

This test validates the functional and operational specifications for the IDirect3DDevice9::GetRenderTargetData method. The GetRenderTargetData method provides a way 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 you must meet 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.

The following table shows the matrix of surface combinations that this test and the command options that are used to select the type of surface.

Surface | Offscreen plan | 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

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.

To run this test, you must have Microsoft DirectX 9.0.

The test writes the test results to a log file called GetRenderTargetData.xml and displays on-screen pass or fail compliance. If run outside of the DCT, the log file can be found in the %USERPROFILE%\dxlogs directory.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running GetRenderTargetData - Mip Texture and Cube Texture

There is no special setup or configuration that you need to complete to run this test.

Command Syntax

Command option | Description
getrendertargetdata.exe [ option ] | Options for specific surfaces. For more information about which option to use, see the table earlier in this topic.


GL Coverage Tests

Overview

The GL Coverage test ensures that an OpenGL implementation covers all of the OpenGL APIs.

Details

The GL Coverage tests are designed to test all API functions within the OpenGL 1.1 library. The test passes specified valid and invalid parameters to these functions to ensure they are handled properly.

Requirements

Software Requirements

The test tool requires the following software:

  • Windows 7

  • Windows Vista

  • Windows Server 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

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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


GL Primitive Tests

Overview

The GL Primitive Tests analyze 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.

The test displays a pass or fail indication of compliance with this requirement. 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 requires the following software:

  • Windows 7
  • Windows Vista
  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


GL Utilities Coverage Tests

Overview

The GL Utilities Coverage test ensures that an OpenGL implementation covers all of the OpenGL Utility APIs.

Details

The GL Utilities Coverage tests are designed to test all API functions within the OpenGL 1.1 library. The test passes specified valid and invalid parameters to these functions to ensure they are handled properly.

Requirements

Software Requirements

The test tool requires the following software:

  • Windows 7
  • Windows Vista
  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


GlitchFree WMV HD 720p video playback quality test (SYSFUND-0062)

For detailed information about this test, please go to GlitchFree WMV HD 720p video playback quality test (SYSFUND-0062).


Graphics - Additional Qualifications - Cold Tuning

Type: Automated test

Overview

The Graphics - Additional Qualifications – Cold Tuning test verifies that a graphics card can decode high-bit-rate H.264 and MPEG-2 video on the graphics processing unit (GPU) while using Windows Media Center Live TV.

Details

Windows Media Center is used to display both an H.264 and MPEG-2 stream. The test succeeds if it reaches an acceptable frame rate during the test.

This test verifies the following requirements:

GRAPHICS-0083: Graphics- Additional Qualifications - Cold Tuning

Success: This test succeeds if the device driver and device complete the following actions successfully:

  • Windows Media Center is launched and the guide is selected.

  • The channel with the specified service name (either for H.264 or MPEG-2) is tuned to within Media Center.

  • A helper thread is started to monitor the frame rate while the stream is playing. The frame rate must reach and stay at or above 20 fps within 20 seconds.

Failure: This test fails if:

  • The frame rate does not reach and maintain at least 20 fps within 20 seconds.
  • Any of the steps above fail.

Run time: 5 minutes
Log file: TvWLPlog.xml
System restart required: No
Supported operating systems for additional qualifications logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1-GHz processor

  • 1 GB of system RAM

  • 40 GB free disk space

  • Audio support

  • Windows keyboard

  • Two-button pointing device

  • Minimum graphics card and display support:
    • DirectX 9 support
    • Supported Windows Display Driver Model (WDDM) driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in Driver Test Manager (DTM) Studio.

Code Tour

File Manifest

File | Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: 712A9E11-950E-43e1-868A-B403942DCBC7


Graphics - Additional Qualifications - Content Protection

Type: Automated test

Overview

The Graphics - Additional Qualifications – Content Protection test verifies that digital outputs on the graphics adapter reestablish a High-bandwidth Digital Content Protection (HDCP) connection to the monitor after resuming from standby while playing protected content.

Details

Windows Media Center plays an encrypted recording during standby and resume. The test succeeds if the HDCP connection is reestablished. The test fails if any of the steps fail before the resumption and the check of HDCP status.

This test verifies the following requirements:

GRAPHICS-0001: Display adapter supports output connectors with content protection features and provides control via Protected Video Path (PVP) and Certified Output Protection Protocol (COPP) device driver interfaces (DDIs).

Success: This test succeeds if the device driver and device complete the following steps successfully:

  1. A helper thread starts to monitor HDCP while encrypted content is playing.
  2. Windows Media Center launches, and the test starts playback of an encrypted .wtv file.
  3. The machine restarts.
  4. The machine goes into standby for 30 seconds and then resumes.
  5. A helper thread starts to monitor HDCP while encrypted content is playing.
  6. Windows Media Center launches, and the test starts playback of an encrypted .wtv file.

Failure: This test fails if:

  • HDCP is not enabled during more than half of the time it is probed.
  • Any of the above steps fail.

Run time: 5 minutes
Log file: TvWLPlog.xml
System restart required: No
Supported operating systems for additional qualifications logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1-GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two-button pointing device

  • Minimum graphics card and display support:
    • DirectX 9 support
    • Supported Windows Display Driver Model (WDDM) Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in Driver Test Manager (DTM) Studio.

Code Tour

File Manifest

File | Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: D0282737-078F-4fb2-BB4B-85295240C334


Graphics - Additional Qualifications - Format Change

Type: Automated test

Overview

The Graphics - Additional Qualifications – Format Change test verifies that a graphics card can handle a format change between high-bit-rate H.264 and MPEG-2 video.

Details

Windows Media Center displays an H.264 and MPEG-2 stream. The test succeeds if it reaches an acceptable frame rate after the channel change.

This test verifies the following requirements:

GRAPHICS-0025: Display driver supports the DirectX VA 2.0 Video Decoder DDI

Success: This test succeeds if the device driver and device complete the following actions successfully:

  • Windows Media Center is launched and the guide is selected.

  • Tune to the H.264 video stream for three minutes.

  • Bring up the guide and then tune to the MPEG-2 channel.

  • A helper thread is started to monitor the frame rate while the second stream is playing. The frame rate must reach a consistent 20 fps within 20 seconds of the second tune.

Failure: This test fails if:

  • The frame rate has not reached 20 fps consistently 20 seconds after the second tune.
  • Any of the preceding steps fail.

Run time: 5 minutes
Log file: TvWLPlog.xml
System restart required: No
Supported operating systems for additional qualifications logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1-GHz processor

  • 1 GB of system RAM

  • 40 GB free disk space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum graphics card and display support:
    • DirectX 9 support
    • Supported Windows Display Driver Model (WDDM) driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in Driver Test Manager (DTM) Studio.

Code Tour

File Manifest

File | Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: 377CB100-5472-4c18-9459-46DBF0EBB0E6


Graphics - Additional Qualifications - Live TV Window Mode Switching

Type: Automated test

Overview

The Graphics - Additional Qualifications – Live TV Window Mode Switching test verifies that a display adapter can display video that results from switching between different window modes while playing back live TV.

Details

Windows Media Center plays live TV. The test succeeds if playback continues after window mode transitions.

This test verifies the following requirements:

GRAPHICS-0084: Additional Qualifications - Live TV Window Mode Switching

Success: This test succeeds if the device driver and device complete the following actions:

  • Media Center tunes and begins playing a high definition live TV stream.

  • Different window mode transitions are attempted, iterating through all possible combinations of minimized, windowed, and full screen.

Failure: This test fails if:

  • Windows Media Center stops displaying video.
  • Any of the steps above fail.

Run time: 5 minutes
Log file: TvWLPlog.xml
System restart required: No
Supported operating systems for additional qualifications logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1-GHz processor

  • 1 GB of system RAM

  • 40 GB free disk space

  • Audio support

  • Windows keyboard

  • Two-button pointing device

  • Minimum graphics card and display support:
    • DirectX 9 support
    • Supported Windows Display Driver Model (WDDM) driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in Driver Test Manager (DTM) Studio.

Code Tour

File Manifest

File | Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: FBB7ABC3-A094-42bc-BCC2-7829DFEA3504


Graphics - Additional Qualifications - Nominal Range Color (manual)

Type: Automated test

Overview

The Graphics - Additional Qualifications – Nominal Range Color (manual) test verifies that a display adapter is applying the correct nominal range setting for color when playing video.

Details

This is tested by using a grayscale pattern that allows verification of nominal range settings.

This test verifies the following requirements:

GRAPHICS-0008: Display adapter or chipset meets color space requirements

Success: This test succeeds if the device driver and device complete the following:

  • The test prompts the tester to switch the display adapter to the default nominal color range.

  • The test plays back a gray level test pattern file.

  • The test takes a screenshot and verifies that the brightness values in the screenshot are 16 and 235 for pixels with values 16 and 235 in the recording.

  • The test prompts the tester if the range can be changed to full.

    • If the tester answers yes, it plays back the same file, takes a screenshot, and checks that the brightness values are 0 and 255 for pixels with 16 and 235 in the recording.
    • If the range cannot be changed, this test is omitted.

Failure: This test fails if:

  • The brightness values of pixels in the screenshot are not as expected.
  • Any of the steps above fail.

Run time: 5 minutes
Log file: TvWLPlog.xml
System restart required: No
Supported operating systems for additional qualifications logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1-GHz processor

  • 1 GB of system RAM

  • 40 GB free disk space

  • Audio support

  • Windows keyboard

  • Two-button pointing device

  • Minimum graphics card and display support:
    • DirectX 9 support
    • Supported Windows Display Driver Model (WDDM) driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in Driver Test Manager (DTM) Studio.

Code Tour

File Manifest

File | Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: CA7B118D-7678-4235-BD9B-98D567C6CAFD


Graphics Bus Transfer

Type: Automated Test

Overview

The Graphics Bus Transfer test moves a known bit-pattern through AGP system memory into local video memory.

Note This test applies to client only.

Details

This test verifies that AGP devices can reliably transfer data when they are configured to run at the required transfer mode. A known bit pattern is transferred between AGP system memory and local video memory (video memory that is residing on the graphics adapter). The bit pattern is then compared to the result of the transfer (while it resides in local video memory) and any differences in the bit pattern indicate data corruption.

Run Time: 15 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Test Assertions

Windows Logo Program: GRAPHICS-0057 Display adapter or chipset interfaces with the system over a high-speed connection that supports sufficient bandwidth


GUIMAN GDI w-poly clip (gmvideo6b)

Type: Automated Test

Overview

The GUIMAN video driver test (GDI SURFACE) tests the GDI interaction with the display driver that is installed.

Details

This test uses .emf files to perform Brush, Pen, Text, Region, Path, various Blt, ROP, and other operations to an output window. The window is a compatible-bitmap surface that GDI controls by using a polygon-star region (alternate-fill).

Verification is automatically made against this surface.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


H.264 Display Test

Type: Automated Test

Overview

The H.264 Display tests verify compliance with the Microsoft DirectX VA 2.0 H.264/AVC specification.

Details

The H.264 Display Test simulates an H.264/AVC decoder and makes calls through the display subsystem to exercise the decode acceleration characteristics of the display driver.

The test will run in automated mode through Driver Test Manager (DTM). The output from the display driver is compared to a reference image. If there are failures, a bitmap of the failing data will be saved and a reference to the file logged.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Test Assertions

H.264 Display Test Automated
Test Assertion GUID: 83110BFD-73E6-40f9-9B41-4858F4F3E1CC


Illegal Imports Test

Overview

The Illegal Imports Test tracks illegal imports in a video miniport driver. Illegal imports are import calls that are considered obsolete, deprecated, unsupported, or not recommended. If an illegal import is found, the test writes the name of the illegal import along with a suggested alternative to the test log file.

Details

This utility finds the illegal imports in a display driver. If an illegal import is found, the test will generate an error or warning in the log file. For example, a warning will occur if the ExAllocatePool function is used for any display driver. Consequently, the VideoPortAllocatePool function is recommended for display drivers and will be listed in the log file.

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. If an illegal function is detected in the list of functions that the driver imports, a warning or error is written to the log file along with the name of the illegal function. Any warning or error that is recorded by the test results in a test failure.

Requirements

Software Requirements

The test tool requires the following software:

  • Windows 7
  • Windows Server 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


LCD WinColor Test

Type: Automated Test

Overview

The LCD WinColor Test validates that an LCD conforms to the LCD Windows Color Compliancy requirements. For more information about the Windows Color Compliancy requirements, see WinColorKit: Windows Color Quality Test Kit for Device OEMs.

Details

The test executable, LCDColor.exe, displays a series of color squares. Each color square must be measured by using a colorimeter, spectrophotometer, or spectroradiometer. The measurement, which must be either CIE XYZ or CIE L*a*b*, is then manually typed into the three channel text entry boxes in LCDColor.exe for that color square.

To obtain these measurements, please refer to the documentation for your color measurement instrument's software to find its mode for measuring single colors and providing the measurement read-outs in CIEXYZ or CIELAB. Note that the color measurement instrument and its software can be running on a different computer from the one running LCDColor.exe.

After all color squares 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 about the methods that are used and the calculations, see WinColorKit: Windows Color Quality Test Kit for Device OEMs.

Run Time: 10 minutes
Log File: LCDColor.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • Supporting color measurement software for the color measurement instrument (see below).
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

  • A suitable color measurement instrument, either a colorimeter, spectrophotometer, or spectroradiometer, with supporting software capable of producing measurements of individual colors in CIE XYZ or CIE L*a*b*

    Note Most modern colorimeters and spectrophotometers from X-Rite or DataColor, as well as spectroradiometers from Photo Research, will suffice. Specifically, the X-Rite i1 Display, i1 Pro and ColorMunki series will work, as will the DataColor Spyder 2 and Spyder 3 series, or the Photo Research PR-655 series. Please contact your instrument manufacturer regarding the correct software to use for single color measurements.

Running LCD WinColor Test

Run LCDColor.exe without any parameters. Follow your measurement instrument manufacturer's instructions for performing single color measurements. Measure the color patch displayed by LCDColor.exe. Their measurement software will display the measurement value for the color. Type the three components of the measured value into the text entry boxes in LCDColor.exe. Repeat until all the color samples have been displayed and measured.

To reproduce what the test is doing manually without running the test, see WinColorKit: Windows Color Quality Test Kit for Device OEMs.


Memory Leak Verifier

Type: Automated Test

Overview

The Memory Leak Verifier test creates and releases numerous resources and checks for memory leaks that are greater than 1 MB.

Details

This test creates and releases numerous resources and checks for memory leaks that are 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

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:


Memory-Texture Management

Overview

The Memory-Texture Management is one of the Microsoft Direct3D Video Memory Management Tests.

Details

This test contains tests for the following features of Direct3D version 8 and Direct3D version 9:

  • DiscardBytes. The test verifies that the resource manager can free managed video memory through the Direc3D version 8 DiscardBytes function. Tests depend heavily on GetAvailableTextureMemory for verification.

  • Preload. The test verifies that preloading works by measuring the time it takes to render a scene with preloaded and non-preloaded resources. The preloaded resources should result in a scene that renders more quickly.

  • TexMan. The test verifies that a managed texture can be recycled multiple times per frame. The test reuses a managed texture 9 times within a frame, verifying the image contents between uses. The test validates the final rendered scene.

  • Memman. The test contains a small set of tests for verifying some basic aspects of video memory management. The 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 Direct3D version 8 interfaces, the tests verify that resources are not allocated on top of one another by writing a byte pattern to surfaces that can be monitored to ensure surface integrity.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


Minimum Screen Resolution

Overview

The Minimum Screen Resolution test Verifies that a 1024 x 768 x 32 display mode is supported with sufficient memory for a double-buffered primary with a 32-bit z-buffer.

Details

This test uses Microsoft DirectDraw APIs to set a 1024 x 768 x 32 display mode. Then, the test creates a double-buffered primary and 32-bit depth/stencil buffer.

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


Monitor - Digital link protection test

Type: Automated Test

Overview

The test is used to verify HDCP support for a given monitor. The test first queries the connector types available on the graphics chipset. If a digital connector is available and supports HDCP, it will try to turn on HDCP.

For internal monitors, such as laptops, the test will skip if the reported connection type is OPM_CONNECTOR_TYPE_LVDS.

Details

Run Time: 1 minute
Log File: Shellrunner.wtl
System Restart Required: Yes
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: OPMComptest.dll

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Graphics card capable of doing HDCP

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
shellrunner.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
WLP_Display_0099.pro.pro | The .profile file of test cases to be run.

Code Tour

File Manifest

File | Location
Shellrunner.exe | Test Shell
OPMComptest.dll | Test Binary
WLP_Display_009.pro | Profile
Shellrunner.wtl | Output log
Test.exe | [testbinroot]\nttest\multimediatest\wmmftest


MPEG-2 and H.264 DXVA 2.0 Test (WLP GRAPHICS-0025)

Type: Automated Test

Overview

This purpose of this test is to enforce the requirements on DirectX VA 2.0 video decoders, as described in WLP GRAPHICS-0025. The scope of the test is limited to MPEG-2 and H.264 decoding options in the current WLK version. A display driver exposing any of the DXVA 2.0 functionalities specified in GRAPHICS-0025 is required to pass all test cases.

Details

The test covers both the data encryption/decryption process and the video playback process. The test cases include both conforming video files and fuzz data.

For video playback, the first mode available from the following list for H.264 and MPEG-2, respectively, will be automatically selected by the test tool:

  • DXVA 2.0 Profile D (aka VLD Profile)

  • DXVA 2.0 Profile C (aka iDCT Profile)

  • DXVA 2.0 Profile B (aka MoComp Profile)

Data protection is required for the functionality validation and the robustness validation. The first mode available from the following list will be automatically selected by the test tool:

  • Standard AES

  • Proprietary AES

  • Private Encryption

  • No data encryption

For video quality validation, the "No data encryption" mode will be used.

There are 47 tests cases, each corresponding to one test video input. A log file will be generated for each test case.

The requirement to pass the functionality and robustness validations is kept at the minimum in this WLK version - basically no crash, hang, TDR for all test cases and no error message for conforming bitstreams.

The requirement to pass the quality validation is to pass a PSNR threshold against the software decoding results. The test is considered a PASS if less than 10% of the frames in a clip have PSNR lower than 40 dB in case of MPEG-2 ,and 50 dB in case of H.264
Run Time: < 2 hours
Log File: A log file is generated for each of the 45 test cases.
System Restart Required: No
Test Category: Graphics Device / Device and Driver / GRAPHICS-0025
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: TE.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

  • Debuggers disabled while running these tests.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running DXVA 2.0 Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
TE.exe whqldecds2.dll /p:DS=Table:whqlcodectest_taef.xml#CPK /select:@ID=<test case ID> /enablewttlogging | Note that the <test case ID> for each test case is included in the test package.

Code Tour

File Manifest

Executables and Binaries:

  • TE.exe

  • WHQLDecDs.dll

  • VisValDecDs2.dll

  • TE.Common.dll

  • TE.DataDrivenTestSource.dll

  • TE.Loaders.dll

  • TE.ProcessHost.exe

  • Wex.Common.dll

  • Wex.Communication.dll

  • Wex.Logger.dll

XML File (for Data input):

whqlcodectest_taef.xml

Input Test Data Files

Conforming video clips for basic functionality validation:

  1. test_30Mbps_frext_slice_1280x720px60.264

  2. test_30Mbps_frext_fieldpic_slice_1920x1088ix30.264 (

  3. test_30Mbps_frext_1280x720px60.264

  4. test_30_2Mbps_frext_1920x1088px30.264

  5. test_23_6Mbps_cavlc.264

  6. test_22_6Mbps_frext_1920x1088ix30.264

  7. test_21_9Mbps_cabac_purembaff_1920x1088ix30.264

  8. test_21_8Mbps_frext_frm_1920x1088ix30.264

  9. test_21_7Mbps_nofrext.264

  10. test_21_7Mbps_frext_fgn_1920x1088px24.264

  11. test_21_7Mbps_frext_1920x1088px24.264

  12. test_14_9Mbps_nofrext.264

  13. satoyama_picaff_003.264

  14. satoyama_mbaff_003.264

  15. Jenna_Drey_Music_Video_720p59.94_5.1.m2v

  16. Int_Young_Pianist_Festival_1080p29.97.m2v

  17. foursquares_320x240_30fps.m2v

  18. College_Tennis_1080p29.97.m2v

  19. Budgies_Butterflies_and_Blooms_1080p23.97.m2v

  20. BMX_1080p29.97.m2v

  21. Animals_of_the_Savannah_1080p23.97.m2v

  22. American_Music-Bluegrass_1080p29.97.m2v

  23. M2VFormatChange.m2v

  24. H264FormatChange.264

Non-conforming (fuzz) video clips for basic robustness validation:

  1. test-128610019864366090.264

  2. test_30Mbps_frext_slice_1280x720px60-128610002091276090.264

  3. test_30_2Mbps_frext_1920x1088px30 -128609992612626090.264

  4. test_21_8Mbps_frext_frm_1920x1088ix30-128610008389466090.264

  5. test_14_9Mbps_frext_1920x1088px24-128610002506326090.264

  6. satoyama_prog_003-128610013146886090.264

  7. satoyama_picaff_003-128610012655586090.264

  8. College_Tennis_1080p29.97-128614057053294475.m2v

  9. Budgies_Butterflies_and_Blooms_1080p23.97-128614029915550972.m2v

  10. BMX_1080p29.97-128614053510740255.m2v

  11. BMX_1080p29.97-128614032807990187.m2v

  12. Animals_of_the_Savannah_1080p23.97-128614047375026745.m2v

  13. American_Music-Bluegrass_1080p29.97-128614059431472269.m2v

Conforming video clips for basic quality validation:

  1. H264 VisualValidation - satoyama_mbaff_003

  2. H264 VisualValidation - satoyama_picaff_003

  3. H264 VisualValidation - satoyama_prog_003

  4. H264 VisualValidation - test_14_9Mbps_frext_1920x1088px24

  5. H264 VisualValidation - test_21_7Mbps_frext_1920x1088px24

  6. MPEG2 VisualValidation - American_Music-Bluegrass_1080p29.97

  7. MPEG2 VisualValidation - Animals_of_the_Savannah_1080p23.97

  8. MPEG2 VisualValidation - BMX_1080p29.97

  9. MPEG2 VisualValidation - College_Tennis_1080p29.97

  10. MPEG2 VisualValidation - Int_Young_Pianist_Festival_1080p29.97


Miscellaneous DirectDraw Tests

Overview

The Miscellaneous DirectDraw Tests are regression tests for various driver bugs that have been reported in the past.

Details

These tests are a set of miscellaneous Microsoft DirectDraw tests that target problems that have been reported in display drivers in the past.

This set of tests contains tests for:

  • Page flipping between a large number of back buffers.

  • Color Fill Blt calls where an unnecessary source surface is provided.

  • Color Converting Blts, which drivers are not required to support but must at least fail gracefully.

  • 1x1 pixel overlays.

All of these tests are contained in the Fnddraw.exe file, and you can select these tests in the dd_misc.pro profile.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running Miscellaneous DirectDraw Tests

To load and run this selection of tests manually, run fnddraw dd_misc.pro -r.


Missing Resource Stability

Type: Automated Test

Overview

The Missing Resource Stability test verifies that a driver can process resource handles correctly.

A 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

In this test, the DrawPrimitive functions are called along with calls to manage resources (such as render targets, textures, and 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 (the test expects that the drivers flush the resource properly), and calls the IDirect3DDevice9::Present function. 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Command Syntax

Command option | Description
-multisample | The test clears the multisample render target and then creates and releases the texture immediately (without loading the image).
-texture | The IDirect3DDevice9::Present method is called when the texture resource has been released.
-buffer | The IDirect3DDevice9::Present method is called when the vertex buffer has been released.

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


Morph - Invalid Params

Type: Automated Test

Overview

The Morph - Invalid Params test verifies system stability when invalid parameters are passed to legacy Microsoft Direct3D APIs.

Details

The Morph - Invalid Params test passes invalid parameters to legacy (Microsoft DirectX 6 and earlier) 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 stop responding (that is, "crash" or "hang") while running this test.

Run Time: 1 hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

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


MovieMaker GPU Pipeline WHQL test

Overview

This tool tests if new 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 six 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 requires the following software:

  • Windows 7
  • Windows Vista
  • Software components included with the device that is being tested.
  • Latest version of Microsoft DirectX
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


Multihead Support

Overview

The Multihead Support test validates the functional and operational specifications for the multihead support that is added in Microsoft DirectX 9.0.

Details

Multihead support allows a single Direct3D device to drive multiple heads; this functionality 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.

When you create and resetting a multihead device, observe the following restrictions:

  • Each head must have the Windowed mode set to FALSE.

  • Each head must have the same value set for the EnableAutoDepthStencil property.

  • If EnableAutoDepthStencil is TRUE, each head must have the same value for AutoDepthStencilFormat, back buffer dimension, and format.

  • You cannot create additional swap chains on a multihead device.

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.

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.

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.

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

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
  • Microsoft DirectX 9.0
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running Multihead Support

There is no special setup or configuration to run this test.


OPM Tests

Type: Automated Test

Overview

The OPMTest tests run PVP-OPM (Protected Video Path - Output Protection Management) commands to test display drivers for PVP-OPM compatibility and checks for the availability of digital protection (HDCP) and analog protections (ACP and CGMSA).

Details

There are three assertions for this test:

  • The display driver must support PVP-OPM driver interfaces.

  • The display driver must support CGMS-A and APS.

  • The display driver must support HDCP.

For all of the assertions, the test goes through the 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 will only query the driver for the availability.

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • If the graphics card supports a digital connector (DVI or HDMI), an HDCP enabled monitor must be connected an enabled.
  • If the graphics card supports an analog connector (component, composite or S-Video), it must be connected and enabled.
Processor
  • x86
  • x64

Running OPMTest

If the graphics card supports a digital connector (DVI or HDMI), you must connect and enable an HDCP-enabled monitor.

If the graphics card supports an analog connector (component, composite or S-Video), you must connect and enable the analog connector.

Command Syntax

Command option | Description
ShellRunnerApp.exe -x [basic/premium] -c [Profile_Name] | Specify the SKU and profile.

OPM Jobs

The following jobs validate the test assertions below:

  • OPM - ACP and CGMSA est

  • OPM - HDCP CSS DVD Test

  • OPM - HDCP Test

  • OPM - Protocol Test

Test Assertions

1.1 The display driver must support PVP-OPM driver interfaces
Test Assertion GUID: E486D7C9-997E-4778-8553-72C4FFFB92CC
Windows Logo Program: GRAPHICS-0001 Display adapter supports output connectors with content protection features and provides control via PVP and COPP DDIs
Additional Information: This assertion tests whether the driver can finish the COPP initialization protocol. The test application will make the following calls:OPMGetVideoOutputsFromIDirect3DDevice9ObjectStartInitializationFinishInitialization

1.2 The display driver must support CGMS-A and APS
Test Assertion GUID: AE3ACD54-E11B-4968-8516-D076E37D3EB8
Windows Logo Program: GRAPHICS-0001 Display adapter supports output connectors with content protection features and provides control via PVP and COPP DDIs
Additional Information: In Windows Vista, if the driver supports an analog connector (S-Video, Component and Composite), you must connect and enable corresponding monitors. For this assertion to be run successfully, the driver needs to have passed the OPM protocol. After the protocol, the test application will start going through the connectors that the driver reports, looking for an analog video adapter. If there are no analog display adapters available, the test will skip. If the test application finds an analog display adapter, the adapter must support CGMS-A and APS. If not, the test will fail for premium SKUs (and skip for basic SKUs)

1.3 The display driver must support HDCP
Test Assertion GUID: 2ECA271F-59E9-4206-9471-D698B28A1A71
Windows Logo Program: GRAPHICS-0001 Display adapter supports output connectors with content protection features and provides control via PVP and COPP DDIs

Additional Information: On Windows Vista, if the driver supports a digital connector (DVI or HDMI), you must connect and enable an HDCP-enabled connector. For this assertion to be run successfully, the driver needs to have passed the OPM protocol. After the protocol, the test application will start going through the connectors that the driver reports, looking for an digital video adapter. If there are no digital display adapters available, the test will skip. If the test application finds an digital display adapter, the adapter must support HDCP. If not, the test will fail for premium SKUs (and skip for basic SKUs)


Palette Tests

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the Palette Tests) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because 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)

Run Time: 00:06:00
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • Microsoft DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DirectDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running Palette Tests

There are no specific steps to follow for this test.

Command Syntax

Command option | Description
fnddraw.exe dd_pal.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full screen applications can cause failures, so you should avoid them.

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


PC99 #10 Supported Pixel Orderings

Overview

The PC99 #10 Supported Pixel Orderings Test checks for PC99 #10 Supported Pixel orderings.

Details

Drivers must support the following pixel orderings for their various display modes:

  • 15-Bit RGB 555

  • 16-Bit RGB 565

  • 24-Bit RGB 888

  • 32-Bit ARGB 8888

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running PC99 #10 Supported Pixel Orderings

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


PC99 #12 downloadable RAMDAC

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the PC99 #12 downloadable RAMDAC test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test verifies that the display adapter supports Microsoft DirectDraw's gamma ramp API. The test maps blue and green components to zero leaving only red.

For more information about implementing Gamma Support, see the "Gamma Control" chapter of the Microsoft DirectX 8.0 Driver Development Kit (DDK) documentation.

Run Time: 00:12:12
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or laters\
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DirectDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running PC99 #12 downloadable RAMDAC

There are no specific steps to follow for this test.

Command Syntax

Command option | Description
fnddraw.exe dd_GAMMA.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen application can cause failures, so you should avoid them.

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


PC99 #3 system uses WC

Type: Automated Test

Overview

Most of the Microsoft DirectDraw tests (including the PC99 #3 system uses WC test) are located in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles that are listed in the DCT shell do not directly match the test names in Fnddraw.exe. 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.

You can pause many Fnddraw tests (especially blt-related tests) to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use the <ESC> key to abort a test run. Be patient because some tests are more responsive than others.

Details

This test determines whether a display adapter driver meets PC98 requirement no. 2 for Graphics Adapters (System uses WC with higher-performance processors).

The test calls Microsoft 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. This test passes if the ratio is greater than or equal to 2.

Run Time: 00:00:05
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

Running PC99 #3 system uses WC

There are no specific steps to follow for this test.

Command Syntax

Command option | Description
fnddraw.exe dd_wc.pro -r -c -p"m%MONITOR%" | Replace the %MONITOR% parameter with a 1-based index that corresponds to the display that you are testing.

Cautions

Turn off the screen saver and disable the power management before you run this test. Mode changes and full-screen application can cause failures, so you should avoid them.

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


PC99TA 6.8.1 Overlay Support

Overview

The PC99TA 6.8.1 Overlay Support test checks for PC9914.10. This test is a Microsoft DirectDraw test for overlay cap and basic support.

Details

This test verifies that DDCAPS_OVERLAY is set and that a simple overlay surface can be created and displayed through DirectDraw APIs.

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running PC99TA 6.8.1 Overlay Support

There are not specific procedures to run this test.

Command Syntax

Command option | Description
fnddraw dd_ov499.pro |


PC99TA 6.8.2 Color Key Support

Overview

The PC99TA 6.8.2 Color Key Support test verifies that the display driver supports destination color keying of overlays.

Details

This test verifies that the 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 requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running PC99TA 6.8.2 Color Key Support

There are not specific procedures to run this test.

Command Syntax

Command option | Description
fnddraw.exe dd_ov599.pro |


PC99TA 6.8.3 YUV Support

Overview

The PC99TA 6.8.3 YUV Support test verifies that required Microsoft DirectDraw overlay formats are supported: yuy2 and yv12.

Details

This test verifies that required YUY2 and YV12 overlay formats can be created and displayed through DirectDraw. This test also tests the recommended UYVY format.

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running PC99TA 6.8.3 YUV Support

There are no specific procedures to run this test.

Command Syntax

Command option | Description
fnddraw.exe dd_ov299.pro |


PC99TA 6.8.5 Qual Scaling Cons.

Overview

The PC99TA 6.8.5 Qual Scaling Cons. test verifies that Microsoft DirectDraw overlays can be stretched and shrunk by a factor of 8:1.

Details

This test contains two separate cases.

  • A 34 x 25 overlay is displayed at a range of sizes up to a stretch factor of 8:1.

  • A 720 x 576 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 requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running PC99TA 6.8.5 Qual Scaling Cons.

There are no specific procedures to run this test.

Command Syntax

Command option | Description
fnddraw.exe dd_ov399.pro |


PC99TA 6.8.6 720x576 resolution

Overview

The PC99TA 6.8.6 720x576 resolution test verifies that a 720 x 576 overlay can be created and displayed through Microsoft DirectDraw.

Details

This 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 requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running PC99TA 6.8.6 720x576 resolution

There are no specific procedures to run this test.


Pixel Shaders Ver 3.0

Overview

The Pixel Shaders Ver 3.0 test verifies that D3D graphics driver/hardware are in 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 (2-D, 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.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


Present Validation

Type: Automated Test

Overview

The Present Validation test ensures that the graphics adapter can perform Idirect3Ddevice8::Present() calls correctly in all situations, including stretching, shrinking, and destination window overrides.

Details

This test ensures that the graphics adapter can perform Idirect3Ddevice8::Present() calls correctly in all situations, including stretching, shrinking, and destination window overrides. The test uses a reference image that Microsoft Direct3Dx uses for comparison.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Test Assertions

5.43.1 Present Validation test.


Present Validation 2

Type: Automated Test

Overview

The Present Validation 2 test attempts to validate the Present() method. This test:

  • Shrinks or stretches the height.

  • Shrinks or stretches the width.

  • Clips to the source area.

  • Clips to the destination area.

  • Overrides the destination window.

These aspects of Present are performed individually and in combination, and the resulting output is verified for correctness.

Details

This test is similar the standard Present Validation test, except that Present Validation 2 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 that the Microsoft Direct3D API generates. The driver is required to perform the color conversion between those two formats (Direct3D does not perform any software emulation).

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 by 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:

  • Scales the color channels to [0..1).

  • Calculates Channel = pow( Channel, 1 / Gamma ).

  • Scales the result back to int [0..256).

Gamma presentation is supported only on a 32-bit color depth desktop.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

  • Software Requirements

    The test tool requires the following software:

    • Supported operating system (see list above).
    • Software components included with the device that is being tested.
  • Hardware Requirements
    • Device to be tested
    • Computer that meets the minimum software requirements
    • Windows keyboard
    • Two-button pointing device
    • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
    • Hard drive with a minimum of 20 GB available on partition C:

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:


Present Validation 2 - Vista

Type: Automated Test

Overview

The Present Validation 2 - Vista test verifies the new D3DPRESENT_DONOTFLIP flag. 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


Present Validation 2 (FullScreen)

Type: Automated Test

Overview

The Present Validation 2 (FullScreen) test verifies that all modes that the EnumAdapterModes method reports 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 three (which is the maximum allowed). The DoNotWait test expects the driver to return control to the application by 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

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 that the test used for the back buffer format and 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 following table lists the image surfaces that are used in the test. If you specify the -Save command option, the test saves these files.

Surface | Description
texture.dds | The texture used to fill the quad that is used in Present operations.
SourceSurface.bmp | The source surface in the back buffer. For full-screen present operations, this surface is the whole buffer.
DestSurface.bmp | The destination surface in the front buffer. For full-screen present operations, this surface is the whole buffer.
refSurface.bmp | The reference surface, as computed by the Microsoft Direct3D API.
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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Test Assertions

5.305.1 Drivers must succeed Reset for all the modes reported through EnumAdapterModes.

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: If the driver cannot be reset into a particular screen resolution, that screen resolution value should not be reported in EnumAdapterModes. A reset failure causes the test to mark the test as failing.

5.305.2 Drivers should succeed the Present calls for all the modes reported through EnumAdapterModes.

Test Assertion GUID:

Windows Logo Program: Anonymous

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:

Windows Logo Program: Anonymous

Additional Information: The expected error code is D3DERR_WASSTILLDRAWING. The test fails if the driver renders all 100 frames without returning an error code. The test also verifies that no error code is returned (and that the driver is busy waiting) if D3DPRESENT_DONOTWAIT is not specified.

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

Windows Logo Program: Anonymous

Additional Information: The expected error code is D3DERR_WASSTILLDRAWING. The test calls the LockRect method on the back buffer.


Processor Amplification Control Test

Type: Automated Test

Overview

The Processor Amplification Control test verifies the presence and correctness of ProcAmpControl support of the display driver.

Details

The test (based on DX7) attempts to create and use the ProcAmpControl device, a construct exposed through the DXVA1.0 DDI. For each of the supported ProcAmp capabilities (and sometimes for combined capabilities), the test performs the following actions:

  • Verifies that the range, minimum, maximum, default values and step size comply with the specification

  • Sets random, minimum, maximum or invalid values, performs the blt operations and compares the output values with those expected

In case of failures, the test logs the corresponding parameters, as well as the actual and expected output values (or, in the case of non-compliance, the exact cause of failure).

Run Time: under 5 minutes
Log File: ProcAmpTest.wtl (and ProcAmpTest.log)
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 Processor Amplification Control Test

Run the test with the required/desired command line parameters, and use the generated log file to interpret the results.

Command Syntax

Command option | Description
-whql | default command line parameter for WDK testing
-d [x] | device index "x" (0-based)

Cautions

No issues.

Troubleshooting

There really aren't any user-serviceable components. Please attach the log to any issue/bug reports.


Projector WinColor Test

Type: Automated Test

Overview

The Projector WinColor Test validates that a projector conforms to the Windows Color Compliancy requirements for projectors. For more information about the Windows Color Compliancy requirements, see WinColorKit: Windows Color Quality Test Kit for Device OEMs.

Details

The test prints a series of color patches. Each color patch must be measured by 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 that are used and the calculations, see WinColorKit: Windows Color Quality Test Kit for Device OEMs.

Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


RateTest

Type: Automated Test

Overview

The RateTest test switches to all enumerated GDI display modes, all available low-resolution GDI modes (< 640 x 480 pixels), and enumerated DirectDraw full-screen modes. The test then intersects these two sets of modes and validates that the set of Microsoft 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 by 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

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 required to support only 640 x 480 pixel resolution.

The test first verifies these requirements in software by querying the Microsoft 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 by using the DDCREATE_HARDWAREONLY flag. This action forces a HAL device to be used, instead of a HEL device.

  2. By using the DirectDraw IDirectDraw4:EnumDisplayModes function, the test verifies the following values in the DDSURFACEDESC2 structure 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 by using the IID_IDirect3DHALDevice class identifier to allow access to the 3-D graphics hardware device.

  8. All other 3-D graphics tests that are specified employ a double-buffered surface to verify compliance with the double frame buffering requirement.

The test application displays and logs a pass or fail indication of compliance with this requirement. Any of the device setup steps in the preceding list can generate failures. 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 that is attached to the system that you are testing must support the minimum display resolution and refresh rate that were specified earlier.

You must install the Microsoft Windows 98, or later operating system and DirectX version 6 or later.

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


Read Scan Line

Type: Automated Test

Overview

Most of the DirectDraw tests are contained in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests.

  1. Open Fnddraw.exe.

  2. On the Tests menu, click Select Tests.

The test titles listed in the DCT shell do not directly match the test names in Fnddraw.exe. In fact, the names in the DCT often refer to a group of tests within Fnddraw.exe. You can obtain the test case names (within Fnddraw.exe) from the DCT log file.

Many tests within Fnddraw.exe (especially blt related tests) can be paused to give you time to visually analyze the blt results.

  • Click Pause to pause and resume tests.

  • Click Esc to abort a test run. This might take a minute or two. Some tests are more responsive than others.

Details

This is a test for DirectDraw's GetScanLine function. This test ensures that scan line information reported by the display driver is 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapter with DirectDraw capabilities.
Processor
  • x86
  • x64
  • Itanium

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 must be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and power management should be disabled before you run this test. Mode changes and full screen applications 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


Refresh Rate

Type: Manual Test

Overview

The Refresh Rate test verifies that the monitor supports ergonomic timing standards for CRTs. It also verifies the preferred display mode of the monitor (both CRT and LCD) based on the monitors EDID. In addition, the test checks for the support of the Industry Standard Timings for 640 x4 80 pixel format at 60 Hz refresh.

Details

This test examines supported modes (ergonomic modes for CRTs and the preferred mode for both CRTs and LCDs) in a monitor's extended display identification data (EDID) and verifies that the monitor can properly change to display in each mode. The test also tries to set 640 x 480 mode with a 60 Hz refresh to verify support for it.

Run Time: 1-5 mins (depending on the number of modes found)
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 Refresh Rate

  1. Start the test.

  2. If the test finds any modes with ergonomic timings (CRTs), it will change to them, one by one, and display a message to let the user verify that each mode is correctly visible.

  3. The test will change to the preferred mode and let the user verify that it is correctly visible.

  4. The test will change to 640 x 480 at 60Hz and let the user verify that it is correctly visible (/DVI switch).

Command Syntax

Command option | Description
/LCD | Runs the test for LCDs (Ergonomic timing is not verified). If this option is not specified, the test assumes the monitor to be a CRT and verified ergonomic modes too.
/DVI | Checks for the support of 640x480@60Hz

Test Assertions

B4.2.4.4 CRT-based display monitor supports ergonomic timing standards

Test Assertion GUID:

Windows Logo Program: DISPLAY-0066 CRT-based display monitor supports ergonomic timing standards


Registry Validation

Type: Automated Test

Overview

The Registry Validation test verifies that display drivers create the correct registry entries.

Details

This test validates the registry entries that a video card driver makes to ensure that they are complete and sensible. Correct entries in the registry are important for the performance and stability of the Microsoft Windows graphics stack.

During installation, video card drivers must create registry entries. The Graphics-0034 assertion lists the registry entries that this test verifies. 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 that is set on the display driver DLL file must conform to the standards that are described in the test assertions.

Run Time: 1 minute
Log File: registry.log
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Reference Documentation

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


RemoteFX Benchmark Test

Type: Automated Test

Overview

The RemoteFX additional qualification (AQ) for the display adapter chipset defines the requirements and tests for server graphics processing units (GPUs) that want to support desktop virtualization in a RemoteFX virtual machine. This test verifies whether the display adapter under test has sufficient memory bandwidth to support RemoteFX scenarios.

Details

Encoding Test

This test runs the existing WinSat DWM Benchmark, which is used as part the Windows Experience Index, to determine whether a display adapter can support Aero mode. The test passes or fails based on the raw memory bandwidth measured in that test. The threshold is set to 20,000 MB/s, which is significantly higher than the requirement to run Aero on a client machine. In the RemoteFX scenario, the display adapter will simultaneously handle the rendering for multiple virtual machines.

Run time: 1 minute
Log file: RemoteFxBenchmark.wtl
System restart required: No
Test category: WDK\Display\Display Adapters\Additional Qualifications
Supported operating systems for logo or signature testing: Windows Server 2008 R2
Program: Display Adapters – RemoteFX Additional Qualification

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested
  • GPU that can handle DirectX 9 and DirectX 10
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard disk drive with a minimum of 20 GB available on partition C:
Processor
  • x86
  • x64

Running the Test

If the server has both the desktop experience feature and Aero enabled, then the test will temporarily switch to non-Aero mode as WinSat runs. A single pass or fail is returned based on whether WinSat ran successfully and met the required bandwidth. You can review the test results in the log file for actual bandwidth measurements and specific details about failures.

Command Syntax

Command option | Description
RemoteFxGpuBenchmark.exe | The test has no command line options. It assumes that WinSat.exe is available in the current directory, runs it, parses the results, and returns a pass or failure based on the memory bandwidth measured.

Code Tour

The files required are the test application itself (RemoteFxGpuBenchmark.exe) and the WinSat binaries. It has a dependency on WTT logging. This is all available on a machine running the supported operating system and set up as a Driver Test Manager (DTM) client.

File Manifest

File | Location
RemoteFxGpuBenchmark.exe | [WTT\TestBinRoot]\NTTEST\TERMSRVTEST\termsrv\Calista\WLK\Benchmark
WinSat.exe | [WTT\OsBinRoot]
WinSatApi.dll | [WTT\OsBinRoot


RemoteFX DX9 DX10 Sharing Test

Type: Automated Test

Overview

The RemoteFX additional qualification (AQ) for the display adapter chipset defines the requirements and tests for server graphics processing units (GPUs) that want to support desktop virtualization in a RemoteFX virtual machine. This test verifies whether the display adapter supports texture sharing between a DirectX 9 (DX9) and DirectX 10 (DX10) device, as used by RemoteFX.

Details

Encoding Test

RemoteFX requires a display adapter to support texture sharing between a DX9 and DX10 device. This test replicates RemoteFX’s use of shared textures, and ensures that the sharing works correctly with the device under test. It creates a Direct 3D share between a 9Ex and 10.0 texture. Rendering is performed on the DX9Ex texture, and the results are probed in the shared DX10 texture.

Run time: 1 minute
Log file: SharingDemo.wtl, SharingDemo.log
System restart required: No
Test category: WDK\Display\Display Adapters\Additional Qualifications
Supported operating systems for logo or signature testing: Windows Server 2008 R2
Program: Display Adapters – RemoteFX Additional Qualification

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested
  • GPU that can handle DirectX 9 and DirectX 10
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 the Test

When running the test, a small window appears repeatedly, and the colors change from white to gray. When the test completes, the window closes. A single pass or fail is returned, based on whether sharing fails or succeeds. Any single failure causes the test to fail. You can review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
Test.exe | Without any options, the test enumerates devices.
/adapter <DX9Ex-adapter index> | Selects the adapter to use.
/auto | Causes the application to run without key presses.
/iterations <n> | Causes the application to run n iterations of surface sharing and then exits.
/delay <milliseconds> | Delay to main texture/surface before writing to counter texture.
/surface | Use surface instead of texture for main sharing buffer.
/output <file path> | Output logs to text file.
/wttlog | Output logs to wttlogfile.
/nopop | Do not pop-up message box when error occurs.

To run test the test as run by Driver Test Manager (DTM):

SharingDemo.exe /iterations 1000 /nopop /wttlog /adapter 0 /output ".\SharingDemo.log"

Code Tour

The only file in the test package is the test executable, SharingDemo.exe. It has dependencies on DirectX 9 and DirectX 10, as well as WTT logging. These are all available on a machine running the supported operating system and set up as a DTM client.

File Manifest

File | Location
SharingDemo.exe | [WTT\TestBinRoot]\NTTEST\TERMSRVTEST\Termsrv\Calista\WLK\ShareTest


Stretch Rect

Type: Automated Test

Overview

The Stretch Rect test automatically verifies correct implementation of the driver functionality that underlies the IDirect3DDevice9::StretchRect method.

Details

The Stretch Rect 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 subset rectangle (subrect). In these test cases, the source surface may be a texture surface (RT or non-RT), an off screen render target, or an off screen 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 off screen RT, or an off screen 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


Surface Flipping Tests

Type: Automated Test

Overview

Most of the DirectDraw tests are contained in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests.

  1. Open Fnddraw.exe.

  2. On the Tests menu, click Select Tests.

The test titles listed in the DCT shell do not directly match the test names in Fnddraw.exe. In fact, the names in the DCT often refer to a group of tests within Fnddraw.exe. You can obtain the test case names (within Fnddraw.exe) from the DCT log file.

Many tests within Fnddraw.exe (especially blt related tests) can be paused to give you time to visually analyze the blt results.

  • Click Pause to pause and resume the test.

  • Click Esc to abort a test run. This might take a minute or two. Some tests are more responsive than others.

Details

This test ensures that the DirectDraw graphics adapter supports surface flipping, flip status reporting, and vertical blank querying.

The follow Fnddraw.exe 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapter with DirectDraw capabilities
Processor
  • x86
  • x64
  • Itanium

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 power management should be disabled before you run this test. Mode changes and full screen applications 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


TVOut Test

Type: Automated Test

Overview

TVOut Test is a quality assurance application for display card secondary output ports (commonly referred to as TV Output ports).

Details

Currently, the output of video content to TVs (analog, component, and so on) does not produce a consumer-level quality of 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 (VidPN targets) are the physical connections on a display card.

These include HD-15, DVI, CD, S-Video, and RCA connectors

The examples of devices that can be connected to these VidPN targets include digital and analog monitors and high and standard definition TVs.

The function of DMM is to try to detect the presence of these devices and their characteristics.

Some targets will send a signal when they arrive or depart from the port

Some targets can be polled at periodic intervals to determine whether the device is 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, DMM can attempt to get the device's extended display identification data (EDID).EDID 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 the host.

The TVOut Test enumerates and exercises the Windows GDI ChangeDisplaySettingsEx function, 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 Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


Update Surface

Type: Automated Test

Overview

The Update Surface 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 that the driver supports.

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 the Microsoft Direct3D version 9 of the LoadSurfaceFromSurface function to prepare reference images.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


Update Texture

Type: Automated Test

Overview

The Update Texture test verifies device capabilities to load textures (such as mipmap or cubemap) from system memory to video memory by using te UpdateTexture function. The test includes the following scenarios:

  1. Load the entire texture.

  2. Load a portion of the texture.

  3. The source and destination texture are square or non square.

  4. The source and destination texture have different levels.

Details

This test 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 and could have different levels) and populates these surfaces with data. Second, the test prepares the source texture; that is, it makes the entire texture dirty, and it makes a portion of the texture dirty. Finally, the test 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Running Update Texture

Test Assertions

Texture Update test.
Test Assertion GUID: 5.65.1


Validate Color Profiles

Type: Automated Test

Overview

The Validate Color Profiles test validates the color profiles associated with the color device and that the color profile meets basic profile file format requirements.

Details

The test verifies the following:

  • The color profile that is associated with a device can be opened by using the OpenColorProfile() and WcsOpenColorProfile() functions.

  • A color transform can be created by using the color profiles.

  • The 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 Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


VBIB - Vertex and Index Buffer Validation

Overview

The VBIB - Vertex and Index Buffer Validation test attempts to validate the use of a variety of vertex and index buffers.

Details

This test is broken into the following test groups, which test vertex and index buffers in different ways:

  • 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 that are 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()).

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


Video Memory Management Tests

Type: Automated Test

Overview

Most of the DirectDraw tests are contained in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests.

  1. Open Fnddraw.exe.

  2. On the Tests menu, click Select Tests.

The test titles listed in the DCT shell do not directly match the test names in Fnddraw.exe. In fact, the names in the DCT often refer to a group of tests within the Fnddraw.exe. You can obtain the test case names (within Fnddraw.exe) from the DCT log file.

Many tests within Fnddraw.exe (especially Blt related tests) can be paused to give you time to visually analyze the blt results.

  • Click Pause to pause and resume the test.

  • Click Esc to abort a test run. This might take a minute or two. Some tests are more responsive than others.

You do not need Fnswtt.dll unless you want WTT logging.

Details

The test verifies that video memory is accurately reported and managed.

The following Fnddraw.exe cases make up this test:

  • MEMMAN_GetAvailableVidMem - This test case examines and 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapater with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

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 must be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and power management should be disabled before running this test. Mode changes and full screen applications 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


Vista Fonts

Type: Automated Test

Overview

The Vista Fonts 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. Two 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


VPE and Kernel Tests

Type: Automated Test

Overview

Most of the DirectDraw tests are contained in Fnddraw.exe. You can run Fnddraw.exe outside of the DCT shell, and select initial tests. On the Tests menu, click Select Tests.

The test titles listed in the DCT shell do not directly match the test names in Fnddraw.exe. In fact, the names in the DCT often refer to a group of Fnddraw.exe tests. You can obtain the Fnddraw.exe test case names from the DCT log file.

Many Fnddraw.exe tests (especially blt related tests) can be paused to give you time to visually analyze the blt results.

  • Press Pause on the keyboard to pause and resume.

  • Press Esc on the keyboard to discontinue a test run. This might take some time. 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), 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapter with DDraw capabilities
Processor
  • x86
  • x64
  • Itanium

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 power management should be disabled before running this test. Mode changes and full screen applications 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


Wait for VBlank

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 run 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 the WaitForVBlank function 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 2 ms.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


WDDM Bit Flip - Invalid Param

Type: Automated Test

Overview

WDDM 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 that is passed from user-mode.

Details

WDDM 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.
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM Blt

Type: Automated Test

Overview

WDDM Blt is a stability test for the user-mode bitblt DDI.

Details

WDDM Blt verifies system stability when performing valid video and system memory surface bitblt operations. This test performs surface bitblts between a variety of surface types and memory pools. LDDM drivers must not crash in user mode or kernel mode when running this test.
Run Time: 20 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM Blt - Depth

Type: Automated Test

Overview

WDDM Blt - Depth verifies that drivers are stable when asked to perform bitblts to and from system memory surfaces with depth/stencil formats.

Details

WDDM Blt - Depth verifies that display drivers correctly handle depth bitblts. 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 perform a bitblt between them. Drivers must not crash or hang during this test.
Run Time: 10 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM Blt - Stretch

Type: Automated Test

Overview

The WDDM Blt - Stretch test verifies that user-mode display drivers correctly implement stretching bitblt operations.

Details

The WDDM Blt - Stretch test creates two surfaces and uses the user-mode blt DDI to transfer data between them. The test asks drivers to perform stretching blts between the two surfaces. The source surface can 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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM BVT2

Type: Automated Test

Overview

The WDDM BVT2 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 Windows Vista Driver Model video driver. The primary goals of this test are to ensure system stability under the Windows Vista driver model and to verify the functionality of Windows Vista display drivers. The test is composed of a set of test groups. Each test group exercises one subset of the Windows 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 entry points in the operating system. Drivers must not crash or leak memory while running this test.
Run Time: 30 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Windows Vista

  • Software components included with the device that is being tested.

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM CCD Test for AdditionalMonitorModes

Type: Automated Test

Overview

This test verifies that v1.1 drivers enumerate all the additional monitor modes for each target that has a monitor connected.

Details

This test verifies that v1.1 drivers enumerate all the additional monitor modes for each target that has a monitor connected. The target types for which this is applicable are - HD15, SVIDEO, COMPOSITE, COMPONENT, HDTV and DVI.

The test enumerates all the raw modes and then calls SetDisplayConfig to make sure that the mode is successful.

If a certain target type fails to enumerate certain modes, those modes are enlisted in the log.
Run Time: Maximum of 1 hour, depending on the number of target monitors are connected to.
Log File: AdditionalMonitorModes.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: AdditionalMonitorModes.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • WDDM v1.1 driver installed

Hardware Requirements

The test tool requires the following hardware:

  • An adapter with v1.1 driver

  • The test will do the mode validation only for targets that have monitors connected. So for a logo test, connect monitors to all the targets on the adapter.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running WDDM CCD Test for AdditionalMonitorModes

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test will return SKIP if the driver is non WDDM 1.1.

The test will return FAIL if the modes that should be supported by a certain target are not supported. All such modes are printed in the log.

Command Syntax

Command option | Description
AdditionalMonitorModes.exe | Without any options, the test does nothing.
bvt | Starts the application and runs the test cases that are specified in the .profile file.
full | Runs a full version of the test.

Code Tour

File Manifest

File | Location
AdditionalMonitorModes.exe | [testbinroot]\NTTEST\WINDOWSTEST\Graphics\wddm\bin


WDDM CCD Test for AspectRatioSupportUI (Manual)

Type: Manual Test

Overview

This test verifies that v1.1 drivers support aspect ratio preserved scaling mode on at least one target and visually verifies aspect ratio.

Details

This test verifies that v1.1 drivers support aspect ratio preserved scaling mode and asks the user to visually verify it.

Because the existing mode enumeration apis in win32k and DirectX do not support this new scaling mode, we apply the following heuristics:

  • Identity scaling can only be supported when the source and target mode have the same resolution, in which case no non-identity scaling is allowed.

  • For resolutions under 1024x768, we are not making any requirements on which scaling modes need to be supported.

  • For higher resolutions, centered should always be supported and max aspect ratio preserving and stretched scaling must either both be supported or neither.

  • The user should have at least two monitors connected with different aspect ratios. The test displays a circle on all the monitors and asks the user if the circle appears as a circle or an ellipse. If the aspect ratio has been preserved correctly, you will see a circle; otherwise, you will see an ellipse.

Run Time: About 5 minutes
Log File: AspectRatioSupportUI.xml
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: AspectRatioSupportUI.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • WDDM v1.1 driver installed

Hardware Requirements

The test tool requires the following hardware:

  • An adapter with v1.1 driver

  • At least 2 monitors with different aspect ratios

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running WDDM CCD Test for AspectRatioSupportUI (Manual)

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test will return SKIP if the driver is non WDDM 1.1.

The test will return FAIL if there are no aspect ratio preserved scaling modes supported or the user cannot see a circle as a circle on the scaled monitor.

All such modes are printed in the log.

Command Syntax

Command option | Description
AspectRatioSupportUI.exe | The test runs without any command line options.

Code Tour

File Manifest

File | Location
AspectRatioSupportUI.exe | [[testbinroot]\NTTEST\WINDOWSTEST\Graphics\wddm\bin


WDDM CCD Test for Forced Projection

Type: Automated Test

Overview

This test verifies that the targets that can be force projected on, are marked that way. It also verifies that it is force projectable indeed.

Details

This test verifies that the targets that can be force projected on, are marked that way. It also verifies that it is force projectable indeed.

If the test finds a forcible target and no physical monitor connected, it simulates a monitor on this target and tries to set and active path on this target.

Run Time: ~10 minutes.
Log File: ForcedProjection.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: ForcedProjection.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • At least one target should be force projectable. Analog targets are marked force projectable.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running WDDM CCD Test for Forced Projection

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test will return SKIP if the driver is not WDDM(-whql not specified) non WDDM 1.1(-whql specified).

The test will return FAIL if:

  1. The target should be forcible but is not set that way

  2. A target is marked forcible but cannot simulate a monitor on this target.

  3. Cannot set an active path on the simulated monitor.

Command Syntax

Command option | Description
ForcedProjection.exe | The test can be run without command line options. In that case, it will run for WDDM drivers.
-whql | The test will make sure that the driver is v1.1 driver.

Code Tour

File Manifest

File | Location
ForcedProjection.exe | [testbinroot]\NTTEST\WINDOWSTEST\Graphics\wddm\bin


WDDM CCD Test for Persistent Reset

Type: Automated Test

Overview

PersistentReset validate that on system and monitor power transitions the desktop configuration doesn't change.

This test verifies that the desktop configuration are reset properly to persistent data saved in the registry. After setting the system to a specified topology, the test use ChangeDisplaySettingsEx(CDS_UPDATEREGISTRY) to change the display modes and save the configuration data to the persistent database. The test then uses SetDisplayConfig to change the desktop modes without update them to the registry. Finally; the test verifies that CcdSetDisplayConfig(0, NULL, 0, NULL, SDC_APPLY| SDC_USE_DATABASE_CURRENT) will reset the desktop configuration to match with data saved previously in the persistent database. The test also places the system in S1, S2, S3, S4 sleep states or turns off the monitor then verify that after waking up from the sleep states, the desktop configuration persisted.

Run Time: Less than 1 Hr for 2 monitor systems and less than 30 minutes for single monitor systems.

Log File: PersistentReset.xml

System Restart Required: No

Test Category:
Program: PersistentReset.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Windows 7

  • WDDM v1.1 driver installed

Hardware Requirements

The test tool requires the following hardware:

  • An adapter with v1.1 driver.

  • The test will do the mode validation only for targets that have monitors connected. So for a logo test, connect monitors to all the targets on the adapter.

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running WDDM CCD Test for Persistent Reset

All test cases cause the desktop configuration changed, monitors power off and on, or the system power set to different sleep states.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the system does not support the display configuration of the test cases.

Command Syntax

Command option | Description
PersistentReset.exe | Without any options, the test does reset and system sleep test cases.
monitor | Starts the application and runs the monitor off/on test cases.
Sleep | Starts the application and runs the system sleep test cases.
Reset | Starts the application and runs the reset test cases

Code Tour

File Manifest

File | Location
PersistentReset.exe | [testbinroot]\NTTEST\WINDOWSTEST\Graphics\wddm\bin


WDDM CCD Test for QueryHardwareCaps

Type:

Overview

This test verifies that with a v1.1 driver, the DDI to query hardware capabilities of the adapter is implemented and calls it.

Details

This test verifies that with a v1.1 driver, the DDI to query hardware capabilities of the adapter is implemented and calls it. The test tries to query the hardware capabilities of all the targets connected to active paths in the system.

Run Time: ~10 minutes.
Log File: QueryHardwareCaps.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: QueryHardwareCaps.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • WDDM v1.1 driver installed

Hardware Requirements

The test tool requires the following hardware:

  • An adapter with v1.1 driver

  • At least one path should be active

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running WDDM CCD Test for QueryHardwareCaps

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test will return SKIP if the driver is non WDDM 1.1.

The test will return FAIL if there was a failure in calling the ddi.

Command Syntax

Command option | Description
QueryHardwareCaps.exe | The test doesn't need any command line options.

Code Tour

File Manifest

File | Location
QueryHardwareCaps.exe | [testbinroot]\NTTEST\WINDOWSTEST\Graphics\wddm\bin


WDDM CCD Test for Validation of Basic Topology

Type: Automated Test

Overview

This test verifies that with Windows 7, the basic topologies of internal, external, extended, and clone are supported.

Details

This test verifies that with Windows 7, the basic topologies of internal, external, extended and clone are supported.

The test tries to validate and set these basic topologies if validation succeeds.

Run Time: ~10 minutes
Log File: SetDisplayConfig.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: SetDisplayConfig.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • An adapter for WDDM driver

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running WDDM CCD Test for Validation of Basic Topology

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test will return SKIP if the validation of the basic topologies does not succeed.

The test will return FAIL if there was a failure in actually setting these topologies after validation succeeds.

Command Syntax

Command option | Description
SetDisplayConfig.exe | The test needs command line options
InternalTopology | Sets internal topology
ExternalTopology | Sets external topology
ExtendedTopology | Sets extended topology
CloneTopology | Sets clone topology

All the command line options can be specified at once -

SetDisplayConfig.exe InternalTopology ExternalTopology ExtendedTopology CloneTopology

Code Tour

File Manifest

File | Location
SetDisplayConfig.exe | [[testbinroot]\NTTEST\WINDOWSTEST\Graphics\wddm\bin


WDDM CCD Test for verifying all targets of enumerated type and not OTHER

Type: Automated Test

Overview

Graphics card drivers are meant to enumerate the type of each target. Before Windows 7, the OTHER type was enumerated for display types handled by the IHV. With Windows 7 and beyond, these devices should be explicitly reported to the system of their correct type. This test verifies that each target path reported is a valid enumeration and that none of the enumerated paths are of type OTHER.

Details

The test executable must be invoked with the "Other" parameter on run. It parses all paths, verifying each is enumerated and that none are of type OTHER.

Run Time: Less than 1 minute
Log File:InternalAdaptersTest.xml
System Restart Required: No
Program:InternalAdaptersTest.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • WDDM video device

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the system is unable to query displays.

Command Syntax

Command option | Description
InternalAdaptersTest.exe | Without any options, the test displays command-line parameters
Internal | Verifies that only one path of type INTERNAL is active at any time.
Other | Executes the test described in this document.
ConnectedDVI:# | Verifies that the system enumerates at least # DVI and HD15 targets for a system with # DVI-I ports.

Code Tour

File Manifest

File | Location
InternalAdaptersTest.exe | [testbinroot]\nttest\windowstest\graphics\wddm\bin\


WDDM CCD Test for verifying only one internal target active on GPU

Type: Automated Test

Overview

Modern laptops can have multiple graphics adapters to provide both performance and battery life. At any point, however, no more than one source-target path of type INTERNAL should be active. This test verifies that no system has more than one active path of type INTERNAL. In addition, if more than one INTERNAL path exists, the test will try to force an invalid state and verify the driver either disallows it or gracefully handles it.

Details

The test executable must be invoked with the "Internal" parameter on run. It parses all paths, seeking those of type INTERNAL, if more than one path is found, all are looped through to verify only one is active.
Run Time: Less than 1 minute
Log File: InternalAdaptersTest.xml
System Restart Required: No
Program: InternalAdaptersTest.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • WDDM video device

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the system is unable to query displays of type INTERNAL.

Command Syntax

Command option | Description
InternalAdaptersTest.exe | Without any options, the test displays command-line parameters
Internal | Verifies that only one path of type INTERNAL is active at any time.
Other | Executes the test described in this document.
ConnectedDVI:# | Verifies that the system enumerates at least # DVI and HD15 targets for a system with # DVI-I ports.

Code Tour

File Manifest

File | Location
InternalAdaptersTest.exe | [testbinroot]\nttest\windowstest\graphics\wddm\bin\


WDDM CCD Verify DVI-I External Adapters Matches Reported Ports Test

Type: Automated Test

Overview

The DVI-I specification states that a port must provide both an HD15 and a DVI path. This test ensures the number of physically-present DVI-I adapters is not greater than the number of internally-reported HD15 or DVI connectors.

Details

The test executable must be invoked with the "DVI" parameter on run. It then prompts the user to enter the number of physical DVI-I ports on the system. When known, it compares this to the results of a QDC, checking that at least as many HD15 and DVI ports are reported.

Run Time: Less than 1 minute
Log File: InternalAdaptersTest.xml
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: InternalAdaptersTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • WDDM video device

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
InternalAdaptersTest.exe | Without any options, the test displays command-line parameters
Internal | Verifies that only one path of type INTERNAL is active at any time.
Other | Tests that all enumerated devices are of a known type and not of type OTHER.
DVI | Executes the test described in this document

Code Tour

File Manifest

File | Location
InternalAdaptersTest.exe | [testbinroot]\nttest\windowstest\graphics\wddm\bin\


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 Windows 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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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
coherency.exe | There are no command line options for this executable.

Code Tour

File Manifest

File | Location
coherency.exe | [testbinroot]\nttest\multimediatest\video\lddm\bin

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


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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM DMASplit (Force Split Points)

Type: Automated Test

Overview

The WDDM DMASplit (Force Split Points) test verifies that whenever DMA buffer references a lot of resources, display driver will insert enough split points for this buffer to be executed in parts

Details

The WDDM DMASplit (Force Split Points) test verifies that whenever DMA buffer references a lot of resources, display driver will insert enough split points for this buffer to be executed in parts. 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 stop responding (hang) while running this test.
Run Time: 30 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM Eviction

Type: Automated Test

Overview

WDDM Eviction tests if eviction has been done correctly by the video memory manager.

Details

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 need 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.

System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Test Assertions

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification


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 contexts does flipping operations. If the driver correctly implements hardware or software flip queuing, 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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM Fuzzer - Invalid Param

Type: Automated Test

Overview

The WDDM Fuzzer test verifies that kernel-mode drivers are stable when requested 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 stop responding while running this test.
Run Time: 30 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM GammaRamp

Type: Automated Test

Overview

The WDDM GammaRamp test verifies that kernel-mode display drivers succeed in the attempts to set gamma ramps.

Details

The WDDM GammaRamp test is a basic test of LDDM gamma ramp functionality. It sets gamma ramps using GDI and operating system kernel-mode entry points. Drivers must not fail during this process.
Run Time: 2 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM Handles - Invalid Param

Type: Automated Test

Overview

The WDDM Handles - Invalid Param test verifies that kernel-mode drivers are stable when requested 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 incorrect type. The test intercepts handles returned from the operating system kernel to the user-mode driver. It then modifies the handles returned to the user-mode driver. User-mode drivers can then generate invalid commands and handle lists that are passed to the kernel-mode driver. Kernel-mode drivers must not fail or stop responding during this test.
Run Time: 20 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM HPD Notification Test

Type: Automated Test

Overview

WDDM HPD Notification Test is a test for HPD removal and arrival notification event.

Details

WDDM HPD Notification Test is a user-mode test. The user has to first generate an HPD removal event by unplugging a computer monitor. Then, the user is required to plug in the monitor. The tests reports success if it detects the arrival event after it detected the removal event.
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Test Assertions

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification


WDDM LockConfirm

Type: Automated

Overview

This test executes different locking scenarios and verifies that surface pattern remains the same after the lock.

Details

This test covers following scenarios:

  • LockEvict - Locks allocations, changes its content, unlocks, and then gets it evicted. Verifies content after allocation is evicted.

  • EvictUnderLock - Locks allocation, changes its content, causes allocation to be evicted while under lock. Unlocks after eviction. Then verifies content.

  • LockPinned - Locks/unlocks pinned allocations, verifies contents.

  • LockUnpinned - Locks/unlocks non-pinned allocations, verifies contents.

  • RunOutOfSwizzlingRanges_nonpinned - Locks non-pinned allocations without unlocking; Video Memory Manager is expected to handle locking when running out of swizzling ranges.

  • RunOutOfSwizzlingRanges_pinned - Locks pinned allocations without unlocking; expects locks to fails when run out of swizzling ranges.

  • LockEachMipLevel - Locks and modifies each mip level of texture without unlocking it. Unlocks levels and verifies contents.

  • LockEachMipLevelNoSwizzlingRange - Executes a scenario where several mip levels are being locked but there is no available swizzling ranges for all levels, so allocation will need to be evicted.Content of the allocation is verified.

  • LockWithFaults - This test will enable different Video Memory Manager faults and lock allocations to force certain code paths.

  • EvictWhileAccessed - This test will read and write to locked allocation while it is being evicted.

  • SwizzlingRangeContentionAndPaging - This test will lock allocation without unlocking to create contention for swizzling ranges, at the same time some of the locked allocation will be evicted freeing the ranges.

Run Time: 45 minutes
Log File: LockConfirm.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: LockConfirm.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Default hardware requirements just like other WDDM tests

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running LockConfirm

All test cases return PASS or FAIL. Review the test results in log file for specific detailes about failures.

Command Syntax

Command option | Description
Lockconfirm.exe | Test executes all the locking scenarios.

Code Tour

File Manifest

File | Location
Lockconfirm.exe | [testbinroot]\ NTTEST\WINDOWSTEST\Graphics\wddm\bin
LockConfirm.xml |


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 simultaneously locks multiple surfaces with a resource and locks surfaces with discard semantics. Display drivers must not stop responding or fail calls to the Lock DDI during this test.
Run Time: 5 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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, the WDDM ManagedPrimary test:

  1. Creates primary surfaces.

  2. Calls the user-mode SetDisplayMode DDI.

  3. Renders some frames into the surfaces and switches between them.

  4. Changes the display mode (which causes the managed primaries to become unpinned from video memory).

  5. 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.

System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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 that can 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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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 might put the system into rotated modes. Display drivers must not crash or stop responding (hang) while this test is running.
Run Time: 60 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM ModifyVAD

Type: Automated Test

Overview

The WDDM ModifyVAD test verifies that drivers correctly protect access to user-mode virtual addresses.

Details

The WDDM ModifyVAD test adjusts the access rights that are 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 stop responding (hang).
Run Time: 2 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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 can crash or hang during this test.

Run Time: 10 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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 operating system. 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 operating system, and they must also fail the corresponding DDI call when an operating system 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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM Passthrough - Lock

Type: Automated Test

Overview

The WDDM Passthrough - Lock test verifies that user-mode display drivers correctly handle failures originating from runtime callback functions.

Details

The WDDM Passthrough - Lock test intercepts calls from the user-mode display driver into the operating system. 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 operating system, and they must also fail the corresponding DDI call when an operating system callback function fails. This test variation injects failures into the following callback functions:

LockCB
UnlockCB

Run Time: 5 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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 WDK documentation.
Run Time: 5 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM PnPStop Test

Type: Automated Test

Overview

The WDDM PnPStop test disables and enables the display adapter.

Details

The WDDM PnPStop test disables the display adapter and then enables it again. Setupapi is used for disabling and enabling the display device. This is an alternate method of enabling and disabling the display adapter to using Device Manager.
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Test Assertions

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification


WDDM PnPStop Test - Update and Rollback

Type: Automated test

Overview

This test updates the driver to the same version, and then rolls back to the version that is currently installed. By doing so, it verifies that the driver does not hold any resources, and allows for clean driver updates and rollbacks without restarting the system.

Details

Run time: Less than 1 minute
Log file: PnPStop.xml
System restart required: No
Supported operating systems for logo or signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: PnPStop.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard disk drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All tests return PASS.

Command Syntax

Command option | Description
PnPStop.exe | Without any options, the command lists options.
UpdateDriver [file] | Starts the application and runs the update driver task. If no file is specified, uses the currently installed driver.
RollbackDriver | Rolls back the driver.

Code Tour

File Manifest

File | Location
PnPStop.exe | [testbinroot]\NTTEST\WINDOWSTEST\Graphics\wddm\bin


WDDM PnPStopVGA Test

Type: Automated Test

Overview

WDDM PnPStopVGA test - This test generates a PnPStop by disabling the device, and then it checks if the system is in VGA mode.

Details

The WDDM PnPStopVGA test is in the new windows driver model for Windows Vista. When the display device is disabled, the system should be in VGA mode. The test checks the registry entry to make sure that the value of

InstalledDisplayDrivers for the specified device key is set to "vga." The test also checks for

the display adapter to support 10x7 for 32bpp or 24bpp.

System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Test Assertions

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification


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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following softwa re:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM PresentStats - Present Statistics Test

Type: Automated Test

Overview

The WDDM PresentStats 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 that the following scenarios work:

  • For multihead 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 that is 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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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 fail to respond (hang) during this test. The following scenarios are executed:

  • Present-blts to 8bpp, 16bpp, and 32bpp surfaces

  • Color-fill presents to 8bpp, 16bpp, and 32bpp surfaces

  • Presents to staging buffers

  • Primary to primary present-blts

  • Present blts with large rectangle counts

Run Time: 60 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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 stop responding (hang) or crash while running this test.
Run Time: 20 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM Rotate

Overview

The WDDM Rotate test executes a number of scenarios to verify that rotation of the contents of the monitors is handled correctly by the display driver and the operating system.

Details

The WDDM Rotate test executes a number of rotation scenarios to verify that the content that is displayed on the screen to the user is shown correctly in a rotated environment. Rotation of the screen is tested at various resolutions and orientations for each test (it is possible to specify command line options to target a certain mode for reproducing issues). The different tests are detailed below:

WinGdi

This test draws a known image to an internal buffer, and then uses BitBlt to copy the contents of the internal buffer into the shadow buffer of the CDD driver. The test then verifies the contents of the CDD primary buffer against what the test expects to be in the primary buffer. The test surface runs in a window for this test. If the caller opts to save a copy of the buffers that are used in the test, the copy will be saved as a file called GdiCdd<Width>x<Height>x<Bpp>r<Rotation>.bmp i.e. GdiCdd1280x1024x32r180.bmp.

WinCdd

This test fills the CDD primary buffer with solid colors by using the ColorFill and Present method, setting the rotation bit to 1 in the D3DKMT_PRESENTFLAGS structure. This requires the driver to perform the rotation. The test then verifies that the contents of the CDD primary and CDD shadow buffers match as expected. This test runs in a window on the desktop, rather than running in a full screen. If the caller opts to save a copy of the image that is captured to compare during the test, the copy will be saved in the working directory as CddGdi<Width>x<Height>x<Bpp>r<Rotation>.bmp.

WinD3D

This test draws data to the render target by using the D3D DrawPrimitive method. Data from the render target is then compared to data in the CDD primary buffer to verify that the contents are as expected, taking the rotation factor into account. This test runs inside a window on the desktop.

D3D

This test executes a full screen version of the WinD3D test, so that the whole screen area is used to test rather than just a windowed portion.

FullScreen

This test executes the WinCdd test in full screen mode, so that the whole screen area is used for testing rather than just a windowed portion. If the caller chooses to save a copy of the image comparison buffer that is used in the test, the copy will be saved in the working directory as FSColorFill<Width>x<Height>x<Bpp>r<Rotation>.bmp.

There are a number of command line parameters that the test uses. Most of these are optional and can be set to reproduce a specific issue, for example, set the width, height, BPP, monitor, and rotation. If the command line parameters relating to display mode properties are not set, the test executes its default set of parameters and runs through a set of predefined modes.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 Rotate

Command Syntax

Command option | Description
WinGdi (Optional) | Indicates the WinGDI test should be executed.
WinCdd (Optional) | Indicates the WinCdd test should be executed.
WinD3D (Optional) | Indicates the WinD3D test should be executed.
Windowed (Optional) | Runs all of the windowed versions of the tests, WinGdi, WinCdd, WinD3D
FullScreen (Optional) | Runs a full screen version of the WinCDD test.
D3D (Optional) | Runs a full screen version of the WinD3D test.
Screen (Optional) | Indicates that the internal images used to compare the expected content of the rotated screen and the actual contents are saved to the hard disk at the end of the test. See detailed description for information about saved file name formats.
Save (Optional) | Indicates that the internal images used to compare the expected content and the actual rotated contents are saved to disk, only if the test fails. See test description for more information about the saved name file format.
Width (Optional) | Indicates the width of the resolution that the test should use while executing. For example, Width:1280.
Height (Optional) | Indicates the height of the resolution that the test should use when it is executing.
BPP (Optional) | Indicates the Bits Per Pixel to set for the mode when the test is executing.
Rotation (Optional) | Specifies the rotation value to use during the test. Valid values are 0, 90, 180, and 270.
Monitor (Optional) | Specifies which monitor to execute the test on. This value is a 1 based index.


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 stop responding (hang) while running this test.
Run Time: 30 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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 stop responding (hang) while running this test.
Run Time: 30 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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 prepatch DMA buffers. Display drivers must not cause the system to crash or stop responding (hang) while running this test.
Run Time: 30 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM SetDXMode

Type: Automated Test

Overview

The WDDM SetDXMode test verifies that display drivers can successfully set all display modes that they enumerate.

Details

The WDDM SetDXMode test attempts to set all display modes that are 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 stop responding (hang) while executing this test.
Run Time: 2 hours
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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 two situations in which user-mode drivers must flush command buffers to kernel mode before returning from a Lock() call:

  • When a resource that is the target of a pending GPU write operation is locked

  • When a resource that is the source of a pending GPU read operation is locked

The test creates video memory resources and instructs 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 is blocked until the GPU finishes processing all commands that reference the resources.

Run Time: 20 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM System Check

Type: Automated Test

Overview

The WDDM System Check test verifies that the system supports the appropriate display driver model.

Details

This test checks for the following:

  1. If the 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 the system is a stand-alone server, the graphics driver is expected to be built from the XDDM, if 3-D acceleration is not supported, or from the WDDM otherwise.

Run Time: 1 minute
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Test Assertions

Windows Logo Program: Anonymous


WDDM TDR Verify Test

Type: Automated Test

Overview

The WDDM TDR Verify test is a user-mode test that simulates a TDR and verifies that d3d applications can render after a TDR.

Details

The WDDM TDR Verify test simulates a TDR, and verifies that a TDR actually occurred. It then executes d3d7, d3d8, and d3d9 applications.
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Test Assertions

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification


WDDM Toaster - Invalid Param

Type: Automated Test

Overview

The WDDM Toaster - Invalid Param test verifies that the operating system is stable and secure despite 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 stop responding "hang" when a user-mode driver is given invalid parameters.
Run Time: 2 hours
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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


WDDM WSSections

Type: Automated Test

Overview

The WDDM WSSections test verifies that graphic drivers are not wide opened to all processes.

Details

Some video vendors might release drivers with shared portable executable (PE) sections that are wide opened to all processes. WSSections finds all installed display driver files and scans for write-shared sections. The test will fail if it finds a write-shared memory section.

Run Time: 30 seconds
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Test Assertions

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification


WDK EVR DCT Player

Type: Automated Test

Overview

The WDK EVR DCT Player tests check basic file playback with Enhanced Video Renderer (EVR) in the following modes: windowed or full-screen, with Media Foundation or with DirectShow.

Details

EVRDCTPlayer.exe is a shellrunnerapp test suite. It runs the following four tests:

Video playback tests

  1. EVR (Media Foundation)
    1.1. D3D9/Default

    1.1.1. Monitor 1\WMV playback: windowed, on monitor 1, default video processor and rasterizer

    This test instantiates EVR as a media sink of Windows Media Foundation topology for a WMV media file. A video window is created as an overlapped window on the primary monitor. Video progression is verified by checking that timestamps of current video frames obtained with IMFVideoDisplayControl::GetCurrentImage() change over time.

    1.1.1. Monitor 1\WMV playback: full-screen, on monitor 1, default video processor and rasterizer

    This test instantiates EVR as a media sink of Windows Media Foundation topology for a WMV media file. A video window is created as an overlapped window on the primary monitor. Test sets EVR to the exclusive full-screen mode by calling IMFVideoDisplayControl::SetFullScreen(true). This causes the video window to change size and style to the top-most covering the entire desktop. It also causes EVR to change D3D device and to reallocate all internal resources. Video progression is verified by checking that timestamps of current video frames obtained with IMFVideoDisplayControl::GetCurrentImage() change over time.

  2. EVR (DirectShow)
    2.1. D3D9/Default

    2.1.1. Monitor 1\DirectShow WMV playback: full-screen, on monitor 1, default video processor and rasterizer

    This test instantiates EVR as a renderer filter of DirectShow filter graph for a WMV media file. A video window is created as an overlapped window on the primary monitor. Video progression is verified by checking that timestamps of current video frames obtained with IMFVideoDisplayControl::GetCurrentImage() change over time.

    2.1.1. Monitor 1\DirectShow WMV playback: windowed, on monitor 1, default video processor and rasterizer

    This test instantiates EVR as a renderer filter of DirectShow filter graph for a WMV media file. A video window is created as an overlapped window on the primary monitor. Test sets EVR to the exclusive full-screen mode by calling IMFVideoDisplayControl::SetFullScreen(true). This causes video window to change size and style to the top-most covering the entire desktop. It also causes EVR to change the D3D device and reallocate all internal resources. Video progression is verified by checking that timestamps of current video frames obtained with IMFVideoDisplayControl::GetCurrentImage() change over time.

Run Time: 10 min
Log File: EVRDCTPlayer.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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 WDK EVR DCT Player

This is a simple file playback scenario and a very basic playback algorithm. Tests will fail if building FilterGraph / completing MF topology fails, or if video disappears or freezes.

Command Syntax

Command option | Description
-c videoplayback_Mon1 -l "s98wtt.dll" |

Code Tour

File Manifest

File | Location
[WTT\TestBinRoot]\nttest\multimediatest\common\ShellRunner*.* |
[WTT\TestBinRoot]\nttest\multimediatest\common\s98wtt.dll |
[WTT\TestBinRoot]\nttest\multimediatest\wmmftest\evrdctplayer.* |
[WTT\TestBinRoot]\nttest\multimediatest\wmmftest\videoPlaybackTest_MSContent.wmv |
[WTT\TestBinRoot]\nttest\multimediatest\wmmftest\videoplayback_Mon1.pro |

Test Assertions

WDK EVR DCT Player
Test Assertion GUID: 665D3965-53BD-4420-88CD-598B64C0A20E

Windows Logo Program: GRAPHICS-0029 Display subsystem implements minimum hardware acceleration capabilities

WDK EVR DCT Player
Test Assertion GUID: 665D3965-53BD-4420-88CD-598B64C0A20E

Windows Logo Program: GRAPHICS-0032 Display subsystem implements minimum hardware acceleration capabilities


WGF11 Async

Type: Automated Test

Overview

The WGF Async test verifies D3D graphics driver/hardware conformance for query and other asynchronous features that are not specifically tested elsewhere.

Details

The Async Conformance Test Plan features the following characteristics:

  • 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 that they are predicated)

  • Counters tested with random amounts of geometry being rendered

  • Possibly considers issues with clipping in regards to pipeline statistics

Run Time: 1 minute
Log File: WGF11Async.xml

System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

  • Windows Server 2008

Program: WGF11Async.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if it is run with a feature level that doesn't support the feature being tested.

The test might return BLOCKED if there is an uncaught exception (framework catches it at the end and logs it).

Command Syntax

Command option | Description
WGF11Async.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
WGF11Async.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Blend

Type: Automated Test

Overview

The WGF11Blend test verifies D3D graphics driver/hardware conformance for color and alpha blending features that are not specifically tested elsewhere.

Details

The Alpha Blending Conformance Test Plan features the following characteristics:

  • Quad rendered to render target

  • Each RT pixel tested programmatically against expected value

  • Different gradients rendered to RT for each blend element (destination, source, second source)

  • Blend modes cycled independently and in tandem for color and alpha

  • RT formats cycled, to find issues with clamping and precision

  • Cycle number of RTs used and with blending enabled

  • Different RT formats used in RT indices, to test independent clamping and precision

Run Time: 40 minutes
Log File: WGF11Blend.xml
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

  • Windows Server 2008

Program: wgf11blend.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if it is run with a feature level that doesn't support the feature being tested.

The test might return BLOCKED if there is an uncaught exception (framework catches it at the end and logs it).

Command Syntax

Command option | Description
wgf11blend.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11blend.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Clipping

Type: Automated Test

Overview

The WGF Clipping test verifies D3D graphics driver/hardware conformance for geometry clipping features that are not specifically tested elsewhere.

Details

The following describes the 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

Run Time: 15 minutes
Log File: WGF11Clipping.xml
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

Program: wgf11clipping.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Some test cases my skip if run using feature level 10.0 or feature level 10.1

Command Syntax

Command option | Description
wgf11clipping.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11clipping.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Compute Shader

Type: Automated Test

Overview

This test includes multiple test groups, exercising different features that are specific to Compute Shader stage. A subset of these features is also extended to Pixel Shader stage. Please make sure that the implementations for critical features from different hardware vendors conform to the DX11 spec.

Details

The features covered by this test include the following:

  • Dispatch calls

  • System Values for Compute Shader Stage

  • Memory Barrier

  • Atomicity of atomic operations

  • Group Shared Memory

  • Unordered Access Views (UAV) of different resource types

  • Append UAVs

  • Counter UAVs and interactions between Compute Shader stage and Pixel Shader stage

Run Time: The run time of this test is largely dependent on the implementation of the DX part. If it is software like the Reference Rasterizer or simulators, it may take days to run the whole test. If it is hardware, it usually takes 2-3 hours to finish the whole test. Running the test with FeatureLevel 11.0 also takes longer than running it with FeatureLevel 10.x. There are more test cases for FeatureLevel 11.0 than FeatureLevel 10.x, because Compute on FeatureLevel 10.x is only a subset of Compute on FeatureLevel 11.0.
Log File: By default, the log file name is WGF11ComputeShader.xml. You can specify a different log file name with -logfilename switch in the command line.
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: wgf11compute.exe .

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test cases return one of the following results:

  • Pass

  • Fail

  • Blocked

  • Skipped

The log file will contain specific details about the test cases that are failed, blocked, or skipped. A test case will return Skipped if it is invalid according to the current hardware configuration (some features are optional and may not be supported by some hardware) and the command line options (some test cases are only valid for certain feature levels). A test case will return Blocked if the failure is caused by reasons other than the tested feature.

Command Syntax

Command option | Description
wgf11compute.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11compute.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Depth Stencil

Type: Automated Test

Overview

The WGF Depth Stencil test verifies D3D graphics driver/hardware conformance for depth stencil functionality and DepthStencilViews.

Details

  • DepthStencil (tests mainly DepthStencilViews) via D3D11 API's

  • Falls back to FL 10.x on D3D10.x parts

  • A Depth/stencil resource stores depth information for primitives rendered on it, with various operations that can be performed on the depth values stored on them against new values being read in. This type of resource is typically used in shadowing applications.

  • Basic functionality for DepthStencil views

  • Cycles through all formats capable of being used for depth-stencil operations

  • Test rendering to Texture 1-D

  • Test rendering to Texture 2-D

  • Varied resource dimensions

  • Array slices

  • Mip levels

  • Basic functionality for ClearDepthStencilView

  • Special floats used to clear view

  • Read-only Depth (D3D11 only)

Run Time: 15 minutes
Log File: WGF11DepthStencil.xml
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

Program: wgf11depthstencil.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Some test cases my skip if run using feature level 10.0 or feature level 10.1

Command Syntax

Command option | Description
wgf11depthstencil.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11depthstencil.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Draw

Type: Automated Test

Overview

The WGF11Draw test verifies that the behavior of draw calls of the graphics drivers/hardware meets the DX11 specification.

Details

The test covers draw calls and indirect draw calls.

In Draw test group:

  • Draw functions are cycled, including Draw(), DrawIndexed(), DrawInstanced() and DrawIndexedInstanced().

  • The vertex buffer size, vertex buffer offset, index buffer size, and index buffer offset cycle through different values.

  • The number of elements in the vertex buffer and the input classification cycle through different values.

  • The number of vertices to draw and the start vertex location cycle through different values.

  • Other parameters that are specific to different draw functions, including index count, start index location, instance count, start instance location, and base vertex location, also cycle through different values.

  • Test results are read back from the stream output buffer and verified against expected values.

  • Pipeline statistics, including VSInvocations, IAPrimitives, and IAVertices are verified.

In DrawIndirect test group:

  • Draw indirect functions are cycled, including DrawInstancedIndirect() and DrawIndexedInstancedIndirect().

  • The methods to fill in the argument buffer include UpdateSubresource, StreamOutput buffer, RenderTarget buffer, and CopyStructureCount.

  • The aligned byte offset for the argument buffer cycles through different values.

  • Test results are read back from the stream output buffer and verified against expected values.

  • Pipeline statistics, including VSInvocations, IAPrimitives, and IAVertices are verified.

Run Time: 2 hours.
Log File: By default, the log file name is WGF11Draw.xml. You can specify a different log file name with -logfilename switch in the command line.
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: wgf11draw.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test cases return one of the following results:

  • Pass

  • Fail

  • Blocked

  • Skipped

The log file will contain specific details about the test cases that are failed, blocked, or skipped. A test case will return Skipped if it is invalid according to the current hardware configuration (some features are optional and may not be supported by some hardware) and the command line options (some test cases are only valid for certain feature levels). A test case will return Blocked if the failure is caused by reasons other than the tested feature.

Command Syntax

Command option | Description
wgf11draw.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11draw.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Fill Rules

Type: Automated Test

Overview

The WGF11 Fill Rules test verifies whether the device is consistent with the triangle fill rules and point fill rules as detailed in the DX11 specification.

Details

The test draws geometry in various orientations relative to sample locations, and verifies that fill rules are observed. Test cases cycle on different formats, pixel positions, sample counts, quality levels, and sample indices. The geometry drawn can be a triangle or a point.
Run Time: 5 minutes.
Log File: By default, the log file name is WGF11FillRules.xml. You can specify a different log file name with -log filename switch in the command line.
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: wgf11fillrules.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test cases return one of the following results:

  • Pass

  • Fail

  • Blocked

  • Skipped

The log file contains specific details about the test cases that are failed, blocked, or skipped. A test case will return Skipped if it is invalid according to the hardware configuration (some features are optional and may not be supported by some hardware) and the command line options (some test cases are only valid for certain feature levels). A test case will return Blocked if the failure is caused by reasons other than the tested feature.

Command Syntax

Command option | Description
wgf11fillrules.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11fillrules.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Filter

Type: Automated Test

Overview

The WGF11 Filter test verifies D3D graphics driver/hardware conformance for texture filtering features that are not specifically tested elsewhere.

Details

The following outlines the content of the test:

  • Quad rendered to render target

  • Each RT pixel tested programmatically against expected value

  • Texture created with non-symmetric colored pattern

  • All texture types tested independently (1-D, 2-D, 3-D, cube)

  • Texture coordinates cycled for all vertices in tandem, to achieve specific LOD values

  • Texture filter type cycled through all valid types (point, linear, mixed point and linear, with and without mipmap LOD)

  • Texture formats cycled, to find issues with, for example, precision and clamping

  • Texture addressing cycled, independently per dimension and then in tandem

  • One texture unit active, with texture arrays occupying a single unit

  • Texture views cycled for mip-level and array constraints

  • Different sample instructions cycled (biased, fixed LOD, fixed deriv, comparison sample), with corresponding attributes

  • Selected filter types tested for Geometry shader stage and Vertex shader stage

  • Selected filter types tested on textures generated by GenerateMips() function

  • Verify that sample_d works in normalized space

  • Covers resources with per-resource minLOD (only for featurel level 11.0 and above)

Run Time: 2 hours
Log File: By default, the log file name is WGF11Filter.xml. You can specify a different log file name with -logfilename switch in the command line.
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: wgf11multisample.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Vista Service Pack 2 (KB948465) (Vista Only)

    Platform Update for Windows Vista (KB971644) (Vista Only)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test cases return one of the following results:

  • Pass

  • Fail

  • Blocked

  • Skipped

The log file contains specific details about the test cases that are failed, blocked, or skipped. A test case will return Skipped if it is invalid according to the current hardware configuration (some features are optional and may not be supported by some hardware) and the command line options (some test cases are only valid for certain feature levels). A test case will return Blocked if the failure is caused by reasons other than the tested feature.

Command Syntax

Command option | Description
wgf11filter.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11filter.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Geometry Shader

Type: Automated Test

Overview

The WGF11 Geometry Shader test verifies D3D graphics driver/hardware conformance for geometry shader features that are not specifically tested elsewhere.

Details

The following items outline the Geometry Shader Conformance Test Plan:

Geometry Shader Input

  • Verifies support for all input primitive types:
    • Line
    • Point
    • Triangle
    • LineAdj
    • TriangleAdj
  • PrimitiveID
    • Verifies that primitive ordering is respected.
    • PS test should test this for cases where there is no GS in the pipeline.

    • Cycle on Draw() and DrawInstanced().

      Note Make sure that the id resets to zero for each instance drawn.

  • InstanceID

Geometry Shader Output

  • RenderTargetArrayIndex

  • Position

  • Limits

    Note Maximum GS invocation output data size (components * vertices) go up to 1024.

  • Ordering (Verifies that primitive ordering is respected.)

Run Time: 2 minutes
Log File: WGF11GeometryShader.xml
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

  • Windows Server 2008

Program: wgf11geometryshader.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if it is run with a feature level that doesn't support the feature being tested.

The test might return BLOCKED if there is an uncaught exception (framework catches it at the end and logs it).

Command Syntax

Command option | Description
wgf11geometryshader.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11geometryshader.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Input Assembler

Type: Automated Test

Overview

WGF11 Input Assembler tests the Input Assembler stage of the graphics pipeline.

Details

This test verifies the following:

  • Whether the Input Assembler stage of the graphics pipeline operates correctly given the different permutations of input layouts and their slot assignments.

  • Whether the combinations of different buffers as inputs work correctly.

The first test group, "InputLayouts," defined through ID3D11InputLayoutsTest, generates its test cases by permuting on the following factors:

  • Input Slot Classes - different sequences of per-instance and per-vertex data

  • Input Slot assignments - out-of-order slot usage, skipping slots, not using slot 0

  • Instance Data Step Rate

  • Alignments

  • Number of Elements per Input Layout - smaller / bigger than number of elements in shader, maximum allowable number of elements as per the spec

The second test group, "Buffers", defined through CBuffersTest, does the following:

  • Makes sure that indices are respected for IB.

  • Makes sure that buffer bound as a view works.

  • Makes sure that VB works.

  • Cycled through all valid buffer usages and some sizes.

  • Tries huge buffers.

  • Bind max number of buffers, with each buffer of a different usage/pool/CPU access.

  • Draws maximum vertices, index, and instance count.

Run Time: 4 hours
Log File: WGF11InputAssembler.xml
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

Program: wgf11inputassembler.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
wgf11inputassembler.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11inputassembler.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Interfaces

Type: Automated Test

Overview

This test verifies different parts of the hardware and the driver for valid shader execution when interfaces are used. The test focuses on covering hidden buffer information that is provided to the driver through the DDI, which includes interface types and resource locations. Some information that is used in interfaces is embedded in the shader itself, such as the function tables and class type tables. The hardware is only required to correctly call and index these tables, because the runtime does all the management required to keep the information organized and mapped correctly.

The test only executes valid scenarios and verifies results are successful. No failures are expected to occur on certifiable D3D11 hardware.

The test logs to WTT as previous conformance tests have, and contain useful information about the failure to help IHVs to debug their failures.

Details

WGF11Interfaces - Interface Shader Execution

The WGF11Interfaces cover all aspects of data transfer to the driver, along with correct execution of shader IL.

A description of each test group and the necessary command-line parameter is listed later in this section. Whole shaders are not provided in this documentation. However, a description of the shader's intended goal and the types of inputs are described to provide information about how to test in Windows Hardware Quality Labs (WHQL). In addition, each test is run on all shader stages to verify consistent behavior for a feature that adheres to the unified architecture goals.

The tests use ints and uints as inputs and during calculation wherever possible, because precision and verification of floating point math is covered in a different conformance test.

Tests that use samplers perform point sampling and use border color to verify whether the correct sampler is used. Filtering and other aspects of sampler coverage are covered in a different conformance test. Interface testing is only concerned with the correct indexing of samplers that are used by class instances during execution.

Tests that use resources focus on formats with 8-bit channels and no MIP levels. Other tests verify resource correctness. Interface testing is only concerned with the correct indexing of textures that are used by class instances during execution. Only resource loads are used. Because they cannot be indexed, UAVs are not important for interfaces.

Tests are run against every shader stage, because the feature is supposed to fit within the unified architecture of Shader Model 5.0.

Each test has a Pri-1 task and a Pri-2 task, which, when combined, complete coverage of the feature. Pri-1 tasks require that a test to run only on a specific shader stage. Pri-2 tasks test the remaining shader stages.

All instances are created by the runtime using the following API calls:

HRESULT CreateClassInstance(

LPCWSTR pszClassTypeName,

UINT ConstantBufferOffset,

UINT ConstantVectorOffset,

UINT TextureOffset,

UINT SamplerOffset,

ID3D11ClassInstance **ppInstance

);

Instances are set when the shader is set by using XXSetShader() calls.

WGF11Interfaces.exe Interfaces\FunctionTables and fcall\[ PS]

Pri-1 16 hours

The large function table test verifies whether hardware is able to manage the shader programs output by the compiler. This verification is specific to shaders that have many cascading interface calls that resulted in large generations of code that have many function bodies. This test does not test the performance of such shaders, but tests whether the execution is correct when compared against the reference rasterizer.

Several shaders are written that will sequentially double the number of function bodies that are created by the compiler. These shaders are then run with several variations on the instances that fill the slots, in order to verify correct execution through a subset of code paths. At any time, the test may attempt to validate all code paths, and it is expected that hardware will not fail on any of them. If the hardware returns out-of-memory during shader creation time, the test returns RESULT_SKIP, when reasonable. The resource requirements of these shaders should not push the limits of hardware. As such, the shader should bind and execute just fine. If hardware fails on even small function tables, a warning occurs. The hardware should support a minimum of 4k function bodies.

The cascading functions are designed by using several interface types, each which relies on an object of another instance for its parameter. These calls are designed to be several layers deep and may easily result in more than 1k function bodies to be created.

The test also provides coverage of the fcall instruction by extensively calling other functions to get appropriate coverage of the 4k function bodies in the shader. This can be done by varying the bound instances by using XXSetShader by the runtime. The framework provides a simple way to get adequate coverage through permutations of bound types.

To ensure that the test does not need maintenance due to changes in the compiler, each function body must be unique from all other function bodies. This is because the compiler may at some point collapse function bodies with identical code to reduce code size and provide a more optimized function table. By ensuring that all function bodies are different, you prevent the test from being changed or becoming obsolete when this optimization is added to the compiler. It is important to review the IL to make sure that the expected code is produced.

Example:

interface Type0
{
 float2 func( float x );
};

interface Type1
{
 float4 func( const Type0 param, inout float2 y );
};

interface Type2
{
 float func( Type0 param0, Type1 param1 );
};

interface Type3
{
 uint func( out float z, Type0 param0, Type1 param1, Type2 param2 );
};

class AT0 : Type0;
class BT0 : Type0;
class CT0 : Type0;
class DT0 : Type0;
class ET0 : Type0;
class FT0 : Type0;

class AT1 : Type1;
class BT1 : Type1;
class CT1 : Type1;
class DT1 : Type1;

class AT2 : Type2;
class BT2 : Type2;
class CT2 : Type2;
class DT2 : Type2;
class ET2 : Type2;

class AT3 : Type3;
class BT3 : Type3;
class CT3 : Type3;
class DT3 : Type3;
class ET3 : Type3;
class FT3 : Type3;

If the interface for Type3 is called, and each implementation calls the interface method of an input parameter, 720 function bodies are created by all possible code paths, each one optimized for its particular code path. Because there is no limitation to code size other than memory, even very large shaders should execute without error.

Shader code is optimized across fcall sites, so it is possible for each call to be unique based on information from the caller and the callee. Simple multiplying by a constant is not enough; instead, each function body must be unique by doing different operations and using member variables. The resulting output must be verified, so multiplication by prime numbers or something similar would work. To verify that the shader was executed correctly, the same math must be done on the CPU based on the bound class instances.

This test also covers call tree depth (32). It is important to test that more than 32 fcalls result in no-ops (you can only test 33 at a given time). The compiler does not allow code to be written to simply test this case, so you need a more sophisticated approach that can dynamically change the call depth and verify that each call was made (or not made).

A fibinachi sequence or similar could be useful for this. Recursive calls are not allowed, so there must be 33 interfaces that can be called one after another. Locally, the instances must decide whether or not to continue the fcall depth. The runtime binds the data to drive these tests.

This test is written for the pixel shader as Pri-1.

Completion of this test proves the following:

  • The fcall works.

  • The function tables are correct and are being used correctly.

  • The 4k function table limit is supported.

  • The call depth is 32.

Results for the test are captured in the following render target:

WGF11Interfaces.exe Interfaces\FunctionTables and fcall \[VS,GS, HS,DS,CS]

Pri-2

The test covers all shader stages.

Verification of this feature supports a wide range of valid design patterns and OO programming techniques that Shader Model 5.0 was designed to support.

Results for these tests are captured in a stream out buffer for VS,HS,DS, and GS. Results for PS and CS are captured by render targets and writeable buffers.

WGF11Interfaces.exe Interfaces\GroupExecutionPathDifferences\[ CS]

Pri-1 40 hours

Exploiting parallelism is very important when designing hardware. However, capitalizing on such opportunities should not disrupt the correct execution of a shader when code paths diverge. This test runs on each shader stage and provides coverage that executes different code paths despite the fact that pixels, vertices, and other pipeline stage primitives might be getting executed as lock step groups. This test does not test performance in such cases. Instead, it is only verifies a valid result after execution.

Providing data to each pipeline stage is important and must be done in sizeable chunks to verify coverage of varied execution across groups. The following method provides the data to the tests for each shader stage:

  • Compute Shader:

    Data that is used to select instances that are based on array slots is provided by using resources to the compute shader. The SV_GroupID and SV_GroupThreadID are used to select the correct data from the resource to choose which class instances to use during the invocation of a shader. The results of execution are written to a writable buffer to be verified that it is correct. A large dimension count of threads in each dimension is used. This includes large prime numbers of threads and multiple groups that will be dispatched to get adequate coverage for this test.

Each hardware thread should execute a method call in a different type provided by the runtime. The runtime is able to calculate the result for verification based on the type used, the data provided, and the algorithm of the type. The code for each method should vary in length and complexity to prove the hardware can handle shaders like this. 12-18 different class implementations should be used, and each SV_[Index] value can be pseudo modded to pick which array index and which class instance to execute.

WGF11Interfaces.exe Interfaces\GroupExecutionPathDifferences\[VS,GS,PS,HS,DS]

Pri-2 40 hours

The test is extended to the other shader stages.

  • Vertex Shader:

    A set of interface slot array indexes are added to the vertex data and used during vertex shader execution to determine which interface instance to invoke. The data also covers which instances are used as parameters when methods are invoked. A block of at least 512 points are drawn to verify hardware behavior. The results are caught by a stream out buffer.

  • Hull Shader:

    The interface slot array indexes are added to the control point input structure, allowing each point to determine which class instances are invoked over the course of the shader. That data also covers which instances are used as parameters when methods are invoked. A full 32 point patch is drawn several times to verify hardware behavior. The results will be caught by a stream out buffer.

    This test also forwards the data to the Patch Constant function, which also verifies correct behavior.

    In addition, the SV_OutputControlPointID and specific forking code are turned on in the compiler. The forking code causes divergent code execution paths by using interfaces in this stage as well. Forking can be accessed by using a loop and calling an interface method from within the loop.

  • Domain Shader:

    Data is passed through the Hull shader on each control point and then recovered by using the SV_PrimitiveID available in the Domain Shader. The tessellator output positions are combined with the SV_PrimitiveID to create the indexes into the available class instance slots during execution. The full 32 point patch is drawn several times to verify hardware behavior. The results are caught by a stream out buffer. The focus is not to cover all domain types.

  • Geometry Shader:

    Interface slot indexes are attached to point primitives that are provided to the geometry shader. The indexes are used to choose class instances to invoke methods on and use as parameters during shader execution. A block of at least 512 points are drawn to verify hardware behavior. The results are captured in a stream out buffer for verification.

  • Pixel Shader:

    For pixel shaders, a texture is used to provide the class instance indexes for each pixel. The texture exactly matches the size of the render target by drawing a large quad. An area of at least 512x512 pixels is drawn, with the supporting resources, to verify hardware behavior. The results are captured in a render target for validation. SV_Position and SV_SampleIndex can also be used to determine how a pixel indexes into the interface slots. Drawing a triangle is more interesting than drawing a quad.

WGF11Interfaces.exe Interfaces\IndexingResources and this[]\[VS]

Pri-1 26 hours

All resources that are used by an interface were made indexable by the IL in order to support dynamic runtime binding. The data is provided through the DDI and includes the following information:

  • Class type ID

  • Cbuffer

  • Cbuffer offset

  • Texture slot

  • Sampler slot

This test ensures that all this information is used correctly by the driver and shader execution. Access to this information can only be done through the "this" keyword, which uses a hidden reserved buffer. Class instances that are 256 bytescan be bound to a shader, so this test provides coverage for using all 256 instance slots. Doing so implies that this needs to be used in combination with each of the other areas in this test. However, the other areas do not need to be verified through permutation with each other.

The test cycles location for all the different slots and offsets in the resources and uses those resources when producing results.

In order to get full coverage, each class instances should execute a method that makes use of the resource data to produce a result. By doing this, it ensures that the instance type ID is being used correctly with respect to the function tables.

Each cbuffer must be tested for class data. The data needs to be placed throughout the buffer using the offset parameter. This can be done by binding 256 instances each with a different location set by the runtime. The shader can execute 256 vertices and use the SV_PrimitiveID to determine the instance slot to use.

Each tbuffer slot in the 128 available must be used in the same way as mentioned previously. Only a simple buffer or texture2d need be used, and only the load instruction is tested. The test is only interested in correct indexing of the texture registers.

Each sampler slot in the 16 available to a shader stage must be used in the same way as mentioned previously. Samplers will be sampled outside of texture boundary so that a border color is returned. Each of the 16 samplers should have a unique border color in order for the test to verify that the correct sampler was used.

These can be tested separately--combined coverage is unnecessary.

WGF11Intefaces.exe Interfaces\IndexingResources and this[]\[GS,PS,HS,DS,CS]

Pri-2 26 hours

The previous test is extended to cover all shader stages.

(Pri 1 18 hours) The deferred context should also be used in these tests.

The test cases outlined will also be run on a deferred context by using command lists to set classes and instances.

Command lists do not inherit state from the immediate context. Therefore, instances set on the immediate context should not be accessible when executing a command list.

State clearing on the deferred context (through the bool parameter in ExecuteCommandList and FinishCommandList) should be tested with interfaces and classes.

Run Time: 5 hours
Log File: WGF11Interfaces.xml
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

Program: Wgf11interfaces.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test returns SKIP when run on feature level < 11.

Command Syntax

Command option | Description
Wgf11interfaces.exe | Without any options, the test enumerates devices.
FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0.

Code Tour

File Manifest

File | Location
Wgf11interfaces.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Multisample

Type: Automated Test

Overview

The WGF11 Multisample test verifies that the multisampling behavior of the device is consistent with the DX11 specification.

Details

WGF11Multisample covers the following areas:

  • Sample Count

  • Sample Positions for standard pattern

  • Area-to-Coverage

  • Sample Mask

  • Occlusion Query and Predicate for multisampled render target

  • Multisample Resolve

  • Centroid Attributes

  • Centroid Definition (only Feature Level 11.0 and above)

  • Sample Frequency Attributes, SV_COVERAGE (only Feature Level 11.0 and above)

  • Depth test for multisampled render target

Test cases are arranged into sub-groups with different sample counts, quality levels and render targets formats.
Run Time: 3 hours.
Log File: By default, the log file name is WGF11Multisample.xml. You can specify a different log file name with -logfilename switch in the command line.
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: wgf11multisample.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test cases return one of the following results:

  • Pass

  • Fail

  • Blocked

  • Skipped

The log file contains specific details about the test cases that are failed, blocked, or skipped. A test case returns Skipped if it is invalid according to the current hardware configuration (some features are optional and may not be supported by some hardware) and the command line options (some test cases are only valid for certain feature levels). A test case returns Blocked if the failure is caused by reasons other than the tested feature.

Command Syntax

Command option | Description
wgf11multisample.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11multisample.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Pixel Shader

Type: Automated Test

Overview

WGF11 Pixel Shader test verifies that pixel shader behavior of the graphics hardware/drivers meets the DX 11 spec.

Details

This test covers System Value Generation (SV_IsFrontFace and SV_PrimitiveId) and Pipeline Statistics ( Cinvocations, Cprimitives and PSInvocations). If run with feature level 11 or above, the test also covers the behavior of pixel shader writing to the render target, the depth-stencil buffer, and the Unordered Access View (UAV), with or without the earlydepthstencil flag.
Run Time: Less than 10 minutes.
Log File: By default, the log file name is WGF11PixelShader.xml. You can specify a different log file name with -logfilename switch in the command line.
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: wgf11pixelshader.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test cases return Pass, Fail, Blocked, or Skipped. The log file contains specific details about the test cases that are failed, blocked, or skipped. A test case returns Skipped if it is invalid according to the current hardware configuration (some features are optional and may not be supported by some hardware) and the command line options (some test cases are only valid for certain feature levels). A test case returns Blocked if the failure is caused by reasons other than the tested feature.

Command Syntax

Command option | Description
wgf11pixelshader.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11pixelshader.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Rasterizer

Type: Automated Test

Overview

The WGF11Rasterizer test verifies various aspects of the D3D primitive rasterizer and rasterizer state as implemented by hardware.

Details

For D3D10 and above, this test verifies the following:

  • Primitive culling, fill mode, and winding order based on the rasterizer state.

  • Interpolation modes in the pixel shader
    • Constant mode is simple, because there is no change from the values sent from the vertex shader.
    • Because it is not tightly spec'd, linear modes are verified by ensuring that adjacent pixels are not equal and follow the gradient of an edge.

  • Sample frequency pixel shader invocation (D3D10.1 and above).

For D3D11, this test verifies pull model attribute evaluation.

The following intrinsic functions will be introduced into D3D11 (HLSL 5.0) for the feature of pull-model attribute evaluation:

  • EvaluateAttributeSnapped( attrib numeric value, int2 pixeloffset )

  • EvaluateAttributeAtSample( attrib numeric value, uint sampleindex )

  • EvaluateAttributeAtCentroid( attrib numeric value )

For each intrinsic function, a set of pixel shaders will be generated, targeting the cases on different combinations of the parameter values of the intrinsic function and the declared interpolation modes of the input attributes.

The following are test factors for all three intrinsics:

  • Input attributes passed from the Vertex shader.

    Note Only float type attribute can be interpolated; int/uint type will always be constant interpolation mode.

    • float4 texCoord : TEXCOORD
    • float4 color : COLOR
    • float clipDis : SV_ClipDistance

  • Declarations of interpolation modes.

    Note Nointerpolation mode is not allowed by the HLSL compiler when the corresponding attribute is evaluated with pull-model in the shader.

    • linear
    • linear noPerspective
    • linear centroid
    • linear sample
    • linear noPerspective centroid
    • linear noPerspective sample
  • Primitives to draw:

    • When the interpolation mode is linear, a triangle C1-C2-C3 as follows will be drawn. This covers one whole pixel and two half pixels. The coordinates of the vertices in projection space are as the following:

      C1: (-1, 1, 0), C2(-1, -1, 0), C3(1, 1, 0). Right triangle within a square, with vertices C1, C2, and C3; C1 forms the 90-degree angle and is at the upper-left corner of the square

    • When the interpolation mode is noperspective, a triangle A-B-C with the following vertex coordinates in the projection space will be drawn:

      A:(-1, 1, 1);

      B:(-1, -1, 0);

      C:(1, 1, 1)

      The screen space triangle should cover the same pixels and pixel areas as triangle C1-C2-C3 shown above.

  • Render target
    • Format: All formats supporting render target.
    • Sample count: 1, 2, ... the maximum supported sample count.

Different values of pixeloffset for EvaluateAttributeSnapped( )

Ideally, all possible 256 offset positions. If the test runs too long, this group of test cases will be reduced to 4 corner positions, 8 border positions, 4 positions from 4x4 grid, 4 positions from 8x8 grid, and 4 positions from 16x16 grid.

Different values of sampleindex for EvaluateAttributeAtSample( )

All sample indices supported by the render target

The verification method begins when the pixel shader writes the interpolated attribute value to the render target. The render target data is then mapped and read out. In cases of multisampled render targets, multisample resolve is required before mapping. The result data will be compared with pre-calculated interpolated data or data got from direct accessing the attribute.

  1. When interpolation mode is linear noperspective:
    a. Calculate and store the interpolated (and extrapolated for uncovered area of p2 and p3) values for 256 offset positions of each pixels of p1, p2, p3.
    b. For EvaluateAttributeSnapped :
    • Pixel p1 should have "pulled " attribute value in between of the expected values for left and right (as well as upper and lower) neighboring offsets of the "pulled" offset.

    • Pixels p2 and p3 :

      In single-sampled cases, they should not be rendered.

      In multi-sampled cases, they should have "pulled" attribute value in between of the expected values for left and right (as well as upper and lower) neighboring offsets of the "pulled" offset.

    c. For EvaluateAttributeAtSample with SampleFinder, find the position of the sample index on the sample coordinate system with range [-8, 7]. Use this position to do the verification the same way as in EvaluateAttributeSnapped above.
    d. For EvaluateAttributeAtCentroid, draw triangle C1-C2-C3 with SV_COVERAGE to find out the first covered sample, which is the centroid position defined by the Shader Model 5.0. Use the sample index for centoid to do the verification the same way as in EvaluateAttributeAtSample above.
  2. When interpolation mode is linear:
    a. Calculate and store the interpolated (and extrapolated for uncovered area of p2 and p3) values for 256 offset positions of each pixels, using perspective correct interpolation. Interpolate the attribute values that have been divided by the respective depth value, then divide the interpolated attribute value by the interpolated reciprocal of the depth.
    b. For EvaluateAttributeSnapped(), use the same verification as 2.a.
    c. For EvaluateAttributeAtCentroid(), use the same verification as 2.c.
    d. For EvaluateAttributeAtSample(), use the same verification as 2.b.
  3. Use PSInvocation to verify the number of PS invocations for all test cases.
    a. If any attribute has sample interpolation mode or SV_SAMPLEINDEX is declared, and the sample count is larger than 1, PSInvocation should be 3*(sample count).
    b. When the sample count is 1, PSInvocation should be 1.
Run Time: 3 minutes
Log File: WGF11Rasterizer.exe
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

  • Windows Server 2008

Program: wgf11rasterizer.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if it is run with a feature level that doesn't support the feature being tested.

The test might return BLOCKED if there is an uncaught exception (framework catches it at the end and logs it).

Command Syntax

Command option | Description
wgf11rasterizer.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11rasterizer.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Render Targets

Type: Automated Test

Overview

The WGF11RenderTargets test verifies D3D graphics driver/hardware conformance for render target features and RenderTargetViews. It also verifies driver support for render target clearing and swap chains.

Details

RenderTargets (tests mainly RenderTargetViews)

Rather than rendering to the backbuffer that is presented on the screen, you can draw to a render target resource. This is typically used in environment mapping techniques or in techniques where multiple passes are involved where the render target texture is used as input in another pass.

  • Tests cycles through all formats capable of being used as a render target. No conversion takes place, but results must be within 1-ULP (Unit Least Precision) of expected result (per component).

  • Three types of source data are used: tiles, gradients, and stripes. Each data type is parameterized, such as gradient colors, tile and stripe size, etc.

  • Depending on the resource type (all five types are tested), the test cycles through different values for height, width, and depth. This includes non-square and non-pow-2 values.

  • MRT (Multiple Render Targets) are tested, and multiple mip-levels and array slices are targeted.

  • Hits all render target slots throughout the test run.

  • Renders to VB, IB, and shader resource (verify in subsequent Draw() call).

  • Renders to texture cube (and sub mips) by creating a Texture2DArray render target view.

Clear

Tests clearing of the bound render target view through the ClearRenderTargetView D3D API. This includes testing of the various resource types (1D, 2D, etc.), and using special floating point values as the clear value (INF, NaN, etc.).

SwapChain

Tests rendering to the backbuffer and presenting using various swap chain creation parameters, including format. Also tests back buffer casting, which is new to D3D11. This allows creating a render target view of a format that is not in the same typeless family as the resource's format.

Run Time: 40 minutes
Log File: WGF11RenderTargets.xml

System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: wgf11rendertargets.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if a format is not supported by the device, or if the device does not support backbuffer casting for a particular format (in the SwapChain test group).

The test might return BLOCKED if there is an uncaught exception (framework catches it at the end and logs it).

Command Syntax

Command option | Description
wgf11rendertargets.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11rendertargets.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Resource Access

Type: Automated Test

Overview

The WGF11ResourceAccess test verifies D3D graphics driver/hardware conformance for resource copying functions and the integrity of the data manipulated. There are also groups for D3D10.1 features that allow copying of compressed textures to structured formats and copying of multisample resources.

Details

ResourceAccess

You can access and modify the contents of resources through four functions: CopyResource(), CopySubresourceRegion(), UpdateSubresource(), and Map().

  • Test behavior when specifying regions that are 1 pixel in size and other special cases.

  • Ensure consistent data when copying from mip (progressively smaller and less detailed versions of the texture) 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 that affect pipeline statistics. You can choose to use the rendering pipeline to "emulate" copy functionality, but the specification states that copy functions cannot affect pipeline statistics.

CopyMultisample

Tests support for the D3D10.1 feature of copy multisample resources.

  • Varies the number of samples used.

  • Ensures a unique value in each sample location.

  • Verifies that this is preserved on copy on the destination resource.

CopyCompressed

Verifies support for copying of compressed textures to structured formats which was added in D3D10.1. The compatible structured format (i.e. traditional 3-4 color channels) for each compressed texture is tested to make sure the data in the original texture is preserved on copy. No conversion should take place. This is a bit-for-bit copy. Roundtrip copy (structured->compressed) is also tested and should also be bit-for-bit accurate.

Run Time: 8 hours
Log File: WGF11ResourceAccess.xml
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: wgf11resourceaccess.exe .

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if a format is not supported by the device, or if the feature level is lower than the one required to test a particular feature (10.1 for CopyMultisample/CopyCompressed).

The test might return BLOCKED if there is an uncaught exception (framework catches it at the end and logs it).

Command Syntax

Command option | Description
wgf11resourceaccess.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11resourceaccess.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Resource Formats

Type: Automated Test

Overview

The WGF11ResourceFormats test verifies D3D graphics driver/hardware conformance for shader resource views and the texture formats that are outlined in the D3D11 functional specification.

Details

ResourceFormats (tests mainly ShaderResourceViews)

There are various formats available for resources. They vary mainly in number of components, type, precision, and whether or not they are compressed.

  • Render target is a four-component, 32-bit float format. The formats tested are converted to this format. Results must be within 1-ULP(Unit Least Precision) per component of expected result.

  • Compressed and other special formats are decoded as specified 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, and stripes. Each data type is parameterized, such as gradient colors, tile and stripe size, and so on.

  • Depending on the resource type (all five 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 throughout 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 (for example: D3D10_BIND_SHADER_RESOURCE | D3D10_BIND_RENDERTARGET)

  • Try using first pass to initialize resource data.

DepthReadbackVerifies driver behavior when using a depth buffer from one pass as a shader resource in a subsequent pass.

CheckFormatSupportVerifies that the driver supports the required formats and their capabilities based on the format table in the spec.

Run Time: 10 minutes
Log File: WGF11ResourceFormats.xml
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: wgf11resourceformats.exe .

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if a format is not supported by the device.

The test might return BLOCKED if there is an uncaught exception (framework catches it at the end and logs it).

Command Syntax

Command option | Description
wgf11resourceformats.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11resourceformats.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Shader 5x

Type: Automated Test

Overview

The WGF11Shader5x test utilizes the D3D11 APIs and Shader 4.0, 4.1, or 5.0 instruction set, depending on the feature level specified on the command line. The test doesn't rely on the compiler; instead it assembles shaders to ensure specific instructions are fully tested and not altered by the compiler. During execution, the test cycles between different instructions (each instruction is a separate group), shader stages, register values, and mask/swizzle combinations. Each test case uses different data depending on the current instruction and its behavior as described by the spec.

Details

WGF11Shader5x adds support for new 4.x instructions (including doubles) and stages (like the Compute Shader), if the driver supports it.
Run Time: The test can take up to 7 hours to complete a full run (all instructions).
Log File: WGF11Shader5x.xml.
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: wgf11shader5x.exe .

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the shader stages are not supported. For example, if running the test with feature level 10.0, HULL and DOMAIN shaders are not supported, so those tests will skip. The test will also skip if specific formats, quality levels, doubles, etc. are not supported. The test asks the driver for support before executing a given test. To run the test with a different feature level, use one of the following command line options (also see below):

  • featurelevel:10.0

  • featurelevel:10.1

  • featurelevel:11.0

Command Syntax

Command option | Description
wgf11shader5x.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11shader5x.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076

Troubleshooting

If your driver sample is in one location, but it reports that the location is in another location during the test, or if the sample locations change between draw calls, you may fail the test with the following error:

"samplepos returned incorrect sample location"

One possible cause for this error is that the test specifies the sample index 0 at (32, 32) in the 256x256 sub-pixel grid, because the driver lit the pixel when a sub-pixel quad was rendered there. However, your driver is returning (192, 192) for sample index 0 through the samplepos instruction.

Test command line: WGF11Shader5x.exe: -src:hw -logclean multisample\samplepos\2\9:9 -featurelevel:11.0

Error message in the log:

Test Case 9: Multisample\samplepos\2\9 Fail
+ Test Case 9: Multisample\samplepos\2\9 Fail
Parameter: Format=R32G32B32A32_FLOAT
Parameter: Dimension=TEXTURE2DMS
Parameter: SampleCount=2
Parameter: SampleQuality=1
Parameter: Height=3
Parameter: Width=7
Parameter: rasterizer=true
Parameter: SRV_Bound=false
Parameter: SampleIndex=0
Pixel [0,0], Sample[0]
samplepos returned (8, 8)
actual sample position = (-12, -12)
[CSampleInfoTest::ExecuteTestCase()] samplepos returned incorrect sample location.


WGF11 SharedResources

Type: Automated Test

Overview

This test verifies that hardware supports resource-sharing between processes and across APIs

Details

The Shared Resources test verifies that D3D resources created by one process can be used in a device context in a separate process. The test uses 2D textures, because this is expected to be the most interesting case. Because resources are also intended to be shared between different APIs (D3D9, D3D10.x, and D3D11), the test creates resources in each of these APIs and validates that they can be shared with devices in all other available API contexts.

Run Time: 5 minutes
Log File: WGF11SharedResources.xml
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

Program: wgf11SharedResources.exe .

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Some test cases my skip if run using feature level 10.0 or feature level 10.1.

Command Syntax

Command option | Description
wgf11SharedResources.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11SharedResources.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Streamout

Type: Automated Test

Overview

The WGF11 Streamout test verifies that graphics drivers/hardware D3D stream-out behavior meets Microsoft Direct3D specifications.

Details

The following outlines the StreamOut Conformance Test Plan:

General Stream Out Test Cases

  • Pass input data into the pipeline by using VB and stream out transformed data from VS or GS.

    Note 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, vand 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 are allowed.

    Note Because this is such a large resource, this works for probably one or two test cases.

Simple Single-Buffer Tests

  • Cycle on several declaration scenarios:
    • Simple.
    • Leave gaps.
    • Split output registers across multiple SO elements.
    • Merge output register into a single SO element.

  • Cycle on different SO vertex sizes.

    Verify limit of 64-component SO vertices.

Simple Multi-Buffer Tests

  • Mix up buffer sizes/offsets so that buffers 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 that focuses on setting "fat" vertex strides to a single buffer, then Draw(), then sets "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.

    Note Consider ping-ponging during this step to make sure that the overflowed state is "sticky" on the buffer.

Addressable Stream Output (D3D11)

Test RasterizedStream and multiple vectors of data:

  • When sending a stream to the rasterizer, make sure that the final result uses the vertex data from that stream.

  • Make sure that more than one vector of data can be output from a stream under feature level 11, even when using a gs_4_x shader.

  • Test strides that aren't tightly aligned to the size of an element in a stream output buffer.

  • Verify that stream output works when the runtime determines strides based on the size calculated using the stream output declaration. The runtime does this when the stride parameters in the create call are both NULL.

Test feature level and query behavior:

  • When using feature levels 10 and 10.1, make sure only stream 0 can be used for stream output.

  • When using feature levels 10 and 10.1, make sure that only gs_4_x shaders can be used. If multiple buffers are used, make sure that only one vector of data can be output from stream 0 i.

  • D3D11_QUERY_SO_STATISTICS and D3D11_QUERY_SO_OVERFLOW_PREDICATE queries should return the correct data for the sum of all streams. D3D11_QUERY_SO_STATISTICS_STREAMn and D3D11_QUERY_SO_OVERFLOW_PREDICATE_STREAMn queries return the correct data for each stream. There are currently test cases for the single stream case. The following will be verified:
    • Expected number of primitives written to stream output buffers.
    • Expected size of the primitives (if they are all to be output to buffers).
    • Overflow predicate is triggered when one buffer overflows when writing to it.
    • If one buffer in a stream is filled, writes to all buffers in that stream are prevented.
    • Results of queries for undefined streams should not be affected.

Run Time: 30 minutes
Log File: WGF11StreamOut.xml

System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

  • Windows Server 2008

Program: wgf11streamout.exe .

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if it is run with a feature level that doesn't support the feature being tested.

The test might return BLOCKED if there is an uncaught exception (framework catches it at the end and logs it).

Command Syntax

Command option | Description
wgf11streamout.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11streamout.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Tessellation

Type: Automated Test

Overview

The WGF11Tessellation test verifies driver behavior with regards to the D3D11 Tessellation feature. Various aspects of this feature are tested, including the hull and domain shader stages, hull shader phases, and the fixed function tessellator.

Details

This test covers the following four test groups:

Tessellator

This test group verifies that the fixed function tessellator is implemented according to the spec. It cycles on the following items and compares the result to the reference rasterizer:

  • Domain (quad, tri, isolines)

  • Partition (integer, pow2, etc.)

  • Topology (point, line, tri, etc.)

  • TessValues

Hull

This group tests the hull shader portion of the tessellation stage. Shaders generate control points that are sorted by the test and compared to expected values. The contents of the control points depend on what the values the test is cycling on, which is similar to the Tessellator test group above. It verifies the following:

  • The input CPs are correctly read by the control point phase.

  • HS is executed once per output control point (not easily verifiable, only a number of output CPs are visible).

  • Output data is correct for inputs (via pass-through DS and stream-out).

  • Primitive ID is identical across a patch. Other system-generated values are also accurate.

  • Pipeline statistics updated appropriately.

Domain

This group tests the domain shader portion of the tessellation stage. Shaders generate vertices that are compared to expected values. The contents of the vertices depend on what the values the test is cycling on, which is similar to the Tessellator test group above. It verifies the following:

  • Primitive ID identical across a patch. Other system-generated values also accurate.

  • All data is available and accurate.

HullPhases

This group tests the phases of the hull shade, including fork and join. Because these phases are not exposed in HLSL the test uses assembly shaders to verify fork and join. It verifies the following:

  • Input and output CPs correctly read by fork and join phases.

  • Fork phase output correctly read by join phase.

  • Output patch constants are correct and fully written (no overwrites or instances getting dropped).

  • Pipeline statistics updated appropriately.

Run Time: 1 hour
Log File: WGF11Tessellation.xml

System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

  • Windows Server 2008

Program: wgf11tessellation.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if it is run with a feature level lower than 11.0.

The test might return BLOCKED if there is an uncaught exception (framework catches it at the end and logs it).

Command Syntax

Command option | Description
wgf11tessellation.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11tessellation.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Vertex Shader

Type: Automated

Overview

The WGF11 Vertex Shader test verifies that vertex shader behavior of the graphics hardware/drivers meets the DX 11 specification.

Details

There are three test cases for this test:

Read From Unbound Buffer Slot

  • Read from a buffer when not set (VB, IB, SRV, 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. IDs should be generated correctly.
    • When only IB is used, VertexID should be the IB Values
    • Try IB smaller than the number of vertices to draw.

Limits

  • Test cases with very large vertex buffers, index buffer and shader resource buffers to test the device's ability to handle large sized resources. The specification requires the device to handle 128MB buffers.

Run Time: Depending on the performance of the device, the run time can be from 10 minutes to 1.5 hours.
Log File: By default, the log file name is WGF11VertexShader.xml. You can specify a different log file name with -logfilename switch in the command line.
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2008

  • Windows Server 2008

Program: wgf11vertexshader.exe .

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test cases return one of the following results: Pass, Fail, Blocked and Skipped. The log file will contain specific details about the test cases that are failed, blocked, or skipped. A test case will return Skipped if it is invalid according to the current hardware configuration ( e.g. some features are optional and may not be supported by some hardware) and the command line options (e.g. some test cases are only valid for certain feature levels). A test case will return Blocked if the failure is caused by reasons other than the tested feature.

Command Syntax

Command option | Description
wgf11vertexshader.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11vertexshader.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


WGF11 Viewports

Type: Automated Test

Overview

The WGF11Viewports test verifies that the behavior of viewports and scissors of the device is consistent with the DX11 specification.

Details

The test covers the following areas:

  • Multiple (up to 16) viewports set/in use.

  • Verify use of arbitrary viewport.

  • Verify overlapping viewports.

  • Verify "ViewportArrayIndex" higher than viewports set is treated as 0, and no index is treated as zero.

  • The value of SV_ViewportArrayIndex passed to pixel shader is unclamped/unconverted.

  • Verify viewport scale is done in float32 arith.

  • Verify the use of scissor with default viewport (viewport with the same size of the render target).

  • More cases of scissors: larger-than-target, off-target, and arbitrary offsets within the viewports.

  • Verify the usage of SV_ViewportArrayIndex by Geometry shader to split the geometry to two different viewports.

  • If the test runs on feature level 11.0 and above, all viewports defined by fractional values.

Run Time: One minute.
Log File: By default, the log file name is WGF11Viewports.xml. You can specify a different log file name with -logfilename switch in the command line.
System Restart Required: No
Test Category: Display Adapter and Chipset
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: wgf11viewports.exe .

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Vista Service Pack 2 (KB948465) (Vista Only)

  • Platform Update for Windows Vista (KB971644) (Vista Only)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test cases return one of the following results: Pass, Fail, Blocked, and Skipped. The log file will contain specific details about the test cases that are failed, blocked,or skipped. A test case will return Skipped if it is invalid according to the current hardware configuration ( e.g. some features are optional and may not be supported by some hardware) and the command line options (e.g. some test cases are only valid for certain feature levels). A test case will return Blocked if the failure is caused by reasons other than the tested feature.

Command Syntax

Command option | Description
wgf11viewports.exe | Without any options, the test enumerates devices.
-FeatureLevel:XX.X | Where XX.X is the Feature Level the test will run at, 10.0, 10.1, or 11.0

Code Tour

File Manifest

File | Location
wgf11viewports.exe | [testbinroot]\nttest\windowstest\graphics\d3d\conf

Test Assertions

Test enforcing Windows Logo Requirement: Graphics-0076


Windows Color Management Plugin Robustness Test

Type: Automated Test

Overview

The Windows Color Management Plug-in Robustness test tests the robustness of WCS color plug-ins to ensure that the plug-ins work as they should, do not crash in edge cases (unusual test cases), and are not vulnerable to malformed input data.

Details

This test enumerates all installed color profiles and tests all installed plug-ins that are referenced by any installed Device Model profile or Gamut Map Model profile. Profiles must be installed and plug-ins must be registered through standard COM procedures before the test is run. Because all installed profiles are tested, some might need to be removed before running the test in order to avoid failures from different third-party plug-ins. The test might issue helpful warning messages about questionable plug-in behavior during the test, but by not crashing, a plug-in passes the robustness test.

Run Time:
Log File: Logfile.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • 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

Requirements

Software Requirements

The test tool requires the following software:

  • Windows Vista
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
Processor
  • x86
  • Itanium

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


Windows Server System Check For Display Driver Support

Type: Automated Test

Overview

This test verifies following requirements:

  1. Display driver model is WDDM1.0 or greater, unless the system is a server or a domain controller.

  2. System that supports multiple discrete graphics adapters or chipset combinations uses the same VEN (unless system is a hybrid configuration).

Details

Run Time: 1 minute
Log File: VerifyMode.xml
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Server 2008

Program: VerifyMode.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • WTTLog.dll

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
VerifyMode.exe | Displays available options
VGA | Checks if machine is using VGA driver
LDA | Checks if machine is in LDA mode
Default | Checks if machine is using default driver (WDDM, unless server with no D3D9)

Code Tour

File Manifest

File | Location
VerifyMode.exe | [testbinroot}NTTEST\WINDOWSTEST\Graphics\wddm\bin\


winsatstress

Type: Automated Test

Overview

winsatstress runs winsat with several command line options. It runs several assessments to assess the hardware of the system. It also runs many resource intensive tests to assess the system's graphics card. By enabling appverifier on WinSAT, this test helps find graphics driver bugs.

Details

Run Time: Infinite by default. Runtime can be controlled too, depending on switches specified to the stress tool.
Log File: Thid test creates winsatstress file in %systemdriver%. The log file starts with used seed value and logs every commands that the stress tool has run. The text file will not show any pass or failure.
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program: winsatstress.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Appverifier

  • WDDM driver for graphics card

  • System should not run on VHDs

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested (Dx9 and Dx10 capable graphics card)

  • System needs to run on AC power

  • Hard-drive with at least 1GB contiguous space

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test binary will run forever and while there are not pass/fail logs created by the tool, a log file with seed info and commands will help to reproduce crashes or failures. winsatstress runs winsat with several command lines options. It runs various winsat assessments. The current WLK CRASH runs this test with " -d3d -dwm -media -mediaex -publicrun" cmd line options, which will run winsat d3d, dwm, media and mediaex assessment in an infinite loop.

Command Syntax

Usage: WinSATStress.exe [-runonce] [Test Options] [-publicrun]

Command option | Description
-runonce | OPTIONAL. Runs specified assessment tests only once each
-cpu | Runs CPU test cases
-disk | Runs disk test cases
-memory | Runs memory test cases
-d3d | Runs D3D test cases
-dwm | Runs DWM test cases
-api | Runs API test cases
-media | Runs media assessment
-datastore | Runs datastore test cases
-formal | Runs Formal Assessment
-mediaex | Run sMediaEX assessments
-prepop | Runs OEM Prepop tests that create partial assessments
-taskschd | Force runs WinSAT via task Scheduler
-publicrun | OPTIONAL: If this flag is on, then delays between test cases run will be longer

Code Tour

File Manifest

File | Location
winsatstress.exe | [testbinroot]\NTTEST\BASETEST\clientperf\wincrs\stress\WinsatStress.exe


WLP RGB Rasterization

Type: Automated Test

Overview

The WLP RGB Rasterization test enforces that the display adapter can meet the minimum Microsoft Direct 3D requirements. For the full list of minimum requirements, refer to the latest Windows Logo Program (WLP) documentation.

Details

The test composes a Direct 3D scene that includes all of the relevant elements from the WLP minimum requirements, such as Gouraud shading, basic alpha blending, Bi-Linear filtering, specific texture formats, and so on. The test then validates that the display adapter claims support for each of these (and will fail the test if it does not) and renders the scene with the display adapter and with the reference rasterizer.

The test does a pixel comparison of the rendered images and determines if the test passed or failed based on that comparison (allowing the standard 15% difference). The test is run twice: the first time in windowed mode and the second time in full-screen mode.

Run Time:
Log File: scenario.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • DirectX version 7.0 or later
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Display adapter with Direct 3D capabilities
Processor
  • x86
  • x64
  • Itanium

Running WLP RGB Rasterization

Run scenario.exe with the -WLP -WHQL command line options.

Reference Documentation

Microsoft DirectX SDK


Avalon shader effect Tests

Type: Automated test

Overview

Tests verify content with ShaderEffect, a feature interacting with graphics driver and taking advantage of pixel shader.

Details

For each test, equally sized windows with ShaderEffect content generated, one rendering in WPF Hardware accelerated mode and the other using RefRast, the DirectX reference rasterizer. Verification is done via visual verification. The same content also render in layered windows and do the visual validation. There are 20 tests in total. Each test is loaded content from a xaml file. The XML script contains details of tolerance curves to use, source of content for each test, and window size.

Run Time: 5 minutes
Log File: WttLog.wtl
System Restart Required: Yes
Test Category:
Program: WpfTest.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running

There will be 4 window rendered for each of 20 tests. Test returns PASS or FAIL. Review the test results in the log file for specific details about failures. If test failed, the rendered images are also saved, named Variation[*]Transparent.png, where [*] depends on variation index, and type of window rendered.

Command Syntax

Command option | Description
WpfTest.exe /testdocument: ShaderEffectTests.xml | Run the tests.

Code Tour

File Manifest

File | Location
WpfTest.exe | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
WpfUnmangedProxy.dll | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
ShaderEffects.dll | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
Factories.dll | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
MinimumTestRuntime.dll | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
ShaderEffectTests.xml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
testprofile.xml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
AverageColorWithPaddings.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
BasicShaderEffect_EffectOnElmentInDrwingBrush.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
BasicShaderEffect_InControlTemplate.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
BasicShaderEffect_Viewport2DVisual3D.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
BasicShaderEffect_WithOpacityMask.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
BasicShaderEffect_WithOpacityMask.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
BlurWithNestedDropShadow.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
BlurWithNestedDropShadow.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
DropShadow_BlurRadius0.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
DropShadow_ColorBlue.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
DropShadow_Opacity05.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
DropShadow_ShadwoDepth100.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
DropShadow_Softness05.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
DropShadow_WithTransform.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
MultiInput_DoubleInputEffect_EffectWithDrawingImageInVisualBrush.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
MultiInput_MultiInputEffect_NestUnderBlur.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
MultiInput_MultiInputEffect_VisualBrushTransform.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
Radius0BoxBlur.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
Radius10GaussianBlur.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
Radius50BoxBlur.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
RenderingBias.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
ShaderEffectTests.xml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\
SimpliestBlur.xaml | [testbinroot]NTTEST\WINDOWSTEST\Client\WDCE\AvaloncpTests\


Windows Presentation Foundation (WPF) Verification Suite

Type: Automated Test

Overview

The Windows Presentation Foundation verification suite enforces that the display adapter meets the minimum requirements for Windows Presentation Foundation (WPF) content.

Details

1. WpfTest.exe

This executable, written in C#, is the main test driver for the WPF verification suite. Its operation is controlled with an XML script file.

1.1 RefRast verification tests Overview:

The main verification technique for the WpfTest framework is to generate equally sized windows with the same WPF content, one rendering in WPF Hardware accelerated mode and the other using RefRast, the DirectX reference rasterizer. The windows rendered are compared pixel by pixel. The same content is also rendered in transparent windows and verified with the same technique. The XML script contains details of tolerance curves to use, source of content for each test, window size, timeout, and preferred log format for text and screen captures.

This technique is used for 2-D, text, ShaderEffect, and some 3-D verification tests. All source content is either XAML file or text defined in the XML script. This driver has the ability to test any loose xaml, so extending the content here is as simple as adding more XAML files to the kit. Currently the content types supported are: Xaml, ImageBrush, Text, and 3D Content.

Tests:

  1. Windows Presentation Foundation 2D Graphics Render Tests - Basic 32bpp

    Command Line: WpfTest.exe /TestDocument: 2DTests_Basic.xml

    Description: Basic 2D Content in a 32bpp mode.

  2. Windows Presentation Foundation 2D Graphics Render Tests - Basic 16bpp

    Command Line: WpfTest.exe /TestDocument: 2DTests_Basic16.xml /noDisplayModeReset

    Description: Validates rendering of basic 2D Content in a 16bpp mode.

  3. Windows Presentation Foundation 2D Graphics Render Tests - Images

    Command Line: WpfTest.exe /TestDocument: 2DTests_Images.xml

    Description: Image content, defined in an image file.

  4. Windows Presentation Foundation 3D Graphics Render Tests - Basic

    Command Line: WpfTest.exe /TestDocument: 3DTests_Basic.xml

    Description: Basic 3D content, defined in Xaml files.

  5. Windows Presentation Foundation 3D Graphics Render Tests - Material

    Command Line: WpfTest.exe /TestDocument: 3DTests_Material.xml

    Description: Some 3D scenarios, defined in the Xml file. They are different Meshes with different Material/BackMaterials, with different Lights and different Position/LookDirections.

  6. Windows Presentation Foundation 3D Graphics Render Tests - Scenario

    Command Line: WpfTest.exe /TestDocument: 3DTests_Scenario.xml

    Description: Advanced 3D scenarios.

  7. Windows Presentation Foundation 3D Graphics Render Tests - Texturing

    Command Line: WpfTest.exe /TestDocument: 3DTests_Texturing.xml

    Description: ImageBrush and DrawingBrush.

  8. Windows Presentation Foundation Text Render Tests - Basic

    Command Line: WpfTest.exe /TestDocument: TextTests.xml

    Description: Text in various options, such as Background, FontFamily, FontSize, FontStretch, FontStyle, TextTrimming, TextWrap, TextAlignment, FontWeight, Foreground, and LineHeight.

  9. Windows Presentation Foundation Text Render Tests - Glyphs

    Command Line: WpfTest.exe /TestDocument: TextTests_Glyphs.xml

    Description: Glyph scenarios, defined in some XAML files.

  10. Windows Presentation Foundation ShaderEffect tests

    Command Line: WpfTest.exe /TestDocument: ShaderEffectTests.xml

    Description: WPF content with ShaderEffect, a feature using pixel shader.

1.2 AntiAliasing test Overview:

Test asserts that the current card supports 3-D anti-aliasing.

Test renders 3D content, which has a solid color, flat shading on a solid color background. It then captures the screen and counts the number of colors it finds. If there are more than the foreground and background colors (along the edges), the test considers that 3DAA is active. Otherwise, test fails.

Test:

  • 3D Graphics Render Tests - Anti-Aliasing

    Command Line: WpfTest.exe /TestDocument: 3DTests_AntiAliasing.xml

1.3 Tiering test Overview:

Test asserts that the current RenderCapabilities.Tier property is set to 2. This is an LDDM requirement for WPF content.

Test:

  • Windows Presentation Foundation Tiering API Test

    Command Line: WpfTest.exe /TestDocument: APITests_Tiering.xml

    Description: Currently disabled since tier 2 is not currently a requirement for Logo program.

1.4 Animation and scenario tests Overview:

Basic functionality tests that cover multiple monitor and animation scenarios. Each test moves and resizes WPF content around different multiple monitor configuration points, fails if an exception is thrown or passes after a given time.

Tests:

  1. Windows Presentation Foundation Animation Scenario Test

    Command Line: WpfTest.exe /TestDocument: 2dAnimationScenario.xml

    Description: Tests animation scenarios.

  2. Windows Presentation Foundation MultiMon Test - Horizontal

    Command Line: WpfTest.exe /TestDocument: MultiMonHorOrientationNormal.xml

    Description: Two monitors, monitor 1 and monitor 2, are arranged on the left and right, respectively. Both monitors are in 32bpp mode.

  3. Windows Presentation Foundation MultiMon Test - Horizontal HW Fallback

    Command Line: WpfTest.exe /TestDocument: MultiMonHorOrientationNormalHWFallback.xml

    Description: Two monitors, monitor 1 and monitor 2, are arranged on the left and right, respectively. Monitor 1 is in 32bpp mode and monitor 2 is in 16bpp mode.

  4. Windows Presentation Foundation MultiMon Test - Horizontal Reverse

    Command Line: WpfTest.exe /TestDocument: MultiMonHorOrientationReversed.xml

    Description: Two monitors, monitor 1 and monitor 2, are arranged on the right and left, respectively. Both monitors are in 32bpp mode.

  5. Windows Presentation Foundation MultiMon Test - Vertical

    Command Line: WpfTest.exe /TestDocument: MultiMonVertOrientationNormal.xml

    Description: Two monitors, monitor 1 and monitor 2, are stacked on the top and bottom, respectively. Both monitors are in 32bpp mode.

  6. Windows Presentation Foundation MultiMon Test - Vertical HW Fallback

    Command Line: WpfTest.exe /TestDocument: MultiMonVertOrientationReversedHWFallback.xml

    Description: Two monitors, monitor 1 and monitor 2, are stacked on the top and bottom, respectively, monitor 1 is in 32bpp mode and monitor 2 is in 16bpp mode.

  7. Windows Presentation Foundation MultiMon Test - Vertical Reverse

    Command Line: WpfTest.exe /TestDocument: MultiMonVertOrientationReversed.xml

    Description: Two monitors, monitor 1 and monitor 2, are stacked on the bottom and top, respectively. Both monitors and both display in 32bpp mode.

2. Stability ("Crash") Tests Overview:

All stability tests are made to run within the DirectX Crash harness together with other DirectX applications in the kit. The spirit of these tests is to be stand-alone applications that produce reproducible content in a random fashion to stress the system - they will be monitored for crashes as part of the stability effort.

These are all built from a common core and have the following common parameters and behavior. Each iteration loads certain content, moves and resizes the window, and changes window background.

/seed=< int > - random number seed to reproduce a sequence of events

/refresh=< int - milliseconds > - time between content refresh

/hardware - create a hardware only render target when set

/serialize - save each iteration as a stand-alone XAML file

/verify - after rendering the random content in hardware, test renders using the reference rasterizer and uses visual verification to validate. This can make the test longer and more cumbersome and should not be used under stress - it's rather meant to be an additional use for this framework.

/forceSave - saves a .png output file of the rendered content for each iteration

Tests:

  1. Windows Presentation Foundation D3D Stress

    Command Line: Crash3DTest.exe /hardware /refresh=2000

    Description: Test creates random 3-D content. The camera is set so that the content is very likely to be in view most of the time. Different numbers of lights, meshes, materials, Effects and some other variations are set in a random fashion.

  2. Windows Presentation Foundation Drawing Stress

    Command Line: CrashDrawingTest.exe /hardware /refresh=1500

    Description: Test creates random 2-D content by generating randomized path segments, with different widths and pens and fills. Since path is the lowest level rendering primitive in WPF, this should be a defining sample of any 2-D content. The path is set to fit into the visible window area.

  3. Windows Presentation Foundation Win32 Host Stress

    Command Line: CrashHostTest.exe /hardware /refresh=2000

    Description: Test creates a randomly sized Win32 button hosted within a WPF application.

  4. Windows Presentation Foundation Video Stress

    Command Line: Test scans the working directory for .WMV files, randomly chooses one from them, and creates a scene with the video in either 2-D or 3-D.

    Description: CrashVideoTest.exe /hardware /refresh=15000

  5. Windows Presentation Foundation Xaml Stress

    Command Line: CrashXamlTest.exe /hardware /refresh=4000

    Description: Test randomly grabs a Xaml file from working directory and creates a scene from the Xaml file.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

  • Software components included with the device that is being tested

  • Microsoft .NET Framework 3.5 Service Pack 1 installed

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64


Game Devices Testing

This section describes how to test storage devices and controllers in order to qualify them for the Windows logo.

Common Controller Testing

USB Gaming Device Testing

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


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.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

  • Preparing: The preparing topics describe how to configure the system or systems for Windows logo testing.

  • Running the test: The test procedure topics describe how to run to run each test in the WDK using the DTM.


Preparing for Common Controller Testing

Before running the Common Controller tests on test 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 the Installation Guide.

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 DTM controller and the DTM Studio. On each test system, install the DTM client. For information, see Install the DTM client.


Running the Common Controller Tests (XNACC)

After you have installed the test devices and drivers in the test clients, and have set up the DTM controller, DTM studio, and clients, you can begin running the logo tests.

To use DTM to run the Common Controller logo tests for the device

  1. Start the DTM studio.

  2. Switch to the Device Console window.

  3. Click the Submission button.

  4. Select New submission.

  5. Select the OS, select Device Submission, select Game Devices, Common Controller, and select Qualification Level you plan to obtain a logo for.
    1. Name your submission and select your machine pool where the devices are installed.
    2. Select the I am not providing an INF or Driver Package checkbox (This is because drivers are system-supplied).
    3. Find and select your device under the Human Interface Device node.
    4. Click Finish.

  6. Select all the tests, click 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.

  9. Once all jobs have passed, right-click 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.


USB Gaming Device Testing Overview

The procedures included in this section 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.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

The test procedures are divided into the following types of topics:

  • Preparing: The preparing topics describe how to configure the system or systems for Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

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 test 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 procedures and requirements for the USB gaming device. For information about installing and configuring the DTM, see Setting Up DTM.

Test System Configuration

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 the USB 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 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 I am not providing an INF or Driver Package (because drivers are system-supplied).

  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.


Game Devices Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


Imaging Testing

This section describes how to test storage devices and controllers in order to qualify them for the Windows logo.

This section includes:

Imaging > Scanning

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Scanner Testing Overview

The procedures presented in this section outline the process for testing your scanner for proper functionality with the Windows operating system. These procedures use the Windows Logo Kit (WLK) 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.

Scanner Program Categories

There are four scanner programs in the WLK:

  • Consumer Scanning
  • Consumer Scanning – Rally Enabled (Network)
  • Enterprise Scanning
  • Enterprise Scanning – Rally Enabled (Network)

The following sections will help you decide which program is necessary for your device. This is dependent on the capabilities of the device.

Consumer vs. Enterprise

Consumer programs are targeted towards scanners designed to be used in the home environment. Consumer programs run on the client versions of Windows and receive a Windows client operating system (OS) logo.

Enterprise programs are targeted towards scanners designed for the enterprise environment. Enterprise programs run on the server versions of Windows and receive a Windows server OS logo.

Consumer Scanning/Consumer Scanning - Rally Enabled (Network) available operating systems:

  • Windows XP
  • Windows Vista
  • Windows 7

Enterprise Scanning/Enterprise Scanning - Rally Enabled (Network) available operating systems:

  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2008 R2 (x64)/Windows 7 (x86)

Note When testing x86 drivers using the Enterprise Scanning and Enterprise Scanning – Rally Enabled (Network) programs, use the Windows 7 x86 operating system. The device will receive a Windows Server 2008 R2 logo.

Scanning vs. Scanning – Rally Enabled (Network)

Scanning programs are designed to test scanners over all non-network connections, such as Universal Serial Bus (USB) and Bluetooth.

The Scanning – Rally Enabled (Network) programs are designed for all network-attached scanners (both wired and wireless). This program tests the device for all Rally requirements. Please visit the LogoPoint website to view the scanner requirements.

Note All consumer scanners that support a network bus must be tested using the Consumer Scanning – Rally Enabled (Network) Program. Rally technologies are not required for enterprise scanners. If your enterprise scanner supports a network bus, but does not support Rally, use the Enterprise Scanner program.

Note You must test the scanner over each bus that it supports. If the device supports both a USB and an Ethernet bus, you must run both Scanner and Scanner – Rally Enabled (Network) programs.

Scanner Tests

The list of tests you need to run depends on the capabilities of the device or system being tested. To see the complete list of tests that are required for your device, see Scanner Tests.

Run time: Approximately 5 hours

Scanner – Rally Enabled (Network) tests

When you create a new submission using a Rally Enabled (Network) program, you receive a prompt for Scanner Network Connection Type. Select one of the following options:

  • If your device supports wireless only, select Wireless Only.
  • If your device supports a wired connection type only, select Wired Only.
  • If your device supports both wireless and wired connections, select Wired and Wireless.

Note If you support both connection types, you can configure the device as necessary to run each set of tests appropriately. For example, you can run all scan tests and wired tests through the wired connection, and then switch to wireless to run the wireless tests.

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 whether there are additional hardware requirements.

  • Basic WLK test setup (Controller, Studio, and Client systems)

  • At least one scanner installed on a client system

Note Testing a device for Server Device qualification requires that the system being used to test the device support four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has more than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard disk drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for para-virtualization drivers (as defined by Logo Program Requirement Policy-0020), physical devices and their associated drivers being tested for a server logo or signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, and so on.

Software Requirements

It is good practice to clean-install the operating system on client systems before final test passes to ensure that the system is in a known clean state.

The following software is required to run the scanner tests:

  • Correct operating system build installed on the WLK client for the intended logo program

  • AppVerifier

  • The driver package being tested installed on a client system

  • Desktop Experience, for computers with Windows Server 2008 installed. Desktop Experience ensures that the scanner tests run correctly. Run the following command from the command prompt to install Desktop experience: ocsetup.exe DesktopExperience /quiet /norestart

  • Microsoft Windows Server 2008 R2 is supported.

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 WLK 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 Scanner Testing Overview.

Many of the tests in the Windows Logo Kit (WLK) 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.

Test System Configuration

The scanner test kit uses a basic WLK lab setup. After the controller has been set up and a machine pool has been created, move the client system to that pool.


Running the Scanner Tests

Running the Printer - Rally Enabled (Network) Tests

The “Rally” tests are only expected to be executed against the wired connection, and the “Wireless Rally” tests are only intended to be executed against the wireless connection.

To run the tests, follow these steps:

  1. Select the operating system and processor architecture to test, and then click Next.
  2. Select a submission category (Device Submission), and then click Next.
  3. Select the appropriate logo program under Scanner – Rally Enabled (Network).
  4. Select a Qualification Level (logo), and then click Next.
  5. Enter a name for the submission, click the machine pool you created earlier, and then click Next.
  6. Select I am not providing an INF or driver package in the lower left hand corner, and then click Next.
  7. Select Device Not Listed, and then click Next.
  8. Fill in the Create New Submission form:
    1. Select the appropriate network connection type for the device: Wired only, Wireless only, or Wired and wireless.
    2. Select whether your device supports XPS Thumbnail processing.
    3. Enter the MAC Address, as noted in Device Setup. The MAC Address must include the dashes, for example, 00-a0-b0-94-5b-fb.
    4. Enter the Discovery protocol.
    5. Enter the device’s UPnP UUID. This should begin with uuid, for example, uuid: de1dec0a-9021-426c-9548-f714b5e8ef56.
    6. Enter the device’s WSD UUID, if applicable. This should begin with uuid, for example, uuid: de1dec0a-9021-426c-9548-f714b5e8ef56.
    7. Enter the device’s UDN or WPS (Wifi protected setup) UUID, if applicable. This information was noted in Device Setup. The unique identifier must include the dashes, for example, 4a96edf6-0aa0-11de-904a-00a0b0945bfb.
    8. Enter the device’s WinQual ID, also known as the vendor ID, used in your hardware ID, formatted is as follows: VEN_XXXX.
    9. Select the appropriate setting indicating UPnP protocol for your device: Required, NotRequired, Unknown.
    10. Select the appropriate setting indicating WSD protocol for your device: Required, NotRequired, Unknown.
    11. Enter the device’s Hostname or Directed Discovery URL for the device.

Note Failure to fill in the correct values may cause the tests to prompt you for additional input.

For more information about creating a new logo program submission and scheduling jobs, see Generic Logo Submission exercise.


Imaging Tests

Test name Target operating system Test description

Scanner WinColor Test

  • Windows Vista

The Scanner WinColor Test test validates that a scanner conforms to the Windows Color Compliancy requirements for scanners. For more information about the Windows Color Compliancy requirements, see WinColorKit: Windows Color Quality Test Kit for Device OEMs.

WIA Data Transfer Tool

  • Windows 7

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2008 R2

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.

WIA Error Handler Tool

  • Windows 7

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2008 R2

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 Filters Test

  • Windows 7

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2008 R2

It helps WIA driver developers to implement their WIA filters in accordance with Windows Driver Kit (WDK) and Windows Logo requirements.

WIA Tester

  • Windows 7

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2008 R2

This test tool verifies that all WIA properties for pre-Vista style drivers are implemented according to the Windows Driver Kit (WDK) and Windows Vista Logo requirements. It also verifies the correct structure of the WIA item tree built by a pre-Vista scanner driver.

This test should help driver developers to detect properties and item tree implementation errors.

WIA Treeproperties

  • Windows 7

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2008 R2

This test tool verifies that all WIA properties for Windows Vista style-drivers are implemented according to Windows Driver Kit (WDK) and Windows Vista Logo requirements. It also verifies the correct structure of WIA Items tree built by Windows Vista-style scanner driver.

It will help driver developers to detect properties and item tree implementation errors.


Scanner WinColor Test

Type: Automated Test

Overview

The Scanner WinColor Test test validates that a scanner conforms to the Windows Color Compliancy requirements for scanners. For more information about the Windows Color Compliancy requirements, see WinColorKit: Windows Color Quality Test Kit for Device OEMs.

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 that are used and the calculations, see WinColorKit: Windows Color Quality Test Kit for Device OEMs .

Run Time: 2 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Processor


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.

WIA 2.0 is a requirement for the test to pass in Windows 7 and Windows 2008 R2. WIA 2.0 is not a requirement for Windows Vista.

Run Time:
Log File: DataTransfer.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • If your device supports automatic document feeder, make sure there is enough paper in the feeder (usually about 50 pages).
Processor
  • x86
  • x64

Running WIA Data Transfer Tool

To set up this tool manually, follow these steps:

  1. Install the WIA device to be tested.

  2. Register WiaTestLog.dll using RegSvr32.

  3. Run the WiaTransferTool.

Note WIA tests may fail if you do not use the WIA Friendly name, To resolve this, please follow these steps:

  1. Restart the DTM Client and wait for it to log in.

  2. Close the Device Console.

  3. Re-open the submission.

This will ensue that the gatherer data is in-sync and that the friendly name is populated.

If the steps above do not work, please work with your driver developer to make sure that the INF is referencing the driver correctly.

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


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.

WIA 2.0 is a requirement for the test to pass in Windows 7 and Windows 2008 R2. WIA 2.0 is not a requirement for Windows Vista.

Run Time: 30 min
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • If your device supports automatic document feeder, make sure there is enough paper in the feeder (usually about 50 pages).
Processor
  • x86
  • x64

Running WIA Error Handler Tool

  1. Install WIA device to be tested.

  2. Register WiaTestLog.dll using RegSvr32.

  3. Run WiaErrorHandlerTool.

Note WIA tests may fail if you do not use the WIA Friendly name, To resolve this, please follow these steps:

  1. Restart the DTM Client and wait for it to log in.

  2. Close the Device Console.

  3. Re-open the submission.

This will ensue that the gatherer data is in-sync and that the friendly name is populated.

If the steps above do not work, please work with your driver developer to make sure that the INF is referencing the driver correctly.

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


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.

WIA 2.0 is a requirement for the test to pass in Windows 7 and Windows 2008 R2. WIA 2.0 is not a requirement for Windows Vista.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
  • wttlog.dll in DLL search path

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • At least 20 GB disk space available on current partition.
  • If your device supports automatic document feeder, make sure there is enough paper in the feeder (usually about 50 pages).
Processor
  • x86
  • x64

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.

Note WIA tests may fail if you do not use the WIA Friendly name, To resolve this, please follow these steps:

  1. Restart the DTM Client and wait for it to log in.

  2. Close the Device Console.

  3. Re-open the submission.

This will ensue that the gatherer data is in-sync and that the friendly name is populated.

If the steps above do not work, please work with your driver developer to make sure that the INF is referencing the driver correctly.

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.

Code Tour

File Manifest

File | Location
WiaFilters.exe | %controller%\tests\<arch>\nttest\PrintScanTest\WIA\wiafilters


WIA Tester

Type: Automated Test

Overview

This test tool verifies that all WIA properties for pre-Vista style drivers are implemented according to the Windows Driver Kit (WDK) and Windows Vista Logo requirements. It also verifies the correct structure of the WIA item tree built by a pre-Vista scanner driver.

This test should 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, required items, optional items, 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, exports test information to a WTT log file, console and custom log window (optional).

  • GUI application WiaTestGui.exe - collects test parameters through the user interface and runs WiaTreeProperties.exe to do the actual testing.

  • WiaTestLog.exe - custom log window; can 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 the WIATester.exe application.

WIA 2.0 is a requirement for the test to pass in Windows 7 and Windows 2008 R2. WIA 2.0 is not a requirement for Windows Vista.

Run Time: 20 mins
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Hard drive with a minimum of 20 GB available on partition C:
  • If your device supports automatic document feeder, make sure there is enough paper in the feeder (usually about 50 pages).
Processor
  • x86
  • x64

Running WIA Tester

WIA tests may fail if you do not use the WIA Friendly name, To resolve this, please follow these steps:

  1. Restart the DTM Client and wait for it to log in.

  2. Close the Device Console.

  3. Re-open the submission.

This will ensue that the gatherer data is in-sync and that the friendly name is populated.

If the steps above do not work, please work with your driver developer to make sure that the INF is referencing the driver correctly.

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\


WIA Treeproperties

Type: Automated Test

Overview

This test tool verifies that all WIA properties for Windows Vista style-drivers are implemented according to Windows Driver Kit (WDK) and Windows Vista Logo requirements. It also verifies the correct structure of WIA Items tree built by Windows 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.

This tool includes:

  • 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

WIA 2.0 is a requirement for the test to pass in Windows 7 and Windows 2008 R2. WIA 2.0 is not a requirement for Windows Vista.

Run Time: 20 min
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • If your device supports automatic document feeder, make sure there is enough paper in the feeder (usually about 50 pages).
Processor
  • x86
  • x64

Running WIA Tree and Properties

WIA tests may fail if you do not use the WIA Friendly name, To resolve this, please follow these steps:

  1. Restart the DTM Client and wait for it to log in.

  2. Close the Device Console.

  3. Re-open the submission.

This will ensue that the gatherer data is in-sync and that the friendly name is populated.

If the steps above do not work, please work with your driver developer to make sure that the INF is referencing the driver correctly.

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.

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


Input Testing

This section describes how to test storage devices and controllers in order to qualify them for the Windows logo.

Input > Digitizer

Input > Keyboard

Input > Media Center Edition Remote Control

Input > Pointing Drawing

Input > Smartcard Reader

Input > Sensor

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Fingerprint Reader Testing Overview

The procedures presented in this section outline the process for testing your fingerprint reader for proper functionality with the Windows operating system. These procedures use the Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that 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 logo testing.
Running: The running topics describe how to run to run the tests for your device or system.

Fingerprint Reader Tests

The list of tests you need to run depends on the capabilities of the device or system being tested. To see the complete list of tests that could be required for your device, see Input Tests.

Run time: Approximately 5-10 minutes. Additional time is needed for USB-related tests, which can take several hours.

Hardware Requirements

The following hardware is required for Fingerprint 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 whether there are additional hardware requirements.

  • Fingerprint device
  • Computer running Windows 7

Tester Knowledge Rrequirements

To run the fingerprint reader tests, testers must know how to install and use DTM, and how to use and install fingerprint devices and drivers.


Preparing for Fingerprint 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 Fingerprint Reader Testing Overview.

Many of the tests in the Windows Logo 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.

Test system configuration

  1. Install the fingerprint device.
  2. Create the following test directory: [SYSTEMDRIVE]\FingerprintReaderTest
  3. Copy the adapter dlls from [SYSTEMDRIVE]\Windows\System32\WinBioPlugins for sensor, storage, and engine adapters.
  4. Using the templates below, create the configuration files for sensor, storage, and engine adapters.
    1. Name the files SensorTestConfig.xml, StorageTestConfig.xml, and EngineTestConfig.xml, respectively.
    2. Edit the sensorAdapterLib, engineAdapterLib, and storageAdapterLib fields to point to the correct adapter dlls, as copied in step 3.
    3. Edit the supportedModes and supportedPurposes fields to match device capabilities.
    4. The runOptional attribute is "false" by default. To run extra tests, change this to "true."
    5. For Storage tests, change the deviceRequired attribute to "true" if the device has onboard storage.

Engine Adapter configuration file template:

Sensor Adapter configuration file template:

Storage Adapter configuration file template:


Running the Fingerprint Reader Tests

For general information about running your tests, please see Generic Logo Submission exercise.


Troubleshooting Fingerprint Reader Testing

For general information about troubleshooting, please see Troubleshooting.htm - Troubleshooting DTM Problems.


Digitizer Testing Overview

The procedures that are presented in this section outline the process for testing your digitizer for correct functionality with the Microsoft Windows operating system. These procedures test your product for correct functionality by using the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that 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.

Digitizer Tests

The tests that you need to run depend upon the capabilities of the device or system that is being tested. For the complete list of tests that could be required for your device, see Digitizer Tests.

Run time: approximately 10 minutes

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Hardware Requirements

The following hardware is required for digitizer 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 digitizer that reports through HID as a pen digitizer (digitizer page 0x0D, usage 0x02) or touch digitizer (digitizer page 0x0D, usage 0x04).

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

Microsoft Windows Server 2008 R2 is supported.

Tester Knowledge Requirements

There are no additional tester knowledge requirements.

This section includes:

Preparing for Digitizer Testing

Running the Digitizer Tests


Preparing for Digitizer Testing

Before running the digitizer 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 Digitizer Testing Overview.

Many of the tests in the Microsoft Windows Driver Kit (WDK) 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 How to turn on automatic logon in Windows XP.

Test System Configuration

To configure the test systems for digitizer testing, do the following:

  • Install the appropriate operating system on the test system.

  • Connect the digitizer to the test system and ensure that basic functionality is working.

  • If appropriate, enable autologon functionality.

  • Install the DTM client on the test system.

  • Ensure the gatherer, MobilePC\TabletPCDigitizer, is installed on the test system


Running the Digitizer Tests

After you have installed the DTM client and gatherer on the test systems, you can begin testing.

To run the Digitizer logo tests by using DTM, do the following

  1. Open DTM Studio.

  2. On the Explorers menu, click Job Monitor.

  3. Create a machine pool where the client systems can go.

  4. Move the client systems to the newly created machine pool.

  5. On the Explorers menu, click Device Selection.

  6. In the View By area, click Submission.

  7. From the Submission drop-down list, click New Submission.

  8. Follow the steps in the Submission Wizard. When you complete the wizard, a set of jobs is displayed.

  9. In the Available Devices pane, click one of the devices.

  10. In the Available Jobs pane, click the main job tree to run all of the jobs that are listed or click the jobs individually and then click Add Selected.

  11. When you are ready to run the jobs, click Schedule.

  12. Repeat steps 11-13 for the other devices in the Available Devices pane.

  13. After testing is complete, click the status button in Device Console and review the information that is provided. Make corrections as necessary.

  14. After you verify the status information, right-click the summary icon in the Available Devices pane of Device Console, and then click Create Submission Package.

You can use Job Monitor to track the progress of jobs as they are run, and you can use Result Explorer to examine the results of jobs that have completed.

Currently, there are no manual digitizer tests.


Keyboard Testing Overview

The procedures that are presented in this section outline the process for testing your keyboard for correct functionality with the Microsoft Windows operating system. These procedures test your product for correct functionality by using the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that 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.

Keyboard 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 the Keyboard Tests.

Run time: approximately one to three hours

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Hardware Requirements

The following hardware is required for keyboard testing.

  • One keyboard compliant with Microsoft-specified scan codes (PS2 or HID)

  • If keyboard is connected through USB, one external USB 2.0 high-speed hub (unless the keyboard contains an embedded hub)

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

There are no additional software requirements.

Tester knowledge requirements

There are no special tester knowledge requirements.

This section includes:

Preparing for Keyboard Testing

Running the Keyboard Tests


Preparing for Keyboard Testing

Many of the tests in the Windows Driver Kit (WDK) 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 systems for keyboard testing, do the following:

  1. Connect the keyboard to the client system and ensure its visibility and basic functionality before proceeding.

  2. If the keyboard supports USB, ensure the keyboard is plugged into the external USB 2.0 high-speed hub that is connected to the client system.


Running the Keyboard Tests

The primary manual test in the keyboard test suite is Winkey. Winkey requires the installation of a keyboard filter driver before the test will run successfully, so the following instructions should be followed for each test involving Winkey (1-key, 2-key, 3-key, and Media-key tests):

  • When the Winkey UI appears for the first time, select the option Install Driver. The system will restart.

  • When the Winkey UI appears for the second time (after you logged back in), select the option Run test.

  • When the Winkey UI appears for the third time, select the option Uninstall Driver. This will return the system to its previous state so that subsequent tests will succeed.


KVM Testing

KVM Testing Overview

Preparing for KVM Testing

Running the KVM Tests

Troubleshooting KVM Testing


KVM Testing Overview

The procedures in this section outline the process for testing your KVM for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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 logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

KVM Tests

The list of test you need to run depends on the capabilities of the device or system being tested. To see the complete list of tests that may be required for your device, please see the KVM Tests under Input Tests.

Run time: Approximately 4 hours

Hardware requirements

The following hardware is required for KVM 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.

  • KVM device

  • Two systems with the same OS installed

  • One display

Software requirements

There is no special software required to run this test.

Tester knowledge requirements

To run the KVM tests, testers must know how to switch from one machine to another using the KVM under test.


Preparing for KVM Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes all related procedures.

For a complete list of required hardware, software, and tester knowledge, see the KVM Testing Overview.

Many of the tests in the Windows Logo Kit require a test system to restart (often multiple times) 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.

Test system configuration

  1. Install both the Devices Kit and the Display Kit on the DTM controller.

  2. Install the DTM client on the two (or more) systems attached to the KVM.

  3. Attach a display to the KVM for testing.

  4. Create a KVM submission in Device Console.

  5. Schedule all available jobs.


Running the KVM Tests

For detailed information, please see the following sections:

  • Device Fundamental Tests

  • KVM - Automated Logo Test for Video

  • KVM - Manual Logo Test for Video


Troubleshooting KVM Testing

See the test documentation for troubleshooting information.


Pointing Drawing Testing Overview

To see the complete list of tests that could be required for your device, see the Pointing Device Tests.

Run time: approximately two hours

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Hardware Requirements

The following hardware is required for pointing device testing.

  • One test pointing device

  • If the device supports USB:

    • One external USB hub

    • One additional test device if a USB serial number is advertised

Note To reduce the chance of failures caused by unrelated hardware problems, Microsoft recommends that all tests be performed on a client test system which is part of the Windows Catalog at Windows Vista Upgrade Advisor.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

There are no additional software requirements.

Tester Knowledge Requirements

There are no special tester knowledge requirements.

This section includes:

Preparing for Pointing Drawing Testing

Running the Pointing Drawing Tests

Troubleshooting the Pointing Drawing Testing


Preparing for Pointing Drawing Testing

Several tests that are part of the Pointing Device suite require the client 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

  • Connect the pointing device under test to the client system and verify basic functionality before proceeding

  • If the test device supports USB, the test devices must be connected through an external USB hub (not directly to the test system)

  • If the device supports a USB serial number, be sure to attach the additional test device to the external hub before scheduling the USB Serial Number test


Running the Pointing Drawing Tests

To create a new pointing device submission in Device Console:

  1. Select New submission from the Submission box.

  2. Choose the target operating system for the logo submission.

  3. Choose Device submission.

  4. Select Input > Pointing Drawing for the Logo Program list.

    Screen shot of the Create New Submission dialog box with Input > Pointing Drawing selected

  5. Choose Basic for the Qualification Level.

  6. Name the submission and specify the machine pool that contains the client test system and pointing device.

  7. If the pointing device utilizes an INF to supply model-specific device information, select the INF. (Note: only inbox Microsoft class drivers are supported, so no driver binaries should be added in this dialog box.) If you do not wish to supply an INF, select I am not providing an INF or Driver Package as shown, and then click Next:

    Screen shot of the Create New Submission dialog box with I am not providing an INF or Driver Package selected

After selecting your test device (if prompted), you will be ready to schedule tests.

The only test specific to pointing devices is located in the "Mouse" category and is named Mouse Test. Mouse Test is an interactive Windows application that requires the operator to follow on-screen instructions on the client system to exercise the pointing device's functionality, such as button-clicking and scrolling. The test is mostly self-explanatory. One thing to remember: it is essential that the operator not touch the mouse during the hibernate portion of the test, or the system will wake prematurely and fail the test.

If your pointing device supports USB, you will be required to run a set of standard USB device tests. Please see the individual documentation for each test for more information.

The remaining tests are included as part of the Driver Reliability Signature test suite. These tests examine generic device behavior, such as power state management. Please see the documentation for each individual test for more information about requirements and troubleshooting.


Troubleshooting the Pointing Drawing Testing

From the Task Execution Status pane of Job Monitor, right-click the failed task (typically the "execute" task is the most critical). Open the relevant log file by right-clicking the task and selecting View task log. If that option is not available, you may need to first select Child job results and select a failed task from the child job.


Sensor Testing Overview

The information in this document outlines the process for testing your sensor device for proper functionality within the Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for your device. Each test enables AppVerifier to run on the user mode driver. The test recommends that a kernel mode debugger be attached to the test to catch any AppVerifier breaks. Each test should run AppVerifier clean and have no AppVerifier debug breaks.

Note: Sensor devices, as defined in this document, are devices that work with the Windows Sensor and Location platform. Currently this platform is only available on Windows 7.

The test procedures in this section are divided into the following sections:

  • Requirements: Describes the hardware, software, and tester knowledge that is required for running the sensor tests.

  • Preparing for Sensor Testing: Describes how to configure the system for Windows logo testing.

  • Running the Sensor Tests: Describes how to run the sensor tests for your device.

  • Troubleshooting: Describes how to diagnose and fix common problems that you might encounter during sensor device testing.

Requirements

Hardware Requirements

There are no specific hardware requirements for sensor device testing other than the device to be tested.

Software Requirements

The following software is required to run the sensor testing components of the WLK:

  • Windows 7 (Home Premium or higher. Windows 7 Ultimate is recommended.)

  • Any drivers that are not shipped with the operating system.

  • A setup information (.inf) file for the device that you are testing.

Tester Knowledge Requirements

To run the sensor tests, you must know how to perform the following actions:

  • Install Windows.

  • Install the sensor device under test.

  • Install the DTM client and DTM studio.

  • Start tests from the DTM Device Console in the DTM Studio.

  • Attach a kernel mode debugger to the target test machine.

  • Review the output log from AppVerifier for errors.

For more information on using the WLK DTM please see Getting Started and Using DTM for Logo Testing.


Preparing for Sensor Testing

Before you run the sensor tests, the test environment must be configured for logo testing. For detailed information on configuring a test environment, please see Configuring the Test Environment in Using DTM for Logo Testing. The information below summarizes the steps needed for setting up an environment for sensor testing. This information is intended to supplement the detailed information in Configuring the Test Environment.

Configure Test Systems for Sensor Testing

  1. Install Windows 7 on the test system.

  2. Install the sensor device on the test system, including any device specific .inf files.

  3. Install the DTM client on the test system.

  4. Open the Location and Other Sensors Control Panel.

  5. Grant all users access to the sensor device being tested. This can be done by doing the following:
    1. In the Location and Other Sensors Control Panel, select the check box next to the sensor device being tested.
    2. Click Apply.

  6. Set up the DTM Client with a kernel mode debugger. See "Configure DTM Client Kernel Debugger Settings" in the Install.htm - Installation Guide for directions on how to enable and attach a kernel mode debugger to the target machine.

Note You will need to have Administrator rights to enable the sensor.

Prepare the DTM for Sensor Testing

The following steps are necessary to prepare the DTM for sensor testing. Before you follow these steps, make sure that you have configured the test system for sensor testing.

  1. Provide a machine pool for testing.

    Note For more information on Machine Pools, please see Grouping Client Computers into Machine Pools.

  2. Move any test computers that will be used for sensor testing into this pool.

  3. Make sure that all test computers used for sensor testing are in a ready state.


Running the Sensor Tests

The following steps show how to use the DTM to create a logo submission for sensor devices:

  1. Open the DTM Studio.

  2. On the Explorers menu, click Device Console.

  3. In the Machine Pool list, select the machine pool that contains the test system with the sensor device to test.

  4. In the View By area, ensure that Submission is selected.

  5. In the Submission list, select <New Submission>

  6. In the Create New Submission dialog box, select either Windows 7 Client or Windows 7 Client x64. Make sure that this selection matches the operating system and architecture of your test system. Click Next after making your choice.

  7. Click Device Submission, and then click Next.

  8. Select Input > Sensor, and then click Next.

  9. Select a Qualification Level of Logo, and then click Next.

  10. In the Name for new submission box, enter a name for your submission.

  11. Select the machine pool that contains your test system, and then click Next.

  12. In the Driver Install File (INF) box, click Browse to find the .inf file for your device. After you have located your file, click Load, and then click Next.

  13. On the summary page, review the information to make sure it is correct, and then click Finish.

  14. In the Available Devices area of the Device Console window, click a test device from the computer pool that you previously created.

  15. In the Available Jobs area, select all of the jobs provided. Note that this box should at least contain an item for Sensor with multiple tests listed for Sensor.

  16. Click Add Selected to add the jobs list.

  17. Click Schedule Jobs to start testing.

While tests are running, you can view their progress from the Job Monitor by following these steps:

  1. On the Explorers menu, select Job Monitor.

  2. In the Machine Pool area, select the computer pool that contains your test system.

In the Machines area, you can select the machines you are testing against to see which tests they are running.


Troubleshooting Sensor Testing

The following information assists in investigating logo test problems.

Find Test Failure Details

If the sensor logo tests successfully ran on the target test system and they reported errors, then log information related to these errors can be viewed by doing the following:

  1. Open the Job Monitor on the Explorers menu.

  2. In the Machine Pool area, select the machine pool that contains your test system.

  3. In the Machines area, select the machine that ran the failing tests.

  4. In the Job Execution area, select the test that failed.

  5. In the Task Execution Status area, right-click the failing tasks. Then select View Task Log to see a full log for the current task.

If the Task Execution Status area is not visible, click Tasks on the View menu.

Test Initialization Failures

When the sensor logo tests start on a client machine, they perform several tests to verify that the environment can be used for testing. If you receive errors with a TUID of A012D6BB-36BB-4088-AF3F-1BE3C5607928, check the following items:

  1. Test system must have Windows 7.

  2. Test system must currently have your device installed and it must be operational for tests to run on it.

  3. The device must be showing up as a sensor device for the sensor logo tests to run on it. Verify that the device is listed in the Location and Other Sensors in Control Panel.

Operating System Issues

The sensor logo tests are only valid on the Windows 7 operating system. If you try to run the tests on any other version of Windows, it is not supported.

Permissions Issues

A portion of the sensor logo tests requires that the user logged into the client machine has permissions to access the sensor device. Do the following to check permissions:

  1. Open the Location and Other Sensors in Control Panel.

  2. Grant all users access to the sensor device being tested. To do this, follow these steps:
    1. In the Location and Other Sensors Control Panel, select the check box next to the sensor device being tested.
    2. Click Apply.

Note that you will need to have rights to change the permissions for a sensor.


Smart Card Reader Testing Overview

The procedures in this section outline the process for testing your smart card reader for proper functionality with the Microsoft Windows operating system. These procedures use the 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.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

  • Preparing: The preparing topics describe how to configure the system or systems for Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

  • Troubleshooting: The troubleshooting section provides information to diagnose failures, warnings and/or errors with the test.

Smart Card Reader Tests

The tests you need to run depend on the capabilities of the device or system that is being tested. The following is the complete list of tests that could be required for your test device:

  • Card Reader Test (IFDTest2)

  • Device Path Exerciser

  • Sleep Stress with IO

  • Disable Enable with IO

  • Common Scenario Stress with IO

  • Plug and Play Driver Test

  • Run INFTest against a single INF

If your device is connected using 1394, run the following test:

  • 1394 Configuration ROM Test

If your device is connected using CardBus, run 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 using PCI, run the following tests:

  • (Windows Vista and later versions) PCI/PCI Express Compliance Test (PCIHCT)

  • (Windows XP/Server 2003) PCI Compliance Test 2.1

If your device is connected using USB, run the following tests:

  • USB Address Description Test

  • USB Descriptor Test

  • USB Device Control Requests Test

  • USB Device Framework (CV) Test

  • USB Enumeration Stress Test

  • USB HIDView (CV) Test

  • USB Selective Suspend

  • USB Serial Number

  • USB Specification Compliance

Run time: approximately three to four hours

Hardware Requirements

The following hardware is required for smart card 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.

  • One computer with the following:

    • Minimum requirements published for the test operating system
    • 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 through the USB port.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software Requirements

The following software is required to run the smart card reader tests:

  • One of the following operating systems:
    • Windows Vista
    • Windows XP Professional with Service Pack 2 (SP2)
    • Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
    • Windows Server 2003, Datacenter Edition, with SP1
    • Windows Server XP Professional x64 Edition
    • Windows Server 2003, Enterprise x64 Edition
    • Windows Server 2003, Datacenter x64 Edition
    • Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
    • Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
    • Windows Server 2008 R2

  • Any drivers that are not shipped with the operating system

  • The current release of WDK

Tester Knowledge Requirements

To run the smart card 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).

This section includes:

Preparing for the Smart Card Reader Testing

Running the Smart Card Reader Tests

Troubleshooting the Smart Card Reader Testing


Preparing for the Smart Card 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 Smart Card 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. To facilitate this DTM will configure the client to automatically login using the DTMLLUAdminUser. This happens when you first create your submission. DTM will also turn off workstation locking and prevent the machine from automatically hibernating/sleeping. If you wish to Remote Desktop into the client after starting a submission, please use DTMLLUAdminUser.

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 through the USB port:
    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.

  4. Install DTM Client.

  5. Configure the machine for testing in DTM Studio.

    Add the machine to a machine pool.

    Deploy the "WDK\ConfigureSmart CardReader" dimension.


Running the Smart Card Reader Tests

  1. Open Device Console in DTM Studio.

  2. Create a new submission for "Input > Smart Card Reader".

  3. During the submission make sure to load the same driver you installed on the system for step 3 of Test system configuration of Preparing for Smart Card Reader Testing.

    If you are not loading a driver, make sure to select your card reader under the Smartcard Readers node in the device list.

  4. Select the tests that 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.


Troubleshooting the Smart Card Reader Testing

To diagnose failures, warnings and/or errors when performing testing, try the following remedies:

  • Before you create a submission, make sure your client is in Ready () Mode. If it is not, right-click the system and choose Change Status and then 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 system.

  • If jobs are not getting your device's parameters check the following:
    • Right-click 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 system from the machine pool, uninstall the client and repeat steps 4 & 5 of Test System Configuration.
  • If jobs are appearing incorrectly.
    • Please ensure that you have done step 5 of Test System Configuration.


Windows Media Center IR Receiver Testing Overview

The procedures in this section outline the process for testing your Windows Media Center Infrared (IR) Receiver for correct functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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 in this section 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 Windows logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

Troubleshooting: The troubleshooting section provides information to diagnose common problems that you might encounter during these tests.

Windows Media Center IR Receiver Tests

The list of tests that you must run depends 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 Windows Media Center IR Receiver Test.

Run time: approximately 1 hour

Hardware requirements

The following hardware is required for testing a Windows Media Center IR Receiver. Additional hardware might be required if the test device provides bus-specific support. See the individual test description for each bus-specific test to determine if there are additional hardware requirements.

  • x86-based and x64-based computers with Windows Vista installed

  • One correctly functioning IR transceiver to act as the control device

  • One IR receiver to act as the device under test to be certified

  • One strong IR emitter for testing receivers or two strong IR emitters for testing transceivers

Software requirements

The following software is required to run the Windows Media Center IR Receiver tests:

  • CIRTest.exe

  • CIRTest.dll

  • Devcaps.ini

  • Wttlog.dll (installed by the DTM Client)

  • DevPathExer.exe (Only required for Port Driver Testing/Verification)

Tester knowledge requirements

To run the Windows Media Center IR Receiver tests, testers must know how to accomplish the following tasks:

  • Set up the test environment, which requires knowledge of IR and IR hardware.

  • Use DTM, and schedule jobs.

  • Verify tests. For a description of how to do this, see the Windows Media Center IR Receiver Test.


Preparing for Windows Media Center IR Receiver Testing

Before you run 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 Windows Media Center IR Receiver Testing Overview.

Many of the tests in the Windows Logo Kit (WLK) require a test system to restart (often more than once) to complete a test run. The test description and the instructions for running the test 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.

Testing system configuration

Make sure that the IR receiver(s) to be tested are installed on the test machine:

  1. Install the known, good control IR receiver device first (control device).

  2. Install the IR receiver to be tested (device under test).

Note If you must add or remove Windows Media Center IR Receivers from your test machine, you must restart the machine in order to re-enumerate the receivers and expose them for the submission process.


Running the Windows Media Center IR Receiver Tests

To set up the machine pool

  1. Open the Device Console.

    You can open the Device Console by clicking Explorers, and then clicking Device Console.

  2. In the Submission drop-down list, click New Submission.

  3. Click Windows Vista Client or Windows Vista Client x64, and then click Next.

  4. Click Device Submission, and then click Next.

  5. Click Input > MCE IR Receiver, and then click Next.

  6. Click Premium, and then click Next.

  7. Type a name for your submission and click a machine pool to run the tests on, and then click Next.

  8. If your device uses the USBCIR port driver, click I am not providing an INF or Driver Package, and click Next.

    Or, if you have your own port driver, add the INF to the list and click Next.

  9. In the drop-down list box, click your device, and click Next (select the hardware device and not the HID device associated with your receiver).

  10. Make sure that the submission data is correct, and click Finish.

  11. In the View By area of the Device Console, click Submission.

  12. Click your device name to view the CIR tests that are listed.

  13. Select the check boxes next to the tests that you want to run, and click Add Selected.

  14. If you must change any parameters of the device such as the emitter location, right-click the job and edit the settings.

  15. When you are ready to run the tests, click Schedule Jobs.

    Note If this is the first time you are running this test, restart the computer so that the test environment is set up correctly. If you are testing on Windows Vista, due to a known issue that is exposed during the test, you might need to unplug the receivers and then plug them in after the reboot has completed, otherwise some test cases might fail. This does not occur unless you reboot with the receivers attached to the test machine.

    Note These jobs require your input periodically. Move to your test machine that contains the device under test to view a dialog box that provides instructions for how to set up your receivers and how to edit the Devcaps.ini file that the test uses for verification. After you close the dialog box, the Devcaps.ini file will open in Notepad for you to edit. Save and close Notepad after you are finished editing the file. If the device has not changed from the previous configuration, you should not need to re-edit the Devcaps.ini file each time you run the tests.

  16. The jobs will now run on your test machine. After the jobs have completed, you can submit the results for certification by right-clicking the device in the submission/Device Console view and clicking Create Submission Package.


Troubleshooting Windows Media Center IR Receiver Testing

Follow these troubleshooting guidelines during the tests to make sure that IR interference does not create a performance issue:

  • Make sure that the IR receivers are not physically facing each other.

  • Make sure that the IR receivers are in a relatively enclosed area such that IR blasting from one device is not received by the other device.

  • Make sure that the IR receivers are positioned away from devices that emit IR, such as plasma displays, overhead fluorescent lights, or natural sun-light.

  • Make sure that your test is running with built-in Administrator privileges (The DTM test cases do this by default.).

  • IR emitter placement and strength are key factors in running these test cases. Some test cases require that the IR emitter is placed in a very specific location (which varies from one receiver to the next). If you have difficulty passing the test, try running it manually on the test machine with the emitter in different positions until you find the one that works for your device.

  • If you are testing your device on Windows Vista and your device is a composite USB device, you may encounter an error message while running the test. The error message you would receive is "Failed to set the DUT as the Active Receiver". The work-around for this specific scenario is to edit the job parameters when running the test and pass in '-a' in the override parameter. This will skip the Active Receiver code and allow you to test your composite device.


Windows Media Center Remote Control Logo Program Certification Overview

The procedures that are presented in this section outline the process for testing your Windows Media Center remote control for proper functionality with the Microsoft Windows operating system. These procedures test your product for correct functionality using the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that 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:

  • Preparing: The preparing topics describe how to configure the system or systems for Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

  • Troubleshooting: The troubleshooting section provides information to diagnose failures, warnings and/or errors with the test.

Windows 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 Windows Media Center Remote Control Certification Tool to verify button functionality. See step 1 of the Running the Windows Media Center Remote Control Certification Tests for more details.

The 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 device, see the Running the Windows Media Center Remote Control Certification Tests.

Run time: approximately 15 minutes

Hardware Requirements

The following hardware is required for Windows Media Center remote control logo 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.

  • Remote control being certified

  • Any supported Windows Media Center IR Receiver or a receiver designed for the remote

  • Client system running and the DTM client

Software Requirements

The following software is required to run the Windows Media Center remote control logo testing component of the WLK:

  • 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.

Tester Knowledge Requirements

To run the Windows Media Center Remote Control Logo Program Certification program, testers must know how to:

  • Install and run the WLP/DTM.

  • Install an appropriate receiver on a client system.

  • Gain access to the client system.

  • Press remote control buttons as requested in the prompt.

This section includes:

Preparing for Windows Media Center Remote Control Certification

Running the Windows Media Center Remote Control Certification Tests

Troubleshooting the Windows Media Center Remote Control Certification Program


Preparing for Windows Media Center Remote Control Certification

Before you attempt to logo a Windows Media Center remote control through WLP, please contact Microsoft as prescribed in step 1 of Running the Windows Media Center Remote Control Certification Tests. (You can omit 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.

Test system configuration

To configure the test systems for Media Center remote control logo testing, do the following:

Connect an approved Windows Media Center IR receiver to the client system.


Running the Windows Media Center Remote Control Certification Tests

The Remote Control Button Verification test relies on drivers that ship with Windows so you do not need to supply an INF file for the logo testing process. Additionally, note that when you use the Submission Wizard in Device Test Manager (DTM) to set up your logo tests, the name of the test is displayed as Input > MCE Remote Control. When you schedule this test, it automatically schedules the Windows Media Center test utility that is explained in Step 2 in the following procedure.

Important You must plug the receiver unit into the client computer before you turn the computer on. Then create a new submission before you begin the test instructions that follow in Step 2.

Step 1: Remote Control Design Verification

  1. Please send email to MCE Remote Control Logo Program with a PDF of the remote control design to be certified.

  2. After design approval, please send the final function sample, along with the Key Logo License agreement for the remote control to be certified. You will receive and approval code which you will be prompted for when you run the Windows Media Center Remote Control certification test.

  3. Save the returned form in a known location. (This form will be digitally signed by Microsoft, and the signature will be used to verify authorization in step 8 in Remote Control Button Verification procedure.)

Step 2: Remote Control Button Verification

  1. Make sure the receiver is still plugged into the client computer.

  2. Launch the Remote Control Self-Certification Tool.

  3. Two options will be available:

    --Self-Test Tool: Verifies button functionality without submitting the result for logo certification

    --Self-Certification Tool: testing of button functionality will be performed as well as additional information about the remote control that is 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 that you are testing and where the remote control will be released.

    Note The approval received in step 3 in Remote Control Design Verification procedure will need to be included at this point.

  5. A dialog will appear asking to verify the signal. Press any button on the remote control in order to test the signal.

  6. The remainder of the tool is in wizard format which will walk through verification of the signal and then verification of each button's functionality.

    The "Press the following button on your remote control" field displays 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, this button brings up the Testing Not Complete dialog box. Within this dialog, if OK is selected, the user is taken to the next page,this action will be treated as a failure for the purpose of certification since not all buttons have been tested. Otherwise, the user will 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 and treated as a failure for the purpose of certification.

  7. Once all buttons have been verified, you will be presented with an un-official pass/failure result. Click Finish to exit the test and complete the test in the DTM.


Troubleshooting the Windows Media Center Remote Control Certification Program

The program used to test the remote control can be run separately outside the logo process to isolate any problems with the remote control prior to submitting the logo request.


Windows Touch Testing Overview

The procedures that are presented in this section outline the process for testing your Windows Touch device for correct functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that 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 Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Windows Touch Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested.

Run time: 1 hours

Hardware Requirements

The following hardware is required for Windows Touch 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.

  • The device to be tested.

  • A computers with the following:

    • One x86-based or x64-based processor with a minimum speed of 450 MHz

    • 512 MB of RAM

    • One AGP or PCI display adapter

  • One 17-inch monitor with at least 1024x768x24 bits per pixel (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.

Software Requirements

The following software is required to run the Windows Touch tests:

  • One of the following operating systems:
    • Windows 7

  • Any drivers that are not shipped with the operating system

  • The current release of the Windows Logo Kit (WLK)

Tester Knowledge Requirements

To run the Windows Touch tests, testers must know how to accomplish the following tasks:

  • Install the Windows Touch hardware

  • Install the manufacturer-supplied device driver, if necessary.

  • Install the operating system from the product DVD.

  • Install the WLK.

In addition to the standard self-certification submission for devices through WHQL, Microsoft requires a validation certification test pass to be run at the Microsoft Windows Touch Test Lab (WTTL) facility before Windows Touch Logo Certification is approved. (WTTL validation is not necessary for system certification if the device has been previously logo'd and the hardware and drivers are unchanged.)

The Windows Touch test application was designed to be executed in a variety of lab environments, including those with precision guidance systems and those where testing is freehand. Accuracy and offset measurements on certain tests have been relaxed to allow freehand input on high quality hardware and produce results that meet the overall requirements. See individual tests below for details of the metrics tested on any given page of the test.

Contact devices and fingers

The tests are intended to be executable by a human operator using a finger as contact. If test operators prefer to use a stylus, we recommend a rounded stylus that is 12.5mm in diameter for the majority of the tests, and a smaller stylus for the corner point tests.

Freehand operation

For point tests, operators should align the contact device(s) with the required target points, and place contact onto the digitizer in a movement that is perpendicular to the touch screen. To reduce issues of parallax, place the eye directly behind the contact device so that eye, contact device, and target point are all in a line perpendicular to the screen. Movement off the screen should be in the opposite direction. For the press and hold tests, keep the contact device steady while you touch the screen.

For line tests, follow the point test guidance above when beginning and ending the line trace at the indicated start and end points. Note that the starting and ending points of contact in themselves are not measured for accuracy, rather the entry and exit points of motion into the measured portion of the line, as indicated by the "funnel" symbols. Trace the line as closely as possible to the target line. Accurate portions of the traced line are shown in green and inaccurate portions in red. Contact before or after entry to the measured portion of the line is indicated in yellow; these parts of the line are not measure for accuracy.

Using a guidance system

If operators already have existing mechanical or jig-based systems in their testing laboratories, they are encouraged to use those systems to complete the logo tests. For individual test operations, the same guidance applies as for the freehand tests, although placement of contacts for the point and line tests can be mechanically aided by jig fixtures, stencils, templates, or other means. The following lines are plotted in the same place on every test to aid mechanical alignments:

  • Horizontal 35mm from the top

  • Horizontal on center

  • Horizontal 35mm from the bottom

  • Vertical 35 mm from the left

  • Vertical on center

  • Vertical 35 mm from the right

Windows Touch Test Lab procedures

When the Windows Touch Test Lab operators receive a submission, they first attempt to pass the tests freehand, with the aid of a straightedge. If this is not possible, the Windows Touch Test Lab will use a more structured guidance system, such as a set of machined jigs, and will attempt each test page until a valid pass is achieved, up to a maximum of 3 times. A 12.5mm stylus will also be used (with the exception of the four initial corner tests, where a smaller stylus will be used). In all cases, the Windows Touch Test Lab operators will follow the instructions as detailed in these documents. For more details of the testing apparatus as used in the WTTL, please contact tab-ext@microsoft.com.


Preparing for the Windows Touch 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 Windows Touch Testing Overview.

Many of the tests in the Windows Logo 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 How to turn on automatic logon in Windows XP.

Test System Configuration

To configure the test system for Windows Touch device testing:

  1. Install the appropriate Microsoft Windows operating system on the test system.

  2. Install the hardware to be tested on the test system.

  3. Install the manufacturer-supplied device driver, if necessary, on the test system.

  4. Set up the device configuration that is specified in the Fidelity Test Setup section.

  5. Check that the capture device functions properly on the test system.

  6. If appropriate, enable autologon functionality.

  7. Set up DTM.

  8. After you set up the DTM controller and create a machine pool, move the client machine to that pool.


Running the Windows Touch Tests

To run the logo tests and create a submission cabinet file to send to WHQL for logo approval, either run the logo tests from a previously saved device job schedule file, or create a new submission. These procedures are as follows:

Run the Logo Tests from a Previously Saved Device Job Schedule File

  1. Open a Device Console window from the Explorers menu.

  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.

Use the Create New Submission Wizard to Select and Run Logo Tests

  1. Open a Device Console window from the Explorers menu.

  2. Select your DTM controller from the drop-down box at the upper left of the Device Console window.

  3. Click the Submission option button in the View By section.

  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 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 a Device Submission, then select the logo program "Windows Touch", 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 systems to use for the submission, and then click Next.
    6. If the device has its own drivers, select the location in the Driver Install File control and then click Finish.

  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 that you selected.

  7. 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 button.
  8. Monitor logo test progress:
    1. Observe logo test progress by using Job Monitor, and manually intervene if required by test.
    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.

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


Troubleshooting the Windows Touch Testing

Understanding the accuracy requirement

For a single touch on a stationary contact point (a contact made when no other contacts are present), the INPUT-0046 accuracy requirement requires that the contact position reported must be within 2.5mm of the target point. For a single touch that traces a line, circle or other pre-determined pattern, the contact data reported must be within 2.5 mm of the target pattern, with an offset from the pattern that varies no more than 1mm for every 10mm of travel, and without interruption to the pattern.

Offset variance is the amount of variation in the offset of the traced line from the target line, and this should be no more than 1mm per 10mm of travel. This is in effect allows a sort of drift (or moving "jitter boundary") of up to 10 percent. The following figure is an example of how this might look in practice.

Diagram of a straight vertical line, a freehand wavy line beside it, and metrics showing the boundary and variance allowed for the freehand line

Figure 1. Accuracy of a single touch trace

The thick blue line is the target line. The red line was produced by a tester attempting to trace the target line on the screen. In order to pass this test, the red line has to meet all of the following conditions:

  • The line falls completely within the 2.5 mm accuracy boundary (as marked by the outer dotted green line).

  • For any given 10 mm along its length, the offset variance - the maximum difference in offset from the blue line (as marked by the inner dotted green line over the first 10 mm) - must be no greater than 1 mm.

  • The line must be intact and without interruption.

Note The offset variance will be measured not just on the first 10 mm of the pattern, but on overlapping 10 mm segments that will cover the whole pattern.

The same principles apply to additional contacts - contacts made when another finger is already touching the screen, or made simultaneously - but in this case there is twice as much room for maneuvering: 5 mm overall accuracy range and 2 mm offset variance per 10 mm.

Analyzing the Windows Touch log files

The Windows Touch test tool uses the UserText attribute of each <Msg> element to output touch-specific information.

Note The default attributes and sub-elements of the <Msg> elements are not included in the examples below.

  • Test 1 Sampling Rate

    The following messages indicate sampling rate logging per second for different contact IDs, in this case 63 and 60, for IDs 10 and 11 as reported by the digitizer:

    <Msg UserText="INFO: Sampling rate was 63 for 10 touch ID" ...> <Msg UserText="INFO: Sampling rate was 60 for 11 touch ID" ...>

    In the case where the sampling rate was insufficiently high, a further message of failure is logged, e.g.:

    <Msg UserText="INFO: Sampling rate was 49 for 10 touch ID"

    <Msg UserText="INFO: Sampling rate did not pass for contact ID 10 : Sampling rate was 49"

    The length of time that each contact is held is also logged in the following way:

    <Msg UserText="INFO: Contact ID 10 lasted for 10 sec" ...>

  • Test 2 Single Taps

    For each test case on the page, the target point and touch point locations in pixels are logged, and if the touch is within the accuracy boundary, success is logged:

    <Msg UserText="INFO: Point Shown for Test 2: Single Taps - Test Case 1: x:640 y:400"...>

    <Msg UserText="INFO: Point Touched for Test 2: Single Taps - Test Case 1: x:646 y:400"...>

    <Msg UserText="INFO:Test 2: Single Tap Test Passed for test case 1 - Test Pass"

    If the touch is outside the permitted accuracy boundary, the failure (and failing distance) is also logged:

    <Msg UserText="INFO: Point Shown for Test 2: Single Taps - Test Case 2: x:640 y:100" ...><Msg UserText="INFO: Point Touched for Test 2: Single Taps - Test Case 2: x:637 y:117" ...>

    <Msg UserText="INFO: Touch do not match the given point- Test Fail, Distance is 3.642690" ...><Msg UserText="INFO:Test 2: Single Tap - Touch did not match the given point for test case 2- Test Fail" ...>

  • Test 3 Single Press and Hold

    Accuracy of the touch point is one of the requirements for the Single Press and Hold tests, so the locations and pass/fail accuracy are logged just as for Test 2:

    <Msg UserText="INFO: Point Shown for Test 3: Single Press and Hold - Test 1: x:640 y:400" ...>

    <Msg UserText="INFO: Point Touched for Test 3: Single Press and Hold - Test 1: x:638 y:401" ...>

    <Msg UserText="INFO:Test 3: Single Press and Hold - Test Case 1 -Test Passed for Single Touch Press and Hold - Test Pass" ...>

    <Msg UserText="INFO: Point Shown for Test 3: Single Press and Hold - Test 2: x:10 y:10" ...><Msg UserText="INFO: Point Touched for Test 3: Single Press and Hold - Test 2: x:18 y:21" ...>

    <Msg UserText="INFO: Touch do not match the given point- Test Fail, Distance is 2.870119" ...>

    Jitter is also measured over the period of contact, so jitter and/or not holding down the contact long enough will result in log message similar to the following:

    <Msg UserText="INFO: Jitter Occurred at 18 21 " ... >

    or

    <Msg UserText="INFO:Test 3: Single Press and Hold - Test Case 2 -Touch did not last for the specified time for single touch press and hold point - Test Fail"...>

  • Test 4 Double Tap

    Logging is as for Test 2 Single Taps, e.g.

    <Msg UserText="INFO: Point Shown for Test 4: Double Taps: x:640 y:400" ...><Msg UserText="INFO: Point Touched for Test 4: Double Taps: x:636 y:409" ... >

    <Msg UserText="INFO:Test 8: Double Taps Test Passed - Test Pass" ...>

    or

    <Msg UserText="INFO: Point Shown for Test 4: Double Taps: x:640 y:400" ...>

    <Msg UserText="INFO: Point Touched for Test 4: Double Taps: x:738 y:506" ...><Msg UserText="INFO: Touch do not match the given point- Test Fail, Distance is 30.433714" ...>

  • Test 5 Multi-touch Points

    Logging for multi-touch points is similar to Test 2, with the following target and touch information:

    <Msg UserText="INFO: Point Shown for Test 5: Multi-touch points - Test Case 1 - Finger 1: x:160 y:200" ...><Msg UserText="INFO: Point Touched for Test 5: Multi-touch points - Test Case 1 - Finger 1: x:326 y:100" ...>

    <Msg UserText="INFO: Point Shown for Test 5: Multi-touch points - Test Case 1 - Finger 2: x:320 y:100" ...>

    <Msg UserText="INFO: Point Touched for Test 5: Multi-touch points - Test Case 1 - Finger 2: x:173 y:201" ...>

    <Msg UserText="INFO:Test 5: Multi-touch points passed for test case 1." CA="30593109" ...>

    Failure is possible due to non-simultaneity (sequential input) or to inaccuracy.

    Non-simultaneous input:

    <Msg UserText="INFO: Point Shown for Test 5: Multi-touch points - Test Case 2 - Finger 1: x:160 y:700" ...>

    <Msg UserText="INFO: Point Touched for Test 5: Multi-touch points - Test Case 2 - Finger 1: x:166 y:694" ...>

    <Msg UserText="INFO: Point Shown for Test 5: Multi-touch points - Test Case 2 - Finger 2: x:320 y:600" ...><Msg UserText="INFO: Point Touched for Test 5: Multi-touch points - Test Case 2 - Finger 2: x:327 y:597" CA="38221429" LA="38221504" ...>

    <Msg UserText="INFO:Test 5: Multi-touch points failed for test case 2.Time difference between contacts more than 30 milliseconds" ...>

    Inaccurate input:

    <Msg UserText="INFO: Point Shown for Test 4: Multi-touch points - Test Case 3 - Finger 1: x:480 y:400" ...>

    <Msg UserText="INFO: Point Touched for Test 4: Multi-touch points - Test Case 3 - Finger 1: x:507 y:456" ...>

    <Msg UserText="INFO: Point Shown for Test 4: Multi-touch points - Test Case 3 - Finger 2: x:640 y:400" ...><Msg

    UserText="INFO: Point Touched for Test 4: Multi-touch points - Test Case 3 - Finger 2: x:704 y:397" ...><Msg UserText="INFO:Test 4: Multi-touch points failed for test case 3." CA="48949421" LA="48949527" ... >

  • Test 6 Press and Tap

    The Power Tap test logs a pass/fail based on the accuracy of the touches, and jitter of the first touch, e.g. for a pass:

    <Msg UserText="INFO:Test 6: Press and Tap Test:Test Pass" ...>

    or for a fail if there is jitter on the first contact:

    <Msg UserText="INFO:Test 6: Press and Tap:Jitter occurred for point 1 - Test Fail" ...>

    or for a fail if there is an accuracy problem:

    <Msg UserText="INFO:Test 6: Press and Tap: You did not touch all points - Test Fail" ...>

  • Test 7 Straight Line Accuracy

    Detailed indications of the pass/fail areas of lines traced are visible on the screen, where green indicates an accurate trace, red indicates an inaccurate trace, and yellow indicates unmeasured portions of the trace. Given the availability of this information in graphical form, the log files hold simpler pass/fail information:

    <Msg UserText="INFO:Test 7: Straight line accuracy - Test Case 1 traced successfully" ...>

    or

    <Msg UserText="INFO:Test 7: Straight line accuracy - Test Case 2 Could not trace all points - Test Fail" ...>

  • Test 8 Maximum Touch Lines

    Pass/fail for each line is logged, e.g.

    <Msg UserText="INFO:Test 8: Maximum contact support test - Line 1 traced correctly." ...><Msg UserText="INFO:Test 8: Maximum contact support test- Line 2 not traced correctly. Test Fail" ...>

  • Note Each line in this case is treated as a separate test item for the purposes of overall pass/fail calculations.

  • Test 9 Multi-Touch Lines

    Logging is as for Test 5, e.g.

    <Msg UserText="INFO:Multi touch lines traced successfully for lines 1 " ...>

    or

    <Msg UserText="INFO:Could not trace all points for multi-touch lines 6" ...>

    Note Drawing the lines sequentially will also result in the failure message, and an indication on screen.

  • Test 10 Line Accuracy Velocity

    The screen display shows as for Test 5 Single Touch Lines, and the log file holds simple Pass/Fail information:

    <Msg UserText="INFO:Test 10: Line Accuracy Velocity Test - Passed" ... >or

    <Msg UserText="INFO:Test 10: Line Accuracy Velocity Test - Failed" ...>

    Contact needs to remain within the moving box while it is traveling along the line, and points at which the contact is outside the line will be displayed on the screen in red (similarly for contacts that are outside the accuracy boundary).

  • Test 11 Single Touch Arcs

    Logging is for as for Test 5, e.g.

    <Msg UserText="INFO:Test 11: Arc accuracy - Test Case 1 traced successfully" ...>

    or

    <Msg UserText="INFO:Test 11: Arc accuracy - Test Case 2 could not traced successfully" ...>

  • Test 12 Pivot

    The pivot test logs as for Test 7 Multi-Touch lines. Note that a failure may be due to inaccuracy of the traced arc, or of inaccuracy of the pivot point.

    <Msg UserText="INFO:Test 12:Pivot Test - Test passed." ... >

    or

    <Msg UserText="INFO:Test 12:Pivot Test : Could not trace all points - Test Fail." ...>

  • Test 13 Multi-Touch Arcs

    Logging is as for Test 7 Multi-Touch lines

    <Msg UserText="INFO:Test 13: Multi-touch arc accuracy - Traced Successfully - Test Pass"...>or

    <Msg UserText="INFO:Test 13: Multi-touch arc accuracy - Could not Traced Successfully - Test Fail" ...>

  • Test 14 Ghost Points

    Simple pass/fail info is logged for the Ghost Points test, i.e.:

    <Msg UserText="INFO:Test 14: Ghost points - Ghost test passed" ...>or

    <Msg UserText="INFO:Test 14: Ghost points - Test Fail" ...>

  • Test pass completion

    A number of messages are logged that collate the overall test pass information in terms of tests attempted, completed, passed, and failed. For any difficulties understanding the messages, please email tab-ext@microsoft.com with your query and a sample log file.


Input Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


Card Minidriver Certification Kit

Type: Automated Test

Overview

This test tool verifies the operation of smart card minidrivers and associated cards. Smart card minidrivers are software DLLs that are loaded by the Microsoft Base Cryptographic Service Provider (Base CSP) and the Microsoft Smart Card Key Storage Provider (SCKSP) that enable access to the functionality of the associated smart card. For smart card vendors, these minidrivers provide a simpler way to implement smart card functionality on Microsoft Windows operating systems than by developing a traditional Cryptographic Service Provider (CSP). (Historically smart card minidrivers were also referred to as smart card modules or smartcard card modules.)

Details

The Card Minidriver Certification Kit performs functional, stress, performance, and reliability testing on a smart card minidriver. This kit calls the Microsoft BaseCSP and the Microsoft Smart Card Key Storage Provider and accesses the card minidriver methods directly to test the correctness of operation of the card minidriver and the associated card. The kit also uses the Smart Card Resource Manager to access the card directly.

Run Time: 6 hours
Log File: cmck_log.xml
System Restart Required: No
Supported operating systems for Logo or Signature:

  • Windows 7

  • Windows Server 2008

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • 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:

  • WHQL-certified smart card readers

Processor

  • x86

  • x64

  • Itanium

Running Card Minidriver Certification Kit

The test exists in Driver Test Manager (DTM) as a single job, although you can run the tool from outside of the DTM environment as well. Copy the binaries from the location that is specified below to a directory of your choice and you can run the test tool from there. You might also need to copy the Wttlog.dll shared library to your run directory. This DLL is installed with the DTM client.

Running the test tool outside of the DTM enables greater flexibility than running through the DTM because you can select tests individually. For more information, see the command line description later in this document.

If you are running the test from within the DTM, you need only one client computer. The DTM documentation explains how to set up the DTM controller, DTM Studio, and DTM client machines.

The following information applies to the machine that the test is being run on, regardless of whether you are running the tests inside or outside the DTM environment.

To run the test, you must have your smart card minidriver installed on the computer and registered in the registry. (Also, for more information about certifying on a 64-bit version of the operating system, see the next section, "Certifying on a 64-bit version of the operating system"). And if your smart card device has the ISO 7816 ID-1 form factor, you must use a PC/SC compliant, WHQL-certified smart card reader for certification.

When you run this test on Windows Server 2003 or Windows XP, you will first need to install MSXML 6.0 on the client computer.

To run the tests, you must have two identical smart cards on the computer, and both must be in the prepared state, where prepared is defined by the Smart Card Minidriver Specification for Windows Base Cryptographic Service Provider (Base CSP) and Smart Card Key Storage Provider (KSP).

The tests that are run depend on the capabilities of the smart card minidriver. The capability of the smart card minidriver can be defined for the test tool in a specific configuration file called cmck_config.xml, which you must put in the C:\SmartCardMinidriverTest directory. The description of this file and a sample are provided below.

In a typical test run, if no configuration file is found, the test will ask you for confirmation to proceed by using default values. For a logo submission however, you must supply a configuration file that matches the capability of your minidriver and card combination.

The default key values are as follows:

  • The default user pin is 0000.

  • The default administration key for challenge/response is all zeros.

Certifying on a 64-bit version of the operating system

When you certify on a 64-bit version of the operating system, you must also have the 32-bit version of your minidriver DLL installed on the system. You can put the DLL in the %systemroot%\syswow64 subdirectory. You must put registry entries for the 32-bit version of the DLL under HKEY_LOCAL_MACHINE\SOFTWARE\wow6432Node\Microsoft\Cryptography\Calais\SmartCards.

When a 32-bit application that uses the minidriver is executed, it loads the 32-bit version of the minidriver.

INF file for a smart card minidriver

When you make a certification submission, you must supply an .inf file. Here is the sample .inf file for x86 architecture:

NOTE: Some of the changes that you will have to make are marked in yellow.

[Version]
Signature="$Windows NT$"
Class=SmartCard
ClassGuid={990A2BD7-E738-46c7-B26F-1CF8FB9F1391}
Provider=%ProviderName%
CatalogFile=delta.cat
DriverVer=06/21/2006,6.1.6473.1

[DefaultInstall]
CopyFiles=System32_CopyFiles
AddReg=MiniDriver_AddReg

[Manufacturer]
%ProviderName%=CompanyName,NTx86,NTx86.6.1

[CompanyName.NTx86]
%ScSuperCardDeviceName%=ScSuperCard_Install,SCFILTER\CID_51FF0800

[CompanyName.NTx86.6.1]
%ScSuperCardDeviceName%=ScSuperCard61_Install,SCFILTER\CID_51FF0800

[SourceDisksFiles]
supercm.dll=1

[SourceDisksNames]
1 = %MediaDescription%

[ScSuperCard_Install.NT]
CopyFiles=System32_CopyFiles
AddReg=MiniDriver_AddReg

[ScSuperCard61_Install.NT]
CopyFiles=System32_CopyFiles
AddReg=MiniDriver_AddReg

[SCSuperCard61_Install.NT.Services]
AddService = UMPass, 0x00000002, UMPassService_Install

[UMPassService_Install]
DisplayName    = %umpass.SVCDESC%     ; Friendly Name of the Service
ServiceType    = 1                    ; SERVICE_KERNEL_DRIVER
StartType      = 3                    ; SERVICE_DEMAND_START
ErrorControl   = 1                    ; SERVICE_ERROR_NORMAL
ServiceBinary  = %12%\umpass.sys
LoadOrderGroup = Extended Base

[System32_CopyFiles]
supercm.dll

[MiniDriver_AddReg]
HKLM, %SmartCardName%,"ATR",0x00000001,3b,04,51,ff,08,00
HKLM, %SmartCardName%,"ATRMask",0x00000001,ff,ff,ff,ff,ff,ff
HKLM, %SmartCardName%,"Crypto Provider",0x00000000,"Microsoft Base Smart Card Crypto Provider"
HKLM, %SmartCardName%,"Smart Card Key Storage Provider",0x00000000,"Microsoft Smart Card Key Storage Provider"
HKLM, %SmartCardName%,"80000001",0x00000000,%SmartCardCardModule%

[DestinationDirs]
System32_CopyFiles=10,system32

[FriendlyName]
ScFriendlyName="Super Card"

; =================== Generic ==================================

[Strings]
ProviderName="ACME"
MediaDescription="Super Card Mini Driver Installation Disk"
SCSuperCardDeviceName="Super Card Mini-driver"
SmartCardName="SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\Super Card"
SmartCardCardModule="supercm.dll"
umpass.SVCDESC = "Microsoft UMPass Driver"

Inf file sample for x64 architecture:

[Version]
Signature="$Windows NT$"
Class=SmartCard
ClassGuid={990A2BD7-E738-46c7-B26F-1CF8FB9F1391}
Provider=%ProviderName%
CatalogFile=delta.cat
DriverVer=06/21/2006,6.1.6473.1

[DefaultInstall]
CopyFiles=System32_CopyFiles
CopyFiles=Syswow64_CopyFiles
AddReg=MiniDriver_AddReg

[Manufacturer]
%ProviderName%=CompanyName,NTamd64,NTamd64.6.1

[CompanyName.NTamd64]
%ScSuperCardDeviceName%=ScSuperCard_Install,SCFILTER\CID_51FF0800

[CompanyName.NTamd64.6.1]
%ScSuperCardDeviceName%=ScSuperCard61_Install,SCFILTER\CID_51FF0800

[SourceDisksFiles]
supercm64.dll=1
supercm.dll=1

[SourceDisksNames]
1 = %MediaDescription%

[ScSuperCard_Install.NT]
CopyFiles=System32_CopyFiles
CopyFiles=Syswow64_CopyFiles
AddReg=MiniDriver_AddReg

[ScSuperCard61_Install.NT]
CopyFiles=System32_CopyFiles
CopyFiles=Syswow64_CopyFiles
AddReg=MiniDriver_AddReg

[SCSuperCard61_Install.NT.Services]
AddService = UMPass, 0x00000002, UMPassService_Install

[UMPassService_Install]
DisplayName    = %umpass.SVCDESC%     ; Friendly Name of the Service
ServiceType    = 1                    ; SERVICE_KERNEL_DRIVER
StartType      = 3                    ; SERVICE_DEMAND_START
ErrorControl   = 1                    ; SERVICE_ERROR_NORMAL
ServiceBinary  = %12%\umpass.sys
LoadOrderGroup = Extended Base

[System32_CopyFiles]
supercm.dll,supercm64.dll

[Syswow64_CopyFiles]
supercm.dll

[MiniDriver_AddReg]
HKLM, %SmartCardName%,"ATR",0x00000001,3b,04,51,ff,08,00
HKLM, %SmartCardName%,"ATRMask",0x00000001,ff,ff,ff,ff,ff,ff
HKLM, %SmartCardName%,"Crypto Provider",0x00000000,"Microsoft Base Smart Card Crypto Provider"
HKLM, %SmartCardName%,"Smart Card Key Storage Provider",0x00000000,"Microsoft Smart Card Key Storage Provider"
HKLM, %SmartCardName%,"80000001",0x00000000,%SmartCardCardModule%
HKLM, %SmartCardNameWOW64%,"ATR",0x00000001,3b,04,51,ff,08,00
HKLM, %SmartCardNameWOW64%,"ATRMask",0x00000001,ff,ff,ff,ff,ff,ff
HKLM, %SmartCardNameWOW64%,"Crypto Provider",0x00000000,"Microsoft Base Smart Card Crypto Provider"
HKLM, %SmartCardNameWOW64%,"Smart Card Key Storage Provider",0x00000000,"Microsoft Smart Card Key Storage Provider"
HKLM, %SmartCardNameWOW64%,"80000001",0x00000000,%SmartCardCardModule%

[DestinationDirs]
System32_CopyFiles=10,system32
Syswow64_CopyFiles=10,syswow64

[FriendlyName]
ScFriendlyName="Super Card"

; =================== Generic ==================================

[Strings]
ProviderName="ACME"
MediaDescription="Super Card Mini Driver Installation Disk"
SCSuperCardDeviceName="Super Card Mini-driver"
SmartCardName="SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\Super Card"
SmartCardNameWOW64="SOFTWARE\Wow6432Node\Microsoft\Cryptography\Calais\SmartCards\Microsoft Virtual Card"
SmartCardCardModule="supercm.dll"
SmartCardCardModule64="supercm64.dll"
umpass.SVCDESC = "Microsoft UMPass Driver"

Smart Card Minidriver Configuration File Description (cmck_config.xml)

CMCK_config.xml consists of below sections for V5, V6, and V7, depending on the versions V5/V6/V7 your minidriver supported. Please note: V5/V6/V7 keywords are uppercased.

<CMCKConfig>

<V5>

.........

</V5>

<V6>

.........

</V6>

<V7>

.........

</V7>

</CMCKConfig>

Each section is filled up with the XML tags described below. Please also note each section may have different settings which depends on what the minidriver supports for that versions.

You can set the following values in each section of the configuration file (in the structure as shown):

  • <Version> is a mandatory field that defines the configuration file's version number. Currently, the expected version is "2" of the CMCK XML configuration file for V6 and V7 sections, and "1" for V5 section.

  • <CardDefaults> contains parameters that are used both for the certification run and for regular test runs.

    • <DefaultPins> - pin values to be used for authentication-related functions

      <PinEntry><RoleID> - allowed value: 1 - 7

      <PinEntry><Type> - allowed value: "AlphanumericPinType", "ChallengeResponsePinType", "EmptyPinType", "ExternalPinType"

      <PinEntry><Value> - list of space-separated hex bytes of the pin. Default value: "0x30 0x30 0x30 0x30" (i.e. "0000")

      <PinEntry><Blocking> [BOOLEAN] - states if the card supports blocking the card for this type of user when the wrong pin is presented too many times. Default "True".

      <PinEntry><Linking> [BOOLEAN] - states if this pin is linked to another pin, i.e changing one pin will make the other one changed. Default "False".

      <PinEntry><AllowZeroLength> [BOOLEAN] - states if the card allows the pin to be empty. Default "False".

  • <CardSupports> -defines optional features that are supported by the card or card minidriver, such as algorithms, key types, and so on. The test will cover the supported features.
    • <MinimumVersion> [DWORD] contains the minimum version of the context CARD_DATA structure that the card minidriver supports. For more information, see the Smart Card Minidriver specification. The allowed value is "4," "5," "6," "7".
    • <CurrentVersion> [DWORD] contains the version of the context CARD_DATA structure for which the card minidriver was designed. For more information, see the Smart Card Minidriver specification. The allowed value is "5," "6," "7".
    • <LoadingUnderCAPI> [BOOLEAN] is "True" if the card minidriver supports being loaded under CAPI and is "False" otherwise.
    • <LoadingUnderCNG> [BOOLEAN] is "True" if the card minidriver supports being loaded under CNG and is "False" otherwise. Note that at least one of the two attributes must be "True" (CAPI and/or CNG).
    • <KeyImport> [BOOLEAN] is "True" if the card minidriver supports key import and is "False" otherwise.
    • <KeyTypes> contains space-separated list of key types that the card minidriver supports. The allowed values are "AT_ECDH_P256", "AT_ECDH_P384", "AT_ECDH_P521", "AT_ECDSA_P256", "AT_ECDSA_P384", or "AT_ECDSA_P521" for ECC keys and "AT_SIGNATURE" or "AT_KEYEXCHANGE" for RSA keys.
    • <OnCardPadding> [BOOLEAN] is "True" if on-card padding is supported and is "False" otherwise.
    • <PaddingAlgorithms> contains a space-separated list of supported on-card padding algorithms (only valid when <OnCardPadding> is "True"). The allowed values are "CARD_PADDING_NONE", "CARD_PADDING_PKCS1", and "CARD_PADDING_PSS".
    • <SignHashAlgorithms> contains a space-separated list of hash algorithms that the card minidriver supports for signing (aiHashAlg in the CARD_SIGNING_INFO structure). Allowed values are "CALG_MD2", "CALG_MD4", "CALG_MD5", "CALG_SHA", "CALG_SHA1", "CALG_SHA_256", CALG_SHA_384" and CALG_SHA_512". For more details, see the Smart Card Minidriver specification.
    • <SignHashFlags> contains a space-separated list of CryptSignHash flags that the card minidriver supports. The allowed values are "CRYPT_NOHASHOID" and "CRYPT_X931_FORMAT".
    • <SignReturnBufferSize> [BOOLEAN] is "True" when the card minidriver supports the CARD_BUFFER_SIZE_ONLY value for dwSigningFlags in the CARD_SIGNING_INFO structure. For more information, see the Smart Card Minidriver specification.
    • <KDFTypes> contains a space-separated list of key derive functions that the card minidriver supports. The allowed values are "HASH", "HMAC", "TLS_PRF", and "SP800_56A_CONCAT". For more information, see the Smart Card Minidriver specification.
    • <KDFHashAlgorithms> contains a space-separated list of hash algorithms that the card minidriver supports for the key derivation functions (KDF). The Smart Card Minidriver specification contains more details. The allowed values are defined in the bcrypt.h header file and are the values for BCRYPT_XXXX_ALGORITHM defines (for example, "SHA256" (BCRYPT_SHA256_ALGORITHM) or "MD5" (BCRYPT_MD5_ALGORITHM)).
    • <Uses2Key3DES> [BOOLEAN] is "True" if the card minidriver ONLY supports 2 key 3DES. When this value is "False", it indicates the card minidriver use default 3 key 3DES. Default value is "False".
    • <KDFHMACFlag> [BOOLEAN] is "True" if the card minidriver supports the BCRYPT_KDF_HMAC key derive function with the KDF_USE_SECRET_AS_HMAC_KEY_FLAG flag (see the Crypto Next Generation (CNG) documentation available on MSDN CNG for details). When this value is "False", the test will provide an explicit HMAC key and will not set the KDF_USE_SECRET_AS_HMAC_KEY_FLAG flag for affected tests.
    • <ChallengePadding>[BOOLEAN] is "True" if the return of card challenge data contains a padding bit. Default value is "False".
    • <SupportsCardGetChallenge> [BOOLEAN] - "True" if CM supports CardGetChallenge API (this is used for read only cards).
    • <SupportsCardAuthenticateChallenge> [BOOLEAN] - "True" if CM supports CardAuthenticateChallenge API (this is used for read only cards).
    • <SupportsCardGetChallengeEx> [BOOLEAN] - "True" if CM supports CardGetChallengeEx API (this is used for read only cards).
    • <SupportsCardUnblockPin> [BOOLEAN] - "True" if CM supports CardUnblockPin API (this is used for read only cards).
    • <SupportsCardChangeAuthenticator> [BOOLEAN] - "True" if CM supports CardChangeAuthenticator API (this is used for read only cards).
    • <SupportsCardChangeAuthenticatorEx> [BOOLEAN] - "True" if CM supports CardChangeAuthenticatorEx API (this is used for read only cards).
  • <TestSuiteDefaults> contains parameters that influence the test runs only. (The certification run uses its own default values.)
    • <INF> contains information about INF file used in smartcard PnP.
      • <INFFile> contains the location and file name for the smartcard PnP INF file, which matches the smartcard/minidriver to be tested. This is mandatory for all minidrivers other than in-box PIV/GICS class minidriver.
    • <Logging> contains logging options that apply to the test runs
      • <LogFile> contains the location and file name for the XML log file. The default is "CMCK_log.xml" (which means that the file will be created in the current directory). Note that the log file will be overwritten.
      • <LogToConsole> [BOOLEAN] is "True" when the logs will be displayed on the console along with writing to the log file. The default value is "True".
      • <CertifyLogLevel> specifies the log level (0, 1, or 2). 0 means minimal logging, 1 logs function entry and exit, and 2 means full logging. Full logging is always used when running tests individually and is mainly to help with development. When you are making a logo submission, we recommend setting the log level to 0.

Configuration File Structure

The following code example shows a sample configure file.

 <CMCKConfig>
<V6>
  <Version>2</Version>
 <CardDefaults>
 <DefaultPins>
 <PinEntry>
  <RoleID>1</RoleID>
  <Type>AlphaNumericPinType</Type>
  <Value>0x30 0x30 0x30 0x30</Value>
  <Blocking>True</Blocking>
  <AllowZeroLength>False</AllowZeroLength>
  </PinEntry>
 <PinEntry>
  <RoleID>2</RoleID>
  <Type>ChallengeResponsePinType</Type>
  <Value>0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00</Value>
  <Blocking>True</Blocking>
  <AllowZeroLength>False</AllowZeroLength>
  </PinEntry>
 <PinEntry>
  <RoleID>3</RoleID>
  <Type>AlphaNumericPinType</Type>
  <Value>0x30 0x30 0x30 0x30</Value>
  <Blocking>True</Blocking>
  <AllowZeroLength>False</AllowZeroLength>
  </PinEntry>
 <PinEntry>
  <RoleID>4</RoleID>
  <Type>AlphaNumericPinType</Type>
  <Value>0x30 0x30 0x30 0x30</Value>
  <Blocking>True</Blocking>
  <AllowZeroLength>False</AllowZeroLength>
  </PinEntry>
 <PinEntry>
  <RoleID>5</RoleID>
  <Type>AlphaNumericPinType</Type>
  <Value>0x30 0x30 0x30 0x30</Value>
  <Blocking>True</Blocking>
  <AllowZeroLength>False</AllowZeroLength>
  </PinEntry>
 <PinEntry>
  <RoleID>6</RoleID>
  <Type>AlphaNumericPinType</Type>
  <Value>0x30 0x30 0x30 0x30</Value>
  <Blocking>True</Blocking>
  <AllowZeroLength>False</AllowZeroLength>
  </PinEntry>
 <PinEntry>
  <RoleID>7</RoleID>
  <Type>AlphaNumericPinType</Type>
  <Value>0x30 0x30 0x30 0x30</Value>
  <Blocking>True</Blocking>
  <AllowZeroLength>False</AllowZeroLength>
  </PinEntry>
  </DefaultPins>
 <CardSupports>
  <MinimumVersion>4</MinimumVersion>
  <CurrentVersion>6</CurrentVersion>
  <LoadingUnderCAPI>True</LoadingUnderCAPI>
  <LoadingUnderCNG>True</LoadingUnderCNG>
  <KeyImport>True</KeyImport>
  <KeyTypes>AT_SIGNATURE AT_KEYEXCHANGE</KeyTypes>
  <OnCardPadding>False</OnCardPadding>
  <PaddingAlgorithms>CARD_PADDING_PKCS1</PaddingAlgorithms>
  <SignHashAlgorithms>CALG_MD5 CALG_SHA CALG_SHA1 CALG_SHA_256 CALG_SHA_384 CALG_SHA_512</SignHashAlgorithms>
  <SignHashFlags />
  <SignReturnBufferSize>True</SignReturnBufferSize>
  <KDFTypes>HASH</KDFTypes>
  <KDFHashAlgorithms>SHA1 SHA256 SHA384 SHA512</KDFHashAlgorithms>
  <KDFHMACflag>False</KDFHMACflag>

  <SupportsCardGetChallenge>True</SupportsCardGetChallenge>
  <SupportsCardAuthenticateChallenge>True</SupportsCardAuthenticateChallenge>
  <SupportsCardGetChallengeEx>True</SupportsCardGetChallengeEx>
  <SupportsCardUnblockPin>True</SupportsCardUnblockPin>
  <SupportsCardChangeAuthenticator>True</SupportsCardChangeAuthenticator>
  <SupportsCardChangeAuthenticatorEx>True</SupportsCardChangeAuthenticatorEx>
  </CardSupports>
  </CardDefaults>
 <TestSuiteDefaults>
      <INF>
 <INFFile>C:\SmartcardMinidriverTest\minidriver.inf</INFFile>
      </INF>
 <Logging>
  <LogFile>CMCK_log.xml</LogFile>
  <LogToConsole>True</LogToConsole>
  </Logging>
 <TestParams>
 <TestParam>
  <Test>MultiThreaded</Test>
  <Name>t</Name>
  <Value>5</Value>
  </TestParam>
 <TestParam>
  <Test>MultiThreaded</Test>
  <Name>n</Name>
  <Value>5</Value>
  </TestParam>
 <TestParam>
  <Test>NonRepeatingChallenge</Test>
  <Name>n</Name>
  <Value>300</Value>
  </TestParam>
  </TestParams>
  </TestSuiteDefaults>
</V6>

<V5>
  <Version>1</Version>

  <CardDefaults>
    <DefaultPins>
        <PinEntry>
            <Type>User</Type>
            <Value>0x30 0x30 0x30 0x30</Value>
            <Blocking>True</Blocking>
            <AllowZeroLength>False</AllowZeroLength>
        </PinEntry>
    </DefaultPins>

    <DefaultKeys>
        <KeyEntry>
            <Type>Admin</Type>
            <Algorithm>3DES</Algorithm>
            <Mode>ECB</Mode>
            <Blocking>True</Blocking>
            <Value>0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00</Value>
        </KeyEntry>
    </DefaultKeys>

    <CardSupports>
        <MinimumVersion>4</MinimumVersion>
        <CurrentVersion>6</CurrentVersion>
        <LoadingUnderCAPI>True</LoadingUnderCAPI>
        <LoadingUnderCNG>True</LoadingUnderCNG>
        <KeyImport>True</KeyImport>
        <KeyTypes>AT_SIGNATURE AT_KEYEXCHANGE</KeyTypes>
        <OnCardPadding>False</OnCardPadding>
        <PaddingAlgorithms>CARD_PADDING_NONE</PaddingAlgorithms>
        <SignHashAlgorithms>CALG_MD5 CALG_SHA CALG_SHA1</SignHashAlgorithms>
        <SignHashFlags>CRYPT_NOHASHOID</SignHashFlags>
        <SignReturnBufferSize>False</SignReturnBufferSize>
        <KDFTypes>HASH</KDFTypes>
        <KDFHashAlgorithms>SHA1 SHA256 SHA384 SHA512</KDFHashAlgorithms>
        <KDFHMACflag>False</KDFHMACflag>
    </CardSupports>
  </CardDefaults>

  <TestSuiteDefaults>
      <INF>
 <INFFile>C:\SmartcardMinidriverTest\minidriver.inf</INFFile>
      </INF>
      <Logging>
          <LogFile>CMCK_log.xml</LogFile>
          <LogToConsole>True</LogToConsole>
      </Logging>

      <TestParams>
          <TestParam>
              <Test>MultiThreaded</Test>
              <Name>t</Name>
              <Value>5</Value>
          </TestParam>
          <TestParam>
              <Test>MultiThreaded</Test>
              <Name>n</Name>
              <Value>5</Value>
          </TestParam>
          <TestParam>
              <Test>NonRepeatingChallenge</Test>
              <Name>n</Name>
              <Value>300</Value>
          </TestParam>
      </TestParams>
  </TestSuiteDefaults>
 </V5>
 </CMCKConfig>

Command Syntax

Command option | Description
cmck.exe <command> [options] | cmck.exe help

Troubleshooting

For more information, see the following Web sites:

Smart Card Minidriver Specification Smart Card Minidriver Certification Requirements

Code Tour

File Manifest

File | Location
cmck.exe | ...\tests\%ARCHITECTURE%\nttest\SmartCardModules
cmck_simuse.exe | ...\tests\%ARCHITECTURE%\nttest\SmartCardModules
intrcptr.dll | ...\tests\%ARCHITECTURE%\nttest\SmartCardModules

Test Assertions

Windows Logo Program: INPUT-0030 Smart Card Minidrivers meet Windows Card Minidriver Specifications and Certification Criteria


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 success of IOCTL_SMARTCARD_POWER to power down the card

  13. Operator removes the card

  14. 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
    • SCARD_ATTR_VENDOR_NAME : non-zero length string
    • SCARD_ATTR_VENDOR_IFD_TYPE : non-zero length string
    • SCARD_ATTR_DEVICE_UNIT : a 4 byte or greater length value
    • SCARD_ATTR_ATR_STRING : read attempt fails
    • SCARD_ATTR_DEFAULT_CLK : 1000 <= value <= 20000
    • SCARD_ATTR_MAX_CLK : 1000 <= value <= 20000
    • SCARD_ATTR_DEFAULT_DATA_RATE : read attempt succeeds
    • SCARD_ATTR_MAX_DATA_RATE : read attempt succeeds
    • SCARD_ATTR_MAX_IFSD : 1 <= value <= 254
    • SCARD_ATTR_CURRENT_PROTOCOL_TYPE : read attempt fails
  6. Test read attributes with a card inserted
    • SCARD_ATTR_VENDOR_NAME : non-zero length string
    • SCARD_ATTR_VENDOR_IFD_TYPE : non-zero length string
    • SCARD_ATTR_DEVICE_UNIT : a 4 byte or greater length value
    • SCARD_ATTR_ATR_STRING : read attempt succeeds
    • SCARD_ATTR_DEFAULT_CLK : value 1000 <= value <= 20000
    • SCARD_ATTR_MAX_CLK : value 1000 <= value <= 20000
    • SCARD_ATTR_DEFAULT_DATA_RATE : read attempt succeeds
    • SCARD_ATTR_MAX_DATA_RATE : read attempt succeeds
    • SCARD_ATTR_MAX_IFSD : 1 <= value <= 254
    • 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 Logo or Signature:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • 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:
  • PC/SC Workgroup test cards
Processor
  • x86
  • x64
  • Itanium

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

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
Windows Logo Program: Anonymous
Additional Information:
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
Windows Logo Program: Anonymous
Additional Information:
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
Windows Logo Program: Anonymous
Additional Information:
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
Windows Logo Program: Anonymous
Additional Information:
E.1 Device reports SCARD_ABSENT when returning from hibernate when no card was inserted.
Test Assertion GUID: d58967a8-cb2e-11da-94f8-00123f3a6b60
Windows Logo Program: Anonymous
Additional Information:
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
Windows Logo Program: Anonymous
Additional Information:
E.3 Device reports SCARD_ABSENT when returning from hibernate when card was removed during hibernation.
Test Assertion GUID: d58967aa-cb2e-11da-94f8-00123f3a6b60
Windows Logo Program: Anonymous
Additional Information:
E.4 Device reports SCARD_PRESENT when returning from hibernate when card was inserted during hibernation.
Test Assertion GUID: d58967ab-cb2e-11da-94f8-00123f3a6b60
Windows Logo Program: Anonymous
Additional Information:


Check smart card services (SC Reader, LOGO)

Type: Automated Test

Overview

This test checks whether the Certificate propagation service and Smart card service are started as per the smart card reader driver load.

Details

This test checks whether the Smart card reader driver INF file configures the following services to set to automatic and running on system startup:

  • Certificate Propagation

  • Smart Card

Run Time: 2 minutes
Log File: ScDiag.wtl
System Restart Required: No
Test Category: Input->SmartCard
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: ScDiag

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64


DirectInput Game

Type: Manual Test

Overview

The DirectInput Game 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 Microsoft 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 Logo or Signature:

  • Windows 7

  • Windows Vista

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Follow the on-screen instructions to put the devices axis to the maximum and minimum, when required. All other tests are automated.


Hot Key Test

Type: Manual Test

Overview

The Multimedia Hot Key test ensures that the expected API is used to implement application command features. This ensures compatibility with any applications that handle these messages.

Details

More information about the WM_APPCOMMAND API notifications, please visit the following Microsoft Web site:
http://msdn.microsoft.com/en-us/library/ms646275(VS.85).aspx

Run Time: Less than 5 minutes
Log File: HotKeyTestLog_YYYYMMDD_HHMM.wtl, where YYYY is the year, MM is the month, DD is the day, and HHMM is the time of log file creation.
System Restart Required: No
Test Category: Input
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: InputTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • .NET Framework 3.5 (installed by the DTM)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

The test has two views: the setup view and execution view. During setup, select which Application command keys have been implemented. During execution, you are prompted to press keys corresponding to each command. If the expected API notification is received the appropriate result displays Pass and the color changes from yellow to green. When all results are green, the test has been passed. To complete the test, click Submit Results. The test can be reset at any time by clicking Reset Test.

Command Syntax

Command option | Description
InputTest.exe | Without any options, the program allows the user to select one of three tests.
/hotkey | Starts the application with the Hot Key Test setup view.

Troubleshooting

If some notifications are not being received by the test application, make sure that the keyboard sends the expected scan code.

Also, make sure that any other software that listens for WM_APPCOMMAND notifications is not running.

Code Tour

File Manifest

File | Location
InputTest.exe | [testbinroot]\nttest\driverstest\input\wlk
Hook.dll | [testbinroot]\nttest\driverstest\input\wlk
WttLoggerWrapper.dll | [testbinroot]\nttest\driverstest\input\wlk

Test Assertions

Some applications interpret these notifications and then do not pass them to other applications. This test assumes that these applications are not running.


KVM - Automated Logo Test for Video

Type: Automated Test

Overview

The KVM automated test contains tests cases that verify the functionalities of the KVM. No user interface is needed. This test uses power management APIs to change system power states and turns the display device off/on. It verifies that the KVM does not prevent the display device from changing device states, and reports EDID data blocks correctly. The personal computer should maintain its desktop mode after the test machine changes its system power states, or the display monitor is powered off then on.

Details

Run Time: From 20 minutes to an hour, depending on the graphic mode that the test machine supports.
Log File: KvmAutoTest.xml.
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: kvmautotest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

This test changes system power states and turns the display device off/on. Any interruption from input devices, such as a keyboard or mouse, while the test is running might interfere with the test and cause a failure.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the test machine did not enumerate certain display mode that a test case was looking for specifically .

Command Syntax

Command option | Description
kvmautotest.exe | Without any options, the test enumerates devices.

Code Tour

File Manifest

File | Location
kvmautotest.exe | [testbinroot]\\nttest\windowstest\graphics\kvm\

Test Assertions

This test enforces the following Windows Logo Requirements:

  • INPUT-0051

  • INPUT-0052

  • INPUT-0053

  • INPUT-0054


KVM - Manual Logo Test for Video

Type: Manual Test

Overview

The KVM Manual test verifies the functionalities of the KVM that requires user interface. This test verifies that the KVM does not interfere with the display device from interacting with the host machine. The display monitor must report connection states and EDID data blocks correctly through the KVM as it did when connecting directly to the host machine.

Details

The test package contains a KvmLogoTest.htm file that details what test cases are covered in this test.

KVM Test Configuration

Hardware configuration should look like the following figure:

Diagram of a hardware configuration of two displays and two computers all connected by a KVM switch

display1: VGA, DVI, or HDMI monitor that has the same connection interface as the KVM in test.

display2: This monitor has different EDID data blocks from Display1. Either display2 model or manufacture is different from display1.

Custom VGA Cable: This special VGA cable is only required for KVM that uses VGA connectors. It is needed for testing KVM with monitors that do not report EDID data. This VGA cable had pin 15 (SCL: DDC Data Clock Line) removed so that EDID data will not be sent to the host PC.

PC1: The target machine where tests were conducted. It should run Windows 7, and support Advanced Configuration and Power Interface (ACPI). A laptop is not valid to be used as PC1, because there is a test case that requires the only monitor to be unplugged and plugged in.

PC2: Needed for KVM switching away and switching back. Also serves as the machine that switches away from PC1, but does not cause any monitor event seen by the PC1.

KVM Test Cases

1. KVM Hardware Qualification Test Cases: These tests qualify if the monitors used in KVM test are valid. The monitor in test is connecting directly to the PC1, as seen in the following figure:

Diagram of a test case with one display connected to one computer

1.1 Qualify display1 for EDID data
This test verifies if the display1 is valid for EDID monitor test cases.

1.2 Qualify display1 for monitor events
This test verifies that PC1 can poll display1 for remove monitor event and add monitor event.

1.3 Qualify display2 with different EDID data then display1
This test verifies that the EDID data of Display2 is different from Display1.

1.4 Qualify custom made VGA cable that can make display1 function as a non-EDID monitor.
Note This test is only applied to KVM whose output technology is HD15.
This test verifies that display1 will not report EDID data if it is connecting to PC1 through the custom made VGA cable.

2. KVM Manual Test Cases: These test cases certify the functionalities of the KVM. Display1 is connected through the KVM, as shown on Figure 1 above.

2.1 Verify EDID data through the KVM
This test verifies that EDID data of display1 through the KVM is the same as when it was connected directly to PC1 and the desktop is set to native display mode as specified by EDID data.

2.2 Unplug and plug in the monitor
This test verifies the unplug then re-plug of the cable from the monitor to KVM.

  • Monitor remove, and monitor add events are detected.

  • No EDID change event is detected.

  • EDID data remains the same.

  • Desktop native mode is persistent.

  • Desktop non-native modes are persistent.

2.3 Switch the KVM away from PC1
This test verifies that switching away the KVM to PC2, and switching the KVM back to PC1 would not cause the detection of any monitor event, or an EDID data changed event.

2.4 Hibernate PC1 and switch the KVM away from PC1.
This test verifies that after setting PC1 to hibernation state, switching the KVM to PC2, switching the KVM back to PC1, and then waking up PC1, EDID data and native mode on PC1 are persistent.

2.5 Different EDID Data for different monitor model (or manufacturer).

This test verifies that after replacing display1 with display2 after the persistent data base is deleted, the KVM causes the following to occur:

  • Monitor remove and monitor add events are detected.

  • EDID change event is detected.

  • EDID data changed.

  • Desktop set to the native mode as defined by new EDID data of display2.

2.6 No EDID Data for non-EDID VGA monitor.
Note This test is only applied to KVM whose output technology is HD15

This test verifies that replacing the VGA cable that connects display1 to KVM by the custom made VGA cable causes the following to occur:

  • Monitor departure and monitor arrival events are detected.

  • EDID change event detected.

  • Display1 reports no EDID data.

  • Desktop set to the default VGA mode.

2.7 Unplug and plug in the custom made VGA cable.
Note This test is only applied to KVM whose output technology is HD15

These test cases verify that PC1 is able to poll display1 for connection states when the custom made VGA cable was unplugged or plugged back to the KVM.

Run Time: 20 minutes
Log File: KvmLogoTest.xml
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: kvmautotest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Display Adapter that supports the graphic cable of the KVM, The graphic driver software should be enable.

  • 2 Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz. They should have different models or from different manufactures so that they will report different EDID data blocks.

  • If the KVM video output technology is HD15A, a custom cable. Refer to KvmLogoTest.htm on how to make this cable.

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Refer to KvmLogoTest.htm for descriptions of all KVM manual test cases. The test instructs the user what should be done through a dialog window. Some test case might SKIP due to the video output technology of the KVM. Because this test checks to make sure that all required test cases are executed, canceling the test causes the test to fail.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the KVM output technology is DVI or HDMI (not VGA).

Command Syntax

Command option | Description
kvmautotest.exe | Without any options, the test enumerates devices.

Code Tour

File Manifest

File | Location
kvmautotest.exe | [testbinroot]\\nttest\windowstest\graphics\kvm\
KvmLogoTest.htm | [testbinroot]\\nttest\windowstest\graphics\kvm\
KvmWttLogger.xsl | [testbinroot]\\nttest\windowstest\graphics\kvm\
KVM-Config1.jpg | [testbinroot]\\nttest\windowstest\graphics\kvm\
KVM-Config2.jpg | [testbinroot]\\nttest\windowstest\graphics\kvm\
HD15.jpg | [testbinroot]\\nttest\windowstest\graphics\kvm\

Test Assertions

The test enforces the following Windows Logo Requirements:

  • INPUT-0051

  • INPUT-0052

  • INPUT-0053

  • INPUT-0054


MCE IR Receiver Test

Type: Automated Test

Overview

The Consumer IR Receiver/Transceiver Test Utility (cirtest.exe) verifies driver compatibility with Microsoft Windows Media Center.

Note The documentation for this test also applies to the following tests:

  • Long-Range Receiver (Wideband) (Manual)

  • Learning Receiver (Manual)

  • Emitter(s) (Manual)

  • Additional Qualification - Long-Range Receiver (Wideband) (Manual)

  • Additional Qualification - Learning Receiver (Manual)

  • Additional Qualification - Emitter(s) (Manual)

Details

CIRTest tests the functionality of CIR Transceiver and Receiver devices and drivers by using a two-device system. One Receiver device (a known good and released device) is used to send test infrared (IR) signals to the device under test (DUT) and verify the incoming IR signals that are emitted from the DUT. The test application looks at the data that is reported from the two devices to ensure that the data is sent and received properly. The test also looks at the capabilities that the device reports to ensure it matches what is expected. You define the DUT, control device, capabilities, emitter ports, and test cases to run. Driver Test Manager (DTM) contains jobs that are set to run all test cases in the suite.

The port driver verification is performed by copying the Device Path Exerciser tool (DevPathExer.exe) into the same directory as CIRTest. CIRTest can then run DevPathExer.exe against the port driver under test to ensure it supports the required IOCTL functionality.

Run Time: 10 minutes to 3 hours (if the Device Path Exerciser is run)
Log File: CirTestRes.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature:

  • Windows Vista

  • Windows 7

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

  • DevPathExer.exe that ships with the WLK if a port driver is being certified

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Control Device (known as the good IR transceiver)

  • 2 strong IR emitters

Processor

  • x86

  • x64

Running MCE IR Receiver Test

  1. Install the Receiver that will act as the control device

  2. Install the Receiver that will act as the device under test.

  3. Insert the IR emitter into port #1 on the DUT and position it in front of the control device.

  4. Insert the IR emitter into any of the ports on the control device and position it in front of the DUT.

  5. Edit the Devcaps.ini file to reflect the expected capabilities of the DUT (found in the same folder as Cirtest.exe)

Command Syntax

Command option | Description
-ld | List the devices attached to the system and exit.
-t | Indicates which tests should be run, test numbers must be supplied as a parameter (e.g. -t1 or -t1,3 or -t1-10). Specify -t* to run all tests related to the DUT component being tested, -tm to run manual tests only or -ta to run automated tests only. Note The '-d' parameter must be passed before '-t'.
-i | Display info about test selected with -t and exit.
-d | Indicates the device under test, chosen by number (-d 0). A second parameter is passed to indicate the component of the device to test. This is denoted by a comma followed by a character ( -d 0,x). If no second character is passed (-d0), then the basic functionality of the device will be tested. Replace 'x' with a character from the following: w - Tests the Long-range (Wide-BPF) receiver, n - Tests the Narrow BPF receiver, l - Tests the Learning receiver, and e - Tests the IR Emitters.
-c | Indicates the control device for the test, chosen by number (-c 0). By default, the first non-selected device is used as the control. If only one device is attached, loopback mode will be used.
-e | Indicates the hex mask of emitters currently attached to the device (-e 7, -e 3). Required by tests that verify the emitters that are reported in software correctly reflect their physical existence.
-f | Indicates the device capabilities. File that lists the capabilities that should be reported by this device. Required by tests that verify the capabilities reported in software correctly reflect the capabilities of the device.
-s | Specify -s if you would like skip the emitter positioning step when running receiver test cases.
-p | Specify a Device Path used to select the device under test This option supersedes the value passed via the '-d' arg. '-p' must be the last option on the command line. The path should be contained in quotes. Example usage: -p "USB\VID_045E&PID_006D\MYSERIALNUMBER".
-z | Specify -z to run the Device Path Exerciser for Legacy and Emulator Devices.

Cautions

Make sure that the IR receivers are not facing each other.

Make sure that the IR receivers are in a relatively enclosed area such that the IR blasting from one device is not received by the other device.

Some displays (such as Plasma displays) and overhead lights can cause IR interference. Ensure the tests are run in a place that is devoid of this type of interference for repeatable results.

Troubleshooting

The most common issues involve having the IR receivers and emitters placed such that they interfere with one another. The second most common issue is because, when running the stress cases, the placement and strength of the IR emitter is important. The test can fail with the IR emitter in one position and pass when moved to another position with respect to the long range or learning receiver on the front of the DUT. Lastly, this tool does require the user have administrator privileges on the computer; otherwise, the test cannot access the hardware during the test.

Code Tour

File Manifest

File | Location
CIRTest.exe | \\%CONTROLLERNAME%\tests\%ARCHITECTURE%\nttest\MultimediaTest\eHome\Tools\CIRTest
CIRTest.dll | \\%CONTROLLERNAME%\tests\%ARCHITECTURE%\nttest\MultimediaTest\eHome\Tools\CIRTest
devcaps.ini | \\%CONTROLLERNAME%\tests\%ARCHITECTURE%\nttest\MultimediaTest\eHome\Tools\CIRTest

Test Assertions

Windows Logo Program: INPUT-0007 IR Receiver/Transceiver interfaces with the Windows Media Center class driver


MCE Remote Control Test

Type: Manual Test

Overview

The MCE Remote Control Certification Tool verifies IR Remote control support for premium Media Center functionality.

For a remote to be certified, it must satisfy the following two criteria:

  • All of the buttons on the remote must work.

  • All of the required buttons must be on the remote.

Details

The MCE Remote Control Certification Tool enables you to test and certify Media Center remote controls. For a remote to be certified, it must satisfy the following criteria:

  1. The MCE remote control team must approve the remote control design.

    This part of the certification process is manual and will be handled outside of the Microsoft Windows Driver Kit (WDK) process. Instead, if you want your remote to be certified, you must first be an authorized Media Center remote control manufacturer. After you complete this process, all remote control designs that you want to be certified must be approved. After this approval is complete, you can begin using the Windows Logo Program test tool to confirm the functionality of the remote control. For more information about the initial steps, contact MCE Remote Control Logo Program.

  2. All of the required buttons must be on the remote.

    The series of required buttons will change depending on whether systems that the remote control will be used with will have a tuner or not. Additionally, the set of required buttons will also vary depending on the where the remote control will be available to support TeleText and ISDB functions.

    The set of required buttons will be determined based on the preceding conditions that are specified during the test; you cannot change the required buttons. You will be able to also select all additional buttons that will be available on the remote control for verification as part of the test.

  3. All of the buttons on the remote control must work.

    After the set of buttons is selected, you will be taken through each button for verification of the button code being transmitted. On each screen, you will see the button that is being tested. After each button press, a result will be immediately returned. All buttons must pass to pass this part of the certification process. Any button failures will cause a failure for certification. All errors will be captured and you can view these results through the Driver Test Manager (DTM) client to better determine what the possible cause for failure may have been.

    Additionally, before you run the Self Certification Tool, you can complete the Self-Test Tool. This tool enables you to verify the button codes and the corresponding HID page, HID usage, and HID values for buttons that are pressed on the remote.

    After all buttons have been tested, a log file will be generated with the results. This log file must be submitted to the Microsoft Windows Hardware Quality Labs (WHQL) for final certification to occur.

Run Time:

Log File: RCTesterLogTest.xml

System Restart Required: No

Test Category:

Supported operating systems for Logo or Signature:

  • Windows 7
  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Media Center IR remote control and receiver

Running MCE Remote Control Test

To run this test, do the following:

  1. Plug the receiver into the client machine.

  2. In DTM Client locate and run the scheduled job that corresponds to the certification of MCE remote controls.

  3. On the client machine, a dialog box for the power button verification will show up.

  4. After verification of the power buttons, the Remote Control test will start.

  5. Choose one of the following two options:
    • The Self-Test Tool verifies button functionality without submitting the result for logo certification.
    • The Self-Certification Tool tests button functionality and verifies additional information about the remote control. The results of the test and the additional information will be submitted to Microsoft for final certification approval.

  6. Select the Self-Certification Tool.

  7. Enter in the authorization code from the remote control design approval. This code is required to proceed with the verification process.

  8. Enter the information on the next form about the type of remote control that you are testing and where the remote control will be released.

  9. Press any button on the remote control to test the signal.

  10. Complete the rest of the wizard to verify the signal and verify each button functionality.

  11. Note what button name appears in the Press the following button on your remote control area, and then press the corresponding button on the remote control. The result will be captured and displayed on the screen. Be aware that at any time, you can also use one of the following buttons:
    • Cancel: Takes you back to the main menu.
    • Previous: Takes you to the previous page.
    • Next: If the buttons-to-test list is not empty, opens the Testing Not Complete dialog box. Within this dialog box, if you click OK, you go to the next page, and the test logs the fact that not all buttons passed certification and logs the names of the delinquent buttons. Otherwise, you will remain on the current page.
    • Skip: Skips the current button in the buttons-to-test list and prompts you for the next button. For example, you might use this button if a particular button did not pass and you wanted to proceed with verification of the remaining buttons. This action will be captured in the log file and will be noted as a failure

  12. Submit the results of the test to Microsoft. You must send the log file for the rest of the certification process to occur. There is an option to view the log file through the DTM client before you submit it.

Cautions

You should observe standard issues with infrared (IR) remote controls. For example, the remote control must be reasonably close to the receiver and pointed at it.

Troubleshooting

You can use the tool in self-test mode to isolate problems with particular buttons.
Green Button Specification and Media Center Remote Control Specifications are currently available through the MS Connect Web site.

Code Tour

File Manifest

File | Location
RCTester.exe |

Test Assertions

Test Assertion GUID:
Windows Logo Program: INPUT-0006 Remote control that supports Media Center functionality complies with the appropriate Windows Remote Control Specification
Additional Information:


Mouse Functionality

Type: Automated Test

Overview

The Mouse Functionality test verifies the functionality of all mouse buttons and movements.

Details

This test is manual test and requires you to move the cursor and click and double-click various buttons.

The test puts the system into hibernate and suspend state during the test.

Run Time: 10 minutes

Log File:

System Restart Required: No

Supported operating systems for Logo or Signature:

  • Windows 7

  • Windows Vista

  • Windows XP

  • Windows Server 2003

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


Scroll Test

Type: Manual Test

Overview

This manual test confirms that the Scroll feature is implemented using the expected API notifications for vertical and horizontal scroll.

Details

The application captures all Mouse input with a low level hook. While running the test, scroll and extended mouse button functionality will not function normally.

Run Time: Less than 5 minutes
Log File: ScrollTestLog_YYYYMMDD_HHMM.wtl, where YYYY is the year, MM is the month, DD is the day, and HHMM is the time of log file creation.
System Restart Required: No
Test Category: Input
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: InputTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • .NET Framework 3.5 (installed by the DTM)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

The test has two views: the setup view and execution view. During setup, the selects whether the vertical scroll, horizontal scroll, or both are implemented. During execution, you will be prompted to scroll in the directions supported by the device. If the expected API notification is returned, the appropriate result displays Pass and the color changes from yellow to green. When the test has been passed, the test summary displays Pass and the color will change to green. To complete the test, click Submit Results. The test can be reset at any time by clicking Reset Test.

Command Syntax

Command option | Description
InputTest.exe | Without any options, the program allows the user to select one of three tests.
/scroll | Starts the application with the Windows Key Test Setup view.

Code Tour

File Manifest

File | Location
InputTest.exe | [testbinroot]\nttest\driverstest\input\wlk
Hook.dll | [testbinroot]\nttest\driverstest\input\wlk
WttLoggerWrapper.dll | [testbinroot]\nttest\driverstest\input\wlk

Test Assertions

The mouse under test is the only mouse connected to the computer.


Sensor Tests

Type: Automated Test

Overview

Sensor Tests verifies that the sensor devices meet the Sensor and Location platform logo requirements.

Details

Test: Sensor Common - Required Properties Exist

Test verifies that the sensor is reporting all the properties required to function correctly in the Sensor and Location platform.

Input Parameter: /test:required_properties_exist

Run Time: (estimated) 2 minutes

TUID: 70C4250C-9231-4d4f-9831-053048FD78F0

Test: Sensor Common - Minimum Supported Data Fields

Test verifies that the sensor is reporting the minimum number of data fields required to function correctly in the Sensor and Location platform.

Input Parameter: /test:minimum_supported_data_fields

Run Time: (estimated) 2 minutes

TUID: 066C231A-40B5-4ac1-ABB5-1099684A3D41

Test: Sensor Common - Settable Properties Support Read Write Access

Test verifies that, if the sensor supports well-known settable properties, the properties support read-write access. If the sensor supports the Report Interval property, the test will verify if Report Interval Best Practices are being followed. Look in the test log for warnings that would indicate a best practices violation. Note that this test will not fail if the Report Interval Best Practices portion of the test reports a warning.

Input Parameter: /test:settable_properties_support_read_write

Run Time: (estimated) 2 minutes

TUID: F88D4E0A-F31A-477b-AD7D-7B536A39F0BC

Test: Sensor Common - Required Static Properties

Test verifies that values for required properties that are expected to be static do not change over time (eg: SENSOR_PROPERTY_FRIENDLY_NAME).

Input Parameter: /test:required_static_properties

Run Time: (estimated) 20 minutes

TUID: 71DB2B92-6DD4-4f38-BC6A-0CFFEC0F373C

Test: Sensor Common - Missing Property Validation

Test verifies that sensor devices return the correct output values and error codes in response to requests for properties that the sensor does not support.

Input Parameter: /test:missing_property

Run Time: (estimated) 2 minutes

TUID: B9AA9A48-CB38-4b37-9725-26F4B7CAD09B

Test: Location Sensor - Required Data Fields Exposed

Test verifies that sensors with a category of SENSOR_CATEGORY_LOCATION support the data fields required to function correctly as a location sensor in the Sensor and Location platform.

Input Parameter: /test:required_location_data_fields

Run Time: (estimated) 2 minutes

TUID: CDC6C0C1-9632-4db2-A467-77EC223EC04B

Test: Ambient Light Sensor - Required Data Fields Exposed

Test verifies that sensors with a type of SENSOR_TYPE_AMBIENT_LIGHT support the data fields required to function correctly as an ambient light sensor in the Sensor and Location platform.

Input Parameter: /test:required_als_data_fields

Run Time: (estimated) 2 minutes

TUID: CBABA91A-485A-4b0a-B22A-0D69FA555289

Test: Sensor Common - Sensor Interface Stress

Test verifies that the sensor can operate without failure under heavy API usage. APIs should not return any unexpected failures.

Input Parameter: /test:stress_common

Run Time: 4 hours

TUID: 478AD25F-F726-4603-9A91-79C246311E5F

Test: Sensor Common - Sensor Interface Stress with Sleep/Resume Cycles

Test verifies that the sensor continues to operate and provide data after prolonged usage including after numerous sleep/resume cycles.

Input Parameter: /test:stress_common_sleepcycle

Run Time: 4 hours

TUID: 269C744C-0706-4788-97FD-C3B70C375FD7

Test: Sensor Common - Timestamp Validation [Manual]

Test verifies that each new event from a sensor has a unique timestamp that is more recent than the previous event timestamp. Note that the test will prompt for the generation of events.

Input Parameter: /test:required_common_timestamp

Run Time (estimated) 2 - 4 minutes

TUID: 69E0126C-3EA8-4bfa-93FB-5192C64BD614

Test: Sensor Common - Ready State Validation

Test verifies that after a device is disabled then enabled, the sensor will go into the Ready State within five minutes. The exposed properties, data fields, and static data will persist after the disable/enable cycle.

Input Parameter: /test:validate_common_ready

Run Time: (estimate) 1 - 5 minutes

TUID: 59930CBF-4A3A-4e26-A74B-A48D7C17CF54

Test: Location Sensor - Validate Location DataReport [Manual]

Test verifies that for a sensor of category SENSOR_CATEGORY_LOCATION, it provides the data for an ILatLongReport or an ICivicAddressReport or both. In the case of either locationreport on the minimum required data fields must be present and have data. Note that if no data is available when the test begins, the test will prompt for the generation of a data event.

Input Parameter: /test:required_location_datareport

Run Time: (estimate) 1 minute

TUID: 52847B83-A474-4301-A969-C4C7D14A15E9

Test: Ambient Light Sensor - Required DataReport LUX

Test verifies that for a sensor of type SENSOR_TYPE_AMBIENT_LIGHT, it provides a datareport that contains at least SENSOR_DATA_TYPE_LIGHT_LEVEL_LUX. The test reads this data and verifies that it is of data type VT_R4 and is greater than or equal to zero.

Input Parameter: /test:required_als_datareport_lux

Run Time: (estimate) 1 minute

TUID: 5D7FD921-9C0E-4710-B22B-4276AE83E61E

Test: Ambient Light Sensor - Required DataReport LUX Event [Manual]

Test verifies that for a sensor of type SENSOR_TYPE_AMBIENT_LIGHT, that when the ambient light level is varied, a data changed event is raised. The data report from the raised event must contain a new LUX level in the SENSOR_DATA_TYPE_LIGHT_LEVEL_LUX field. Note that at the start of the test, a base level light reading will be taken. You will be prompted to cover the Ambient Light Sensor (ALS). It is expected that the LUX reading will decrease. You will then be prompted to increase the LUX level beyond the base reading. It is expected that the LUX reading will increase.

Input Parameter: /test:required_als_datareport_lux_event

Run Time: (estimate) 2 minutes

TUID: 95597316-A658-4fe5-8A62-DEA4EAFFE908

Run Time: Each test above identifies a specific estimated run time.
Log File: SensorLocationTests.xml
System Restart Required: No
Test Category: Input > Sensor
Supported operating systems for Logo or Signature:

  • Windows 7

Program: SensorLocationTests.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Hard disk with a minimum of 20 GB available on partition C

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running Sensor Tests

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The following tests will report a SKIP result under certain conditions:

  • Location Sensor - Required Data Fields Exposed: If the sensor under test does not have a category of SENSOR_CATEGORY_LOCATION, then this test will report SKIP.

  • Location Sensor - Validate Location Data Report: If the sensor under test does not have a category of SENSOR_CATEGORY_LOCATION, then this test will report SKIP.

  • Ambient Light Sensor - Required Data Fields Exposed: If the sensor under test does not have a type of SENSOR_TYPE_AMBIENT_LIGHT, then this test will report SKIP.

  • Ambient Light Sensor - Required DataReport LUX: If the sensor under test does not have a type of SENSOR_TYPE_AMBIENT_LIGHT, then this test will report SKIP.

  • Ambient Light Sensor - Required DataReport LUX Even: If the sensor under test does not have a type of SENSOR_TYPE_AMBIENT_LIGHT, then this test will report SKIP.

Command Syntax

Command option | Description
SensorLocationTests.exe | Without any option, the test executable will report the required input parameters for test execution.
/path: | The /path: input parameter is used to provide the device instance path for the sensor to test. Note that the device path will commonly need double quotes for this parameter to function correctly. The following is an example of how this might look: /path:"ROOT\SENSOR\0000" or /path:" HID\VID_C1CA&PID_0004\6&2A0A6310&0&0000"
/test: | The /test: input parameter specifies the test that should be ran on the sensor under test. The supported input parameters are: /test:required_properties_exist /test:required_static_properties /test:minimum_supported_data_fields /test:required_location_data_fields /test:required_als_data_fields /test:settable_properties_support_read_write /test:missing_property /test:stress_common /test:stress_common_sleepcycle /test:required_common_timestamp /test:validate_common_ready /test:required_location_datareport /test:required_als_datareport_lux /test:required_als_datareport_lux_event Note The detail section above indicates the input parameter required to run each test.
/rs: | The /rs: input parameter specifies a random seed that should be used during the running of the test. This parameter only applies to the /test:stress_common and the /test:stress_common_sleepcycle tests. This enables a random test to be repeated to try and reproduce a previous test run failure. Look at the output log of the original test to find the test seed generated. Note that a test seed value of 0 (/rs:0) will use the current system time as the random seed.

Code Tour

File Manifest

File | Location
SensorLocationTests.exe | [testbinroot]\NTTEST\DRIVERSTEST\MobilePC\Sensors\WLK


Tablet PC Digitizer Logo Test

Type: Automated Test

Overview

The Tablet PC Digitizer Logo Test automated tool verifies Tablet PC digitizer logo requirements.

Details

Before you schedule any jobs, ensure that the MobilePC\TabletPCDigitizer gatherer is running on the test systems.

Run Time:

10 minutes

Log File:

System Restart Required:

No

Test Category:

Supported operating systems for Logo or Signature:

  • Windows 7

  • Windows Vista

Program:

Requirements

The test tool requires the following software:

  • Software Requirements
    • Supported operating system (see list above).
    • Software components included with the device that is being tested.
  • Hardware Requirements
    • Device to be tested
    • Computer that meets the minimum software requirements
    • Color display monitor capable of at 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 Tablet PC Digitizer Logo Test

To configure the test system to run the Digitizer logo tests, do the following:

  1. Install the appropriate operating system on the test system.

  2. Connect the digitizer to the test system and ensure basic functionality is working.

  3. If appropriate, enable autologon functionality.

  4. Install the DTM client on the test system.

  5. Ensure that the MobilePC\TabletPCDigitizer gatherer is installed on the test system.

To use DTM to run the Digitizer logo tests, do the following:

  1. Open DTM Studio.

  2. On the Explorers menu, click Job Monitor.

  3. Create a machine pool for the client systems.

  4. Move the client systems to the newly created machine pool.

  5. On the Explorers menu, click Device Selection.

  6. In the View By area, select Submission.

  7. In the Submission list, click New submission.

    Follow the steps in the Submission Wizard. After you are done, a set of jobs will appear.

  8. In the Available devices pane, select one of the devices.

  9. In the Available jobs pane, select the main job tree to run all of the jobs that are listed or choose the jobs individually and then click Add selected.

  10. When you are ready to run the jobs, click Schedule.

  11. Repute step 11 - 13 for the other devices in the Available devices pane.

  12. When testing is complete, click the status button in DeviceCconsole and review the information that is provided; correct any issues that are identified.

  13. After verifying the status information, right-click the summary icon in the Available devices pane of Device Console and click Create submission package.

Use the Job Monitor window to track the progress of jobs as they are run.

Use the Result Explorer window to examine the results of jobs that have completed.


Windows Key Test

Type: Manual Test

Overview

This manual test confirms that the Windows Logo Flag key is implemented using the expected scan code and virtual key code. If a left and right Windows Logo Flag key is implemented, both keys are tested individually.

Details

The application captures all keyboard input with a low level hook. While running the test, the keyboard will not work in other applications. System commands such as Control-Alt-Delete function as normal.

Run Time: Less than 5 minutes
Log File: WinKeyTestLog_YYYYMMDD_HHMM.wtl where YYYY is the year, MM is the month, DD is the day, and HHMM is the time of log file creation.
System Restart Required: No
Test Category: Input
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: InputTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • .NET Framework 3.5 (installed by the DTM)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

The test has two views: the setup view and execution view. During setup, select whether the left, right, or both windows keys are implemented. During execution, you are prompted to press the windows keys. If the expected scan code and virtual key code are returned, the appropriate result displays Pass and the color changes from yellow to green. When the test passes, the test summary displays Pass and the color changes to green. To complete the test, click the Submit Results. The test can be reset at any time by clicking Reset Test.

Command Syntax

Command option | Description
InputTest.exe | Without any options, the program allows the user to select one of three tests.
/winkey | Starts the application with the Windows Key Test Setup view.

Code Tour

File Manifest

File | Location
InputTest.exe | [testbinroot]\nttest\driverstest\input\wlk
Hook.dll | [testbinroot]\nttest\driverstest\input\wlk
WttLoggerWrapper.dll | [testbinroot]\nttest\driverstest\input\wlk

Test Assertions

The keyboard under test is the only keyboard connected to the computer.


Windows Touch Test

Type: Automated Test

Overview

The Windows Touch Test validates the logo requirements for Touch digitizers that report a capability of 2 or more contacts. These requirements are covered in logo requirement INPUT-0046. In addition to the standard self-certification submission for devices through WHQL, Microsoft requires a validation certification test pass to be run at the Microsoft Windows Touch Test Lab (WTTL) facility before Windows Touch Logo Certification is approved. WTTL validation is not necessary for system certification if the device has been previously logo'd and the hardware and drivers are unchanged.

Details

Run Time: 20 minutes per iteration
Log File: TabletDigitizerOPK.xml
System Restart Required: Yes
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: MTWindowsLogo.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

Test Application Structure

The series of tests for the Windows Touch submissions in divided into 14 pages. Each page holds one or more individual tests. Individual test results are shown after completion of individual tests and of page results are shown after completion of test pages.

Complete iterations

A complete, passing test execution is required for each of the following situations:

  • After boot

  • After resuming from sleep

  • After resuming from hibernation

  • If the device is used in a mobile system, on battery (DC) power

Navigation

Navigation is possible at the page level by right-clicking and selecting an option from the menu. All tests on a single page must be executed in order of appearance, by clicking the Next Test button to move from one test to the next. Pages can be executed in any order the tester chooses. Using the Next Test button will advance sequentially through the test pages.

Results

The log file containing results of the tests is written to the file named "TabletDigitizerOPK.xml".

Skipping to any test page in the set using right-click navigation will reset any existing results for that page. New results will be appended to the log file, and the results from the last iteration of the page taken into consideration for logo verification.

Pass/fail requirements

The following test pages must be passed in full in order to meet INPUT-0046 requirements:

  • Introduction screen (this tests for supported resolution and maximum contact count, and enables navigation to the remaining tests)

  • Test 1: Sampling Rate

  • Test 2: Single Touch Taps: the initial 4 corner tests

  • Test 14: Ghost Point Test

The following accuracy test pages must be passed at a 95% rate:

  • Test 2: Single Touch Taps: the remaining 5 locations

  • Test 3: Single Touch Press-and-Hold

  • Test 4: Double Taps

  • Test 5: Multi-Touch Points

  • Test 6: Press and Tap

  • Test 7: Straight Line Accuracy

  • Test 8: Maximum Touch Lines

  • Test 10: Line Accuracy Velocity

  • Test 11: Single Touch Arcs

  • Test 12: Pivot

  • Test 13: Multi-Touch Arcs

This means that a maximum of 2 test items from these pages can be failed, while still achieving an overall pass. Be aware that for the Maximum Touch Lines page, each line is counted as a single test item. For all other pages, each test is counted as a single test item.

Test Pages

Introduction Screen

This screen requires input of screen dimensions in mm. This should be obtained from an accurate measurement of the physical size of the display area. Accuracy to 2 decimal places is supported. The entered value is validated against the physical size reported by the digitizer (to within 5mm).

It also validates the information for supported resolution and maximum contact count from the device's HID descriptor. Resolution is checked to be at least 25ppi and at least display resolution. The maximum contact value is used in the following way:

  1. The Sampling Rate test will measure sampling rate for the maximum number of contacts.

  2. The Maximum Touch lines test will measure line accuracy for the maximum number of contacts, up to a maximum of 5.

All other tests require only 1 or 2 simultaneous contacts.

Test 1 Sampling Rate

This test measures the sampling rate of the maximum number of contacts supported. The rate is calculated over every second for a period of 10 seconds, and should stay above the requirement (50Hz) for all ten seconds.

To execute this test, place the number of supported contacts simultaneously onto the screen and hold these down for a period of 10 seconds. The period will be counted down by a timer in the top right quadrant of the screen. Sampling rate per contact is shown in the upper left quadrant.

Test 14 Ghost Points

This test checks that no unintended input is reported over a period of 2 minutes. The device must be left in an unattended state for this period. Success is reported if no touch input is detected during this period.

Test 2 Single Taps

This measures the accuracy of single taps in all four corners of the screen. Target touch points are indicated by a cross-hair graphic with a 2.5mm-radius circle at the center.

For single test item to pass, the touch-point reported must be within 2.5mm of the target test point. A successful touch-point is indicated by a green cross-hair graphic centered on the reported point. A failed touch-point is indicated by a red cross-hair graphic rotated 45 degrees and centered on the reported point.

Test 3 Single Press and Hold

This measures both accuracy and jitter of touches in different areas of the screen. Target touch points are indicated as for Test 2: Signal Taps. In this case contact must be held for a period of 2 seconds without moving.

For a single test item to pass, the touch-point reported must be within 2.5mm of the target test point, and there must be no jitter reported during contact.

Test 4 Double Tap

This test measures the accuracy reported by a double-tap gesture of a single contact. The target point is indicated as for Test 2 Single Taps. The test should be completed with a rapid double-tap movement centered on the target point, i.e. down-up, down-up, with minimal delay in between.

Single taps will not be registered as test input, and the 2.5mm accuracy requirement applies to the locus of the double-tap.

Test 5 Multi-touch Points

This measures the accuracy of simultaneous multi-touches in different areas of the screen. Please note that the touches should be made simultaneously and not sequentially. Target points are as for Single Taps, however the accuracy boundary is 5mm (per the 'additional touch' requirements for simultaneous touches in INPUT-0046 requirements), and the simultaneity requirement means that no longer than 30ms may elapse between touches.

Motion of each contact should be made as for Test 2 Single Taps, i.e. the contacts should make a simultaneous rapid 'tap' on the screen and be lifted immediately after contact.

Test 6 Press and Tap

This test measures accuracy as executed by a press-and-tap gesture using two contacts. A press and tap gesture made when an initial contact is made and held, a second contact makes a tap nearby, then the initial contact is lifted.

To execute these tests, press and hold on point P1, make a tap on point P2, then release the contact on point P1.

Test 7 Straight Line Accuracy

This measures both the accuracy (2.5mm) and offset requirements (<1mm offset variation, over any 10mm of travel - see explanation below) of straight lines traced by a single contact. Test operators may wish to use a straightedge, jig or other apparatus to minimize errors resulting from freehand input.

Initial contact may be made anywhere on the screen. Once the contact comes within 2.5mm of the starting point (indicated by "S"), accuracy and offset measurement begin. It is good practice to begin the line outside the 'funnel' close to the "S" point and enter the measuring area through the funnel. Once the line comes within 2.5mm of the ending point (marked "E") the contact may be lifted off since it will no longer be measured.

Unmeasured parts of the line are plotted in yellow; accurate parts of the line are plotted in green; inaccurate parts of the line are plotted in red. To improve visibility of the line, each reported pixel is represented in the form of a '+', with each neighboring pixel on the x and y axes also plotted in the same color. Any inaccurate parts of the line will cause the test to fail. If early contact lift-off is the reason for failure, that will be indicated onscreen. More than one contact during execution of the line will also fail the test.

Test 9 Multi-Touch Lines

This test measures the accuracy of straight lines traced by two contacts. The first contact is required to remain within 2.5 mm of the target, and the second contact is required to remain within 5 mm of the target. (To enable apparatus-free human input, the offset tolerance on both lines is relaxed to 5 mm variance over 10 mm travel.)

First place a contact down outside the funnel of the starting point labeled S1. Then place a second contact down outside the funnel of the starting point labeled S2. Move the contact simultaneously along the lines to E1 and E2, respectively. Accuracy is measured on both lines, and contacts must remain within [n] mm of each other in order to guarantee simultaneity of line drawing.

Test 8 Maximum Touch Lines

This test measures the accuracy of [n] lines where [n] is the maximum contacts supported by the device or 5, whichever is lower. To enable apparatus-free human input, the offset tolerance is relaxed to 5mm drift.

This test is implemented in the same manner as Test 9: Multi-touch lines. To execute the test, contacts should be placed outside the funnel starting points in ascending order, i.e. place the first contact near S1, the second near S2 and so on. When all contacts are down, trace each line through to E1, E2 etc. Accuracy is measured and results are reported in the same way as Test 7: Multi-touch lines.

Note that for overall pass/fail calculations for logo certification, each line of this test is counted as a single test item. This is to ensure that accuracy is high for all contacts reported by a device.

Test 9 Multi-Touch Lines

This test measures the accuracy of straight lines traced by two contacts. The first contact is required to remain within 2.5mm of the target, the second contact is required to remain within 5mm of the target. (To enable apparatus-free human input, the offset tolerance on both lines is relaxed to 5mm variance over 10mm travel.)

First place a contact down outside the funnel of the starting point labeled S1. Then place a second contact down outside the funnel of the starting point labeled S2. Then move the contact simultaneously along the lines to E1 and E2 respectively. Accuracy is measured on both lines, and contacts must remain within [n] mm of each other in order to guarantee simultaneity of line drawing.

Test 10 Line Accuracy Velocity

This test validates the accuracy of lines traced in accordance with the standard velocity of typical human drag and move gestures by following an object moving at a fixed speed along the line. To enable apparatus-free human input, the offset tolerance is relaxed to 5mm drift.

This test is implemented in the same way as Test 7: Straight Line Accuracy, but imposes fixed velocities on the tracing of lines in order to measure accuracy under standard gesture conditions. Each line has an initial 'runway' to allow the finger or stylus to gauge the required speed; the measured portion of the line begins at the first short perpendicular axis and ends at the second.

To execute the test, place a contact in the 5mm square box at the start of the line, and as it moves along the line, maintain the contact within the box.

In the multi-line case, there is a longer runway. Place initial contact on Line 1 and them immediately place contact on line 2, and maintain each contact within the moving box on each line.

To pass each test: for the measured portion of the line, the contact point must be reported both inside the moving box at all times, and within the standard 2.5mm accuracy boundary of the line.

Test 11 Arc Accuracy

This test measures the accuracy of arcs traced by a single contact (within 2.5mm of the target). (To enable apparatus-free human input, the offset tolerance is relaxed to 5mm drift.)

This test is implemented in the same manner as Test 5: Single Touch Lines, the only difference being that the tested lines are arcs (portions of a circle) and not straight. It should be executed in the same manner as Test 5.

Test 12 Pivot

This test measures accuracy on a pivot gesture such as those used for rotation in certain applications. To enable apparatus-free human input, the offset tolerance is relaxed to 5mm drift.

To execute the test, place the first contact on the point P1 and then place a second contact outside the funnel labeled Start. With the second contact, trace the line from Start to End while keeping the first contact within the circular area labeled P1.

Test 13 Multi-Touch Arcs

This test measures the accuracy of arcs traced by two contacts. The goal of this test is to validate more that dual arc gestures can be reasonably accomplished than to validate absolute accuracy of each arc, and so the absolute accuracy requirement on this test is looser, and no offset checking is done.

The test is implemented and should be executed in exactly the same way as for multi-touch lines.

Test 14 Ghost Points

This test checks that no unintended input is reported over a period of 2 minutes. The device must be left in an unattended state for this period. Success is reported if no touch input is detected during this period.

Command Syntax

Command option | Description
MTWindowsLogo.exe | Execute the test.

Code Tour

File Manifest

File

MTWindowsLogo.exe


Winkey Test

Type: Automated Test

Overview

The Winkey test verifies that the test keyboard functions correctly.

Details

Winkey One-Key Combination testThis test verifies that the test keyboard functions correctly when any one key is pressed.

Run time: approximately 2 minutes

Winkey Two-Key Combination test

This test verifies that the test keyboard functions correctly when any two-key combination is pressed.

This test is required if the Windows logo key and the Application key are present on the test keyboard.

Run time: approximately 10 minutes

Winkey Three-Key Combination test

This test verifies that the test keyboard functions correctly when any three-key combination is pressed.

This test is required if the Windows logo key and the Application key are present on the test keyboard.

Run time: approximately 30 minutes

Winkey Media testThis test verifies the compatibility of the keyboard media key scan codes with the predefined Microsoft Windows operating system media scan codes. If a media button generates the Windows predefined scan code, the button must function exactly as the scan code is defined.

This test determines if the keyboard generates the correct usage IDs to take advantage of predefined scan code support.

Run time: approximately 1 minute

Run Time: varies with test
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

  • Software components included with the device that is being tested.

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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


XBOX 360 Controller Feature Test

Type: Manual Test

Overview

The XBOX 360 Controller Feature Test (XNACCTST) is a 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 responds as it should, through the XINPUT API. This test checks all of the capabilities of the device that you are test. This test will determine what type of common controller device is attached and adjust its tests accordingly (for example, wheels test differently than arcade sticks).

This test is a completely manual test, with the graphical user interface (GUI) giving you prompts and instructions about what action to perform. There is an XML file that is created with test results after each completed pass.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature:

  • Windows 7

  • Windows Vista

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

Follow the steps that the test harness specifies.


XBOX 360 Controller State and Audio Test

Overview

The XBOX 360 Controller State and Audio Test (XNAState) is a manual test that enables you to get instant feedback about what functions of the common controller are working and to view the capabilities of the controller.

Details

XNAState is the test application that you can use to view the capabilities of all of the devices that connect to the computer 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 graphical user interface (GUI). You will be asked to hit a button on the controller, and then the GUI will appear. 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 can use. There is no XML file output for this test because 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 7
  • 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
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at 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

By using the test harness UI, view that all buttons, axis, and functions of the controller are working as expected.

Connect multiple devices and switch from one device's input to another by selecting which port is in use.


Kernel Filters Testing

Kernel Filters Testing Overview
Preparing for Kernel Filters Testing
Running the Kernel Filters Tests
Troubleshooting Kernel Filters Testing
Kernel Filters Tests


Kernel Filters Testing Overview

The procedures presented in this section outline the process for testing your Kernel Filter for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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 logo testing.
  • Running: The running topics describe how to run to run the tests for your device or system.

Kernel Filter Tests

The list of test you need to run depends on 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 Kernel Filters Tests.

Run time: Approximately 4 hours.

Hardware requirements

The following hardware is required for Kernel Filter 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 machine running client or server Windows 7 SP1 or Windows 2008 R2 SP1
  • Another server Windows 2008 R2 SP1 machine

Software requirements

The following software is required to run the Kernel Filter tests:

  • The AV filter driver under test

Tester knowledge requirements

To run the Kernel Filter tests, testers must know how to accomplish the following tasks:

  • Edit a DTM job to provide volume info in the parameters section.
  • Create a remote share on a server.


Preparing for Kernel Filters Testing

Before running the tests, you must first 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 Kernel Filters Testing Overview.

Many of the tests in the Windows Logo 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.

Test system configuration

To configure the test system, follow these steps:

Note Please refer to the following table to see the letter assignment for each volume:
NTFS | g:
CNTFS | i:
Fat16 | k:
Fat32 | l:
ExFat | m:
UDF | n:

  1. On the client machine, several volumes need to be present (NTFS 2gb, ntfs compressed 2gb, fat16 1gb, Fat32 1gb, Exfat 1gb, UDF 2gb).
  2. In the controller, modify the parameters on the jobs undef $\WDK Tests\Storage\Filesystems\ to point to test volumes, as follows:
    1. TxF2: Modify ntfs and cntfs to point at test volumes.
    2. ReparsePoints: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    3. Installable Filesystems filter test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    4. Antivirus Installable Filesystems filter test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    5. File IO test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    6. Mapped File IO test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    7. Object ID test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    8. Oplocks test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    9. Syscache test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
  3. On the server, create share RDRTest.
  4. Modify the parameters on $\WDK Tests\Leasing\SMB_OplockRDR test to point at the server name and share name.


Running the Kernel Filters Tests

Submit the job under Devices, Kernel Filter AV, Logo.


Troubleshooting Kernel Filters Testing

Follow the log output for the test result.


Kernel Filters Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


Remote File Systems Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


OplockRDR Test

Type: Automated Test

Overview

This test verifies Lease logic or "Oplock" in Server Message Block (SMB) Version 2.1.

For lease information, please see the [MS-SMB2] protocol document at http://msdn.microsoft.com/en-us/library/cc246482(PROT.13).aspx

Details

Run Time:20 minutes
Log File:

OplockRDR.log

System Restart Required: No
Test Category:User mode test application
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: OplockRDRTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
Hardware Requirements
  • Two computers (client and server) that meet the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64
  • IA64

Running the Test

Create a share on the server machine. Then run the test from the client machine.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
OplockRDRTest.exe | Without any options, it will display usage information.
-s [ServerName] | Specifies the server machine name.
-I [ServerAddressScheme] | Specifies the address method used in tests.
-h [ShareOnServer] | Specifies the share name on server machine to be tested.
-logfile OplockRDR.log | Specifies log file name.

Code Tour

File Manifest

File | Location
OplockRDRTest.exe | [testbinroot]\nttest\basetest\core_file_Services\SMB\Oplock\OplockEnhancement\RDRTest\
Stresslog.dll | [testbinroot]\nttest\basetest\core_file_Services\Shared_Libs
Ntlog.dll | [testbinroot]\nttest\CommonTest\

Test Assertions

The test expects a share to be created on the server machine before test execution.


Local File Systems Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


File IO Test

Type: Automated Test

Overview

The File IO Test tests basic File IO on the driver stack.

More information about File System Behavior is available at http://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf.

Details

Run Time:1 hour
Log File:
Fileio-Local-Ntfs.log
Fileio-Local-Cntfs.log
Fileio-Local-Fat16.log
Fileio-Local-Fat32.log
Fileio-Local-ExFat.log
Fileio-Local-UDF.log
System Restart Required: Yes
Test Category:Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7 SP1

  • Windows Server 2008 R2 SP1

Program: IFSTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Filter driver to be tested, along with any supporting application suite
Hardware Requirements
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Extra hard drive space for four simple 2048 mb partitions and two simple 1024 mb partitions
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

Before running the test, the following partitions need to be added to the Windows environment:

Label | File System | Size | Expected Drive Letter
NTFS | ntfs | 2048mb | g:
CNTFS | ntfs (compressed) | 2048mb | i:
FAT | Fat16 | 1024mb | k:
FAT32 | Fat32 | 1024mb | l:
ExFAT | ExFat | 2048mb | m:
UDF | UDF | 2048mb | n:

When executed, the test will run variations for each of the six partitions above.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

RunFileIO.cmd contains references to environment variables that can be changed to allow for skipping of certain file systems.

Command Syntax

Command option | Description
runkarr %DRIVE_1% %DRIVE_2% -bvt | Requires two drive letters and the –bvt parameter

Troubleshooting

The test uses ntlog for logging the test results.

The test is capable of running isolated variations.

To run the FileIO regression test, follow these steps:

  • Runkarr x: e:
  • Where x: is the test drive and e: is a local auxiliary drive, and both are not the system drives.

To run the FileIO BVT with more debug information, follow these steps:

  • Runkarr x: e: -bvt:f -v
  • Where x: is the test drive and e: is a local auxiliary drive, and both are not the system drives.

To run individual variation, follow these steps::

  • Runkarr x: e: -t 1,2,3,5:10,12
  • This runs variations 1, 2, 3, 5, 10, and 12

To turn on debugging information, follow these steps:

  • Runkarr x: e: -t 1,2,3,5:10,12 -v

Any failure is logged with the Win32 GetLastError() code.

The test can be used to verifying the following information:

  • The context the test or variation ran (for example, x86/ia64, filesystem, local/remote, language, build number)
  • Pass, fail, and variation count numbers
  • If failed, information that can help determine the cause of failure

To interpret the log, follow these steps::

  1. +Call+ 291; Call 1 to AKRNFIL2 SdkCompletionPorts (test #131); verlevel=3 pcnt=100 seed=19890
  2. +TEST_PARAMETERS+ NO Parameters
  3. +Test_Case+ 6 SdkCompletionPorts: TestCancelAsyncFileIo I/O.
  4. +VER_RESULT+ SEV2 ConfirmLock: ReadFile failed when it should not. nBytesRead: 0 bRet: 0 GLE=33.
  5. +VER_RESULT+ SEV2 CheckCompletionIo: Failed in ConfirmLock.
  6. Search for variations that are marked as “BLOCK” or “SEV”
  7. Determine the API that failed (for example, ReadFile)
  8. Determine the parameters that were passed into the API, if any
  9. Determine the returned value of the API (for example, bRet: 0)
  10. Determine the value of GetLastError() (for example, GLE=33). This will provide useful information about what is wrong, such as ERROR_INVALID_HANDLE or ERROR_NETNAME_DELETED.

Code Tour

File Manifest

File | Location
ntlog.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
ntlogger.ini | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
betacomp.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
dups.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
entry.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
GetDoc.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
LOG.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
parse.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
rats.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
rats.ini | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
ratsutil.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
ratsshr.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
RATS_ENG.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
shrmem.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
statw32.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
timerw32.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
tshrmem.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wrap0.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wrap1.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wrap3.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wrapinline.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wrapit.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wtscript.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
dbcsstrs.dll | [WTT\TestBinRoot]\NTTest\CommonTest\dbcsstrs\
detoured.dll | [WTT\TestBinRoot]\NTTest\BaseTest\Core_File_Services\Shared_Tools\Detours\
rats2wtt.dll | [WTT\TestBinRoot]\NTTest\BaseTest\Core_File_Services\Shared_Tools\Detours\
setdll.exe | [WTT\TestBinRoot]\NTTest\BaseTest\Core_File_Services\Shared_Tools\Detours\
withdll.exe | [WTT\TestBinRoot]\NTTest\BaseTest\Core_File_Services\Shared_Tools\Detours\
AKRNFIL2.dll | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
attribex.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
Attribs.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
cdsetup.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
charmap.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
chinf.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
chldread.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
chldsize.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
copyfile.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
crdirex.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
crutil.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
cutil.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
delf.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
dirent.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
eautil.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
expath.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
findex.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
fssortkey.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
fstype.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
genrdwr.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
getdrive.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
getdtype.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
getfree.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
getftype.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
getinf.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
getres.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
getset.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
getshort.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
getsize.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
gettime.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
getvol.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
growpage.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
longname.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
lotsdir.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
lotsfile.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
names.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
parselog.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
rasync.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
readch.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
rother.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
runiorat.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
runkarr.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
setfp.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
settime.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
setvol.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
srchpath.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
tempfile.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
wasync.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
wother.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
writech.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
allwin32filbvt.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
cdfs.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
cdfs.nam | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
cdhct.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
cdrom1.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
davbvt.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
example.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
fat.nam | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
fatlong.nam | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
filcdfs.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
filcdfs.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
fildblsp.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
fildblsp.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
fileio.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
fileio.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
fileio_2.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
filesysdrives.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
filesysdrives.vbs | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
file_io.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
file_iog.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
filidw.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
filsdk.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
filst1.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hctcd.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hctcd.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hctdrive.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hctdrive.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hctflop.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hctflop.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hcttest.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hlink.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hlinkidw.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hlinksdk.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hlinkst1.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
hpfs.nam | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
maphctc.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
maphctd.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
maphcte.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
maphctf.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
maphctg.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
maphcth.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
maphcti.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
netware.nam | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
nfs.nam | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
nfsbvt.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
nfsio.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
novell.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
ntfs.nam | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
nwclong.nam | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
nwcompat.nam | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
recomp.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
runtestfilbvtllu.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
run_fileio_bvt_new.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
sc-rats.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
setfio.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
trydrive.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\common\
RunFileIO.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\

Test Assertions

The tests expect the partitions to be in place.


IFS Test

Type: Automated Test

Overview

The installable file system test suite verifies whether the behavior in the file system stack is consistent with the File System Behavior Overview. This is a regression test suite.

More information about File System Behavior is available at http://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf.

Details

Documentation for the test variations can be found at http://msdn.microsoft.com/en-us/library/ff563405(VS.85).aspx

Run Time:1 hour
Log File:
Ifstest-Local-NtfsResults.log
Ifstest-Local-CntfsResults.log
Ifstest-Local-Fat16Results.log
Ifstest-Local-Fat32Results.log
Ifstest-Local-ExFatResults.log
Ifstest-Local-UDFResults.log
System Restart Required: Yes
Test Category:Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7 SP1

  • Windows Server 2008 R2 SP1

Program: IFSTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Filter driver to be tested, along with any supporting application suite
Hardware Requirements
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Extra hard drive space for four simple 2048 mb partitions and two simple 1024 mb partitions
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

Before running the test, the following partitions need to be added to the Windows environment:

Label | File System | Size | Expected Drive Letter
NTFS | ntfs | 2048mb | g:
CNTFS | ntfs (compressed) | 2048mb | i:
FAT | Fat16 | 1024mb | k:
FAT32 | Fat32 | 1024mb | l:
ExFAT | ExFat | 2048mb | m:
UDF | UDF | 2048mb | n:

When executed, the test will run variations for each of the six partitions above.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

If there is a policy on the test system of locking out new accounts, the IFS test might return "blocked" on the multiprocess variations if the local machine account "ifstest" is locked out.

Please use account manager to unlock the account and rerun the suite.

RunIFStest.cmd contains references to environment variables that can be changed to allow for skipping of certain file systems.

Command Syntax

Command option | Description
IfsTest.exe | -g Virus /n .\Ifstest-Local-NtfsResults.log /N 356789AB /T /p /m /E /j /r c: -d \Ntfs -a \datacoh.exe /u ifstest /U *rw53w5
-g <suitename> | Do not run <suitename>
/n <logname> | Create a long of name <logname>
/N

Specify NTLOG levels. If not included, then the GUI dialog box appears. This is useful in a batch mode run of the test

NTLOG Levels:

1 ABORT
2 SEV1
3 SEV2
4 SEV3
5 WARN
6 PASS
7 BLOCK
8 INFO
9 SYSTEM INFO
A DEBUG INFO
B TEST
/T | Enable trace of tests being done
/p | Enable pagefile testing in CreatePagingFileTest
/m | Enable dirty bit testing in MountedDirtyTest
/E | Enable AllowExtendedDASDTest
/j | Enable support for tests involving the change journal
/r <volumeletter> | Path to second volume required in certain tests
-d <> | System Path to FSD device object in FileSystemDeviceOpenTest.
-a | Provide path to executable
/u | Username for test account
/U | Password for test account
/t <variation> | Execute only one named variation

Troubleshooting

The tests should be able to create a temporary local machine account (ifstest). They also expect to have additional partitioned volumes.

Use a tool such as minispy to see what irps are traveling on the file system stack. Compare passing (default Windows install) with installs, including any failing driver.

For information about File System Behavior, go tohttp://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf.

For documentation about the test variations, go tohttp://msdn.microsoft.com/en-us/library/ff563405(VS.85).aspx

Code Tour

File Manifest

File | Location
ntlog.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
ntlogger.ini | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
chg.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
chgfile.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
chgnotif.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
cleanupfiles.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
closedel.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
createkc.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
datacoh.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
decrypt.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
defrag.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
devctrl.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
dirinfo.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
dirpt.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
eainfo.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
encrypt.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
encryptvirus.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
enum.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
esecurit.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
estream.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
fileinfo.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
filelock.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
forcedis.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
fsctlgen.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
fsctlvol.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
IFSCFG.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifsmsg.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest-av.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest-av_wdk.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstestcleanup.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest_storagelogo.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest_wdk.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ishell.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
linkpt.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
linktrak.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
mfile.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
mountpt.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
objectid.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
opcreatg.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
opcreatp.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
oplocks.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
quotas.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
readwr.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
reparspt.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ResetAutoLogon.vbs | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
restoresystem.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
seccache.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
securit.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
setupsystem.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
skel.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
sparse.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
virus.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
volinfo.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
writevirus.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
xchg.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
guidefile.dat | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\virusfiles\
virusfile1.evf | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\virusfiles\
virusfile2.evf | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\virusfiles\
virusfile3.evf | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\virusfiles\
virusfile4.evf | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\virusfiles\
createwttlog.vbs | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\LFS_Automation\common\
chgjourn.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
fbslog.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\shared_libs\fbslog\
RunIFSTests.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
WrapIFSTests.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
attachfilter.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\

Test Assertions

The tests expect the partitions to be in place.


Mapped File IO Test

Type: Automated Test

Overview

The Mapped File IO Test tests basic Mapped File IO on the driver stack.

More information about File System Behavior is available at http://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf.

Details

Run Time:1 hour
Log File: map_pdk_bvt.log (renamed in run scripts to format FileIO_Mapped_<fs>.log)
System Restart Required: Yes
Test Category:Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7 SP1

  • Windows Server 2008 R2 SP1

Program: IFSTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Filter driver to be tested, along with any supporting application suite
Hardware Requirements
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Extra hard drive space for four simple 2048 mb partitions and two simple 1024 mb partitions
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

Before running the test, the following partitions need to be added to the Windows environment:

Label | File System | Size | Expected Drive Letter
NTFS | ntfs | 2048mb | g:
CNTFS | ntfs (compressed) | 2048mb | i:
FAT | Fat16 | 1024mb | k:
FAT32 | Fat32 | 1024mb | l:
ExFAT | ExFat | 2048mb | m:
UDF | UDF | 2048mb | n:

When executed, the test will run variations for each of the six partitions above.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

RunFileIO.cmd contains references to environment variables that can be changed to allow for skipping of certain file systems.

Command Syntax

Command option | Description
runkarr %DRIVE_1% -bvt:mp | Requires drive letter and the –bvt:mp parameter

Code Tour

File Manifest

File | Location
ntlog.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
ntlogger.ini | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
betacomp.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
dups.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
entry.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
GetDoc.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
LOG.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
parse.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
rats.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
rats.ini | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
ratsshr.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
ratsutil.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
RATS_ENG.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
shrmem.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
statw32.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
timerw32.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
tshrmem.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wrap0.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wrap1.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wrap3.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wrapinline.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wrapit.exe | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
wtscript.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Rats\
dbcsstrs.dll | [WTT\TestBinRoot]\NTTest\CommonTest\dbcsstrs\
detoured.dll | [WTT\TestBinRoot]\NTTest\BaseTest\Core_File_Services\Shared_Tools\Detours\
rats2wtt.dll | [WTT\TestBinRoot]\NTTest\BaseTest\Core_File_Services\Shared_Tools\Detours\
setdll.exe | [WTT\TestBinRoot]\NTTest\BaseTest\Core_File_Services\Shared_Tools\Detours\
withdll.exe | [WTT\TestBinRoot]\NTTest\BaseTest\Core_File_Services\Shared_Tools\Detours\
runkarr.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilBVT\[WTT\Processor]\
AKRN1MAP.dll | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\[WTT\Processor]\
childacc.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\[WTT\Processor]\
childmap.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\[WTT\Processor]\
mapchild.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\[WTT\Processor]\
viewchld.exe | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\[WTT\Processor]\
allwin32filmapbvt.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
filesysdrives.vbs | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
mapbeta.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
maphctc.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
maphctd.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
maphcte.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
maphctf.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
maphctg.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
maphcth.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
maphcti.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
mappdk.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
map_pdk_bvt.rat | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
run_filemap_bvt.cmd | [WTT\TestBinRoot]\NTTest\BVTBIN\Win32FilmapBVT\common\
RunMappedFileIO.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
WrapMappedFileIO.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\

Test Assertions

The tests expect the partitions to be in place.


Object ID Test

Type: Automated Test

Overview

The object ID test checks the following FSCTLs:

  • FSCTL_CREATE_OR_GET_OBJECT_ID
  • FSCTL_DELETE_OBJECT_ID
  • FSCTL_GET_OBJECT_ID
  • FSCTL_SET_OBJECT_ID
  • FSCTL_SET_OBJECT_ID_EXTENDED

More information about File System Behavior is available at http://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf.

Details

Run Time:1 hour
Log File:
ObjectID_BVT_NTFS.log
ObjectID_BVT_CNTFS.log
System Restart Required: Yes
Test Category:Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7 SP1

  • Windows Server 2008 R2 SP1

Program: IFSTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Filter driver to be tested, along with any supporting application suite
Hardware Requirements
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Extra hard drive space for four simple 2048 mb partitions and two simple 1024 mb partitions
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

Before running the test, the following partitions need to be added to the Windows environment:

Label | File System | Size | Expected Drive Letter
NTFS | ntfs | 2048mb | g:
CNTFS | ntfs (compressed) | 2048mb | i:
FAT | Fat16 | 1024mb | k:
FAT32 | Fat32 | 1024mb | l:
ExFAT | ExFat | 2048mb | m:
UDF | UDF | 2048mb | n:

When executed, the test will run variations for each of the six partitions above.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

RunFileIO.cmd contains references to environment variables that can be changed to allow for skipping of certain file systems.

Command Syntax

Command option | Description
runkarr %DRIVE_1% %DRIVE_2% -bvt | Requires two drive letters and the –bvt parameter

Code Tour

File Manifest

File | Location
oidtest.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\ntfs\oid\
RunObjectID.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
WrapObjectID.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
ntlog.dll | [WTT\TestBinRoot]\NTTest\CommonTest\NTLog\
ntlogger.ini | [WTT\TestBinRoot]\NTTest\CommonTest\NTLog\

Test Assertions

The tests expect the partitions to be in place.


Oplocks Test

Type: Automated Test

Overview

General File System Behavior (including Oplock) is available at http://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf.

More information about File System Behavior is available at http://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf.

Details

This test verifies the basic behavior of Legacy Oplocks (Level2, Level1, Filter, and Batch) and Enhanced Oplocks (Read, Read-Write, Read-Handle, and Read-Write-Handle). It has the following variations:

  • Legacy_Acquire_Release: Acquire a Legacy Oplock and then release it
  • Enhanced_Acquire_Release: Acquire an Enhanced Oplock and then release it
  • Enhanced_Acquire_Release_Opkey: Acquire an Enhanced oplock using oplock key
  • Legacy_Break_L2: Break an L2 oplock with various file operations
  • Enhanced_Break_R: Break an R oplock with various file operations
  • Legacy_Break_L1: Break an L1 oplock with various file operations
  • Enhanced_Break_RW: Break an RW oplock with various file operations
  • Enhanced_Break_RH: Break an RH oplock with various file operations
  • Legacy_Break_Batch: Break a Batch oplock with various file operations
  • Enhanced_Break_RWH: Break an RWH oplock with various file operations
  • EnhancedMultipleSharedOplocks: Acquire multiple enhanced oplocks on the same file
  • EnhancedUpgradeOplocks: Upgrade an enhanced oplock
  • EnhancedOplockBreakAckOtherHandle: Acknowledge an enhanced oplock break on another handle that opened with the same key
  • EnhancedOplockStealthUpgrade: Acknowledge an oplock break and requesting an upgrade level oplock
  • AtomicOplocksVariation: Atomic open (open a handle with CreatOptions=FILE_OPEN_REQUIRING_OPLOCK)
  • AtomicOplocksNonIntrusiveVariation: Atomic open when oplock already exist on the file
  • BreakingRHOplocks: Special operations to break RH oplock

Run Time:1 hour
Log File:
Oplocks-Ntfs.log
Oplocks-CNtfs.log
Oplocks-FAT.log
Oplocks-FAT32.log
Oplocks-EXFAT.log
Oplocks-UDF.log
System Restart Required: Yes
Test Category:Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7 SP1

  • Windows Server 2008 R2 SP1

Program: IFSTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Filter driver to be tested, along with any supporting application suite
Hardware Requirements
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Extra hard drive space for four simple 2048 mb partitions and two simple 1024 mb partitions
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

Before running the test, the following partitions need to be added to the Windows environment:

Label | File System | Size | Expected Drive Letter
NTFS | ntfs | 2048mb | g:
CNTFS | ntfs (compressed) | 2048mb | i:
FAT | Fat16 | 1024mb | k:
FAT32 | Fat32 | 1024mb | l:
ExFAT | ExFat | 2048mb | m:
UDF | UDF | 2048mb | n:

When executed, the test will run variations for each of the six partitions above.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

RunFileIO.cmd contains references to environment variables that can be changed to allow for skipping of certain file systems.

Command Syntax

Command option | Description
runkarr %DRIVE_1% %DRIVE_2% -bvt | Requires two drive letters and the –bvt parameter

Code Tour

File Manifest

File | Location
enhancedoplocks.exe | [WTT\TestBinRoot]\NTTest\BASETEST\core_file_services\Shared_Tests\Regression\Oplocks\
opkey.inf | [WTT\TestBinRoot]\NTTest\BASETEST\core_file_services\FilterManager\
opkey.sys | [WTT\TestBinRoot]\NTTest\BASETEST\core_file_services\FilterManager\
RunOplocks.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
WrapOplocks.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\

Test Assertions

The tests expect the partitions to be in place.


Reparse Points Test

Type: Automated Test

Overview

The Reparse Points Test tests reparse points on the upper file system stack.

More information about File System Behavior is available at http://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf.

Details

Run Time:1 hour
Log File:
ReparsePoint_NTFS.log
ReparsePoint_CNTFS.log
System Restart Required: Yes
Test Category:Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7 SP1

  • Windows Server 2008 R2 SP1

Program: rp_regres.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Filter driver to be tested, along with any supporting application suite
Hardware Requirements
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Extra hard drive space for four simple 2048 mb partitions and two simple 1024 mb partitions
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

Before running the test, the following partitions need to be added to the Windows environment:

Label | File System | Size | Expected Drive Letter
NTFS | ntfs | 2048mb | g:
CNTFS | ntfs (compressed) | 2048mb | i:
FAT | Fat16 | 1024mb | k:
FAT32 | Fat32 | 1024mb | l:
ExFAT | ExFat | 2048mb | m:
UDF | UDF | 2048mb | n:

When executed, the test will run variations for each of the six partitions above.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

RunFileIO.cmd contains references to environment variables that can be changed to allow for skipping of certain file systems.

Command Syntax

Command option | Description
rp_regres %DRIVE_ltr% | Specifies driver to test

Troubleshooting

If you experience a test failure, run it with the option /V to have the test print additional information on variation failures. Example: rp_regres %DRIVE_ltr% /V

If you experience a large number of failures, make sure that you are running on the correct file-system type. You can also check the file-system information of a volume to make sure that Reparse Points are supported by using the following fsutil command, and looking for the output “Supports Reparse Points”: fsutil fsinfo volumeinfo %DRIVE_ltr%

Code Tour

File Manifest

File | Location
rp_regres.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\ntfs\
ntlog.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
ntlogger.ini | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
stresslog.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\shared_libs\
RunReparsePoint.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
WrapReparsePoint.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\

Test Assertions

The tests expect the partitions to be in place.


Syscache Test

Type: Automated Test

Overview

Syscache is a test that writes to a file and verifies that the data written is read back correctly. It can detect corruptions caused by anything in the path from firmware, drivers, file system, or memory. It uses a standard Win32 File System and memory management APIs to read and write data from the file.

The test binary is Readwrit.exe.

Details

Syscache opens a file with a certain flag or attribute, and it writes to the file. Each selected flag may span several runs on the file. A run is defined as a set of the following sequence:

  1. Create/open a file.
  2. Truncate the filesize to 0.
  3. Write to the file.
  4. Close the file.
  5. Reopen the file.
  6. Read the file.
  7. Verify file content.
  8. Close the file.

There is a set of zero and non-zero regions in the file. Zero regions are areas in the file where no data was written. Non-zero regions are areas in the file where data was written. The pattern is a DWORD of the format RRPPPPPP. The top two bytes are the run number, and the next three bytes are the one’s complement of the offset of this DWORD in the file.

Attributes used for writing a file:

Write Attribute | Explanation
FILE_ATTRIBUTE_NORMAL | FILE_ATTRIBUTE_NORMAL See CreateFile() Documentation
FILE_FLAG_SEQUENTIAL_SCAN | FILE_ATTRIBUTE_NORMAL See CreateFile() Documentation
FILE_FLAG_NO_BUFFERING | FILE_ATTRIBUTE_NORMAL See CreateFile() Documentation
FILE_FLAG_RANDOM_ACCESS | FILE_ATTRIBUTE_NORMAL See CreateFile() Documentation
FILE_FLAG_WRITE_THROUGH | FILE_ATTRIBUTE_NORMAL See CreateFile() Documentation
FILE_ATTRIBUTE_TEMPORARY | FILE_ATTRIBUTE_NORMAL See CreateFile() Documentation
NO_BUFFERING | WRITE_THROUGH | FILE_ATTRIBUTE_NORMAL See CreateFile() Documentation
FILE_ATTRIBUTE_SPARSE_FILE | The file is set to sparse.
NORMAL APPEND_WRITE | Same as FILE_ATTRIBUTE_NORMAL; closes and reopening the file per write and appending the next region.
FILE_FLAG_SECTOR_CHUNKS | Same as FILE_FLAG_NO_BUFFERING, data is written one sector at a time.
FILE_MAP | Same as FILE_ATTRIBUTE_NORMAL, data is written via memory mapping.
FILE_FLAG_OVEREXTEND | Same as FILE_ATTRIBUTE_NORMAL, data is written via memory mapping, but aligned at 0x10000 boundaries.

Attributes used for reading from the file:

Read Attribute | Explanation
FILE_MAP | FILE_ATTRIBUTE_NORMAL, data is read via memory mapping
NO_BUFFERING | FILE_FLAG_NO_BUFFERING
NORMAL | FILE_ATTRIBUTE_NORMAL
RANDOM_ACCESS | FILE_FLAG_RANDOM_ACCESS
SEQUENTIAL_SCAN | FILE_FLAG_SEQUENTIAL_SCAN
TEMPORARY | FILE_FLAG_TEMPORARY
WRITE_THROUGH | FILE_FLAG_WRITE_THROUGH

Run Time:1 hour
Log File:
Syscache-NTFS.log
Syscache-CNTFS.log
Syscache-FAT16.log
Syscache-FAT32.log
Syscache-ExFAT.log
Syscache-UDF.log
System Restart Required: Yes
Test Category:Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7 SP1

  • Windows Server 2008 R2 SP1

Program: IFSTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Filter driver to be tested, along with any supporting application suite
Hardware Requirements
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Extra hard drive space for four simple 2048 mb partitions and two simple 1024 mb partitions
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

Before running the test, the following partitions need to be added to the Windows environment:

Label | File System | Size | Expected Drive Letter
NTFS | ntfs | 2048mb | g:
CNTFS | ntfs (compressed) | 2048mb | i:
FAT | Fat16 | 1024mb | k:
FAT32 | Fat32 | 1024mb | l:
ExFAT | ExFat | 2048mb | m:
UDF | UDF | 2048mb | n:

When executed, the test will run variations for each of the six partitions above.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

RunFileIO.cmd contains references to environment variables that can be changed to allow for skipping of certain file systems.

Command Syntax

Command option | Description
-l TempFileLocation | Directory where TempFile will be created. Default = current directory
-p TempFilePrefix | Three character prefix for the TempFile. Default = "cac"
-s SeedValue | Seed to generate random numbers. Default = program generated
-z FileSize | Max size of TempFile in megabytes. Default = TempFile size up to 1 MB.
-m | Flush System Cache before verifying file. Default = No flush
-f | Flush files after writing Default = No flush
-d | Break into the debugger if the file is corrupt. Default = Do not break into the debugger
-e | Continue test after a failure. Default = Exit upon failure
-C | Continue checking for corruption for succeeding data after detecting corruption.
-t | Stress mode. Default = No stress mode
-n minutes | Minimum minutes test should run.
-c | Run in cluster-aware mode.
-y Log file name | Name of log file.
-v level | Name of log file. 0 = quiet 1 = normal default level 2 = output to screen as well
-S | Permute order of variations.
-N | Use new expanded set of variations to enable single cached reader, single unbuffered reader, etc.
-B | Let the readers move from back to front when verifying 50% of the time.
-R file | Run reboot tests. Use the given file to store data.
-W size | Working set maximum size to use.
-r ReadThread | Does not spawn thread that does read with:
0 | NORMAL
1 | SEQUENTIAL_SCAN
2 | NO_BUFFERING
3 | RANDOM_ACCESS
4 | WRITE_THROUGH
5 | FILE_MAP
6 | TEMPORARY
-X | Exclude SPARSE FILE write test on CSC drives.
-O options | Debug options. Options are hex flags.
0x0001 | DebugBreak after parse.
0x0002 | Flag events for WMI logging.
-w WriteThread | Does not do write with:
0 | FILE_ATTRIBUTE_NORMAL
1 | FILE_FLAG_SEQUENTIAL_SCAN
2 | FILE_FLAG_SECTOR_CHUNKS
3 | FILE_FLAG_NO_BUFFERING
4 | FILE_FLAG_RANDOM_ACCESS
5 | FILE_FLAG_WRITE_THROUGH
6 | FILE_MAP
7 | FILE_FLAG_OVEREXTEND
8 | FILE_ATTRIBUTE_TEMPORARY
9 | NO_BUFFERING | WRITE_THROUGH
10 | FILE_ATTRIBUTE_SPARSE_FILE
11 | NORMAL APPEND_WRITE
 | Default = Do all writes

Troubleshooting

When the test fails, the log contains all the information needed to analyze the failure. Look for the following information:

  • Write attributes, to find how the data was written to the file
  • Read attributes, to find out how the data was read back from the file
  • Offset at which the error occurred
  • Region of the file where the error occurred

    Note The test typically writes the entire region using a single write (with the exception of the FILE_FLAG_SECTOR_CHUNKS option).

With the above information, you should be able to reproduce the failure on your own.

Code Tour

File Manifest

File | Location
readwrit.exe | [WTT\TestBinRoot]\NTTest\BASETEST\core_file_services\cachemgr\
RunSyscache.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
WrapSyscache.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
ntlog.dll | [WTT\TestBinRoot]\NTTest\CommonTest\NtLog\
ntlogger.ini | [WTT\TestBinRoot]\NTTest\CommonTest\NtLog\
stresslog.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\shared_libs\

Test Assertions

The tests expect the partitions to be in place.


TxF Test

Type: Automated Test

Overview

This regression test targets the transactional capability of NTFS called TxF. It contains scenarios that test simple transacted operations, such as creating and deleting a file, or committing and rolling back the transaction. It also tests more advanced features of TxF, such as savepoints, miniversion, and secondary RMs.

More information about File System Behavior is available at http://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf.

Details

Run Time:1 hour
Log File:
  • txfs2-NTFS.log
  • txfs2-CNTFS.log
System Restart Required: Yes
Test Category:Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7 SP1

  • Windows Server 2008 R2 SP1

Program: txfsreg.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Filter driver to be tested, along with any supporting application suite
Hardware Requirements
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Extra hard drive space for four simple 2048 mb partitions and two simple 1024 mb partitions
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

Before running the test, the following partitions need to be added to the Windows environment:

Label | File System | Size | Expected Drive Letter
NTFS | ntfs | 2048mb | g:
CNTFS | ntfs (compressed) | 2048mb | i:
FAT | Fat16 | 1024mb | k:
FAT32 | Fat32 | 1024mb | l:
ExFAT | ExFat | 2048mb | m:
UDF | UDF | 2048mb | n:

When executed, the test will run variations for each of the six partitions above.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

RunFileIO.cmd contains references to environment variables that can be changed to allow for skipping of certain file systems.

Command Syntax

Command option | Description
txfsreg.exe --regression | Requires being run in target volume

Code Tour

File Manifest

File | Location
txfsReg.exe | [WTT\TestBinRoot]\nttest\basetest\core_file_services\txf\txfsReg.exe
ntlog.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
ntlogger.ini | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
stresslog.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\shared_libs\
RunTxF.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
WrapTxF.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\

Test Assertions

The tests expect the partitions to be in place.


Network Filter Driver Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


Winsock Functional

Type: Automated Test

Overview

The Winsock WLK test iterates through some of the core Winsock functionality against a loopback interface, and verifies whether the Winsock API interface is properly maintained. More information on the Winsock API can be found at http://msdn.microsoft.com/en-us/library/ms740673(VS.85).aspx

Details

All tests cover IPv4 and IPv6 sockets, which all bind to the loopback interface.

  • Socket Catalog variation: Enumerates the Winsock catalog, creates a socket for each protocolinfo structure returned (each protocol-tuple), and binds it to the loopback interface.
  • OVERLAPPED IO variation: Creates both IPv4 and IPv6 TCP stream sockets, establishes a connection over loopback, and sends data between sockets via blocking send and overlapped recv calls. All data is verified as received.
  • TransmitFile variation: Verifies if TransmitFile correctly sends data and implements the TF_DISCONNECT flag for socket reuse for both IPv4 and IPv6 sockets. Creates a 260-byte temporary file, and transmits over a TCP connection via TransmitFile. The listening socket uses AcceptEx to verify the connection and socket reuse.
  • ConditionalAccept variation: Verifies semantics of conditional accept over both IPv4 and IPv6 TCP stream sockets. Tests five connections: without a listener, returning CF_REJECT, returning CF_ACCEPT, returning CF_DEFER + CF_REJECT, and returning CF_DEFER + CF_ACCEPT.
  • Streams variation: Blocks send/recv over IPv4 and IPv6 TCP stream sockets. Defers calling accept with a zero listen backlog until the connect has completed.
  • Datagrams variation: Verifies sending and receiving of datagrams over IPv4 and IPv6 UDP sockets. Tests both sending datagrams via connect/send/receive, as well as connection-less send to/receive from.
  • Select variation: Verifies READFDS notification on both IPv4 and IPv6 TCP sockets for indications for connection establishment, receiving data, and closure of the socket.
  • Bind variation: Verifies bind semantics for IPv4 and IPv6 TCP sockets: basic bind, SO_REUSEADDR binds, and SO_EXCLUSIVEADDRUSE binds.
  • ReadFile/WriteFile variation: Verifies whether OVERLAPPED ReadFile() and WriteFile() APIs function properly over both IPv4 and IPv6 TCP sockets.
  • Shutdown variation: Verifies shutdown() semantics on IPv4 and IPv6 TCP sockets by establishing a connection, posting a blocking recv, and verifying whether calling shutdown completes the recv with zero-bytes received.
  • Addressing variation: Verifies the conversion of IPv4 and IPv6 addresses from hex, decimal, and octal strings to the corresponding socket address struct values (WSAAddressToString/WSAStringToAddress).
  • Multicast variation: For IPv4 and IPv6, verifies the joining to multicast groups via IP_ADD_MEMBERSHIP/IPV6_ADD_MEMBERSHIP, sending and receiving data to the group, and leaving the group.
  • JoinLeaf variation: For IPv4 and IPv6, verifies the joining to multicast groups via WSAJoinLeaf, sending and receiving data to the group, and leaving the group.
  • AsyncSelect variation: For IPv4 and IPv6 TCP sockets, verifies FD_CONNECT, FD_SEND, and FD_READ windows messages are processed via WSAAsyncSelect. Also verifies whether FD_CONNECT is processed when a multicast socket completes WSAJoinLeaf.
  • IOCP variation: For IPv4 and IPv6 TCP sockets, OVERLAPPED recv calls are made with the socket associated to an IO completion port. Also verifies whether the OVERLAPPED completions are processed and all data is received.
  • RAW socket variation: For IPv4 and IPv6, creates RAW sockets, sending and receiving ICMP messages via OVERLAPPED IO.
  • PnP variation: Verifies whether OVERLAPPED address change notification is signaled when non-loopback IP addresses are added and removed to the first non-loopback .

Run Time:Less than 5 minutes
Log File: The WTT Log file is returned to DTM with details of the test.
System Restart Required: No
Test Category:Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: WinsockFunctional.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Filter Driver to be tested along with any supporting application suite.
Hardware Requirements
  • Device to be tested
  • At least one connected network interface with a valid IPv4 and IPv6 address assigned
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64
  • IA64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
winsockfunctional.exe -protocol ip -t "Winsock API\Current Protocols (IPv4/IPv6)\BVT" -wtt -r -dontdisable –ipsec –notrace | The core argument that must be supplied.
-lsponly | Append this argument when an LSP is installed.

Troubleshooting

The Windows Firewall may open a Firewall dialog box that suggests that the firewall may be blocking some features of the test. This is expected and the firewall does not affect the test. You can safely ignore this message without affecting the results of the test.

Code Tour

File Manifest

File | Location
WinsockFunctional.exe | [WTT\TestBinRoot]\NTTest\NetTest\Winsock\common\WinsockFunctional.exe
WinsockFunctional.wtl | Detailed output log from the test with the test results.
Wsbvt.log | Summary output log of the test results.
Bvterr.log | Summary output log of the test results.
Fnshell.ini | Temporary ini file generated and used by the test.


Process Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


Module Management Test

Type: Automated Test

Overview

This is the general module management test.

Details

This test serves as a functional test for CreateSection, CreateProcess, FreeLibrary, GetProcAddress, LoadLibrary, DisableThreadLibraryCalls, FreeLibraryAndExitThread, GetModuleFileName, and GetModuleHandle.

Run Time: 20 minutes
Log File: modm.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: Modm.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Computers that meets the minimum software requirements
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
Test.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to be tested.
wdk_test.pro | The .profile file of test cases to be run.

Code Tour

Note There are many files in this test. Please use the copy script to update the test binaries.

File Manifest

File | Location
Modm.exe – the main test binaries | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\
Ntlog.dll – the log library |


TermRace Test

Type: Automated Test

Overview

TermRace Test tests for race conditions during process/thread termination.

Details

The test verifies whether the data is consistent in race conditions during process/thread termination. It includes the following:

  • Children processes entry points for all APC tests.
  • Test variations for terminating threads/processes while having pending APCs.
  • Children processes entry points for all async IO tests.
  • Test variations for terminating threads/processes while having pending async I/O operations.

Run Time: Under 5 minutes
Log File: Modm.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: TermRace.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Computers that meets the minimum software requirements
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

TermRace.exe -all

Command option | Description
Test.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to be tested.
wdk_test.pro | The .profile file of test cases to be run.

Code Tour

File Manifest

File | Location
TermRace.exe – main test binaries | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\
Ntlog.dll – log library |


Object Callback Test

Type: Automated Test

Overview

The Object Callback Test tests for thread and process handle operations.

Details

This test verifies whether the process management callbacks function correctly.

Run Time: Under 5 minutes
Log File: ObCallbackTestCtrl.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: ObCallbackTestCtrl.exe -regr

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Computers that meets the minimum software requirements
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

ObCallbackTestCtrl.exe -regr [-t <test id>] [-?]

Command option | Description
appktsvc.exe | Without any options, the test lists usage.
-regr | Image load/unload events.

Code Tour

File Manifest

File | Location
ObCallbackTestCtrl.exe – the main test binaries | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\
ObCallbackTest.sys – the kernel mode driver |
Ntlog.dll – the log library |


Process Callback Test

Type: Automated Test

Overview

This test verify the process management callbacks functionalities. It includes the following:

  • Process create/exit events
  • Thread create/exit events
  • Image load/unload events

Details

Run Time: Under 5 minutes
Log File: Appktsvc.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: Appktsvc.log.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Computers that meets the minimum software requirements
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

appktsvc.exe all

Command option | Description
appktsvc.exe | Without any options, the test lists usage.
LoadImage | Image Load/Unload events.
CreateProcess | Process Create/Exit.
CreateThread | Thread Create/Exit.

Code Tour

File Manifest

File | Location
ObCallbackTestCtrl.exe – the main test binaries | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\
ObCallbackTest.sys – the kernel mode driver |
Ntlog.dll – the log library |


Registry Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


UNICODE Registry APIs

Type: Automated Test

Overview

This test exercises the basic registry operations using Unicode strings.

Details

The Basic Tests exercise the following APIs:

  • RegCloseKey
  • RegCreateKey
  • RegCreateKeyEx
  • RegDeleteKey
  • RegDeleteValue
  • RegEnumKey
  • RegEnumValue
  • RegOpenKeyEx
  • RegQueryInfoKey
  • RegQueryMultipleValues
  • RegQueryValue
  • RegQueryValueEx
  • RegRestoreKey
  • RegSaveKey
  • RegSaveKeyEx
  • RegSetValue
  • RegSetValue

Multi-Threaded Tests verify the concurrent behavior of basic registry APIs. They include the following steps:

  1. Create the same key on multiple threads at the same time. Using the Disposition value returned by RegCreateKeyEx, ensure that only one thread actually creates the key and all other threads open the key.
  2. Create or open the same key on multiple threads at the same time. Using the Disposition value returned by RegCreateKeyEx, ensure that only one thread actually creates the key and all other threads that attempt to create the key actually opens the key.
  3. Delete the same key on multiple threads at the same time. Ensure that only one thread succeeds.
  4. Delete or open the same key on multiple threads at the same time. Ensure that only one of the delete threads succeeds.
  5. Set a value with one thread while simultaneously querying for the same value in several other threads. Ensure the set value succeeds.
  6. Set the same value with several threads. Some of the threads will try to set the value’s data to "Multithread value" and the rest of the threads will try to set the value data to "Multithread second value." Ensure that after all threads run, the value data matches one of the two possible strings.
  7. Query the same value on multiple threads. Ensure that all queries succeed.

Notification Change Tests verify the registry notification mechanism. They include the following steps:

  1. Create a test key and register for notifications on the key handle returned.
  2. Perform one of the following operations, either on the test key or a subkey of the testkey:
    • RegCreateKey
    • RegDeleteKey
    • RegSetValue
    • RegDeleteValue
  3. Verify that the notification is triggered depending on options set when registering for notifications.
  4. There are two variations:
    • Create the test key under HKEY_CURRENT_USER\Software\Classes and then do the operations on the key through the alternate path of HKEY_CLASSES_ROOT. Notifications should be triggered just as they were in the original variation.
    • Create the test key under HKEY_LOCAL_MACHINE\Software\Classes and then do the operations on the key through the alternate path of HKEY_CLASSES_ROOT. Notifications should be triggered just as they were in the original variation.

Misc Parameter Tests verify that the registry handles the following scenarios correctly. They include the following steps:

  1. Pass in a null buffer and buffer size 0 for RegEnumValue, RegQueryValue, and RegQueryValueEx. Check that the returned buffer size is the correct size of the value’s data.
  2. Open a predefined handle by doing RegOpenKeyEx on the predefined handle with a NULL key path. Verify that a value created under the predefined handle can be queried through the handle returned by open key.
  3. Create a value with value data size greater than 16k bytes. Check that creation succeeds and that value can be queried.

Alloc Tests verify that creating multiple keys and values succeed. They include the following steps:

  1. Create 100 keys under the same key. All creates should succeed.
  2. Create 100 values under the same key. All creates should succeed.
  3. Create 100 key where each is a subkey of the previous key. All creates should succeed.

Run Time: Under 5 minutes
Log File: Regbetau.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: Regbetau.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
Regbetau.exe -f <config file> | Runs the test using the configuration specified in the config file

Code Tour

File Manifest

File | Location
Regbetau.exe – main test binaries | [WTT\TestBinRoot]\nttest\basetest\kernel\cm
Param.lis – configuration file | [WTT\TestBinRoot]\nttest\basetest\kernel\cm
Ntlog.dll – logging library |


Get Set Key Security Test

Type: Automated Test

Overview

This test verifies the RegGetKeySecurity and RegSetKeySecurity APIs.

Details

RegGetKeySecurity Test: Call RegGetKeySecurity on the predefined handles and a subkey under each of them.

RegSetKeySecurity Test: Call RegSetKeySecurity on predefined handles and a subkey under each of them.

Invalid parameter tests for RegGetKeySecurity and RegSetKeySecurity:

  • NULL handle
  • INVALID_HANDLE_VALUE handle
  • Invalid SecurityInformation values for RegGetKeySecurity
  • Invalid pSecurityDescriptor value
  • Invalid lpcbSecurityDescriptor value for RegGetKeySecurity

Run Time: Under 5 minutes
Log File: GetSetKeySecurity.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: Reggetsetkeysec.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
reggetsetkeysec.exe | With no options, runs the test

Code Tour

File Manifest

File | Location
RegGetSetKeySec.exe – main test binary | [WTT\TestBinRoot]\nttest\basetest\kernel\cm
Ntlog.dll – logging library |


DeleteKeyEx Local

Type: Automated Test

Overview

This test exercises the DeleteKeyEx API.

Details

This test verifies whether DeleteKeyEx works correctly when the wow64 flags are specified in the samDesired field.

Run Time: Under 5 minutes
Log File: DeleteKeyEx.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: DeleteKeyEx.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
DeleteKeyEx.exe | Runs the test.

Troubleshooting

When looking at failures in this test, please be aware that this test behaves differently if it is run on a 32-bit machine versus a 64-bit machine.

Code Tour

File Manifest

File | Location
DeleteKeyEx.exe – main test binary | [WTT\TestBinRoot]\NTTEST\BASETEST\kernel\cm
Ntlog.dll – logging library |


NT Registry APIs Invalid Params Test

Type: Automated Test

Overview

This test verifies invalid parameters for the NT Registry APIs.

Details

The test calls the NT Registry APIs with invalid parameters.

Run Time: Under 5 minutes
Log File: Ntreginvprms.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: Ntreginvprms.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
NtRegInvPrms.exe | Without any options, runs the test.

Troubleshooting

Each invalid parameter test is an API call with all valid parameters except for one. After you identify the invalid parameter, you can reproduce the failure.

Code Tour

File Manifest

File | Location
NtRegInvPrms.exe – main test binary | [WTTTestBinRoot]\nttest\basetest\kernel\cm
Ntlog.dll – logging library |


NtLoadKeyEx

Type: Automated Test

Overview

This tests exercises the NtLoadKeyEx API.

Details

This test verifies that hives loaded with NtLoadKeyEx and various values for the TrustClass allow or disallow cross hive symbolic links as appropriate.

Run Time: Less than 1 minute
Log File: LoadKeyEx.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: LoadKeyEx.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
LoadKeyEx.exe | Runs the test.

Troubleshooting

NtLoadKeyEx is not a documented API and TrustClasses are not documented. If you have an error with this test and the error code is not due to insufficient system resources, please send it to the Registry Team to investigate.

Code Tour

File Manifest

File | Location
LoadKeyEx.exe – main test binary | [WTT\TestBinRoot]\NTTEST\BASETEST\kernel\cm
Ntlog.dll – logging library |


NtUnLoadKey2

Type: Automated Test

Overview

This test exercises the NtUnLoadKey2.

Details

This test uses NtUnloadKey2 to unload a hive.

Run Time: Less than 5 minutes
Log File: Ntunload2.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: Ntunload2.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
ntunload2.exe | Runs the test.

Code Tour

File Manifest

File | Location
ntunload2.exe – main test binary | [WTT\TestBinRoot]\NTTEST\BASETEST\kernel\cm
Ntlog.dll – logging library |


RegBadParameterTests-UNICODE

Type: Automated Test

Overview

This test verifies the Win32 Registry APIs (APIs prefixed with Reg).

Details

This test uses the following invalid parameters:

  • Invalid Handles (NULL, INVALID_HANDLE_VALUE, file handle, closed key handle, etc.)
  • Invalid Buffers (NULL, memory protected, kernel mode address, unallocated user mode address, etc.)
  • Invalid String Names (Nonexistent key names, strings with leading ‘\’ characters, etc.)

Run Time: Less than 5 minutes
Log File: RegBadParameterTestsU.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: RegbadparametertestsU.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
RegbadparametertestsU.exe | Runs the test.

Code Tour

File Manifest

File | Location
RegbadparametertestsU.exe – main test binary | [WTT\TestBinRoot]\nttest\basetest\kernel\cm
Ntlog.dll – logging library |


Registry Callback Tests

Type: Automated Test

Overview

This test exercises basic tests for a registry filter driver.

Details

This test includes the following tests. Each test is followed by the necessary steps to complete the test.

Altitude Conflict Test

  1. Register a callback with altitude 1000.
  2. Register another callback at the same altitude and check to see if it fails.
  3. CreateKey the Monitor Test.
  4. Register three of the same callbacks at altitudes 1000, 2000, and 3000. Set all three callbacks to “monitor” mode. This means the callback will do nothing but return STATUS_SUCCESS.
  5. Create a key, and check to see that it succeeds.
  6. Unregister the callbacks.
  7. Check that each callback was invoked appropriately based on its altitude.

CreateKey Block Test

  1. Register three of the same callback at altitudes 1000, 2000, and 3000.
  2. Set callback 1000 and 3000 to “monitor” mode. This means the callback will do nothing but return STATUS_SUCCESS.
  3. Set callback 2000 to “block” mode. This means the callback will return an error status.
  4. Create a key, and check to see if it fails.
  5. Unregister the callbacks.
  6. Check that each callback was invoked appropriately based on its altitude.

CreateKey Bypass Test

  1. Register three of the same callback at altitudes 1000, 2000, and 3000.
  2. Set callback 1000 and 3000 to “monitor” mode. This means the callback will do nothing but return STATUS_SUCCESS.
  3. Set callback 2000 to “bypass” mode. This means the callback will return an STATUS_CALLBACK_BYPASS and perform the operation on behalf of the registry.
  4. Create a key, and check to see that it succeeds.
  5. Unregister the callbacks.
  6. Check that each callback was invoked appropriately based on its altitude.

CreateKey Override Access Denied Test

  1. Create a key K1, and then set its DACL to give read only access.
  2. Create a key under K1. This should fail because of the read only DACL.
  3. Register three of the same callbacks at altitudes 1000, 2000, and 3000. STATUS_CALLBACK_BYPASS.
  4. Set callback 1000 and 3000 to “monitor” mode. This means the callback will do nothing but return STATUS_SUCCESS.
  5. Set callback 2000 to “access denied bypass” mode. This means that the callback will perform the operation from user mode, not be blocked by the read only DACL, and return.
  6. Create a key under K1,and check to see that it succeeds.
  7. Unregister the callbacks.
  8. Check that each callback was invoked appropriately based on its altitude.

CreateKey Override Block Test

  1. Register four of the same callbacks at altitudes 1000, 2000, 3000, and 4000.
  2. Set callback 1000 and 4000 to “monitor” mode. This means the callback will do nothing but return STATUS_SUCCESS.
  3. Set callback 2000 to “block” mode. This means the callback will return STATUS_UNSUCCESSFUL.
  4. Set callback 3000 to “override failure” mode. This means if the callback sees STATUS_UNSUCCESSFUL in the post operation callback, it will still perform the operation and return success.
  5. Create a key, and check to see that it succeeds.
  6. Unregister the callbacks.
  7. Check that each callback was invoked appropriately based on its altitude.

SetKeySecurity Bypass Test

  1. Register three of the same callbacks at altitudes 1000, 2000, and 3000.
  2. Set callback 1000 and 3000 to “monitor” mode. This means the callback will do nothing but return STATUS_SUCCESS.
  3. Set callback 2000 to “bypass” mode. This means the callback will return an STATUS_CALLBACK_BYPASS and perform the operation on behalf of the registry.
  4. Call RegSetKeySecurity to set the security descriptor of a key, and check to see that it succeeds.
  5. Unregister the callbacks.
  6. Check that each callback was invoked appropriately based on its altitude.

Transacted CreateKey Bypass Test

  1. Create a transaction T1.
  2. Create a key in the context of transaction T1. .
  3. Check that the key succeeds, and then delete it.
  4. Register three of the same callbacks at altitudes 1000, 2000, and 3000.
  5. Set callback 1000 and 3000 to “monitor” mode. This means the callback will do nothing but return STATUS_SUCCESS.
  6. Set callback 2000 to “bypass” mode. This means the callback will return an STATUS_CALLBACK_BYPASS and do the operation on behalf of the registry.
  7. Create a key in the context of transaction T1, and check to see if it succeeds.
  8. Commit the transaction.
  9. Unregister the callbacks.

Transacted CreateKey Bypass (No Commit) Test

  • Complete the same steps as the Transacted CreateKey Bypass test, but do not commit the transaction at the end.

Unregister Close Race Test

  1. Launch a thread that opens a test key, and then close the handle in a loop.
  2. In the original thread, register and unregister a callback 100 times.
  3. Signal the other thread to exit.

Save Restore Replace Test

  1. Create a key under the software hive.
  2. Register a callback at altitude 1000 and put it into “monitor” mode. This means the callback will do nothing but return STATUS_SUCCESS.
  3. Perform a RegSaveKey on the created key, and check to see that it succeeds.
  4. Perform a RegRestoreKey on the created key using the hive file created by RegSaveKey, and check to see that it succeeds.
  5. Make a copy of the hive file.
  6. Load the original hive file under HKLM, and check to see that it succeeds.
  7. Perform a RegReplaceKey using the copy of the hive file. This should fail with a sharing violation, but will still trigger the callbacks for this operation.
  8. Unregister the callback, and verify that it was invoked appropriately.

Run Time: Less than 5 minutes
Log File: RegCbTestCtrl.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: RegCbTestCtrl.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
RegCbTestctrl.exe -regr | Runs the test.

Code Tour

File Manifest

File | Location
RegCbTestCtrl.exe – main test binary | [WTT\TestBinRoot]\NTTEST\BASETEST\kernel\cm
RegCbTest.sys – registry filter driver | [WTT\TestBinRoot]\NTTEST\BASETEST\kernel\cm
Ntlog.dll – logging library |


Registry Symbolic Link Test

Type: Automated Test

Overview

This test exercises the creation, manipulation, and deletion of registry symbolic links.

Details

TSymbolic links are not documented fully and we discourage their use. If there is an issue with this test, please contact the Registry Team for diagnosis.

Run Time: Less than 5 minutes
Log File: Regsymlink.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: Regsymlink.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
regsymlink.exe | Runs the test.

Code Tour

File Manifest

File | Location
regsymlink.exe – main test binary | [WTT\TestBinRoot]\nttest\basetest\kernel\cm
InvalidSymlinkHive |
Ntlog.dll – logging library |


SaveKeyEx

Type: Automated Test

Overview

This tests verifies the RegSaveKeyEx API

Details

This test saves the HKEY_USERS\.DEFAULT hive to a file using the RegSaveKeyEx API with the REG_NO_COMPRESSION option. Then it loads the result hive file.

The second variation checks that RegSaveKeyEx fails when the Flags field has an invalid value.

Run Time: Less than 3 minutes.
Log File: SaveKeyEx.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: SaveKeyEx.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
SaveKeyEx.exe | Runs the test.

Code Tour

File Manifest

File | Location
SaveKeyEx.exe | [Wtt\testbinroot]\nttest\basetest\kernel\cm
Ntlog.dll – logging library |


ShellReg APIs Unicode Test

Type: Automated Test

Overview

This test exercises the newer win32 registry APIs added in Windows Vista.

Details

The test performs functional and invalid parameter tests on the following APIs:

  • RegSetKeyValue
  • RegDeleteKeyValue
  • RegDeleteTree
  • RegCopyTree
  • RegGetValue

Run Time: Less than 5 minutes
Log File: ShregapisU.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: ShregapisU.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
shregapisU.exe | Runs the test.

Code Tour

File Manifest

File | Location
shregapisU.exe – main test binary | [WTT\TestBinRoot]\NTTEST\BASETEST\kernel\cm
Ntlog.dll – logging library |


Transactional Registry Wow Regressions

Type: Automated Test

Overview

This test performs registry operations on redirected keys in the context of a transaction.

Details

On 32-bit machines, there is no 64-bit view of the registry. Therefore, specifying the KEY_WOW64_64KEY or KEY_WOW64_32KEY flags is meaningless and always indicates the key in the 32-bit view. In the variations, if the machine is 32-bit, completing an action in one view affects the other view because there is only one view.

The three different variations are listed below, along with the actions associated with each.

Variation 1

  1. In the context of a transaction, open a key in the 32-bit view of the registry and make the changes.
  2. Check that the changes cannot be seen from the context of another transaction or from outside of the context of a transaction in either view of the registry.
  3. Commit the transaction, and check that the changes can now be seen from the context of another transaction and from outside of the context of a transaction in the 32-bit view of the registry.
  4. Complete the above steps again, but roll back the transaction. Make sure that the changes are not present on either view of the registry.
  5. Complete the above steps on the 64-bit view of the registry.

Variation 2

  1. In the context of transaction T1, open a key in the 32-bit view of the registry.
  2. In the context of transaction T1, open a key in the 64-bit view of the registry.
  3. Make changes to both keys.
  4. Verify that the changes are not visible in either view from inside or outside the context of another transaction.
  5. Commit transaction T1. Check that the appropriate change is now seen on the appropriate registry view from both inside and outside the context of another transaction.
  6. Complete the above steps, but rollback transaction T1. Check that changes not visible on either side of the registry from both inside and outside the context of another transaction.

Variation 3 (Only run on 64-bit machines)

  1. In the context of transaction T1, open a key in the 32-bit view of the registry.
  2. n the context of transaction T2, open a key in the 64-bit view of the registry.
  3. Make changes to both keys.
  4. Verify that the changes are not visible in either view from inside or outside the context of another transaction.
  5. Commit transaction T1 and T2. Check that the appropriate change is now seen on the appropriate registry view from both inside and outside the context of another transaction.
  6. Complete the above steps, but rollback transaction T1 and T2. Check that changes not visible on either side of the registry from both inside and outside the context of another transaction.

Run Time: Less than 5 minutes
Log File: Txrwow.log
System Restart Required: No
Test Category: Kernel Mode Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: Txrwow.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Software components included with the device that is being tested
Hardware Requirements
  • Device to be tested
  • Computers that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

All test cases return PASS or FAIL. Search for the term “+sev” in the log file for failures.

Command Syntax

Command option | Description
txrwow.exe | Runs the test.

Code Tour

File Manifest

File | Location
txrwow.exe – main test binary | [WTT\TestBinRoot]\NTTEST\BASETEST\kernel\cm
Ntlog.dll – logging library |


Kernel Anti Virus Filters Testing

Kernel Anti Virus Filters Testing Overview
Preparing for Kernel Anti Virus Filters Testing
Running the Kernel Anti Virus Filters Tests
Troubleshooting Kernel Anti Virus Filters Testing
Kernel Anti Virus Filters Tests


Kernel Anti Virus Filters Testing Overview

The procedures presented in this section outline the process for testing your Kernel Filter Anti Virus for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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 logo testing.
  • Running: The running topics describe how to run to run the tests for your device or system.

Kernel Filter Anti Virus Tests

The list of test you need to run depends on 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 Kernel Anti Virus Filters Tests.

Run time: Approximately 4 hours.

Hardware requirements

The following hardware is required for Kernel Filter Anti Virus 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 machine running client or server Windows 7 SP1 or Windows 2008 R2 SP1
  • Another server Windows 2008 R2 SP1 machine

Software requirements

The following software is required to run the Kernel Filter Anti Virus tests:

  • The AV filter driver under test

Tester knowledge requirements

To run the Kernel Filter Anti Virus tests, testers must know how to accomplish the following tasks:

  • Edit a DTM job to provide volume info in the parameters section.
  • Create a remote share on a server.


Preparing for Kernel Anti Virus Filters Testing

Before running the tests, you must first 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 Kernel Anti Virus Filters Testing Overview.

Many of the tests in the Windows Logo 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.

Test system configuration

To configure the test system, follow these steps:

Note Please refer to the following table to see the letter assignment for each volume:
NTFS | g:
CNTFS | i:
Fat16 | k:
Fat32 | l:
ExFat | m:
UDF | n:

  1. On the client machine, several volumes need to be present (NTFS 2gb, ntfs compressed 2gb, fat16 1gb, Fat32 1gb, Exfat 1gb, UDF 2gb).
  2. In the controller, modify the parameters on the jobs undef $\WDK Tests\Storage\Filesystems\ to point to test volumes, as follows:
    1. TxF2: Modify ntfs and cntfs to point at test volumes.
    2. ReparsePoints: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    3. Installable Filesystems filter test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    4. Antivirus Installable Filesystems filter test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    5. File IO test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    6. Mapped File IO test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    7. Object ID test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    8. Oplocks test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
    9. Syscache test: Modify ntfs, cntfs, fat, fat32, exfat, udf to point at test volumes.
  3. On the server, create share RDRTest.
  4. Modify the parameters on $\WDK Tests\Leasing\SMB_OplockRDR test to point at the server name and share name.


Running the Kernel Anti Virus Filters Tests

Submit the job under Devices, Kernel Filter AV, Logo.


Troubleshooting Kernel Anti Virus Filters Testing

Follow the log output for the test result.


Kernel Anti Virus Filters Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


IFS AntiVirus Test

Type: Automated Test

Overview

The installable file system test antivirus suite checks that the behavior in the file system stack is consistent with the File System Behavior Overview and the presence of an antivirus filter.

More information about File System Behavior is available at http://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf.

Details

Documentation for the test variations can be found at http://msdn.microsoft.com/en-us/library/ff563405(VS.85).aspx

Run Time:1 hour
Log File:
Ifstest-Virus-NtfsResults.log
Ifstest-Virus-CntfsResults.log
Ifstest-Virus-Fat16Results.log
Ifstest-Virus-Fat32Results.log
Ifstest-Virus-ExFatResults.log
Ifstest-Virus-UDFResults.log
System Restart Required: Yes
Test Category:Kernel Mode Antivirus Filter Drivers
Supported operating systems for Logo or Signature testing:

  • Windows 7 SP1

  • Windows Server 2008 R2 SP1

Program: IFSTest.exe /g Virus

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)
  • Filter driver to be tested, along with any supporting application suite
Hardware Requirements
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • Extra hard drive space for four simple 2048 mb partitions and two simple 1024 mb partitions
Processor

The test tool runs on the following processor architectures:

  • x86
  • x64

Running the Test

Before running the test, the following partitions need to be added to the Windows environment:

Label | File System | Size | Expected Drive Letter
NTFS | ntfs | 2048mb | g:
CNTFS | ntfs (compressed) | 2048mb | i:
FAT | Fat16 | 1024mb | k:
FAT32 | Fat32 | 1024mb | l:
ExFAT | ExFat | 2048mb | m:
UDF | UDF | 2048mb | n:

When executed, the test will run variations for each of the six partitions above.

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

If there is a policy on the test system of locking out new accounts, the IFS test might return "blocked" on the multiprocess variations if the local machine account "ifstest" is locked out.

Please use account manager to unlock the account and rerun the suite.

RunIFStest.cmd contains references to environment variables that can be changed to allow for skipping of certain file systems.

Command Syntax

Command option | Description
IfsTest.exe | -g Virus /n .\Ifstest-Local-NtfsResults.log /N 356789AB /T /p /m /E /j /r c: -d \Ntfs -a \datacoh.exe /u ifstest /U *rw53w5
-g <suitename> | Do not run <suitename>
/n <logname> | Create a long of name <logname>
/N

Specify NTLOG levels. If not included, then the GUI dialog box appears. This is useful in a batch mode run of the test

NTLOG Levels:

1 ABORT
2 SEV1
3 SEV2
4 SEV3
5 WARN
6 PASS
7 BLOCK
8 INFO
9 SYSTEM INFO
A DEBUG INFO
B TEST
/T | Enable trace of tests being done
/p | Enable pagefile testing in CreatePagingFileTest
/m | Enable dirty bit testing in MountedDirtyTest
/E | Enable AllowExtendedDASDTest
/j | Enable support for tests involving the change journal
/r <volumeletter> | Path to second volume required in certain tests
-d <> | System Path to FSD device object in FileSystemDeviceOpenTest.
-a | Provide path to executable
/u | Username for test account
/U | Password for test account
/t <variation> | Execute only one named variation

Troubleshooting

The tests should be able to create a temporary local machine account (ifstest). They also expect to have additional partitioned volumes.

Use a tool such as minispy to see what irps are traveling on the file system stack. Compare passing (default Windows install) with installs, including any failing driver.

For information about File System Behavior, go tohttp://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf.

For documentation about the test variations, go tohttp://msdn.microsoft.com/en-us/library/ff563405(VS.85).aspx

Code Tour

File Manifest

File | Location
ntlog.dll | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
ntlogger.ini | [WTT\TestBinRoot]\NTTest\CommonTest\Ntlog\
chg.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
chgfile.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
chgnotif.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
cleanupfiles.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
closedel.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
createkc.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
datacoh.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
decrypt.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
defrag.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
devctrl.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
dirinfo.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
dirpt.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
eainfo.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
encrypt.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
encryptvirus.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
enum.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
esecurit.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
estream.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
fileinfo.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
filelock.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
forcedis.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
fsctlgen.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
fsctlvol.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
IFSCFG.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifsmsg.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest-av.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest-av_wdk.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstestcleanup.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest_storagelogo.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ifstest_wdk.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ishell.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
linkpt.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
linktrak.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
mfile.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
mountpt.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
objectid.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
opcreatg.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
opcreatp.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
oplocks.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
quotas.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
readwr.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
reparspt.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
ResetAutoLogon.vbs | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
restoresystem.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
seccache.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
securit.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
setupsystem.cmd | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
skel.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
sparse.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
virus.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
volinfo.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
writevirus.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
xchg.exe | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
guidefile.dat | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\virusfiles\
virusfile1.evf | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\virusfiles\
virusfile2.evf | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\virusfiles\
virusfile3.evf | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\virusfiles\
virusfile4.evf | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\virusfiles\
createwttlog.vbs | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\LFS_Automation\common\
chgjourn.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\IFS_TEST_KIT\
fbslog.dll | [WTT\TestBinRoot]\NTTest\basetest\core_file_services\shared_libs\fbslog\
RunIFSTests.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
WrapIFSTests.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\
attachfilter.cmd | [WTT\TestBinRoot]\NTTest\BASETEST\Core_File_Services\FilterManager\TestSuite\Scripts\FileSystems\

Test Assertions

The tests expect the partitions to be in place.


Network Controller Testing

This section describes how to test network controllers to qualify them for the Windows logo. To complete logo testing, you must install and run Driver Test Manager (DTM) and set up your testing environment. For information about installing and configuring DTM, see Install the DTM.

This section includes information about the following types of network controllers:

Lightweight Filter

LAN (Ethernet)

Router

Wireless LAN (802.11)

Mobile Broadband Network

Wireless Router

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."

Note To troubleshoot the NDISTest, try attaching a debugger to the test machine.


Lightweight Filter Testing Overview

The procedures in this section outline the process for testing your NDIS Lightweight Filter driver for correct 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 DTM identifies as required for the device.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Using the Test Procedure Help Topics

The test procedures in this section 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 Windows logo testing.

Running: The running topics describe how to run the tests for your device or system.

Run time: approximately 1 hour

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

DTM Setup for Lightweight Filter Device Testing

A DTM setup for NDIS Lightweight Filter driver testing consists of three parts: DTM Controller, DTM Studio, and DTM clients.

You can use DTM Studio to schedule the filter driver test job on the DTM clients that are registered on the DTM Controller. The following steps summarize the scheduling procedure:

  1. Type all of the information that the filter driver test job requires into DTM Studio, and schedule the job.

    Note The Lightweight filter test job requires only one DTM client machine.

  2. DTM Studio sends job configuration information to the DTM Controller, which reserves a DTM client and dispatches the job to it.

  3. The DTM client runs the job. It first copies NDISTest, which is the actual filter driver test tool, to the DTM client and runs NDISTest on the desktop of the current user.

  4. After the test is finished, the log files are gathered on the DTM Controller.

This section includes the following topics:

Preparing for Lightweight Filter Driver Testing

Running the Lightweight Filter Driver Tests


Preparing for Lightweight Filter Driver Testing

After you install the DTM Controller, DTM clients, and DTM Studio, you can monitor the status of the DTM client machines through DTM Studio. The DTM clients are grouped into logical machine pools that the DTM Controller machine monitors. New DTM client machines are automatically put into the default pool.

You must create your own machine pool to hold the DTM client machines for filter driver testing. Before the filter driver test can be started, you must complete the following steps:

  1. Drag the DTM client machine from the default pool into your machine pool and wait for its status to change to Ready.

  2. Install two virtual miniport drivers for the Lightweight Filter test. The Lightweight Filter logo program requires the filter driver to be attached over the designated virtual miniport drivers provided by Microsoft. To install the virtual miniport drivers, schedule the DTM job called Install Virtual Miniport for the Lightweight Filter Test on the test machine. The DTM job is located under the feature "$\WDK Tests\Networking". Because two instances of the virtual miniport drivers are required, the installation job has to be scheduled twice. The following figure shows an ongoing installation of the two virtual miniport drivers.

    Screen shot of the Job Monitor dialog box displaying the filter, machine name, and job and task execution status

  3. Install the filter driver on the DTM client machine. After installing the filter driver under the test, make sure that it is attached to the virtual miniport drivers that you installed in Step 3. You can find out whether the filter driver is attached to the virtual miniport drivers by checking the connection property of the virtual miniport as shown by the following screen shot:

    Screen shot of the Local Area Connection Properties dialog box with Client for Microsoft Networks selected

  4. To troubleshoot the NDISTest, try attaching a debugger to the test machine.


Running the Lightweight Filter Driver Tests

To schedule the Lightweight Filter driver tests, you can use the Device Console window in DTM Studio.

The following logo submission procedure demonstrates how to run the filter driver tests:

  1. Open DTM Studio.

  2. On the Explorers menu, click Device Console. (You can also switch to the Device Console window by clicking the Device Console tab in the lower left corner of DTM Studio.)

    Screen shot of the Device Console dialog box

  3. In the View By area, click Submission, and then in the Submission list, click <New Submission>.

    Screen shot of the Device Console dialog box displaying the Create New Submission dialog box

  4. In the Create New Submission dialog box, click Windows Vista Client, and click Next.

    Screen shot of the Create New Submission dialog box with Windows Vista Client selected

  5. Click Device Submission, and click Next.

    Screen shot of the Create New Submission dialog box with Device Submission selected

  6. Click Network > Filter LAN (Ethernet), and click Next.

    Screen shot of the Create New Submission dialog box with Network > Filter LAN (Ethernet) selected

  7. Click Basic, and click Next. Note that for the Lightweight Filter you should only run the Basic qualification level. Do not run the Premium qualification level.

    Screen shot of the Create New Submission dialog box with Basic selected

  8. In the Name for new submission box, type a name for the submission, and then click the machine pool that the submission will be associated with. Click Next.

    Screen shot of the Create New Submission dialog box with NDIS Sample Filter in the Name box

  9. In the Driver Install File (INF) box, click Browse to find the INF file, and then click the Load button.

    Screen shot of the Create New Submission dialog box with a path entered in the Driver Install File (INF) box

  10. Review the summary page to make sure the information is correct, and then click Finish.

    Screen shot of the Create New Submission dialog box listing the names and values for the new submission

  11. In the Available Devices area of the Device Console window, click a test device from the machine pool you have previously created. In the Available Jobs box, right-click a logo job, and click Add Information.

    Screen shot of the Device Console dialog box with the Add Information command selected

  12. In the Job extension dialog box, do the following:

    Screen shot of the Job extension dialog box listing the machine name, the test device, and the support device

    1. In the Test Device list, click NDISTest 6.0 - CL - IM/Filter Test
    2. In the Support Device list, click NDISTest 6.0 - CL - IM/Filter Test #2
    3. Click Save.

    The Test Device and Support Device are the two virtual miniport drivers that you installed during the Preparing for Light Weight Filter Test, Step 3.

  13. Click Add Selected to add the job to the configured job list.

After you complete the preceding steps, the job is ready for scheduling. After you click Schedule Jobs, the DTM Studio will send the job to the DTM Controller and dispatch the job on the designated DTM client machine.


LAN (Ethernet) Testing Overview

The procedures that are presented in this section outline the process for testing your LAN device for correct 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 DTM identifies as required for the device.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Note Windows Server 2008 R2 is supported.

The test procedures in this section 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 Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

  • Troubleshooting / Frequently Asked Questions: The troubleshooting topics describe how to diagnose and fix common problems encountered while you test LAN (Ethernet) devices.

LAN Device Tests

The tests that you must run depend on the capabilities of the device or system that you are testing. The DTM determines which tests are applicable for your device based on the information collected for your device by DTM. To see the complete list of tests that you might need for your device, see LAN Device Tests.

Run time: approximately 12 hours

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device. Additionally, run Storage > Adapter and LAN (Ethernet) test submissions for Windows Server 2008 on systems with a minimum of 4 processor cores and 6 gigabytes of memory. These requirements are in addition to those related to the Dynamic Partitioning (DP) Simulator and Test that all Windows Server 2008 device driver submissions must meet.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

DTM Setup for LAN (Ethernet) Device Testing

On a conceptual level, in order to test a LAN (Ethernet) networking card, two computers must be used. One computer is needed to hold the device under test and another computer and network device is needed to receive and send data to the device under test while testing is in progress. Additionally, there must be a separate line of communication between the two computers that will be used to exchange information about ongoing tests. For example, on a send test it is beneficial for the receiver of the data to know how much traffic to expect from the sender.

A DTM setup for LAN (Ethernet) device testing consists of a DTM controller, DTM Studio, and DTM clients.

The following figure shows the relationship between these computers.

Note DTM Studio and the DTM controller can be running on one computer to reduce the cost of the setup.

Diagram of a DTM Setup for LAN (Ethernet) Device Testing

Here is a summary of each computer in the figure, devices installed in them, and the computer role during testing:

  • DTM Studio computer - Used to manage all the DTM client computers during testing. See DTM Studio

  • DTM Controller computer - Used to control DTM client computers and gather all test information from them. See DTM Controller.

  • DTM Client 1 computer - This computer, during the LAN device testing, is referred to as the remote test machine, or NDISTest server. This computer contains the following network devices:
    • Remote support device - A device that communicates with the DTM controller. This device also communicates the test status information to the local support device in the local test machine via the support network.
    • Remote message device - A device that communicates with the local test device in the local test machine via the test network.
  • DTM Client 2 computer - This computer, during the LAN device testing, is referred to as the local test machine, or NDISTest client. This computer contains the following network devices:
    • Local test device - This is the device under test. During testing it communicates to the remote message device in the remote test machine via the test network.
    • Local message device - This device communicates with the DTM controller. It also communicates test status information to the remote support device in the remote test machine via the support network.
    • Other local devices - "NDISTest 6.5 (PM and WoL)" job requires any local device other than local test device and local support device to be disconnected from the network.

You can use DTM Studio to schedule the LAN device test job on the DTM clients that are registered on the DTM controller. The following steps summarize the scheduling procedure:

  1. Enter all of the information that the LAN device test job needs into DTM Studio, and schedule the job.

    The LAN device test job requires two DTM client machines. For logo submission, you will also need three identical network cards. These requirements are enforced when you configure the DTM job.

  2. DTM Studio sends job configuration information to the DTM controller, which reserves the DTM clients and dispatches the job to them.

  3. The DTM clients run the job. They first copy NDISTest, which is the actual LAN device test tool, to the DTM clients and run NDISTest on the desktop of the user that is currently logged in.

  4. After the test is finished, the log files are gathered and copied on the DTM controller.

WLK 1.2 Update

  • The NDISTest 6.0 "2c_priority" script has been removed and separated into its own job to enable running the NDISTest 6.0 with a crossover cable between the test and support adapter. This change is to address the difficulty some vendors experienced with the switch stripping the priority header. The new job is named "NDISTest 6.0 (Priority)"

  • The NDISTest 6.5 "LinkCheck", "PowerManagement", "WoLMagicPacket", and "WoLPattern" scripts have been removed and separated into their own jobs.
    • The "NDISTest 6.5 (Manual)" job now runs only the "LinkCheck" test. This is the only manual LAN script. This change is to ease the tester's job of pulling the cable by providing discreet scheduling.
    • The "NDISTest 6.5 (PM and WoL)" job now runs the Power Management and Wake-on-LAN tests (PowerManagement, WoLMagicPacket, and WoLPattern). This change is to enable running the test on a machine that more readily supports power management and Wake-on-LAN. The machine does not need to be a multiprocessor machine.
  • Two new jobs have been added to NDISTest 6.5.
    • The "NDISTest 6.5 (Premium)" job tests to verify the support of six Wake-on-LAN patterns.
    • The "NDISTest 6.5 (MPE)" job is a new testing methodology (Multi-path Exerciser) that repeatedly schedules multiple tasks in parallel looking for severe driver failures. The tasks perform activities such as sending and receiving packets, resetting the driver, manage power on the host machine, query OIDs, pause and restart the driver, and halt and initialize the driver. Some of these problems can be difficult to diagnose and MPE has proven to be an effective test at diagnosing them.

This section includes

Preparing for LAN (Ethernet) Testing

Running the LAN (Ethernet) Tests


Preparing for LAN (Ethernet) Testing

After you install the DTM controller, DTM clients, and DTM Studio, you can monitor the status of the DTM client machines through DTM Studio. The DTM clients are grouped into logical machine pools that the DTM controller monitors. New DTM client machines are automatically put into the default pool.

You must create your own machine pool to hold the DTM client machines for LAN (Ethernet) device testing. Before the LAN(Ethernet) testing can be started, you must drag the DTM client machine from the default pool into your machine pool and wait for its status to change to Ready.

To troubleshoot the NDISTest, attach a debugger to the test machine.


Running the LAN (Ethernet) Tests

To schedule the LAN (Ethernet) device tests, you can use the Device Console window in DTM Studio.

The following logo submission procedure demonstrates how to run the LAN device tests:

  1. Open DTM Studio.

  2. On the Explorers menu, click Device Console. (You can also switch to the Device Console window by clicking the Device Console tab in the lower left corner of DTM Studio.) Screen shot of the Device Console dialog box

  3. In the View By area, select Submission, and then in the Submission list, click <New Submission>. Screen shot of the Device Console dialog box displaying the Create New Submission dialog box

  4. Click Windows Vista Client. Screen shot of the Create New Submission dialog box with Windows Vista Client selected

  5. Click Device Submission. Screen shot of the Create New Submission dialog box with Device Submission selected

  6. Click Network > LAN (Ethernet). Screen shot of the Create New Submission dialog box with Network > LAN (Ethernet) selected

  7. Click Basic.

    Screen shot of the Create New Submission dialog box with Basic selected

  8. In the Name for new submission box, enter a name for the submission, and then select the machine pool that the submission will be associated with. Screen shot of the Create New Submission dialog box with Lan Submission entered in the Name box

  9. In the Driver Install File (INF) box, locate the device's INF file. Screen shot of the Create New Submission dialog box with a path displayed in the Driver Install File (INF) box

  10. Review the summary page to make sure the information is correct, and then click Finish. Screen shot of the Create New Submission dialog box listing the name and values of the new submission

  11. In the Available Devices area of the Device Console window, select a test device from the devices that appear. In the Available Jobs area, place a check next to the logo job, then right-click the logo job, and click Add Information. Screen shot of the Device Console dialog box displaying the new LAN (Ethernet) job

    The Job extension dialog box will open.

  12. In the Job extension dialog box, do the following:

    Screen shot of the Job extension dialog box

    1. In the Local Support Device area, select the support test device that is connected to the Test network Switch.
    2. From the Local Message Device list, select a device that is connected to the Message network Switch.
    3. In the Remote Machines area, select the computer (DTM Client 1) which hosts the Remote Support Device.
    4. In the Remote Support Device area, select the support test device that is connected to the Test network Switch.
    5. In the Remote Message Device list, select the device that is connected to the Message network Switch.
    6. Click Advanced Test Device Info to provide additional information of the test device. A detailed description of Advanced Test Device Info is given later in this subsection.
    7. Click Save.

    Note The Local Test Device, Local Support Device, and Remote Support Device entries must be identical. This rule is the requirement of the logo submission. Although the Job extension dialog box does not enforce this policy, the actual test will fail if the three network devices are not the same.

    The Advanced Test Device Info button gives the user a chance to provide more information about the device under test. After you click the button, the Advanced Options dialog box appears.

    Screen shot of the Advanced Options dialog box

    The following table provides a detailed description of every property in the Advanced Options window.

    PropertyName Type Default value Description

    CardBusAdapter

    Bool

    False

    Is the device under test a Card Bus device?

    DisconnectSupported

    Bool

    True

    Can the device under test generate disconnect and subsequent connect events under any scenario?

    FiberOpticDevice

    Bool

    False

    Is the device under test using Optical Fiber as the transmission medium?

    MapsExternalIoSpace

    Bool

    False

    Does the device under test map IoSpace that falls outside of the range assigned to the device by the operating system?

    MultipleDeviceInstancesSupported

    Bool

    True

    Can two instances of the device under test be installed on a single machine?

    SupportNdisScatterGatherDma

    Bool

    True

    Virtual network drivers should set to False as they are not required to support Scatter Gather DMA.

    SystemIntegratedDevice

    Bool

    False

    Is the device under test physically integrated on the system you are testing with and cannot be used on any other system?

    The information provided in the Advanced Options dialog box helps NDISTest adjust its test cases to fit the capabilities of the test device. For example, if MultipleDeviceInstancesSupported is set as False, the NDISTest does not require the existence of the local support device during the logo submission. The default values of the properties should fit most LAN Ethernet devices.

    After the user clicks Save on the Job Extension UI, the data in Advanced Options persists on the machine where the DTM Studio is installed. When a user launches a job more than once for the same test device, they do not have to add these properties again.

  13. Click Add Selected to add the job to the configured job list. Screen shot of the Device Console dialog box displaying the new LAN Ethernet job

After you complete the preceding steps, the job is ready for scheduling. After you click Schedule Jobs, DTM Studio will send the job to the DTM controller and dispatch the job on the designated DTM client machines. You can also put multiple configured jobs into the configured job list first, and then schedule them in one batch.


Troubleshooting LAN (Ethernet) Testing

  1. The "Ethernet NDISTest xx" jobs stay in the "Scheduler" status and never get run:

    This problem is usually caused by various communication issues between the DTM client and the controller. You can check whether the "Last Heartbeat time" is close to the current time. To force the DTM client that is reporting a heartbeat, you can manually change the status of the machine to Reset or Unsafe in the DTM Studio, and then wait until the status of the machine changes back to "Normal". After the status of all machines that are required to run the job is changed to Normal, the job will be scheduled on the DTM clients. If the machine status changes to Debug, verify whether the DTM client machine is still responsive. Sometimes, the machine status is Normal and the heartbeat is correct, but the job still won't run. This is most likely caused by the firewall or IPsec blocking the communication between the DTM client and the controller. Make sure that the DTM client and controller have the same IPsec configuration. If the client has IPsec turned on but the controller turned off, or vice versa, the job will not get scheduled. The DTM client is designed to work with a firewall, but sometimes the firewall blocks normal traffic between the client and the controller. Try to turn off the firewall on both DTM client and DTM controller and see if that solves the problem.

  2. "The Job xxx requires a device to be selected, not a driver" when clicking "Add Information":

    The error happens because you have selected a driver, not a test device, in the Device Console to run the test job. If you cannot find a device under the driver in the Device Console, the INF file and driver files that you provided during the logo submission do not match the actual INF file and driver files on the DTM client. You should update your INF file and driver files by using the actual INF file and driver files installed on the DTM client.

  3. No "Ethernet NDISTest xxx" job shows up in the "Device Console":

    Make sure your device is an Ethernet (LAN) device and report media type to NDIS as NdisMedium802_3. This error sometimes happens when the hardware information reported by the DTM client is incomplete. You can reboot the DTM client machine, and then refresh the view of Device Console to solve this problem. Another option is to stop and restart the "wttsvc" service on the DTM client, and then refresh the view of Device Console.

  4. To troubleshoot the NDISTest, try attaching a debugger to the test machine.


Router Logo Program Test Lab Setup (non-wireless)

The following documentation outlines procedures that are specific to the Router Logo program for routers that don't support wireless. This should be viewed as supplementary documentation to the standard Driver Test Manager (DTM) setup documentation.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Prerequisites

To create a Router Logo submission, you must have the following setup configured using the standard DTM setup documentation.

  • DTM controller

  • DTM Studio running on a computer on the same network as the DTM controller

  • Four DTM client machines (specific configuration and system requirements will be described in detail in the following section)

  • A minimum of two 100 mbit hubs (You might need more depending on the number of available Ethernet ports on the device under test)

The rest of this documentation assumes that the DTM controller, Studio, and clients are properly configured. This means that the controller has the proper permissions set, the studio is able to connect to and execute jobs on the controller, the clients are added to a machine pool, and all clients are working in the ready state.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Machine Requirements and Configuration

Among the four DTM client machines, there are three individual configurations. Therefore, two of the client machines are set up identically. These machines are designated as LAN1, LAN2, WAN1, and WAN2. All system requirements are in addition to minimum system requirements for Windows Vista and the DTM test suite. The following network schematic shows how each machine is connected in the network.

Diagram of machine requirements and configuration

Router

  • Make sure the DHCP server for the router is enabled.

  • You must set the WAN port to this static IP address: 17.1.1.1.

  • Make sure UPnP setting is enabled, if it's not enabled by default.

Machines LAN1 and LAN2

System Requirements:

  • The x86-based version of Windows Vista Client

  • Three 10/100 Ethernet Cards
    • At least one of the three must support QOS 802.1p

Both of these machines, LAN1 and LAN2, have an identical setup procedure. Complete the following steps for each machine:

  1. Connect two of the Ethernet cards to the LAN side of the router via Ethernet cable. One of these two must be QOS 802.1p-capable.

  2. Connect the third Ethernet card to the DTM network.

  3. Open the Network Connections folder (this can be done by clicking Manage Network Connections in Network Center).

  4. Rename the network connections such that:
    1. The connection to the DTM network is named DTM.
    2. The connection to the LAN side of the router with the QOS-capable interface is named LAN_P.
    3. The remaining interface that is connected to the LAN side is named LAN.

  5. Enable QOS 802.1p on the LAN_P connection (consult individual interface card manual if you are unsure how to do this)

  6. Make sure all of the connections are marked Private in the Network Sharing Center.

  7. Run the configuration jobs: Setup Machine LAN1 and Setup Machine LAN2 for Machine Lan1 and Machine2, respectively. These jobs will set Static IP addresses and setup machine dimensions for each machine as follows:
    Interface LAN1 LAN2

    LAN

    192.168.0.10

    192.168.0.20

    LAN_P

    192.168.0.11

    192.168.0.21

    DTM

    IP address assigned by DHCP

    IP address assigned by DHCP

  8. For each machine, run ipconfig in the command prompt window to verify that each interface has a correctly assigned IP address.

  9. To ensure IP connectivity on all interfaces, try to ping other addresses. If a firewall is enabled, open the ping exception via netsh firewall set icmpsettigns 8.

  10. Make sure that all network connections are set to Private in Network Center.

Machine WAN1

System Requirements

  • The x86-based version of Windows Vista Client

  • Two 10/100 Ethernet Cards

Use the following procedure to set up the WAN1 machine:

  1. Connect one Ethernet card to the WAN side of the router. Because most routers only have one port for the WAN interface, a hub can be used (as shown in the diagram).

  2. Connect the other Ethernet card to the DTM network.

  3. Open the Network Connections folder (this can be done by clicking Manage Network Connections in Network Center.

  4. Rename the network connections such that
    1. The connection to the DTM network is named DTM.
    2. The connection to the WAN side of the router is named WAN.

  5. Run the Setup Machine WAN1configuration job. These jobs will set static IP addresses and set up machine dimensions as follows:
    Interface WAN1

    WAN

    17.1.1.10

    DTM

    IP address assigned by DHCP

  6. Run ipconfig in a command prompt window to verify that each interface has a correctly assigned IP address.

  7. Make sure that all interfaces have an IP connection. If a firewall is enabled, open the ping exception via: netsh firewall set icmpsettigns 8.

  8. Ensure that all network connections are set to Private in Network Center.

Machine WAN2

System Requirements

  • The x86-based version of Windows Vista Client

  • Three 10/100 Ethernet Cards

Use the following procedure to set up the WAN2 machine:

  1. Connect two of the Ethernet cards to the WAN side of the router. A switch can be used to accomplish this.

  2. Connect the remaining Ethernet card to the DTM network.

  3. Open the Network Connections folder (this can be done by clicking Manage Network Connections in Network Center).

  4. Rename the network connections such that
    1. The connection to the DTM network is named DTM.
    2. The connections to the WAN side of the router are named WAN1 and WAN2.

  5. Run the Setup Machine WAN2 configuration job. These jobs will set static IP addresses and set up machine dimensions as follows:
    Interface WAN2

    WAN1

    17.1.1.20

    WAN2

    17.1.1.21

    DTM

    IP address assigned by DHCP

  6. Run ipconfig in a command prompt window to verify that each interface has a correctly assigned IP address.

  7. Make sure that all interfaces have an IP connection. If a firewall is enabled, open the ping exception via: netsh firewall set icmpsettigns 8

  8. Ensure that all network connections are set to Private in Network Center.

Machine Pool Configuration

Proper setup of the machine pool is vital. When the machine pool is not properly configured, scheduled jobs will stay in the status Scheduler. When you properly configure the machine pool, the DTM controller can assign each individual task to the correct machine. For each of the four machines in the pool, a configuration job must be run. This job will set Dimensions on that machine, which will describe its role in the network.

To run the configurations job, do the following on each machine in the pool:

  1. Open DTM Studio.

  2. On the Explorers menu, click Job Explorer.

  3. On the left side, select the correct machine pool.

  4. Right-click the machine, and click Schedule.

  5. Click Browse, and then click the job Setup Machine XYZ found under WDK Tests\Networking\Routers\Configuration (where XYZ correspond to LAN1, LAN2, WAN1, and WAN2).

  6. For LAN1 and LAN2: Type the MAC address of the LAN side interface of the wireless router in the Value field for the IGD_Mac parameter.

  7. Click Start.

Creating a Submission

In order to receive a logo for the Router Logo Program, you must create a submission that contains all of the run tests. There are three steps to doing this: creating a new submission, running the tests, and then creating a submission package to send to Microsoft.

To create a new submission, use the DTM Studio.

  1. UOn the Explorers menu, click the Device Console.

  2. Select New Submission.

  3. When the Submission Wizard appears, click Windows Vista Client.

  4. Click Device Submission, and then click Next.

  5. Click Network > Router, and then click Next.

  6. Choose Basic or Premium based on desired logo.

  7. Select the machine pool that you have previously configured to run these tests.

  8. Type a name for the submission (preferably the device name), and then click Next.

Next, run each test individually. After you have created a new submission, you will notice that the right pane will be filled with many test names with check boxes beside them. You can select more tests, and click Add Selected. After selecting a test, you might need to edit a parameter in order for the test to run properly. To do this, right-click the job and click Edit Parameters. More information about how to edit parameters can be found in the individual instructions for each category of tests later in this document. Once you have done so, click Schedule Jobs. Go to the job monitor and wait for the job to finish. After the job finishes, you can run the next test. Some of the tests have special requirements that must be fulfilled before they can be run. In the next section, there is a list of those requirements for each specific test or test category. Pay close attention to these requirements. Failing to do somight result in unexpected failures.

LLTD Responder Verification Tests

All LLTD tests start with the prefix "LLD2". In order to schedule more than one of these tests at a time, you must put one of the LAN machines into manual mode.

Important If you do not put one of the LAN machines into manual mode, some tests might fail.

When you are done running the LLTD tests, ensure that you reset the machine state back to ready mode so that the other test sets can use both LAN machines. Additionally, the test "LLD2 Verification Tests - Performance and Reliability" might take up to 24 hours to complete. Schedule this test accordingly.

These tests rely on the IGD's MAC address to be properly set in the setup job for each machine. A common mistake, especially if testing more than one device, is to not have the proper MAC address set for either LAN1 or LAN2.

IPV6 Tests

These tests should be run one at a time, but sequence is not important. The machine running the server should have two interfaces with two IP addresses. The parameters should be configured with the two IP addresses of the machine that runs the server. These tests do not rely on the IGD's MAC address in the setup job for each machine.

IGD byte counters tests

The DTM jobs for these tests have the common prefix IGDByteCounters in their names. Although the sequence is not important, it is recommended that the basic logo tests are run first.

Make sure the following conditions are met before running these tests:

  1. The user logged on to the console of the machines has administrator privileges

  2. UPnP framework is enabled on the IGD.


Wireless LAN (802.11) Testing Overview

The procedures that are presented in this section outline the process for testing your Wireless LAN (WLAN) device to ensure that it will function correctly with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To comply with the WLAN Logo Program and ensure that the device and driver function correctly, you must run all of the tests that DTM identifies as required for the device.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Note Software-based Access Points using the Realtek 8185 chipset were deprecated with the release of WLK version 1.3. DTM testing with Software-based Access Points are exclusively supported with Atheros WLAN NICs. WLK customers that are testing WLAN drivers must use Atheros hardware to complete their submissions. If you have further questions on this, please let us know at wlanndt@microsoft.com.

The test procedures in this section are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements for running the WLAN test.

  • Preparing: The preparing topics describe how to configure test machines and setup DTM machine pools for Windows logo testing.

  • Running: The running topics describe how to execute the WLAN Logo tests for your device.

  • Troubleshooting: The troubleshooting topics describe how to diagnose and fix common problems that you might encounter during WLAN testing.

WLAN Device Tests

The tests that you need to run depend on the capabilities of the device or system that you are testing.

Execution time:

  • Windows XP -3 to 4 hours

  • Windows Vista - 6 to 8 hours

  • Windows 7 - 8 to 12 hours

DTM Setup for WLAN Device Testing

A DTM setup for WLAN device testing consists of the following three components:

  • A computer that is running DTM Studio. Through this application, you can control and configure the DTM controller to send jobs to the DTM clients on the DTM system pool. All requirements for a WLAN Logo submission are enforced when the DTM test execution job is configured.

  • A DTM controller computer. This computer must be running Microsoft Windows Server 2003. (This computer can be the same computer that runs DTM Studio.) This component reserves DTM clients in the system pool for a test job.

  • Several DTM client computers. For WLAN Logo device tests, you need three client machines. These are identified as the DUT (Device Under Test), SUT (Support Device Under Test), and Test SoftAP, as shown in the following figure. The DUT and SUT will have the test device and driver installed. The Test SoftAP will have two Atheros-based 802.11n capable wireless adapters installed. When a test job is run, the DTM clients will first copy NDISTest from the DTM controller onto the DTM clients and run NDISTest locally. The DTM controller will gather test results.

Install the Windows 7 operating system on the Test Soft AP.

Note Windows Vista is deprecated and is not supported for the Test SoftAP.

The following table summarizes the configurations:

Test Client | Windows XP Logo | Windows Vista Logo | Windows 7 Logo
DUT | XP | Vista | Windows 7
SUT | XP | Vista | Windows 7
Test SoftAP | Windows 7 | Windows 7 | Windows 7

Note The operating systems installed on the test clients must be matching processor architecture versions. If you are Logo testing a 32-bit driver, the DUT, SUT, and Test SoftAP must all have 32-bit versions of Windows installed upon them. For example, you may not use a 64-bit DUT with a 32-bit Test SoftAP.

The following figure provides an overview of the WLAN Logo test setup.

Diagram of an overview of the WLAN Logo test Setup

This section includes

Preparing for Wireless LAN (802.11) Testing

Running Wireless LAN (802.11) Tests for Logo Submission

Troubleshooting Wireless LAN (802.11) Testing


Preparing for Wireless LAN (802.11) Testing

To prepare the test systems for WLAN device testing, do the following:

  1. Set up the following machine configuration:
    • One test device on the DUT.
    • One test device on the SUT.
    • Two Atheros chipset devices on the Test SoftAP.

  2. Install the DTM client software on all computers. For more information about the installation, please see Setting Up DTM.

    Note The WTT client must be installed before the Test SoftAP driver.

  3. Open DTM Studio.

  4. Under My Explorers, click My Machines. The screen that opens enables you to organize client computers into groups called machine pools. At first, only two elements will show up in the list in the Machine Pool tab: "Default Pool" and "System". "Default Pool" initially contains all of the client machines that it can recognize, including the client machines that you just configured.

  5. Right-click the root machine pool ($), and then click Add Machine Pool. A configuration window appears to enable you to define parts of a new machine pool such as the name and scheduling rules.

  6. In the Name field, enter a name for the new machine pool. Click OK to create the pool.

  7. In the Job Monitor, there is a section that shows any clients with the DTM client installed under the heading Machines. Test clients in the default pool should be moved into the machine pool that was created. Select any test clients which will be used for WLAN Logo testing. Right-click the selected test clients from the default pool. Select the option Move...

  8. The Move Machines dialog box will open. Select the machine pool you created and click the OK button. The test clients will be moved to the new pool.

  9. Right-click the test clients again. Select Change status and then select Reset. This will apply the WLAN Logo configuration settings on the clients and the machines will be ready for a Logo submission.

  10. Install SoftAP driver for both of the Atheros WLAN devices on the Test SoftAP. You can install this driver from Device Manager (which you can open by running devmgmt.msc from a command prompt). Please, do the following
    • In Device Manager, install the driver for SoftAP stations from \\<ControllerMachine>\Tests\<architecture>\nttest\nettest\ndis\NDISTest.net\SoftAPMiniport\. <ControllerMachine> is the name of the DTM controller computer and <architecture> is either x86 (for x86-based processors), amd64 (for x64-based processors), depending on the processor architecture of the DTM client machine that have the SoftAP devices.
  11. To troubleshoot the NDISTest, attach a debugger to the test machine.


Running Wireless LAN (802.11) Tests for Logo Submission

The following logo submission procedure demonstrates how to run the WLAN device tests:

  1. Open DTM Studio.

  2. On the Explorers menu, click Device Console. (You can also switch to the Device Console window by clicking the Device Console tab in the lower left corner of DTM Studio.)

  3. In the View By area, select Submission, and then in the Submission list, click <New Submission>. You will see the Create New Submission dialog box.

  4. Select the operating system and architecture that your test device is running on, and then click Next.

  5. Click Device Submission, and then click Next.

  6. Click Network > Wireless LAN (802.11), and then click Next.

  7. Select the desired Qualification Level, and then click Next.

  8. In the Name for new submission box, enter an appropriate name for this test submission, and then, in the Machine Pool area, select the machine pool to use to run the test jobs.

  9. In the Driver Install File (INF) box, locate the INF file that is associated with the driver you are testing, click Load, and then click Next.

  10. Review the summary of the settings you have chosen, and then click Next. A summary of your submission will be displayed. Click the Finish button to close the wizard. The Device Console window will re-appear

  11. In the Available Jobs area, select the check box next to Wireless LAN - 802.11, and then click Add Selected button in the lower left hand corner. The Job extension dialog box will appear. Screen shot of the Device Console dialog box

  12. In the Job extension dialog box, select the appropriate support devices, AP devices, and remote message devices for each client machine, and then click Save.

    Screen shot of the AP Setting tab on the Job extension dialog box with the devices selected

    Screen shot of the AP Setting tab on the Job extension dialog box with the devices selected

  13. In the Device Console window, click the Schedule Jobs button in the lower right corner of the screen. The tests will begin to execute.

When you first run DTM tests on a WLAN device driver, any client machine that has a SoftAP device will ask if you want to install an unsigned driver. You must click Install before test execution can continue.

During test execution and after test execution completes, you can view status and progress through the Job Monitor window. To open this window, on the Explorers menu, click Job Monitor. Job Monitor is the same window that you used to define a new machine pool.

When the client machines complete test jobs, you can gather information from the Job Execution Status frame by right-clicking on a job and viewing errors, job reports, or result reports. You can also click Browse Job Logs to access NDISTest results.


Troubleshooting Wireless LAN (802.11) Testing

The following list describes some common troubleshooting tips for WLAN testing:

  • Changes that you made to devices on DTM clients machines are not reflected in DTM Studio. For example, the machine is expected to be in the Ready state but it is not.
    1. Open a Command Prompt window on the client machine, and then run net stop wttsvc.
    2. Run net start wttsvc. This command will update the C:\wtt\JobsWorkingDir\AssetCfg\Log\ directory.
    3. Refresh the Device Console window in DTM Studio. You might have to wait several minutes for the DTM controller to poll the client machine for changes in its device list.
  • Machines have not been discovered for the machine pool.
    1. Open the Job Monitor window in DTM Studio.
    2. Select the Show Query Builder button at the top of the screen.
    3. Click the Machine Query tab.
    4. Define search parameters for the machines that you are looking for. Typically, you can set a single rule such as "DataStore equals 'Controller Name'".
    5. Right-click the rule that you just defined, and then click Execute. An extensive list of machines should populate the Machines list below the query fields that you defined.
    6. Drag any machines in the Machines list into new machine pools that you created.
  • Machines do not seem to run jobs that are scheduled for them.
    1. Open the Job Monitor window in DTM Studio.
    2. In the Machine Pool tab, select the machine pool that you expect to be running jobs.
    3. For each machine in that pool, verify that its status is Ready.
    4. If a machine's status is not Ready, right-click the machine, point to Change Status, and then click Reset.
    5. After a few minutes, refresh the screen and the status will change to Ready.
    6. Schedule and start the jobs again.

  • Problems with installing the Test SoftAP driver on the topology: Device Manager reports code 52

    Do not install the x64 Test SoftAP driver before installing the DTM client. When the DTM client is installed, the Root Certificate is installed. Because the Test SoftAP driver signing depends on installation of the Root Certificate, the device manager reports device code 52.

  • Configuring NDISTest for stand-alone execution

    Installing NDISTest separate from DTM Studio enables you to execute individual tests. A DUT, SUT, and Test SoftAP needs to be configured to enable stand-alone execution.

    Note All test machines must use the same processor architecture.

    Note To troubleshoot the NDISTest, try attaching a debugger to the test machine.

  • Configuring a Support Device Under Test (SUT)

    1. Copy all NDISTest binaries and sub directories from the following DTM controller:

      \\<ControllerMachine>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\

      <ControllerMachine> is the name of the DTM controller computer and <architecture> is either x86 (for x86-based processors) or amd64 (for x64-based processors).

    2. Launch NDISTest.exe from the install directory. When the main form opens, select Server from the File menu to launch the server form.
    3. Select the message device from the Message Device list. This device must be IP-enabled and on the same subnet as the client message device that will be set up later.
    4. Select SUT device(s) from Support Devices. The support device selected on this server from will be visible to the client after the server is started.
    5. Select the "server" job from Jobs. This is the server side test that will be launched after you click the start button.

    After all the options have been selected, click Start to start the server.

  • Configuring a Test Software Access Point (Test SoftAP)

    1. Copy all NDISTest binaries and sub directories from the following DTM controller:

      \\<ControllerMachine>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\

      <ControllerMachine> is the name of the DTM controller computer and <architecture> is either x86 (for x86-based processors) or amd64 (for x64-based processors).

    2. Install SoftAP driver for both of the Atheros WLAN devices on the Test SoftAP. You can install this driver from Device Manager, which you can open by running devmgmt.msc from a command prompt. Complete the following step:

      In Device Manager, install the driver for SoftAP stations from \\<ControllerMachine>\Tests\<architecture>\nttest\nettest\ndis\NDISTest.net\SoftAPMiniport\

      <ControllerMachine> is the name of the DTM controller computer and <architecture> is either x86 (for x86-based processors) or amd64 (for x64-based processors), depending on the processor architecture of the DTM client machine that have the SoftAP devices.

    3. Launch NDISTest.exe from the install directory. When the main form opens, select Server from the File menu to launch the server form.
    4. Select the message device from the Message Device list. This device must be IP-enabled device and on the same subnet as the client message device that will be set up later.
    5. Select the AP device(s) from AP Devices. AP devices selected on this server will be visible to the client after the server is started.
    6. Select the "server" job from Jobs. This is the server side test that will be launched after you click the start button.

    After all the options have been selected, click Start to start the server.

  • Configuring the Device Under Test (DUT)

    1. Copy all NDISTest binaries and sub directories from the following DTM controller:

      \\<ControllerMachine>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\

      <ControllerMachine> is the name of the DTM controller computer and <architecture> is either x86 (for x86-based processors) or amd64 (for x64-based processors).

    2. Launch NDISTest.exe from the install directory. When the main form opens, select Client from the File menu to launch the client form.
    3. Select the test target from the Test Target list. For network device, this test target should be Miniport.
    4. Select the test device from the Test Device list. This must be a vendor-specific test device.
    5. Select a message device from the Message Device list. This should be an IP-enabled device that is on the same subnet as the server message device. After the message device has been selected, the AP device section should be displayed and the server AP device should be available in the list.
    6. Select a support device from Support Devices. This must be a vendor-specific support device.
    7. Select an AP device from AP Devices. This must be the AP device that was select on the server side.
    8. Select the tests from the Jobs section that will be run after the client is launched.

    After all the options have been selected, click Start to start the client. Any jobs that were selected will begin execution. Test results will be stored on the client in the following logging sub-folder:

    <NDISTestRootFolder>/logs/<AdapterName>/

  • Configuring Client Packet Capture
    1. Configure a test topology for stand-alone execution. For more information, go to "Configuring NDISTest for stand-alone execution."
    2. Setup a second SUT. For more information, go to "Configuring a Support Device Under Test (SUT)."
    3. Launch NDISTest.exe from the install directory. When the main form opens, select Debug from the View menu to launch the Packet Capture section on the client.
    4. Select a Capture device from Packet Capture. This must be a Support device that was selected on the server side.
    5. From Jobs, select the tests that will be run after the client is launched.
    6. After all of the options have been selected, click Start to start the client.

    7. Packet captures corresponding to the Tests will be generated on the Server with the capture device. The logs will be in the following logging sub-folder:

      <NDISTestRootFolder>/logs/<AdapterName>/

  • Troubleshooting when the Packet Capture section does not show up on client

    Verify that the message center user interface is closed. If the NDISTest user interface is not maximized, the Packet Capture section may be hidden behind the message center user interface.


Mobile Broadband Testing

This section includes the following topics:

Mobile Broadband Testing Overview

Preparing for Mobile Broadband Testing

Running the Mobile Broadband Tests

Troubleshooting Mobile Broadband Testing


Mobile Broadband Testing Overview

This document outlines the test cases that are implemented to test the Mobile Broadband (MB) device, also known as Wireless WAN - WWAN device, to make sure that it will function correctly with the Windows 7 operating system and all later versions of Windows. To test Mobile Broadband devices, use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM) test kit. To be in compliance with the Mobile Broadband Logo Program, and to make sure that the device and driver function correctly with Microsoft Windows, you must run all the tests that DTM identifies as required for the device.

Using the Test Procedure Help Topics

This test procedure is divided into the following sections:

  • Overview: Describes hardware and software requirements for running the Mobile Broadband test. This section also outlines a basic procedure for how to successfully run the tests.

  • Preparing: Describes how to configure the system for Windows logo testing.

  • Running: Describes the procedure to run the Mobile Broadband test.

  • Troubleshooting: Describes ways to diagnose and fix common problems that you might encounter during Mobile Broadband testing.

Mobile Broadband Tests

The specific device and the system capabilities where the device is tested determine which tests you must run. The tests can be divided into Non-Interactive Tests and Interactive Tests. During the Interactive Tests, the tester must perform certain operations, such as plugging and unplugging the device, replacing the SIM, and so on.

Run time: approximately 3 hours

Hardware requirements

The following hardware is required to run the Mobile Broadband tests:

  • 1 computer that runs DTM StudioDTM studio provides an interface to control and configure the DTM Controller. The DTM Controller sends jobs to the DTM clients on the DTM system pool. All requirements for logo submission are enforced when the DTM test execution job is configured.

  • 1 computer that runs DTM ControllerThis computer must be running the Windows Server 2003 operating system. The DTM Controller reserves DTM clients in the system pool for test jobs. The DTM Controller dispatches commands and tests to be run by the DTM clients.

    Note This can be the same computer that runs DTM Studio.

  • 1 DTM client computerThis computer must have the test device and driver installed (with Mobile Broadband data service activated). When a test job is run, the DTM clients copy NDISTest from the DTM Controller locally onto the machine and run NDISTest locally. The DTM Controller is used to gather test results.

  • The following SIM cards:
    • 'Home' SIM with data provisioned
    • 'Roaming' SIM with data provisioned
    • 'Home' SIM with no data provisioned
    • 'Roaming' SIM with no data provisioned
    • 'Bad' SIM
    • 'Inactive' SIM

The following figure shows the relationship between these three computer components:

Diagram of illustrating the three hardware requirements: DTM Studio, DTM controller, and DTM client


Preparing for Mobile Broadband Testing

To set-up the Mobile Broadband device test, complete the following steps:

  1. Configure the computer as one test device on DTM Client.

  2. Install the DTM test suite on all computers. For more information about installing DTM, see Install.htm - Installation Guide.

  3. Open DTM Studio. The following screen appears.

    Screen shot of the DTM Studio Start page

  4. Under My Explorers, click My Machines. On this screen, you can organize client computers into groups called machine pools. At first, only the following will show up in the list on the Machine Pool tab: Default Pool and System. Default Pool initially contains all the client computers that it can recognize, which includes the client computers that were configured in steps 1 and 2.

    Note If it did not show up under the Machines window pane, you can remove the User Name - Current Owner and User Name - Permanent Owner query from the Machine Query.

    Screen shot of the Job Monitor dialog box

  5. Right-click the root machine pool ($), and then click Add Machine Pool. A configuration window appears where you can define the new machine pool, such as the name and scheduling rules. Screen shot of the Add Machine Pool dialog box

  6. Define and configure a new machine pool (for example, MBN), and then click OK.

  7. On the Machine Pool tab, click Default Pool, and then drag the relevant machine into the new machine pool.

  8. Press F5 or the refresh button to refresh the screen. Right-click the machine and click Reset Status to get the machine to the Ready state.

    Note You cannot proceed unless all the machines in the newly created machine pool say Ready.

    Screen shot of the Job Monitor dialog box displaying the new machine pool


Running the Mobile Broadband Tests

After you complete the Preparing DTM for Mobile Broadband Testing procedure, the test harness is ready to begin running the Mobile Broadband device test for logo submission. To run the Mobile Broadband device test, follow these steps:

  1. On the Explorers menu, click Device Console.

    Note You can also switch to the Device Console window by clicking the Device Console tab in the lower-left corner of DTM Studio.

    Screen shot of the Device Console dialog box
  2. In the View By area, click Submission, and then in the Submission list, click <New Submission>. The following dialog box appears.

    Note It might take a moment for the following screen to appear.

    Screen shot of the Create New Submission dialog box with a list of Windows operating systems to select from
  3. Click the operating system and architecture that the test device is running on, and then click Next.

    Note Currently, the Mobile Broadband test is only supported in Windows 7 Client and Windows 7 Client x64.

  4. Click Device Submission, and then click Next.

  5. Click Network > Mobile Broadband Network, and then click Next.

  6. Click Logo, and then click Next.

  7. In the Name for new submission box, type an appropriate name for this test submission, and then click the machine pool to run the test jobs under Machine Pool. Screen shot of the Create New Submission dialog box with the MBN machine pool selected

  8. In the Driver Install File (INF) box, locate the INF file that is associated with the driver to be tested, click Load, and then click Next. Screen shot of the Create New Submission dialog box showing the Driver Install File (INF) box

  9. Review the summary of the settings that have been selected, and then click Next. Screen shot of the Create New Submission dialog box listing the devices that can be tested

  10. If the device supports dual mode (both GSM and CDMA), click Yes. If it is a single mode device (either GSM or CDMA but not both), click No.

    Screen shot of the Create New Submission dialog box displaying an Is this a dual-mode device? drop-down list

  11. Click Next.

    Screen shot of the Create New Submission dialog box displaying a No additional Qualifications are available for this submission message

  12. The following screen appears:

    Screen shot of the Create New Submission dialog box listing the name and value information for the new submission

  13. The category is based on the dual mode device choice. If the device is a single mode device, the following screen appears: Screen shot of the Create New Submission dialog box listing the names and values for a single-mode device

    If the device is a dual mode device, the following screen appears:

    Screen shot of the Create New Submission dialog box listing the names and values for a dual-mode device

  14. Click Finish.

  15. The Device Console window appears.

  16. In the Available Jobs area, select the MBN check box. Make sure that all the child nodes of MBN are also selected, and then click Add Selected. All the selected jobs are added to the bottom of the window. Screen shot of the Job Monitor dialog box

  17. Right-click Mobile Broadband Networking (Interactive) - NDISTest 6.5 and Mobile Broadband Networking (Non-Interactive) - NDISTest 6.5, and then click Edit Parameters.

  18. In the Parameters dialog box, type the requested information, and then click OK. Screen shots of two Parameters dialog boxes: one interactive, the other non-interactive

  19. In the Device Console window, click Add Selected, and then click Schedule Jobs in the lower-right corner of the screen. The tests begin to run.

    If your device is a single mode device, you should see the following screen:

    Screen shot of the Device Console dialog box for a single-mode device

    If your device is a dual mode device, the following screen appears:

    Screen shot of the Device Console dialog box for a dual-mode device

Note During the test run and after the test run completes, you can view test progress and status from the Job Monitor window. To open this window, click Job Monitor on Explorers. Job Monitor is the same window that is used to define a new machine pool.

When the client computers complete the test jobs, you can gather information from the Job Execution Status window by right-clicking on a job and viewing errors, job reports, or result reports. Alternatively, you can click Browse Job Logs to access NDISTest results.


Troubleshooting Mobile Broadband Testing

The following list describes some common troubleshooting tips for Mobile Broadband testing:

Changes that were made to devices on DTM client computers are not reflected in DTM Studio. For example, the machine is expected to be in the Ready state but it is not.

  1. Open a command prompt window on the client computer, and then run net stop wttsvc.

  2. Run net start wttsvc. This command updates the C:\wtt\JobsWorkingDir\AssetCfg\Log\ directory.

  3. Refresh the Device Console window in DTM Studio. It may take several minutes for the DTM Controller to poll the client computer for changes in its device list.

Computers have not been discovered for the machine pool.

  1. Open the Job Monitor window in DTM Studio.

  2. Click the Show Query Builder button at the top of the screen.

  3. Click the Machine Query tab.

  4. Define search parameters for the targeted computers. Typically, set a single rule such as "DataStore equals 'Controller Name'".

  5. Right-click the rule that was just defined, and then click Execute. An extensive list of computers populates the Machines list below the query fields.

  6. Drag any machines in the Machines list into new machine pool that was created.

Computers do not seem to run jobs that are scheduled for them.

  1. Open the Job Monitor window in DTM Studio.

  2. In the Machine Pool tab, select the machine pool that is expected to be running jobs.

  3. For each computer in that pool, verify that its status is Ready.

  4. If a computer's status is not Ready, right-click the computer, point to Change Status, and then click Reset.

  5. After a few minutes, refresh the screen and the status changes to Ready.

  6. Schedule and start the jobs again.


Wireless Router Logo Program Testing

The following documentation outlines procedures specific to the Wireless Router Logo program. This should be viewed as supplementary documentation to the standard Driver Test Manager (DTM) setup documentation.

Prerequisites

Persons attempting to create a Wireless Router Logo submission should have the following setup and configured using the standard DTM setup documentation.

  • DTM Controller

  • DTM Studio running on a computer on the same network as the DTM controller

  • 4 DTM Client machines (specific configuration and system requirements will be described in detail in the following section).

  • A minimum of 2 100 megabit switches. More may be needed depending on the number of available Ethernet ports on the device under test.

The rest of this documentation makes the assumption that the controller, studio, and clients are properly configured. This means that the controller has the proper permissions set, the studio is able to connect to and execute jobs on the controller, and that the clients are added to a machine pool, and all clients are heart beating in the ready state.

Machine Requirements and Configuration

Among the 4 DTM client machines, there are 3 individual configurations. Therefore, two of the client machines will be setup identically. These machines will be designated as LAN1, LAN2, WAN, and SERVER. All system requirements are in addition to minimum system requirements for Windows Vista or Windows 7 and the DTM test suite. The following network schematic illustrates how each is connected in the network:

Diagram illustrating hardware requirements and configuration

NOTE: a "Y" above the computer designates it is wirelessly connected to the router.

Wireless Router

The wireless router should have its DHCP server enabled. You will need to set the WAN port to this static IP address: 17.1.1.1. The wireless router should be in a controlled environment with its wireless network open (no security enabled). UPnP framework should be enabled, even if not by default.

Machines LAN1 and LAN2

System Requirements

  • Windows Vista Client x86 for Vista Logos or Windows 7 x86 Client for Windows 7 Logos

  • Three 10/100 Ethernet Cards
    • At least one of the three MUST support QOS 802.1p
  • One wireless adapter supporting 802.11a/b/g
    • Wireless adapter MUST use NDIS 6.0 compliant Native Wi-Fi Driver with support of WMM

  • Support for QueryPerformanceFrequency and QueryPerformanceCounter APIs. This is needed for the Wifi performance test.

Both of these machines, LAN1 and LAN2, have an identical setup procedure. Please replicate the following steps for each machine:

  1. Connect two of the Ethernet cards to the LAN side of the Wireless router via Ethernet cable. One of these two must be QOS 802.1p capable.

  2. Connect the third Ethernet card to the DTM network.

  3. Open the network connections folder. This can be done by clicking Manage Network Connections in the Network Center in the Control Panel.

  4. Rename the network connections such that:
    1. The connection to the DTM network is named DTM.
    2. The connection to the LAN side of the router with the QOS capable interface is named LAN_P.
    3. The non QOS capable interface connected to the LAN side is named LAN.
    4. The wireless connection is named Wireless.

  5. Make sure all of the connections are marked Private in the Network Sharing Center.

  6. Enable QOS 802.1p on the LAN_P connection (consult individual interface card manual).

  7. The wireless connection needs be associated with the router's wireless network.

  8. Run configuration Jobs: "Setup Machine LAN1" and "Setup Machine LAN2" for Machine Lan1 and Machine2 respectively. These jobs will set Static IP addresses and setup machine dimensions for each machine as follow:
    Interface LAN1 LAN2

    LAN

    192.168.0.10

    192.168.0.20

    LAN_P

    192.168.0.11

    192.168.0.21

    Wireless

    192.168.0.12

    192.168.0.22

    DTM

    IP Address assigned by DHCP

    IP Address assigned by DHCP

  9. For each machine, run ipconfig at a command prompt to verify that each interface has correctly assigned IP address.

  10. To ensure IP connectivity on all interfaces try to ping other addresses. If firewall is enabled, then open the ping exception via: netsh firewall set icmpsettings 8

  11. Make sure that all network connections are set to Private in the Network Center in the Control Panel.

    In order to ensure that your test network remains set to Private, you can set a policy to do this automatically by running gpedit.msc (as an Administrator) and modifying the settings for "Unidentified Networks":

    Screen shot of the Local Group Policy Editor window with Unidentified Networks selected Screen shot of the Unidentified Networks Properties dialog box with Private and Not Configured selected

Machine WAN1

System Requirements

  • Windows Vista Client x86 for Vista Logos or Windows 7 x86 Client for Windows 7 Logos

  • Two 10/100 Ethernet Cards

  • One wireless adapter that supports 802.11b/g
    • Adapter MUST use NDIS 6.0 compliant Native Wi-Fi Driver with support of WMM

The WAN machine should be setup using the following steps:

  1. Connect one Ethernet card to the WAN side of the wireless router. Because most routers only have one port for the WAN interface, a switch may be used (as shown in the diagram).

  2. Connect the other Ethernet card to the DTM network.

  3. Open the network connections folder (this can be done by clicking Manage Network Connections in the Network Center in the Control Panel.

  4. Rename network connections such that:
    1. The connection to the DTM network is named DTM.
    2. The connection to the WAN side of the router is named WAN
    3. The wireless connection is named Wireless

  5. The wireless connection needs be associated with the router's wireless network.

  6. Run configuration Job: Setup Machine WAN1. These jobs will set Static IP addresses and setup machine dimensions as follow:
    Interface WAN1

    Wireless

    192.168.0.30

    WAN

    17.1.1.10

    DTM

    IP Address assigned by DHCP

  7. Run ipconfig at a command prompt to verify that each interface has correctly assigned IP address.

  8. Ensure IP connectivity on all interfaces. If firewall is enabled, then open the ping exception via: netsh firewall set icmpsettings 8

  9. Ensure that all network connections are set to Private in the Network Center in the Control Panel.

Machine WAN2

System Requirements

  • Windows Vista Client x86

  • Three 10/100 Ethernet Cards

The WAN2 machine should be setup using the following steps:

  1. Connect two of the Ethernet cards to the WAN side of the router. A switch may be used to accomplish this.

  2. Connect the remaining Ethernet card to the DTM network.

  3. Open the network connections folder. This can be done by clicking Manage Network Connections in the Network Center in the Control Panel.

  4. Rename network connections such that
    1. The connection to the DTM network is named DTM.
    2. The connections to the WAN side of the router are named WAN1 and WAN2

  5. Run configuration Job: Setup Machine WAN2. These jobs will set Static IP addresses and setup machine dimensions as follow:
    Interface WAN2

    WAN1

    17.1.1.20

    WAN2

    17.1.1.21

    DTM

    IP Address assigned by DHCP

  6. Run ipconfig at a command prompt to verify that each interface has correctly assigned IP address.

  7. Ensure IP connectivity on all interfaces. If firewall is enabled, then open the ping exception via: netsh firewall set icmpsettings 8

  8. Ensure that all network connections are set to Private in the Network Center in the Control Panel.

Machine Pool Configuration

Proper setup of the machine pool is vital. When the machine pool is not properly configured, scheduled jobs will stay in the status "Scheduler". Configuration of the machine pool allows the DTM controller to assign each individual task to the correct machine. For each of the four machines in the pool, a configuration job will have to be run. This job will set "Dimensions" on that machine which will describe its role in the network.

To run the configurations job, do the following on each machine in the pool:

  1. Open up DTM Studio.

  2. Click Explorers and then choose Job Monitor.

  3. On the left hand side, select the proper machine pool.

  4. Right click the machine and select Schedule.

  5. Select Browse, and then select the job Setup Machine XYZ found under WDK Tests\Networking\Routers\Configuration. (Where XYZ correspond to LAN1, LAN2, WAN1 and WAN2)

  6. For LAN1 and LAN2: Enter the MAC address of the LAN side interface of the Wireless Router in the Value field for the IGD_Mac parameter

  7. Click Start.

Creating a Submission

In order to receive a logo for the Wireless Router Logo Program, you will need to create a submission which contains all of the run tests. There are 3 steps to doing this: creating a new submission, running the tests, creating a submission package to send to Microsoft.

In order to create a new submission, you will once again need to use the DTM studio.

  1. Click Explorers and then choose Device Console.

  2. Select New Submission.

  3. When the submission wizard pops up, select Windows Vista Client or Windows 7 Client.

  4. Select Device Submission and click Next.

  5. Select Network > Wireless Router and click Next.

  6. Choose Basic or Premium based on desired logo (only one logo is available for Windows 7).

  7. Select the pool that you have previously configured to run these tests.

  8. Enter a name for the submission (preferably the device name) and click Next.

Next we will need to run each test individually. Once you have created a new submission, you will notice that the right hand pane will be filled with many test names with check boxes beside them. You may select one or more tests and hit "Add Selected". After selecting a test, you may need to edit a parameter in order for the test to run properly. To do this, right-click the job and select "Edit Parameters". More information on editing parameters can be found in the individual instructions for each category of tests below. Once you have done so, click "Schedule Jobs". Go to the job monitor and wait for the job to finish. Once it has, you may run the next test. Some of the tests must have special requirements that must be fulfilled before they can be run. Below is a list of those requirements for each specific test or test category. Please pay close attention as failure to do so may result in unexpected failures.

LLTD Responder Verification Tests

All LLTD tests start with the prefix "LLD2". In order to schedule more than one of these tests at a time you will need to put one of the LAN machines into manual mode. Failure to do so will cause test failures! When you are done running the LLTD tests, ensure that you reset the machine state back to ready mode so that the other test sets may use both LAN machines. Another thing that should be noted is that the test "LLD2 Verification Tests - Performance and Reliability" may take up to 24 hours to complete. Therefore, you will want to schedule this test accordingly.

These tests rely on the IGD's MAC address to be properly set in the setup job for each machine. A common mistake, especially if testing more than one device, is to not have the proper MAC address set for the either LAN1 or LAN2.

WCN Tests

All WCN tests start with prefix "WCN". The automated tests can be run at any order; the only requirement is that they should be scheduled one at a time.

Before running the tests, make sure the device is plugged in and it is in 'configurable state'. All of the tests try to configure the device. If the device does not support being configured when it is already configured, then the router will need to be reset to a 'configurable state' before running a test.

The WCN Tests uses the UPnP protocol as the underlying transport to configure the device, so make sure the firewall doesn't block UPnP traffic (firewall can be disabled from "Control Panel") and SSDP service is not disabled (or stopped).

All the jobs require the routers BSSID and WPS PIN. The wireless network BSSID is usually the MAC address of the Wireless Interface. Available wireless network BSSIDs can be viewed by executing the netsh command "netsh wlan show networks mode=bssid" on the LAN1 machine. Static WPS pins should be 8 digits and Dynamic WPS pins should be 8 or 4 digits.

There should be no wireless profiles on the LAN machines and the machines should not be associated with any wireless networks, before starting the WCN Wireless Tests. You may see a pop-up on the machine saying the computer could not connect to a particular network. This is expected, so please ignore the pop-up.

WCN Display WPS Pin Test:

The following test verifies that a Wireless AP Properly displays the WPS Pin. When the test is executed you will see the window below on one of the LAN computers. Select Pass or Fail accordingly.

Screen shot of the Manual Task window with Verify the router is able to display the WPS Pin displayed

Feature Path: $\WDK Tests\Networking\Routers\WCN

  • WCN UPnP Verify the router is able to display the WPS Pin

WCN UPnP PIN Based Configuration and Connect Tests:

The following tests verifies that a Wireless AP is able to be configured using WPS over UPnP framework, accept a wireless connection, and queried for wireless settings using WPS over EAP. The test acting as the registrar will initiate an UPnP WPS configuration session with the AP using PIN for authentication. The test will comply with the WPS Protocol and confirm the AP is also using all required attributes in its messages. During the configuration session, the test will configure the AP to use a specific set of wireless settings. After completing the UPnP WPS configuration session, the test will wait up to 60 seconds for the AP to reboot and apply settings. The test will ensure the AP is properly advertising its state as 'Configured'. The test will confirm the AP is properly implementing the wireless settings, by using the configuration settings to connect to the AP, verify connectivity, and disconnect from the AP. The test will then initiate a Wireless EAP WPS query session with the AP using PIN authentication. The test queries the AP by acting as a WPS Registrar, starting a WPS Session, and sending a NACK after receiving the M7 message from the AP. The test will validate the M7 settings to make sure they are the same settings that were used to configure the router.

Feature Path: $\WDK Tests\Networking\Routers\WCN

  • WCN UPnP Configure And Connect to AP with WPA PSK TKIP NetworkKey using PIN

  • WCN UPnP Configure And Connect to AP with WPA PSK TKIP PassPhrase using PIN

  • WCN UPnP Configure And Connect to AP with WPA PSK AES NetworkKey using PIN

  • WCN UPnP Configure And Connect to AP with WPA PSK AES PassPhrase using PIN

  • WCN UPnP Configure And Connect to AP with WPA2 PSK TKIP NetworkKey using PIN

  • WCN UPnP Configure And Connect to AP with WPA2 PSK TKIP PassPhrase using PIN

  • WCN UPnP Configure And Connect to AP with WPA2 PSK AES NetworkKey using PIN

  • WCN UPnP Configure And Connect to AP with WPA2 PSK AES PassPhrase using PIN

  • WCN UPnP Configure And Connect to AP with Open None using PIN

  • WCN UPnP Configure And Connect to AP with WEP 5 ASCII using PIN

  • WCN UPnP Configure And Connect to AP with WEP 13 ASCII using PIN

  • WCN UPnP Configure And Connect to AP with WEP 10 HEX using PIN

  • WCN UPnP Configure And Connect to AP with WEP 26 HEX using PIN

WCN UPnP PIN Based Configuration and Connect Test over Wireless (Preview for 1.5)

The following test verifies that a Wireless AP is able to be configured using WPS over UPnP framework via a wireless connection, accept a wireless connection, and be queried for wireless settings using WPS over EAP. The test acting as the registrar gets the current wireless settings from the AP and connects to the AP with these settings. It then initiates an UPnP WPS configuration session with the AP using PIN for authentication. The test complies with the WPS Protocol and confirms that the AP is also using all required attributes in its messages. During the configuration session, the test configures the AP to use a specific set of wireless settings. After completing the UPnP WPS configuration session, the test waits up to 60 seconds for the AP to reboot and apply settings. The test ensures the AP is properly advertising its state as "Configured." The test confirms the AP is properly implementing the wireless settings by using the new configuration settings to connect to the AP, verify connectivity, and disconnect from the AP. The test then initiates a Wireless EAP WPS query session with the AP using PIN authentication. The test queries the AP by acting as a WPS Registrar, starting a WPS Session, and sending a NACK after receiving the M7 message from the AP. The test validates the M7 settings to make sure they are the same settings that were used to configure the router.

Feature Path: $\WDK Tests\Networking\Routers\WCN

  • WCN UPnP Configure And Connect to AP with WPA2 PSK AES PassPhrase using PIN over Wireless

WCN Default AP Configuration Test (Preview for 1.5)

The following test verifies that the default configuration of the AP is set to either Secure/Configured or Unsecured/Not Configured. The purpose of this is to ensure a good user experience with Windows and the AP out-of-the-box. The test requires that the AP be reset to the factory defaults. The test waits for the AP to become visible from the scan list to determine the current security settings. The test then performs a discovery connect to obtain the probe response to determine the configuration state. With this information, the test determines whether the correct attributes are set.

Feature Path: $\WDK Tests\Networking\Routers\WCN

  • WCN Default AP Configuration

WCN UPnP Invalid PIN Configuration Tests:

The following tests will try to configure the AP with an incorrect pin. When the first half of the pin is invalid, the test expects to receive a NACK after sending a M4 message. When the second half of the pin is invalid, the test expects to receive a NACK after sending a M6 message. The error in the NACK should be properly set to Password Auth Failure 0x12.

Feature Path: $\WDK Tests\Networking\Routers\WCN

  • WCN UPnP Configure with first half of the PIN incorrect

  • WCN UPnP Configure with second half of the PIN incorrect

WCN Wireless Tests

All WCN tests start with prefix "WCN Wireless". The automated tests can be run at any order; the only requirement is that they should be scheduled one at a time.

Before running the tests, make sure the device is plugged in and it is in 'configurable state'. All of the tests try to configure the device. If the device does not support being configured when it is already configured, then the router will need to be reset to a 'configurable state' before running a test.

The WCN Tests uses the UPnP protocol as the underlying transport to configure the device, so make sure the firewall doesn't block UPnP traffic (firewall can be disabled from "Control Panel") and SSDP service is not disabled (or stopped).

All the jobs require the routers BSSID and WPS PIN. The wireless network BSSID is usually the MAC address of the Wireless Interface. Available wireless network BSSIDs can be viewed by executing the netsh command "netsh wlan show networks mode=bssid" on the LAN1 machine. Static WPS pins should be 8 digits and Dynamic WPS pins should be 8 or 4 digits.

There should be no wireless profiles on the LAN machines and the machines should not be associated with any wireless networks, before starting the WCN Wireless Tests. You may see a pop-up on the machine saying the computer could not connect to a particular network. This is expected, so please ignore the pop-up.

WCN Verify Router has a WPS Pushbutton Test:

The following test verifies that the Wireless AP has a WPS Pushbutton physically on the machine. When the test is executed you will see the window below on one of the LAN computers. Select Pass or Fail accordingly.

Screen shot of the Manual Task window with Verify the router has a WPS Pushbutton displayed

Feature Path: $\WDK Tests\Networking\Routers\WCN

  • WCN Wireless Verify the router has a WPS Pushbutton

PIN Based Registrar Configuration and Query Tests:

The following tests verify that a Wireless AP is compatible with the way Microsoft's WCN component configures and queries an AP's Wireless Settings using the WPS protocol. The test acting as the registrar will initiate a Wireless EAP WPS configuration session with the AP under test using PIN for authentication. The test will comply with the WPS Protocol and confirm the AP is also using all required attributes in its messages. During the configuration session, the test will configure the AP under test to use a specific set of wireless settings. After completing the Wireless EAP in-band WPS configuration session, the test will wait up to 60 seconds for the AP under test to reboot and apply settings. To confirm the AP under test is properly implementing the wireless settings, the test will use a wireless profile to connect to the AP under test, verify connectivity, and disconnect from the AP under test. The test will then initiate a Wireless EAP WPS query session with the AP under test using a PIN for authentication. After the test receives the M7 message from the AP under Test, the test will reply with a NACK message to terminate the WPS session. The test will analyze the settings contained in the M7 message to confirm the AP is properly configured from the first WPS configuration session and is properly advertising it's settings through the WPS protocol.

Feature Path: $\WDK Tests\Networking\Routers\WCN Wireless

  • WCN Wireless Configure And Connect to AP with WPA PSK TKIP NetworkKey using PIN

  • WCN Wireless Configure And Connect to AP with WPA PSK TKIP PassPhrase using PIN

  • WCN Wireless Configure And Connect to AP with WPA PSK AES NetworkKey using PIN

  • WCN Wireless Configure And Connect to AP with WPA PSK AES PassPhrase using PIN

  • WCN Wireless Configure And Connect to AP with WPA2 PSK TKIP NetworkKey using PIN

  • WCN Wireless Configure And Connect to AP with WPA2 PSK TKIP PassPhrase using PIN

  • WCN Wireless Configure And Connect to AP with WPA2 PSK AES NetworkKey using PIN

  • WCN Wireless Configure And Connect to AP with WPA2 PSK AES PassPhrase using PIN

  • WCN Wireless Configure And Connect to AP with Open None using PIN

  • WCN Wireless Configure And Connect to AP with WEP 5 ASCII using PIN

  • WCN Wireless Configure And Connect to AP with WEP 13 ASCII using PIN

  • WCN Wireless Configure And Connect to AP with WEP 10 HEX using PIN

  • WCN Wireless Configure And Connect to AP with WEP 26 HEX using PIN

Missing Attribute Tests:

The following tests verify that a Wireless AP correctly handles receiving a Wireless EAP WPS message that is missing a required attribute. The test expects the Wireless AP to fail the WPS session and respond with a NACK message upon receiving the message with a missing required attribute.

Feature Path: $\WDK Tests\Networking\Routers\WCN Wireless

  • WCN Wireless Missing Attribute M2 Registrar Nonce

  • WCN Wireless Missing Attribute M4 MessageType

  • WCN Wireless Missing Attribute M6 EncryptedSettings

  • WCN Wireless Missing Attribute M8 Authenticator

Optional Attribute Test:

The following test verifies that a Wireless AP correctly handles receiving a Wireless EAP WPS message that contains an optional attribute. The test expects the Wireless AP to correctly process the optional attribute and continue the WPS session. When running the tests where the test acts as an enrollee, the test will ask you to push the WPS Button on the AP and press 'Enter' to continue.

Feature Path: $\WDK Tests\Networking\Routers\WCN Wireless

  • WCN Wireless Optional Attribute M2 Vendor Extension

  • WCN Wireless Optional Attribute M4 Vendor Extension

  • WCN Wireless Optional Attribute M4 Encrypted Settings Vendor Extension

  • WCN Wireless Optional Attribute M6 Vendor Extension

  • WCN Wireless Optional Attribute M6 Encrypted Settings Vendor Extension

  • WCN Wireless Optional Attribute M8 Vendor Extension

  • WCN Wireless Optional Attribute M8 Encrypted Settings Vendor Extension

  • WCN Wireless Optional Attribute M1 Vendor Extension

  • WCN Wireless Optional Attribute M3 Vendor Extension

  • WCN Wireless Optional Attribute M5 Vendor Extension

  • WCN Wireless Optional Attribute M5 Encrypted Settings Vendor Extension

  • WCN Wireless Optional Attribute M7 Vendor Extension

  • WCN Wireless Optional Attribute M7 Encrypted Settings Vendor Extension

Proxy Test:

The following test verifies that a Wireless AP is capable of proxying Wireless EAP WPS messages to Ethernet UPnP framework and vice versa. A router with this functionality allows a Microsoft WCN capable computer connected to the Wireless AP via Ethernet to act as a WPS registrar. The test will act as a WPS registrar on the Ethernet side of the router and a WPS enrollee on the Wireless EAP side of the router. The test will send a WPS M1 message to the AP under test over wireless EAP. The test expects to receive the same WPS M1 message via Ethernet UPnP framework through the AP under test. The test will then send a WPS M2D message over Ethernet UPnP framework to the AP under test. The test expects to receive the same WPS M2D message via Wireless EAP through the AP under test.

Feature Path: $\WDK Tests\Networking\Routers\WCN Wireless

  • WCN Wireless M1-M2D Proxy Functionality

Push Button Auth Tests:

The following logo tests verify that a Wireless AP is capable of using push button authentication in a Wireless EAP WPS session. The logo test will act as an enrollee and prompt the user to push the 'WPS Button'. After the user unblocks the logo test by pushing any key, the logo test will establish a Wireless EAP WPS session with the Wireless AP under test using Push Button Authentication (AKA PBC).

Feature Path: $\WDK Tests\Networking\Routers\WCN Wireless

  • WCN Wireless Push Button Auth

Registrar Discovery Test:

The following logo test verifies that a Wireless AP is capable of being discovered through an EAP WPS M1-M2D message exchange. The logo test will act as a registrar and respond to the Wireless AP's M1 request message with a M2D response message. The logo test expects the Wireless AP to respond to the M2D response message with a NACK request message. The logo test will then respond with a NACK response. The Wireless AP should end the EAP session with an EAP-Fail message.

Feature Path: $\WDK Tests\Networking\Routers\WCN Wireless

  • WCN Wireless Registrar Discovery

Compare Probe Response and M1 message Test:

The following test will verify that the Probe Response and M1 message are identical.

Feature Path: $\WDK Tests\Networking\Routers\WCN Wireless

  • WCN Wireless Compare Probe Response and M1 messages

Selected Registrar Test:

The following test will verify that when SetSelectedRegistrar is invoked on the AP, the ap will have the SetSelectedRegistrar attribute set to 1 in its beacon and probe response message.

Feature Path: $\WDK Tests\Networking\Routers\WCN Wireless

WCN Wireless Selected Registrar Flag

IGD Data Tests

The IGD Data tests verify the routers ability to route UDP and TCP traffic across the WLAN and LAN networks.

Test: IGD Data Connection Test (Verify UPnP IGD is enabled)

Test adds port mapping to router using UPnP interface and then verifies port mapping by sending traffic from WAN machine to LAN machine. Test fails if router does not properly implement UPnP port mapping interface.

Test: IGD Data Connection Test (Verify IGD type is cone or restricted)

Test determines router's NAT Type. Test passes if NAT type is cone or restricted. Test fails if NAT type is symmetric.

Test: IGD Data Connection Test (Verify ECN does not trigger router reboot)

Test establishes TCP connection through router with Explicit Congestion Notification enabled (ECN). Test fails if connection is not established.

Test: IGD Data Transmission Test Udp Test

Test streams UDP data through the router for 8 minutes. Test fails if more than 4 packets are dropped.

Test: IGD Data Transmission Test for Windows Scaling

Test performs TCP Windows Scaling checks between a LAN machine and WAN machine. The test sets the LAN machine's scaling factor to 8, sets the WAN machine's scaling factor to 3, and restricts auto-tuning. The test fails if TCP connections and data transfers are not properly executed between the two machines.

Test: IGD Data Transmission Test for ECN streaming

Test sends and receives data over TCP through router with Explicit Congestion Notification (ECN) enabled. Test fails if data is not properly transmitted and received.

IPv6 Tests

The IPv6 tests verify whether the router supports the IPv6 protocol.

Test: IPv6 Logo Test (Verify 6to4 data transmission)

Test verifies whether the TCP connection can be established from a v6 address assigned by a 6to4 router. Test fails if connection cannot be established.

Test: IPv6 Logo Test (Verify 6to4 is supported)

Test verifies a 6to4 address can be obtained from the router. Test fails if address cannot be obtained.

Test: IPv6 Logo Test (Verify IGD loopback is supported)

Test sends a UDP packet from one internal IP address to another internal IP address and verifies whether the loopback traffic is forwarded back. This feature is needed for Teredo to function in a double NAT scenario.

Test: IPv6 Logo Test (DHCPv6 Support)

Test verifies router supports DHCPv6 by examining the local configuration of a client.

QOS Test

The QOS test name is QOSRouterLogo (LMS), select that test and right click to show edit parameters and update the REMOTEPCADDRESS to the IP address of the DTM interface of the WAN machine. And follow the rest of the instructions above.

IGD byte counters tests

These tests can be identified by the presence of "TotalBytesSent" or "TotalBytesReceived" in their names. The tests should be run one at a time. Although the sequence is not important it is recommended that the Basic logo tests are ran first.

Important manual steps to perform before running the tests: Before running the tests, please perform the following on each LAN-side machine. This is required to make sure that the LAN-side machines can resolve the correct IP address of the WAN machine.

Necessary conditions to run the tests: Please make sure the following conditions are met before running the IGD byte counter tests:

  1. The user logged on to the console of the machines has administrator privileges

  2. UPnP framework is enabled on the IGD

WiFi performance test

Before running a particular WiFi performance job with a specific wireless configuration (SSID, PHY setting, security settings) one has to setup the tested device properly before the test is started. Because the tests cover different wireless settings it's not possible to schedule all WiFi performance jobs at once. It is possible though to group these jobs based on the given wireless configuration.

It's generally good idea to validate connectivity for a given wireless configuration before the test is started. It means applying a given wireless profile at a machine (L1 or L2) and try if you're able to connect using this profile. The used wireless profiles are stored in \\<your DTM controller>\Tests\x86fre\nttest\NetTest\wireless\apcert\profiles. In order to simplify settings the following tables summarize the expected wireless configuration and respective profiles for every test.

Test Case | SSID | PHY | Wireless Security | Security Key
Test_ID_S2_1 | 802_11a_wep | 802.11a | WEP | 0001020304
Test_ID_S2_2 | 802_11a_wpa-psk | 802.11a | WPA-PSK | Nativewifi
Test_ID_S2_3 | 802_11a_wpa2-psk | 802.11a | WPA2-PSK | Nativewifi
Test_ID_S2_4 | 802_11g_wep | 802.11g | WEP | 0001020304
Test_ID_S2_5 | 802_11g_wpa-psk | 802.11g | WPA-PSK | Nativewifi
Test_ID_S2_6 | 802_11g_wpa2-psk | 802.11g | WPA2-PSK | Nativewifi
Test_ID_S3_1 | 802_11a_wpa2-psk | 802.11a | WPA2-PSK | Nativewifi
Test_ID_S3_2 | 802_11g_wpa2-psk | 802.11g | WPA2-PSK | Nativewifi
Test_ID_P3_1 | 802_11a_wpa2-psk | 802.11a | WPA2-PSK | Nativewifi
Test_ID_P3_2 | 802_11a_wpa-psk | 802.11a | WPA-PSK | Nativewifi
Test_ID_P3_3 | 802_11a_wep | 802.11a | WEP | 0001020304
Test_ID_P3_4 | 802_11g_wpa-psk | 802.11g | WPA-PSK | Nativewifi
Test_ID_P3_5 | 802_11g_wep | 802.11g | WEP | 0001020304
Test_ID_P3_6 | 802_11g_wpa2-psk | 802.11g | WPA2-PSK | Nativewifi
Test_ID_P4_1 | 802_11a_wpa2-psk | 802.11a | WPA2-PSK | Nativewifi
Test_ID_P4_2 | 802_11g_wpa2-psk | 802.11g | WPA2-PSK | Nativewifi

For the Windows 7 Logo, there are only two available wireless performance tests. Both use the SSID WIN7_LOGO and the pass phrase "Nativewifi". It should also be noted that the Windows 7 wireless performance tests MUST be conducted over open air and not in a shielded room. Details are in the following table.

Test Case | SSID | PHY | Wireless Security | Security Key
Sustained Throughput-802.11G_WPA2-PSK | WIN7_LOGO | 802.11g | WPA2-PSK | Nativewifi
Sustained Throughput-802.11N_WPA2-PSK | WIN7_LOGO | 802.11n | WPA2-PSK | Nativewifi

Test case and Wireless Profile mapping table

Test Case | SSID
Test_ID_S2_1 | 802_11a_wep.xml
Test_ID_S2_2 | 802_11a_wpa-psk.xml
Test_ID_S2_3 | 802_11a_wpa2-psk.xml
Test_ID_S2_4 | 802_11g_wep.xml
Test_ID_S2_5 | 802_11g_wpa-psk.xml
Test_ID_S2_6 | 802_11g_wpa2-psk.xml
Test_ID_S3_1 | 802_11a_wpa2-psk.xml
Test_ID_S3_2 | 802_11g_wpa2-psk.xml
Test_ID_P3_1 | 802_11a_wpa2-psk.xml
Test_ID_P3_2 | 802_11a_wpa-psk.xml
Test_ID_P3_3 | 802_11a_wep.xml
Test_ID_P3_4 | 802_11g_wpa-psk.xml
Test_ID_P3_5 | 802_11g_wep.xml
Test_ID_P3_6 | 802_11g_wpa2-psk.xml
Test_ID_P4_1 | 802_11a_wpa2-psk.xml
Test_ID_P4_2 | 802_11g_wpa2-psk.xml
Sustained Throughput-802.11G_WPA2-PSK | 802_11n_wpa2-psk.xml
Sustained Throughput-802.11N_WPA2-PSK | 802_11n_wpa2-psk.xml

Appendix A - Troubleshooting logo test issues

This tip will help you in testing the ability of machine sending higher bit rates using Ethernet connection (i.e. validates the machine)

Ethernet Test:

  1. Setup the hardware as shown below with only Ethernet connection Diagram illustrating hardware configuration with Machine S and Machine C connected to a hub

  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 a command prompt and run Stats tool on Machine C with following parameters:

    stats.exe -z DISCARD -i 20 -x 50 -y 30 -r 20000000 -c 3600 -l -h -u

  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

  6. Observe the output of Step 4 and Step 5.

Conclusion:

If the output of either Step 4 or Step 5 shows any failures then your machines cannot make bit rates using wireless adapters.

Appendix B - How to add wireless profile manually

Wireless profile can be added using following command:

netsh wlan add profile filename=<xmlfilename> i=*

For Example: To add the 802_11a_wpa-psk.xml wireless profile:

  1. Click Start, click Run, and enter cmd.exe.

  2. Type netsh wlan add profile filename=802_11a_wpa-psk.xml i=*

  3. Click OK.

Note: Make sure that Wireless Profile XML file exists in the current directory or specify the full path.


EAP Certification Program (ECP) Testing Overview

The procedures that are presented in this section outline the process for testing with the Extensible Authentication Protocol (EAP) Certification Program (ECP) for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

The test procedures are divided into the following types of topics:

Overview: The ECP uses the Windows User Mode Device Framework to install an ECP virtual device bus and to bind Logo-certified EAP methods and network supplicants to user-mode virtual devices. By using this approach, you can install the EAP methods and network supplicants by using the INF/driver mechanism of the operating system. Optionally, you can also use the Windows Update (WU) and Windows Server Update Services (WSUS) driver distribution systems to maintain your driver compatibility.

Preparing: The ECP requires that the server and test clients are appropriately configured. The Preparing for EAP Certification Program (ECP) Testing topic describes how to configure your testing environment.

Running: The Running the EAP Certification Program (ECP) Tests topic describes how to run the ECP.

EAP Certification Program (ECP) Tests

The tests that you need to run depend upon the capabilities of the device or system that you are testing. To review the complete list of tests that could be required to test your device, see:

Extensible Authentication Protocol (EAP) Test - Peer Method

Extensible Authentication Protocol (EAP) Test - Authenticator Method

Extensible Authentication Protocol (EAP) Test - Network Supplicant

Run time: Approximately 24 to 48 hours

Hardware requirements

Not applicable.


Preparing for EAP Certification Program (ECP) Testing

Before running the tests, you must configure your testing environment. This section summarizes the related procedures to do this.

Many of the tests in the Windows Logo Kit (WLK) 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 test system to restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each time the test system restarts in order for the test run to resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about configuring auto logon, see DTM Lab Security.

Modify Registry Settings to Expose the ECP Bus and Device

Use the following procedure to install your ECP device.

  1. To install the device bus, create the following registry key on the test client:
  2. To install a method or supplicant device, create the following registry key on the test client:

    Use the information in the following table to complete this step.

    Scenario RoleID TypeID VendorID VendorType AuthorID

    The role of the component

    The IANA Type ID for the EAP component

    The IANA Enterprise identifier for the vendor who authored the component

    Vendor specific expended type ID

    The IANA Enterprise identifier for the vendor who implemented the component

    EAP method non expanded type

    1 - Peer method
    2 - Authenticator method

    !=0 and !=254 and <=255

    0

    0

    < 2^32

    EAP method expanded type

    ==254

    <2^24

    <2^32

    < 2^32

    Supplicant

    3 - Supplicant

    0

    <2^32

    Vendor-defined numeric identifier

    < 2^32

  3. Make sure that EAPHOST service is running. To start the EAPHOST service, run the following command:
    NET START EAPHOST

Note We recommended that you also enable the EAPHOST service to start automatically. To start the EAPHOST service automatically, run the following command:

SC set EAPHOST start=auto

Example Registry Settings

The following two examples show how to specify registry keys for your method or supplicant:

Microsoft peer EAP-MSCHAPv2:

Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EapHost\ECP\1.29.0.0.311

Device ID:

EH\1.29.0.0.311
Scenario | RoleID | TypeID | VendorID | VendorType | AuthorID
MS EAP-MSCHAPv2 | 1 | 29 | 0 | 0 | 311

Microsoft peer simple configuration (extended type):

Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EapHost\ECP\1.254.14122.1.311

Device ID:

EH\1.254.14122.1.311
Scenario | RoleID | TypeID | VendorID | VendorType | AuthorID
MS EAP-MSCHAPv2 | 1 | 254 | 14122 (WFA-SMI) | 1 | 311

Sample supplicant:

Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EapHost\ECP\3.0.xx.yy.zz

Device ID:

EH\3.0.xx.yy.zz
Scenario | RoleID | TypeID | VendorID | VendorType | AuthorID
MS EAP-MSCHAPv2 | 3 | 0 | xx (Author IANA ID) | yy (implementer defined numeric identifier) | zz (Implementer IANA ID)

Note Do not use the Microsoft examples to specify your registry keys. You must specify your own registry keys.

EAP Device Installation

After you have created the registry key, it might take up to 5 minutes for the device console to reflect the configuration change and display the device. You should see something similar to the following screen shot when the device has been configured and initialized by Windows:

Screen shot of the Device Manager dialog box with three system devices circled

After the device appears, update it to use the latest driver.

There are two methods you can use to update the driver.

  1. Right-click the ECPNode and click Properties.

  2. On the Driver tab, click Update Driver.

  3. Click Browse my computer for driver software, and point to the location where the package is installed.

Alternately, you can use this method.

  1. Extract all the needed files (binaries and INF files) to a folder.

  2. Right-click the extracted INF file, and click Install.

ECP Package Installation

Extract the entire ECP package (including the INF file and binaries) to a folder on the test client. Make sure that you make a note of folder because you will need to specify the same folder in the Submission dialog box when you enter the details for your submission.

User and Connection XMLs required with method testing

The EAP Certification Program requires end-to-end authentication to verify your EAP method(s)/supplicant. For authentication to be successful, both user XML and connection XML files are required.

These files must exist on the test client. You will be prompted to enter the location of these files and the file name(s) when you schedule your submission.

You must supply the connection XML file. This file specifies which method of authentication is to be used for testing. Additionally, you can also specify details about the way the authentication is to be performed.

You also supply the user XML file, which typically specifies the credentials that will be used by the method during authentication.

Connect/disconnect scripts for supplicant method tests

When you test a supplicant method, you need a script that instructs the supplicant method to connect and disconnect. You then specify the folder and filename of these scripts in the Submission dialog box when you schedule your submission.

You must create these scripts, and make sure that they are present on the test client before you begin the test. Otherwise, the submission will fail.

You can use either of the following methods to create a sample script named "RestartSupplicant.cmd" that stops and restarts "SampleSupplicant":

NET STOP SampleSupplicant
NET START SampleSupplicant

Alternatively, you can use "Taskkill" as a technique to recycle your supplicant method. In this case, the "RestartSupplicant.cmd" script would be as follows:

Taskkill /f /im SampleSupplicant.exe
SampleSupplicant

Re-running gatherer to apply changes done in target test type

When you change the target test type by changing any value in the"ECP\RoleID.TypeID.VendorID.VendorType.AuthorID" registry key, follow these steps:

  1. Change the property of "wttsvc" service to manual.

  2. Stop "wttsvc" service.

  3. Change desired value under ECP registry key.

  4. Restart "Eaphost" service.

  5. Wait 5 minutes until ECPNode device is created.

  6. Start "wttsvc" service.

  7. Create new submission and start testing.

Preparing to run your first submission

  1. Install the DTM Controller.

  2. Install the DTM Client.

    Note You must install Windows Vista SP1 or later as the operating system on the client machine.

  3. Install DTM Studio.

  4. Create a new machine pool and then add the client to a machine pool.

  5. Create two LLUs named LLU_NAO (Network Access Only and LLU_LAU (Local Administrative User) on the machine pool .

  6. Open Services.msc, change property of "wttsvc" service to manual, and then stop the service. Create "ECP\RoleID.TypeID.VendorID.VendorType.AuthorID" as described above. Wait 5 minutes until the ECPNode device is created. Then start the "wttsvc" service.

  7. If you are using a peer method, make sure your authentication server is running and ready to process calls.

  8. Install the method to test on the test client(s).

  9. Setup the RADIUS server and add the current method as the authentication method in the radius server.

  10. For testing Authenticator method, create a RADIUS client with the same IP address as that of the target test machine.

  11. Make sure that you make note of the folder that you plan to install your ECP package to. For example, name your folder "C:\EAPSample".

    The directory structure should be similar to the following example:

    C:\EAPSample\

    | install.inf

    |

    +-----AMD64\

    | EAPSAMPLE.DLL

    |

    \-------X86\

    EAPSAMPLE.DLL


Running the EAP Certification Program (ECP) Tests

The test client must contain an ECP device in order for the testing to begin. Failure to have successfully created a device will result in failures when you run the certification tests and result in failed submissions.

We recommend that you have two test computers: one computer to run the tests on, and the other computer to host the server/authenticator. However, it is possible to execute the tests and host the server/authenticator on the same host computer.

Make sure that you have configured your test client correctly and that you can perform a complete end-to-end authentication manually on your test client. Note that you might need to disable the firewall on your client and server to proceed.

Create your Submission

After you have installed the method and updated it through the Device Manager, you can start testing and create a submission to validate your method.

To create a submission, complete the following steps.

  1. Make sure that the test client's status is set to Ready in the Job Monitor view. To determine status, click your test client, and then click Refresh.

  2. On the Explorers menu, click the Device Console.

  3. Click the Submissions button.

  4. Click <New submission>.

  5. Click Windows Vista Client (or Windows Server 2008, as appropriate for your submission).

  6. Complete the wizard by selecting the options that correspond to your method.

  7. After you have completed the wizard, the related methods will appear in the Available Jobs view.

  8. You must select all these cases, one by one, and schedule them to run.

  9. After you have selected a case, click ADD. The following dialog box appears. Screen shot of the Peer tab on the Job extension dialog box

  10. Fill in the necessary information that corresponds to the method that you want to test. If you make an error or leave a field blank, your submission might fail. The different tabs and fields of this dialog box are explained later in this section.

  11. The Expected Auth Completion Time(ms) field displays the expected time in milliseconds that are used by one full end-to-end authentication. This value should also include any user interaction time, which might be needed to enter user credentials during authentication.

  12. After you have entered the necessary information, click Save.

Note Testing for the Authenticator method applies only to Windows 2008 Server and Windows 2008 Server R2 submissions.

Peer Method Details

  • The EAP Type, Vendor ID, Vendor Type, and Author ID fields should match the TypeID, VendorID, VendorType, and AuthorID values that you specified to create the registry key for your method as described under Modify Registry Settings to Expose the ECP Bus and Device in Preparing for EAP Certification Program (ECP) Testing.

  • BeginSessionFlag: This is the value to pass to BeginSessionAPI. For more information about the API, see the Preparing for EAP Certification Program (ECP) Testing.

  • IANA Enterprise Name: The name of your enterprise. You can obtain this information from the IANA.

Radius Details

  • Radius Server IP: Corresponds to the IP address of your Radius server.

  • Client Machine IP: Corresponds to the IP address of the test client.

  • Shared Secret: Represents the arbitrary encryption key that you use to secure the connection between a RADIUS client and a RADIUS server.

Supported Methods Properties

  • MutualAuth: The method provides an exchange, in which the authenticator authenticates the peer, and the peer authenticates the authenticator.

  • Integrity: The method provides data origin authentication and protection against unauthorized changes to the EAP packets, including EAP requests and responses. When a specification method specifies this field, it must specify the protected EAP packets and protected fields within the EAP packets.

  • ReplayProtection: The method can protect against replay of an EAP method or its messages. Success and failure result indications cannot be replayed.

  • Confidentiality: The method can encrypt EAP messages. EAP requests, EAP responses, success result indications, and failure result indications are encrypted. A method that specifies this field must support identity protection.

  • KeyDerivation: The method can derive exportable keying material, such as the Master Session Key (MSK) and the Extended Master Session Key (EMSK). The MSK is used only for further key derivation, not directly for protection of the EAP conversation or subsequent data. Use of the EMSK is reserved.

  • MethodChaining: The method has the ability of method chaining. This is applicable for tunneling methods only.

  • DictionaryAttackResistance: The method does not allow an offline attack that has a work factor that is based on the number of passwords in an attacker's dictionary. If password authentication is used, passwords are commonly selected from a small set (as compared to a set of N-bit keys), which raises a concern about dictionary attacks. A method might be able to provide protection against dictionary attacks if, when it uses a password as a secret, the method does not allow an offline attack that has a work factor that is based on the number of passwords in an attacker's dictionary.

  • Shared State Equivalence: The method has the ability to support shared state equivalence as defined in RFC4017.

  • Identity Privacy: The method completes an authentication without exposing the authenticated identity in the EAP identity response or unencrypted identity during the authentication itself.

  • FastReconnect: The method has the ability, in the case where a security association has been previously established, to create a new or refreshed security association more efficiently or in a smaller number of round trips.

  • CryptoBinding: The method shows the EAP server that a single entity has acted as the EAP peer for all methods that are executed within a tunnel method. Binding may also imply that the EAP server shows the peer that a single entity has acted as the EAP server for all methods that are executed within a tunnel method. If executed correctly, binding serves to mitigate man-in-the-middle vulnerabilities.

  • Machine Auth: The method has the ability to do machine authentication

  • User Auth: The method has the ability to do user authentication

  • Fragmentation: The method can support fragmentation and reassembly if EAP packets exceed the minimum maximum transmission unit (MTU) of 1020 octets.

  • ChannelBinding: The method can communicate integrity-protected channel properties, such as endpoint identifiers, which can be compared to values that are communicated by using nontraditional mechanisms. For example, these properties can be an Authentication, Authorization, and Accounting (AAA) or the lower layer protocol.

  • NapSupport: The method supports Network Access Protection (NAP).

  • Standalone: The method can be used on a stand-alone computer.

  • SupportsConfig: The method has a user interface and supports configurable properties.

  • MppEncryption: The method supports Microsoft Point-to-Point Encryption (MPPE) protocol encryption.

  • SessionIndependence: The method shows that passive attacks (such as capture of the EAP conversation) or active attacks (including compromise of the MSK or EMSK) do not compromise subsequent or prior MSKs or EMSKs.

  • CipherSuiteNegotiation: The method allows the cipher suite to be negotiated for the purpose of data encryption.

  • KeyStrength64: The minimum key length that is supported by the EAP method is 64 bits.

  • KeyStrength128: The minimum key length that is supported by the EAP method is 128 bits.

  • KeyStrength256: The minimum key length that is supported by the EAP method is 256 bits.

  • KeyStrength512: The minimum key length that is supported by the EAP method is 512 bits.

  • KeyStrength1024: The minimum key length that is supported by the EAP method is 1024 bits.

Note MSDN provides a reference for EAP method properties.

ECP Binary Info

  • ECP Package Name and Location: The path where you extracted the INF file and DLL(s) for your method.

  • User XML Name and Location: The path and name to the file to use for user credentials. The file that you specify must be physically present on the client computer. You must supply this XML file because it does not come with the logo kit. The submission process uses this file to create successful end-to-end authentications on the client computer.

  • User XML Schema Name and Location: The path and name to the schema file to use for user credentials.

  • Conn XML Name and Location: The path and name to the file to use for connection configurations. The file that you specify must be physically present on the client computer. You must supply this XML file because it does not come with the logo kit. The submission process uses this file to create successful end-to-end authentications on the client computer.

  • Conn XML Schema Name and Location: The path and name to the schema file for connection configurations.

  • ECP Binary Name and Location: The path and name to your method DLL to use with testing. To comply with logo requirements, the DLL should be located in %PROGRAMFILES%.

  • Trace File Name and Location: The path and name where traces that are generated by the method should be stored for validation.

  • Channel\Provider Name: The name that is used for registering Event\Channel provider name for windows event.

Specifications for the Supplicant method tab in the Job Extensions dialog box

The following screen shot shows the Supplicant tab on the Job extension dialog box.

Note Supplicant method testing applies only to Windows 2008 Server submissions.

Screen shot of the Supplicant tab on the Job extension dialog box

Supplicant Config Details

  • The Vendor Type, Vendor ID, and Author ID fields should match the VendorType, VendorID, and AuthorID values that you specified to create the registry key for your method. This process is described in the Modify Registry Settings to Expose the ECP Bus and Device topic in Preparing for EAP Certification Program (ECP) Testing.

Note Select the Check if Supplicant Runs As a Service check box to indicate that your supplicant method runs as a service (like the Microsoft wireless supplicant).

ECP Binary Info

  • ECP Package Name and Location: The path where you extracted the INF file and DLL(s) for your supplicant method.

  • ECP Binary Name and Location: The path and name to your method DLL to use with testing. To comply with logo requirements, the DLL should be located in %PROGRAMFILES%.

  • Trace File Name and Location: The path and name where all traces that are generated by the supplicant method should be stored for validation.

  • Supplicant Executable Script: The path and name of the script that forces the supplicant method to perform a full authentication. The script should contain everything necessary to instruct the supplicant method.

  • IANA Enterprise Name: The name of your enterprise. You can obtain this information from the IANA.

  • Script to Restart Supplicant Service Name and Location: The path and name of the script to restart the supplicant method. This information is described in the Connect/disconnect scripts for Supplicant method tests topic in Preparing for EAP Certification Program (ECP) Testing. Note that this field is disabled if Check if Supplicant Runs As a Service is not checked.


Network Security Software Testing

Network Security Software Testing Overview

Preparing for Network Security Software Testing

Running the Network Security Software Tests


Network Security Software Testing Overview

This section discusses how to test your Network Security Software for correct functionality with the Microsoft Windows operating system. The procedures in this section use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure full functionality, you must run all the tests that the DTM requires 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 and software requirements, as well as knowledge requirements of the test engineer who runs the tests.

Preparing: The preparing topics describe how to configure the system or systems for Windows logo testing.

Running: The running topics describe how to run the tests for your device or system.

Network Security Software Tests

The list of tests that you need to run depend upon the capabilities of the device or system being tested. To see the complete list of tests that might be required for your device, see Network Controller Tests .

Run time: Approximately 2.5 hours

Hardware requirements

The following hardware is required to run the network security software tests. Additional hardware might 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 single computer that has the following specifications:

    • Has at least one network interface card that is connected. Ideally, the network interface card is on a private network with the DTM Controller's network interface.
    • Supports S1-S3 (Suspend) and S4 (Hibernate) power states.
    • Is not joined to a domain.

Software requirements

The following software is required to run the Network Security Software tests:

  • Network Security Software to test. This software is expected to be freshly installed on a computer that has a clean installation of Windows 7.

Firewalls\Network_SecuritySoftware_Firewalls_BasicFirewall_Tests

File name

Origin / Removal

Location

Purpose

CabArc.Exe

Copied as part of the Network Security Software tests' "Basic Firewalls - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Basic Firewalls - Remove Binaries" library job. For more information about library jobs, go to "Creating a Library Job."

%WinDir%\System32\

This file is used to create a cabinet file of the logs: Networking_SecuritySoftware_Firewalls_Basic_Firewall.cab.

Callout.Sys

Copied as part of the Network Security Software tests' "Basic Firewalls - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Basic Firewalls - Remove Binaries" library job.

%WinDir%\System32\Drivers\

This file is required for the tests' callout functions that are used during the stream and injection tests

DrInstall.Exe

Copied as part of the Network Security Software tests' "Basic Firewalls - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Basic Firewalls - Remove Binaries" library job.

%WinDir%\System32\

This file is required for to install the Sparta Miniport Driver.

NTLog.DLL

Copied as part of the Network Security Software tests' Basic Firewalls - Copy Binaries library job.

Removed as part of the Network Security Software tests' Basic Firewalls - Remove Binaries library job.

%WinDir%\System32\

This file is required to log output for the test environment.

SpartaMini.Cat

Copied as part of the Network Security Software tests' "Basic Firewalls - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Basic Firewalls - Remove Binaries" library job.

%WinDir%\System32\Drivers\

This file is required to install the Sparta Miniport Driver.

SpartaMini.Inf

Copied as part of the Network Security Software tests' "Basic Firewalls - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Basic Firewalls - Remove Binaries" library job

%WinDir%\System32\Drivers\

This file is required to install the Sparta Miniport Driver.

SpartaMini.Sys

Copied as part of the Network Security Software tests' "Basic Firewalls - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Basic Firewalls - Remove Binaries" library job.

%WinDir%\System32\Drivers\

This file is required to install the Sparta Miniport Driver.

WFPLogo.Answer

Copied as part of the Network Security Software tests' "Basic Firewalls - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Basic Firewalls - Remove Binaries" library job.

%WinDir%\System32\

This file is optional to partially automate the test process.

WFPLogo.Exe

Copied as part of the Network Security Software tests' "Basic Firewalls - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Basic Firewalls - Remove Binaries" library job.

%WinDir%\System32\

This file is required in order for the test to run.

WFPLogo.Info

Copied as part of the Network Security Software tests' "Basic Firewalls - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Basic Firewalls - Remove Binaries" library job.

%WinDir%\System32\

This file is required to determine how best to run the tests for the Network Security Software's.

WFPLogo.NTLog

Created during test execution.

%WinDir%\System32\

This file is created at runtime to log whether each test passes or fails.

WFPLogo.Trace

Created during test execution.

%WinDir%\System32\

This file is created at runtime and is used to troubleshoot what WFP objects were added during the test run.

WFPLogoSetup.JS

Copied as part of the Network Security Software tests' "Basic Firewalls - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Basic Firewalls - Remove Binaries" library job.

%WinDir%\System32\

This file is used to install and configure the Sparta Miniport drivers.

Firewalls\Network_SecuritySoftware_Firewalls_TransitionTechnologies_Tests

File name

Origin / Removal

Location

Purpose

AutoSrv.Exe

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required to run the tests that use the Sparta Miniport driver.

AutoSrvC.DLL

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required to run the tests that use the Sparta Miniport driver.

CabArc.Exe

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%WinDir%\System32\

This file is used to create a cabinet file of the logs: Networking_SecuritySoftware_Firewalls_Transition_Technologies.cab.

DevCon.Exe

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required to install the Sparta Miniport driver.

DrvInstall.Exe

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required to install the Sparta Miniport driver.

InitAddress.VBS

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required by Teredo_WLK.wsf to run the test scenarios.

InstallSpartaMini.Bat

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is used to install and uninstall the Sparta Miniport driver.

NetCapDrv6.Cat

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required by the Sparta Miniport driver to capture the network packets during the tests.

NetCapDrv6.Inf

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required by the Sparta Miniport driver to capture the network packets during the tests.

NetCapDrv6.Sys

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required by the Sparta Miniport driver to capture the network packets during the tests.

NetCapture.DLL

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required by the Sparta Miniport driver to capture the network packets during the tests.

NTLog.DLL

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required to create output logs for the test environment.

SpartaCM.DLL

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required to install the Sparta Miniport driver.

SpartaExtensions.MSI

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required to install the Sparta Miniport driver.

SpartaMini.Cat

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required to install the Sparta Miniport driver.

SpartaMini.Inf

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required to install the Sparta Miniport driver.

SpartaMini.Sys

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required to install the Sparta Miniport driver.

TestCore.DLL

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta\

This file is required to install the Sparta Miniport driver.

Common.VBS

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta_Test\Common

This file is required by Teredo_WLK.wsf to run the test scenarios.

DNS.VBS

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta_Test\DNS

This file is required by Teredo_WLK.wsf to run the test scenarios.

Teredo_WLK.WSF

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta_Test\Tunnel\Teredo\

This script file is used to run the transition technologies tests. This file is required by the job, Transition Technologies - Run Teredo Tests.

TeredoEmulator.VBS

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta_Test\Tunnel\Teredo\

This file is required by Teredo_WLK.wsf to run the test scenarios

TeredoPeer.VBS

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta_Test\Tunnel\Teredo\

This file is required by Teredo_WLK.wsf to run the test scenarios.

Tunnel.VBS

Copied as part of the Network Security Software tests' "Transition Technologies - Copy Binaries" library job.

Removed as part of the Network Security Software tests' "Transition Technologies - Remove Binaries" library job.

%SystemDrive%\Sparta_Test\Tunnel\

This file is required by Teredo_WLK.wsf to run the test scenarios.

Knowledge Requirements

To run the Network Security Software tests, the test engineer must be able to complete the following tasks:

  • Add and remove various filters (rules) for the network security software under test.


Preparing for Network Security Software Testing

Before you run the tests, you must configure the system under test and install the operating system. This section explains how to do both.

For a complete list of required hardware and software, and the knowledge requirements of the test engineer, see Network Security Software Testing Overview.

Many of the tests in the Windows Logo Kit require a test system to restart (often more than one time) in order 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.


Running the Network Security Software Tests

The logo tests consist of two test suites: one test validates Basic Firewall operation, and one test validates interoperability with Transition Technologies (currently targeted at Teredo). The suites consist of multiple parts.

Firewalls\Network_SecuritySoftware_Firewalls_BasicFirewall_Tests

The first part of running the Network Security Software Basic Firewalls Tests is to copy the required binary files. You do this by running the "Basic Firewall - Copy Binaries" library job. For more information about library jobs, go to "Creating a Library Job."

Second, the Sparta Miniport drivers must be installed and configured correctly. To install the Sparta Miniport drivers, run the "Install Sparta Miniport Interfaces (x4)" library job. To confirm that the job was installed, open a command prompt and type IPConfig.exe /all. You should see four new Sparta interfaces named Sparta Miniport Primary, Sparta Miniport Secondary, Sparta Miniport Tertiary, and Sparta Miniport Quaternary.

You can now run these tests. The test suite starts the "Basic Firewall - Run WFPLogo.exe" library job. The WFPLogo Information Gathering dialog box appears, showing the WFPTest.Info form. Fill in the form completely. The Network Security Software Tests use this information to validate the WLK Requirements.

The form consists of the following fields.

Value name

Description

Default value

CompanyName

Populate this value with the name of your company. This information is used to help validate the Network Security Software's WFP Provider.

""Microsoft Corporation"

ProductName

Populate this value with the name of the Network Security Software. This information is used to help validate the Network Security Software's WFP Provider.

"Windows Firewall"

UseAnswerFile

Populate this value with 1 if you are supplying an answer file to automate the filter additions, deletions, or both during the logo test run. Otherwise, set to 0. For more information, see the "WFPLogo.Answer File Expansion" table below.

0

CalloutDriver

Populate this value with 1 if your Network Security Software contains a callout driver. Otherwise, set to 0.

1

LayeredOnMicrosoftWindowsFirewall

Populate this value with 1 if your Network Security Software adds filters and rules to Windows Firewall. Otherwise, set to 0.

0

WFPObjectEnumAndACLs

Populate this value with 1 if any WFP objects your Network Security Software adds uses access control lists so that a third party would be able to enumerate them. If you set this to 0, the logo test will fail.

0

NonTampered3rdPartyObjects

Populate this value with 1 if your Network Security Software does not manipulate any third party's WFP object(s). If you set this to 0, the logo test will fail.

0

NoPermitBlockAll

Populate this value with 1 if your Network Security Software does not contain only a "permit all" or "block all" filter. If you set this to 0, the logo test will fail.

0

NoAVs

Populate this value with 1 if your Network Security Software has no known causes for an Access Violation to occur. If you set this to 0, the logo test will fail.

0

CleanUp

Populate this value with 1 if your Network Security Software, when properly uninstalled, performs cleanup of all its WFP Objects, registry entries, and files, and attempts to restore Windows Firewall if it disabled it during installation. If you set this to 0, the logo test will fail.

0

TDIFiltering

Populate this value with 1 if your Network Security Software uses TDI Filters. Otherwise, set it to 0.

If your Network Security Software is using TDI Filters, explain why you are using TDI filtering instead of WFP.

Because WFP is replacing TDI Filtering, if you set this value to 1, thetest will fail and will require that you obtain an exception.

0

NDISFiltering

Populate this value with 1 if your Network Security Software uses of NDIS Filters. Otherwise, set it to 0.

If your Network Security Software is using NDIS Filters, explain why you are using NDIS Filtering instead of WFP.

0

WinSockLSP

Populate this value with 1 if your Network Security Software uses WinSock Layered Service Providers. Otherwise, set it to 0.

If your Network Security Software is using WinSock Layered Service Providers, explain why you are using Network Security Software instead of WFP.

0

Save the form and click OK. The WFP Logo tests will run. You will be prompted to configure the Network Security Software in various specific configurations before many of the tests begin. You will also need to remove the configuration after the test has run. This dialog box contains all required information to make the test succeed.

Each of the following tests request that the Network Security Software be configured as the following:

ArchitectualDesign.PowerStates

  • Variation: Permit Outbound IPv4
    • Source / Local Address= Pseudo Random i.e. 1.0.0.1
    • Destination / Remote Address= Pseudo Random i.e. 1.0.0.254
    • Protocol= Pseudo Random i.e. TCP (6)
    • Source / Remote Port= Random i.e. 43990
    • Destination / Local Port= Random i.e. 45521
  • Variation: Block Outbound IPv4
    • Source / Local Address= Pseudo Random i.e. 1.0.0.1
    • Destination / Remote Address= Pseudo Random i.e. 1.0.0.254
    • Protocol= Pseudo Random i.e. UDP (17)
    • Source / Remote Port= Random i.e. 43990
    • Destination / Local Port= Random i.e. 45521
  • Variation: Permit Inbound IPv4
    • Source / Remote Address= Pseudo Random i.e. 1.0.0.254
    • Destination / Local Address= Pseudo Random i.e. 1.0.0.1
    • Protocol= Pseudo Random i.e. UDP (17)
    • Source / Remote Port= Random i.e. 43990
    • Destination / Local Port= Random i.e. 45521
  • Variation: Block Inbound IPv4
    • Source / Remote Address= Pseudo Random i.e. 1.0.0.254
    • Destination / Local Address= Pseudo Random i.e. 1.0.0.1
    • Protocol= Pseudo Random i.e. TCP (6)
    • Source / Remote Port= Random i.e. 45521
    • Destination / Local Port= Random i.e. 43990
  • Variation: Permit Outbound IPv6
    • Source / Local Address= Pseudo Random i.e. FE80::8D8C:ECCB:1589:F169
    • Destination / Remote Address= Pseudo Random i.e. FE80::1:0:0:FE
    • Protocol= Pseudo Random i.e. UDP (17)
    • Source / Remote Port= Random i.e. 45521
    • Destination / Local Port= Random i.e. 43990
  • Variation: Block Outbound IPv6
    • Source / Local Address= Pseudo Random i.e. FE80::8D8C:ECCB:1589:F169
    • Destination / Remote Address= Pseudo Random i.e. FE80::1:0:0:FE
    • Protocol= Pseudo Random i.e. TCP (6)
    • Source / Remote Port= Random i.e. 45521
    • Destination / Local Port= Random i.e. 43990
  • Variation: Permit Inbound IPv6
    • Source / Remote Address= Pseudo Random i.e. FE80::1:0:0:FE
    • Destination / Local Address= Pseudo Random i.e. FE80::8D8C:ECCB:1589:F169
    • Protocol= Pseudo Random i.e. UDP (17)
    • Source / Remote Port= Random i.e. 45521
    • Destination / Local Port= Random i.e. 43990
  • Variation: Block Inbound IPv6
    • Source / Remote Address= Pseudo Random i.e. FE80::1:0:0:FE
    • Destination / Local Address= Pseudo Random i.e. FE80::8D8C:ECCB:1589:F169
    • Protocol= Pseudo Random i.e. TCP (6)
    • Source / Remote Port= Random i.e. 45521
    • Destination / Local Port= Random i.e. 43990

ArchitectualDesign.StreamFiltering.StarveStream

  • Variation: IPv4
    • Protocol= TCP (6)
    • Source / Remote Address= Pseudo Random i.e. 1.0.0.254
    • Destination / Local Address= Pseudo Random i.e. 1.0.0.1
    • Source / Remote Port= Random i.e. 43919
    • Destination / Local Port= Random i.e. 49037
  • Variation: IPv6
    • Protocol= TCP (6)
    • Source / Remote Address= Pseudo Random i.e. FE80::1:0:0:FE
    • Destination / Local Address= Pseudo Random i.e. FE80::8D8C:ECCB:1589:F169
    • Source / Remote Port= Random i.e. 43900
    • Destination / Local Port= Random i.e. 49005

Scenarios.AddressExceptions

  • Variation: Permit Outbound IPv4
    • Source / Local Address= Pseudo Random i.e. 1.0.0.1
    • Destination / Remote Address= Pseudo Random i.e. 1.0.0.254
  • Variation: Block Outbound IPv4
    • Source / Local Address= Pseudo Random i.e. 1.0.0.1
    • Destination / Remote Address= Pseudo Random i.e. 1.0.0.254
  • Variation: Permit Inbound IPv4
    • Source / Remote Address= Pseudo Random i.e. 1.0.0.254
    • Destination / Local Address= Pseudo Random i.e. 1.0.0.1
  • Variation: Block Inbound IPv4
    • Source / Remote Address= Pseudo Random i.e. 1.0.0.254
    • Destination / Local Address= Pseudo Random i.e. 1.0.0.1
  • Variation: Permit Outbound IPv6
    • Source / Local Address= Pseudo Random i.e. FE80::8D8C:ECCB:1589:F169
    • Destination / Remote Address= Pseudo Random i.e. FE80::1:0:0:FE
  • Variation: Block Outbound IPv6
    • Source / Local Address= Pseudo Random i.e. FE80::8D8C:ECCB:1589:F169
    • Destination / Remote Address= Pseudo Random i.e. FE80::1:0:0:FE
  • Variation: Permit Inbound IPv6
    • Source / Remote Address= Pseudo Random i.e. FE80::1:0:0:FE
    • Destination / Local Address= Pseudo Random i.e. FE80::8D8C:ECCB:1589:F169
  • Variation: Block Inbound IPv6
    • Source / Remote Address= Pseudo Random i.e. FE80::1:0:0:FE
    • Destination / Local Address= Pseudo Random i.e. FE80::8D8C:ECCB:1589:F169

Scenarios.PortExceptions

  • Variation: Permit Outbound IPv4
    • Protocol= Pseudo Random i.e. UDP (17)
    • Source / Local Port= Random i.e. 42930
    • Destination / Remote Port= Random i.e. 47702
  • Variation: Block Outbound IPv4
    • Protocol= Pseudo Random i.e. Raw UDP (17)
    • Source / Local Port= Random i.e. 41468
    • Destination / Remote Port= Random i.e. 46747
  • Variation: Permit Inbound IPv4
    • Protocol= Pseudo Random i.e. Raw UDP (17)
    • Source / Remote Port= Random i.e. 44033
    • Destination / Local Port= Random i.e. 46859
  • Variation: Block Inbound IPv4
    • Protocol= Pseudo Random i.e. UDP (17)
    • Source / Remote Port= Random i.e. 41388
    • Destination / Local Port= Random i.e. 48370
  • Variation: Permit Outbound IPv6
    • Protocol= Pseudo Random i.e. TCP (6)
    • Source / Local Port= Random i.e. 41975
    • Destination / Remote Port= Random i.e. 47275
  • Variation: Block Outbound IPv6
    • Protocol= Pseudo Random i.e. Raw UDP (17)
    • Source / Local Port= Random i.e. 44754
    • Destination / Remote Port= Random i.e. 445305
  • Variation: Permit Inbound IPv6
    • Protocol= Pseudo Random i.e. TCP (6)
    • Source / Remote Port= Random i.e. 41008
    • Destination / Local Port= Random i.e. 46382
  • Variation: Block Inbound IPv6
    • Protocol= Pseudo Random i.e. UDP (17)
    • Source / Remote Port= Random i.e. 43990
    • Destination / Local Port= Random i.e. 45521

Scenarios.ProtocolExceptions

  • Variation: Permit Outbound IPv4
    • Protocol= Pseudo Random i.e. Raw UDP (17)
  • Variation: Block Outbound IPv4
    • Protocol= Pseudo Random i.e. UDP (17)
  • Variation: Permit Inbound IPv4
    • Protocol= Pseudo Random i.e. IP Raw (255)
  • Variation: Block Inbound IPv4
    • Protocol= Pseudo Random i.e. TCP (6)
  • Variation: Permit Outbound IPv6
    • Protocol= Pseudo Random i.e. IP Raw (255)
  • Variation: Block Outbound IPv6
    • Protocol= Pseudo Random i.e. IPv6 ICMP (58)
  • Variation: Permit Inbound IPv6
    • Protocol= Pseudo Random i.e. IPv6 ICMP (58)
  • Variation: Block Inbound IPv6
    • Protocol= Pseudo Random i.e. IPv6 ICMP (58)

Scenarios.ICMPExceptions

  • Variation: Permit Outbound IPv4
    • Protocol= IPv4 ICMP (1)
    • Type= Pseudo Random i.e. 8
    • Code= Pseudo Random i.e. 0
  • Variation: Block Outbound IPv4
    • Protocol= IPv4 ICMP (1)
    • Type= Pseudo Random i.e. 8
    • Code= Pseudo Random i.e. 0
  • Variation: Permit Inbound IPv4
    • Protocol= IPv4 ICMP (1)
    • Type= Pseudo Random i.e. 8
    • Code= Pseudo Random i.e. 0
  • Variation: Block Inbound IPv4
    • Protocol= IPv4 ICMP (1)
    • Type= Pseudo Random i.e. 8
    • Code= Pseudo Random i.e. 0
  • Variation: Permit Outbound IPv6
    • Protocol= IPv6 ICMP (58)
    • Type= Pseudo Random i.e. 128
    • Code= Pseudo Random i.e. 0
  • Variation: Block Outbound IPv6
    • Protocol= IPv6 ICMP (58)
    • Type= Pseudo Random i.e. 128
    • Code= Pseudo Random i.e. 0
  • Variation: Permit Inbound IPv6
    • Protocol= IPv6 ICMP (58)
    • Type= Pseudo Random i.e. 128
    • Code= Pseudo Random i.e. 0
  • Variation: Block Inbound IPv6
    • Protocol= IPv6 ICMP (58)
    • Type= Pseudo Random i.e. 128
    • Code= Pseudo Random i.e. 0

Be aware that you can automate the addition, deletion, or both, of filters by modifying the WFPLogo.Answer file. This answer file is parsed by the logo tests to run the command-line that is specified for the applicable test. It is filled out by default to use the NetSh.exe command-line tool to configure Windows Firewall for the tests. By using this method, you enable a more repeatable and faster test pass. The answer file replaces the following variables with the correct value being used during the test:

WFPLogo.Answer File Expansion
Parameter | Use | Example
%APPLICATION% | Replaced during runtime with the Application's Name that is used. | %WinDir%\System32\WFPLogo.Exe
%LOCAL_IP% | Replaced during runtime with the Local IP Address that is used. | IPv4 | 1.0.0.1
 |  | IPv6 | FE80::1:0:0:1
%REMOTE_IP% | Replaced during runtime with the Remote IP Address that is used. | IPv4 | 1.0.0.254
 |  | IPv6 | FE80::1:0:0:254
%PROTOCOL% | Replaced during runtime with the IP Protocol that is used. | 17
%LOCAL_PORT% | Replaced during runtime with the Local Port that is used. | 40960
%REMOTE_PORT% | Replaced during runtime with the Remote Port that is used. | 45056
%ICMP_TYPE% | Replaced during runtime with the ICMP Type that is used. | 8
%ICMP_CODE% | Replaced during runtime with the ICMP Code that is used. | 0
%IS_RAW% | Replaced during runtime with the Boolean value that represents whether or not the socket is raw. | Raw Socket |  | 1
 |  | Native Socket |  | 0

After the "Basic Firewall - Uninstall Sparta Miniport Interfaces (x4)" library job runs the tests successfully, it removes the Sparta Miniport interfaces.

Finally, running the "Basic Firewall - Remove Binaries" library job deletes the copied files.

Firewalls\Network_SecuritySoftware_Firewalls_TransitionTechnologies_Tests

The first part of running the Network Security Software Transition Technologies Tests to copy the required binary files. You do this by running the "Transition Technologies - Copy Binaries" library job.

Next, the Sparta Miniport drivers must be installed and configured correctly. You do this by running the "Transition Technologies - Install Sparta Miniport (x1)" library job. To confirm that the drivers were installed correctly, open a command prompt and type IPConfig.exe /all. You should see one Sparta interface.

Now the tests can be run. The test suite starts the "Transition Technologies - Run Teredo Tests" library job. The following variations are run:

  • S1 - Check DNS query for Teredo server succeeds.

  • S2 - Teredo qualifies as if behind a port preserving symmetric NAT.

  • S3 - Sequential symmetric NAT. Send and receive traffic on peer ports.

To succeed, these tests must meet the following requirements:

S1 - Check DNS query for Teredo server succeeds

This test verifies that the system can send a DNS query for the Teredo server address and receive the DNS response. If the test is successful, the Teredo client will be in the DORMANT state.

For the test to complete successfully, make sure that the firewall does not block any DNS traffic. Most firewalls allow DNS requests and responses by default. The following configuration is used by the test:

  • (Spoofed) Teredo Server : 5.5.1.21

  • (Spoofed) DNS Server : 5.5.1.21 (port 53)

  • DNS query sent : teredo.ipv6.microsoft.com

S2 - Teredo qualifies as if behind a port preserving symmetric NAT

The test verifies that the system can send and receive multiple Router Solicitations (RS) and Router Advertisements (RA) . In this case, the Teredo client acts as if it is behind a port, preserving symmetric NAT.

For the test to be successful, it must receive inbound Teredo packets (over UDP) on the local port 7000. Before the test begins, you are prompted to create a firewall exception to allow inbound UDP packets on the local port 7000. Create a firewall exception according to the prompts, and click OK to resume the test.

Note Do not click OK on the prompt before you add the firewall exception. Doing so causes the test to resume and might cause the test to fail. The following is the configuration for the firewall exception:

  • (Protocol: UDP

  • Local Port: 7000

  • Direction of traffic: Inbound

  • Action: ALLOW

S3 - Sequential symmetric NAT. Send and receive traffic on peer ports

The test verifies that the system can send and receive multiple Router Solicitations (RS) and Router Advertisements (RA). In this case, the Teredo client acts as if it is behind a sequential symmetric NAT, and the system is able to send and receive Teredo traffic by using random ports.

For the test to be successful, it must receive inbound Teredo packets (over UDP) on the local port 7000 and send outbound Teredo packets (over UDP) on any random local port (in the range 5001-65535). Before the test begins, you are prompted to create firewall exceptions to allow inbound UDP packets on \ port 7000 and outbound UDP packets on ALL the local ports (5001-65535). Create the firewall exceptions accordingly and click OK to complete the test.

Note Do not click OK on the prompt before you add the firewall exceptions. Doing so causes the test to resume and might cause the test to fail. The following is the configuration for the firewall exception:

  • Protocol: UDP

  • Local Port: 7000

  • Direction of traffic: Inbound

  • Action: ALLOW

  • Protocol: UDP

  • Local Port: ANY or in the range 5001 - 65535

  • Direction of traffic: Outbound

  • Action: ALLOW

After the tests are run successfully, the "Transition Technologies - Uninstall Sparta Miniport Interface (x1)" library job removes the Sparta Miniport interface.

Finally, the "Transition Technologies - Remove Binaries" library job deletes the copied files.


IPsec Task Offload v2 Testing

IPsec Task Offload v2 Testing Overview

Preparing for IPsec Task Offload v2 Testing

Running the IPsec Task Offload v2 Tests

Troubleshooting IPsec Task Offload v2 Testing


IPsec Task Offload v2 (part of the LAN (Ethernet) suite) Testing Overview

The procedures presented in this section outline the process for testing your IPsec Task Offload v2 for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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 Windows logo testing.

  • Running: The running topics describe how to run to run the tests for your device or system.

IPsec Task Offload v2 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 device, see the IPsec Task Offload v2 Tests.

Run time: Approximately 2 hours

Hardware requirements

The following hardware is required for IPsec Task Offload v2 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.

DTM Setup for IPsec Offload Device Testing

On a conceptual level, in order to test a LAN (Ethernet) networking card, two computers must be used. One computer is needed to hold the device under test, and another computer and network device are needed to receive and send data to the device under test while testing is in progress. Additionally, there must be a separate line of communication between the two computers that will be used to exchange information about ongoing tests. This will be used as a message channel to exchange control commands to know how much traffic to expect from the sender.

A DTM setup for LAN (Ethernet) device testing consists of a DTM controller, DTM Studio, and DTM clients.

  • DTM Studio computer - Manages all the DTM client computers during testing. See DTM Studio.

  • DTM Controller computer - Controls DTM client computers and gathers all test information from them. See DTM Controller.

  • DTM Client 1 computer - Referred to as the local test machine or NDISTest client during LAN device testing. Contains the following network devices:
    • Local test device - The device under test. During testing, it communicates to the remote message device in the remote test machine via the test network.
    • Local message device - Communicates with the DTM controller. It also communicates test status information to the remote message device in the remote test machine via the support network.
  • DTM Client 2 computer - Referred to as the remote test machine or NDISTest serve during LAN device testing. Contains the following network devices:
    • Remote support device - Communicates with the local test device in the local test machine via the test network.
    • Remote message device - Communicates with the DTM controller. This device also communicates the test status information to the local message device in the local test machine via the support network

Software requirements

The following software is required to run the IPsec Task Offload v2 tests:

  • Windows 7

Tester knowledge requirements

To run the IPsec Task Offload v2 tests, testers must know how to set firewall rules.


Preparing for IPsec Task Offload v2 Testing

Before running the tests, you must first configure the system and install the operating system. This section describes in detail how to do this.

For a complete list of required hardware, software, and tester knowledge, see the IPsec Task Offload v2 Testing Overview.

Many of the tests in the Windows Logo 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

After you install the DTM controller, DTM clients, and DTM Studio, you can monitor the status of the DTM client machines through DTM Studio. The DTM clients are grouped into logical machine pools that the DTM controller monitors. New DTM client machines are automatically put into the default pool.

Before LAN (Ethernet) testing can be started, you must first create your own machine pool to hold the DTM client machines for LAN (Ethernet) device testing. To do this, drag the DTM client machine from the default pool into your machine pool and wait for its status to change to Ready.


Running the IPsec Task Offload v2 Tests

To schedule the LAN (Ethernet) device tests, you can use the Device Console window in DTM Studio.

To run the LAN device tests, use the following logo submission procedure:

  1. Open DTM Studio.

  2. On the Explorers menu, click Device Console. (You can also switch to the Device Console window by clicking the Device Console tab in the lower left corner of DTM Studio.)

  3. In the View By area, select Submission, and then in the Submission list, click <New Submission>.

  4. Click Windows 7.

  5. Click Device Submission.

  6. Click Network > LAN (Ethernet).

  7. Click Logo.

  8. In the Name for new submission box, enter a name for the submission, and then select the machine pool that the submission will be associated with.

  9. In the Driver Install File (INF) box, locate the device's INF file.

  10. Review the summary page to make sure the information is correct, and then click Finish.

  11. In the Available Devices area of the Device Console window, select a test device from the devices that appear. In the Available Jobs area, place a check next to the IPsec Offloadv2 logo verification (Win7) logo job, then right-click the logo job, and click Add Information. The Job extension dialog box will open.

  12. In the Job extension dialog box, do the following:

    1. From the Local Message Device list, select a device that is connected to the Support network Switch.
    2. In the Remote Machines area, select the computer (DTM Client 1) that hosts the Remote Support Device.
    3. In the Remote Support Device area, select the support test device that is connected to the Test network Switch.
    4. In the Remote Message Device list, select the device that is connected to the Support network Switch.
    5. Click Advanced Test Device Info to provide additional information of the test device. A detailed description of Advanced Test Device Info appears later in this subsection.
    6. Click Save.

    Note The Local Test Device and Remote Support Device should be connected to the Test network switch. This rule is the requirement of the logo submission. Although the Job extension dialog box does not enforce this policy, the actual test will fail if these network devices are not on the same network.

  13. Click Add Selected to add the job to the configured job list.

After you complete the preceding steps, the job is ready for scheduling. After you click Schedule Jobs, DTM Studio will send the job to the DTM controller and dispatch the job on the designated DTM client machines. You can also put multiple configured jobs into the configured job list first, and then schedule them in one batch. After the test is finished, the log files are gathered and copied on the DTM controller.

The "IPsec Offloadv2 logo verification (Win7)" job tests to verify the support for IPsec Offloadv2. These end-to-end tests require a minimum of two machines. These tests plumb different types of IPsec policies and trigger traffic between these machines and measure characteristics of traffic, IPsec negotiations, and offloaded SA counts.

Role and content of significant files:

IPsecScenario.exe: Main test application that takes the IP address and port information to listen for commands from the IPsecControl.exe app.

IPsecControl.exe: Synchronizes all IPsecScenario sessions running on the test machines. It takes three parameters. First, the test case to be run. Second, a configuration file (config.dat) containing the IP addresses of all the clients that it must connect to. Third, a parameter indicating the total number of Clients.

Config.dat: Configuration file used by IPsecControl.exe to connect to all test machines.

Note: This should automatically be generated by the setup scripts.

Format of Config.dat:

Controller = <local IP address to bind to>

Port= <port range to be used for outbound connections>

clientport= <port on which all IPsecScenario sessions are listening>

Client1 = <ip address of Client1>

Client2 = <ip address of Client1>

Anatomy of a Test Case

The test script (OffloadV2_logoTests.xml) contains the details of all test cases. IPsecScenario uses this XML file for running all tests. A test XML file is broadly divided into the following XML tags:

  • Config: Sets up the machine for the tests within the script. This mostly includes setting up private IP addresses for the test network, adding routes if necessary, etc. This section also includes the cleanup once testing is complete.

  • Group: This is a logical construct for grouping tests within a specific area of testing.

  • Test: Title and description of each test variation.

  • Action: This tag corresponds to actions needed to be performed by a Client. The controller sends signals to each Client in the sequence defined by the action number. For the same action number, all Clients perform the encompassed actions asynchronously and return control to the Controller. Only when all Clients complete their action does the Controller send the signal for starting the next action.

Understanding the logs

The following is a sample test log for one test variation with comments explaining the entries:

Log: OffloadV2_logoTests_Crypto_AH[GCMAES128]_v6.log

Start: OffloadV2_logoTests\Crypto\AH[GCMAES128]\v6, TUID=(null) Test Name

MyAddress: 2001:4898:28:1055:20f:feff:fe98:27e1 Addresses read from config.dat

Client1: 2001:4898:28:1055:20f:feff:fe98:27e1

Client2: 2001:4898:28:1055:20f:feff:fe98:2795

Connecting to Clients.....

Client1: Success - Connection Completed

Client2: Success - Connection Completed

<If the above connections to the clients don't succeed, check the firewall settings, etc. or anything that is preventing the controller from connecting to the clients.>

Sending command CHECK_VERSION

Controller Version: 2.060116

Client0 version: 2.060116

Client1 version: 2.060116

Sending command TRACE_NAME

Not a Code Coverage Build

Not a Code Coverage Build

Sending command OPEN_SUITE

Client1:

Suite opened for IPv6.

Client2:

Suite opened for IPv6.

Sending command CONFIGURE_SUITE

Client1: The initial config adds private IP addresses to the Test interface

Suite configured successfully.

Start Time = Fri Apr 25 13:59:46 2008

Client2:

Suite configured successfully.

Start Time = Fri Apr 25 13:59:35 2008

Sending command QUERY_ACTION_COUNT

Number of actions in test: 7

Sending Command ACTION 1

Client1:

Capturing IKE Logs in Progress....

Client1: Adding IPsec policy on Client

AddPolicy

Policy Name: Test

Type : ipsec transport

Source Addr: fe80::90:2

Source Port: 0

Dest Addr : fe80::90:1

Dest Port : 0

Protocol :

MM Policy : DES-MD5-1

MM Auth : PRE:'Oakley'

QM Policy : AH[GCMAES128]

QM Auth :

LocAddr :

RemAddr :

Flag :

--Transport Policy successfully added

Client2:

Capturing IKE Logs in Progress....

Client2:

AddPolicy

Policy Name: Test

Type : ipsec transport

Source Addr: fe80::90:1

Source Port: 0

Dest Addr : fe80::90:2

Dest Port : 0

Protocol :

MM Policy : DES-MD5-1

MM Auth : PRE:'Oakley'

QM Policy : AH[GCMAES128]

QM Auth :

LocAddr :

RemAddr :

Flag :

--Transport Policy successfully added

Sending Command ACTION 2

Client1:

Sleep

Time = 6000 msec

Client1: Read initial values of the IPsec counters

Initial iPSecStats read successfully.

IPSec Stats:

ActiveAssociations : 0

OffloadedSAs : 0 Tests focus on this counter

SasPending : 0

SaAdditions : 153

SaDeletions : 162

ReKeys : 7

ActiveTunnels : 0

InvalidSpi : 2

AHInvalidSpi : 2

ESPInvalidSpi : 0

DecryptionFailures : 0

ESPDecryptionFailures : 0

AuthenticationFailures : 0

AHAuthenticationFailures : 0

ESPAuthenticationFailures : 0

ReplayCheckFailures : 0

AHReplayCheckFailures : 0

ESPReplayCheckFailures : 0

SaNotInitialized : 0

AHSaNotInitialized : 0

ESPSaNotInitialized : 0

UdpEspValidationFailures : 0

InvalidClearText : 6

ReceiveOverIncorrectSa : 0

ConfidentialBytesSent : 61562444

ConfidentialBytesReceived : 62582784

AuthenticatedBytesSent : 1540552

AuthenticatedBytesReceived : 1449240

AuthenticatedESPBytesSent : 62585988

AuthenticatedESPBytesReceived : 62582784

TransportBytesSent : 64106720

TransportBytesReceived : 64013628

BytesSentInTunnels : 7712

BytesReceivedInTunnels : 5600

OffloadedBytesSent : 60271468

OffloadedBytesReceived : 60173808

Client2: Read the same counters on the second machine.

Sleep

Time = 6000 msec

Client2:

Initial iPSecStats read successfully.

IPSec Stats:

ActiveAssociations : 0

OffloadedSAs : 0

SasPending : 0

SaAdditions : 147

SaDeletions : 165

ReKeys : 6

ActiveTunnels : 0

InvalidSpi : 0

AHInvalidSpi : 0

ESPInvalidSpi : 0

DecryptionFailures : 0

ESPDecryptionFailures : 0

AuthenticationFailures : 0

AHAuthenticationFailures : 0

ESPAuthenticationFailures : 0

ReplayCheckFailures : 0

AHReplayCheckFailures : 0

ESPReplayCheckFailures : 0

SaNotInitialized : 0

AHSaNotInitialized : 0

ESPSaNotInitialized : 0

UdpEspValidationFailures : 0

InvalidClearText : 12

ReceiveOverIncorrectSa : 0

ConfidentialBytesSent : 61562232

ConfidentialBytesReceived : 62580300

AuthenticatedBytesSent : 1446224

AuthenticatedBytesReceived : 1532840

AuthenticatedESPBytesSent : 62581104

AuthenticatedESPBytesReceived : 62580300

TransportBytesSent : 64016868

TransportBytesReceived : 64091216

BytesSentInTunnels : 5600

BytesReceivedInTunnels : 7712

OffloadedBytesSent : 60161724

OffloadedBytesReceived : 60286708

Sending Command ACTION 3

Client1: Add traffic item on the machines.

ConfigTraffic

Traffic Name: Test1

Traffic Type: Send Note that Client1 is the source ('Initiator') of the traffic

Traffic Echo: On

Local Address: fe80::90:2

Remote Address: fe80::90:1

Local Port: 5002

Remote Port: 5002

Protocol: UDP

Iterations: 50

Buffer Length: 100 100

Delay: 1000

--Traffic Item: Test1 has been successfully added

Client2:

ConfigTraffic

Traffic Name: Test1

Traffic Type: Receive Client 2 is the destination ('Responder') for the traffic

Traffic Echo: On

Local Address: fe80::90:1

Remote Address: fe80::90:2

Local Port: 5002

Remote Port: 0

Protocol: UDP

Iterations: 50

Buffer Length: 100 100

Delay: 1000

--Traffic Item: Test1 has been successfully added

Client2:

StartTraffic Responder starts listening for the traffic

TrafficName = Test1

--Traffic Started successfully

Sending Command ACTION 4

Client1:

StartTraffic Initiator starts the traffic which would trigger IPsec negotiations

TrafficName = Test1

--Traffic Started successfully

Client1:

WaitForTraffic Initiator waits for all traffic to be completed.

TrafficName = Test1

--WaitOnTraffic successful

Client2:

No Action

Sending Command ACTION 5

Client1: Check if the total bytes sent match the expected bytes

QueryTraffic

TrafficName = Test1

Expected BytesSent = 5000

Expected BytesRecv = 5000

--Actual BytesSent = 5000

--Actual BytesRecv = 5000

--Data Errors = 0

--Test Passed

Client1: Check for Main Mode and Quick Mode SAs

QueryMainModeSA

PolicyName = Test

Expected: 1

Actual: 1

--Test Passed.

Client1:

QueryQuickModeSA

PolicyName = Test

Expected: 1

Actual: 1

--Test Passed.

Client2: Check for Main Mode and Quick Mode SAs

QueryMainModeSA

PolicyName = Test

Expected: 1

Actual: 1

--Test Passed.

Client2:

QueryQuickModeSA

PolicyName = Test

Expected: 1

Actual: 1

--Test Passed.

Sending Command ACTION 6

Client1:

LoadHardwareCapability: Successfully loaded NIC's capability

<For the very first test case the IPsec offload capabilities are loaded as reported by the Driver>

HARDWARE CAPABILITIES:

Encapsulation: 0x2

IPv6Supported: TRUE

IPv4Options: FALSE

IPv6NonIPsecExtHdrsAddr: FALSE

Ah: TRUE

Esp : TRUE

AhEspCombined : FALSE

Transport : TRUE

Tunnel : FALSE

TransportTunnelCombined: FALSE

LsoSupported : FALSE

ExtendedSequenceNumbers: FALSE

UdpEsp : 0x0

AuthenticationAlgorithm: 0x38

EncryptionAlgorithms : 0x39

SaOffloadCapacity : 0x20

LoadTestExpectedCapability: Successfully translated test policy

<Load test expectations based on the IPsec policy used above>

IsTestCompatibleWithHardware: Test capability matches hardware capability

<Match test's expectation to those proclaimed by the NIC>

SUCCESS: 2 SA(s) offloaded

<If capabilities match, check the total number of offloaded SAs, else make sure that no SAs are offloaded>

Client2:

LoadHardwareCapability: Successfully loaded NIC's capability

HARDWARE CAPABILITIES:

Encapsulation: 0x2

IPv6Supported: TRUE

IPv4Options: FALSE

IPv6NonIPsecExtHdrsAddr: FALSE

Ah: TRUE

Esp : TRUE

AhEspCombined : FALSE

Transport : TRUE

Tunnel : FALSE

TransportTunnelCombined: FALSE

LsoSupported : FALSE

ExtendedSequenceNumbers: FALSE

UdpEsp : 0x0

AuthenticationAlgorithm: 0x38

EncryptionAlgorithms : 0x39

SaOffloadCapacity : 0x20

LoadTestExpectedCapability: Successfully translated test policy

IsTestCompatibleWithHardware: Test capability matches hardware capability

SUCCESS: 2 SA(s) offloaded

Sending Command ACTION 7 Cleanup after the test is complete.

Client1: DisconnectTraffic

TrafficName = Test1

--Traffic Disconnect successfully

Client2:

DisconnectTraffic

TrafficName = Test1

--Traffic Disconnect successfully

Sending command CLEANUP_TEST

Client1:

Application Structs cleaned up successfully

Client1:

All Policies been deleted

End Time = Fri Apr 25 14:01:02 2008

Client2:

Application Structs cleaned up successfully

Client2:

All Policies been deleted

End Time = Fri Apr 25 14:01:02 2008

Final Result: TEST PASSED Final Result of the test.

End: Pass, OffloadV2_logoTests\Crypto\AH[GCMAES128]\v6, TUID=, Repro=C:\IPsecTestKit\IPsecScenario\Controller\ipseccontrol.exe


Troubleshooting IPsec Task Offload v2 Testing

If controller cannot connect to clients, follow these steps:

  1. The very first test case is designed to ensure that the setup is correct. It does nothing but check the public and private network for connectivity. If this test fails, then there is a test setup issue.

  2. Check to ensure that the file config.dat is placed in the %SystemDrive%\IPsecTestKit\IPsecScenario\ directory and has the right IP addresses for the controller and the clients. This file is auto generated, but in certain cases such as DNS resolution failures, the config.dat file may contain incorrect data or be missing altogether. Please use the format described in the Test Setup section to verify the config.dat file.

  3. Check to ensure that you have firewall exemptions for IPsecControl.exe and IPsecScenario.exe

  4. Check to ensure that after running the setup scripts, the IPsec Offload V2 interfaces are successfully renamed to "Test1".

Genconfig_phase2.vbs may not generate the necessary CMD files if there is only 1 default gateway for the message adapter. If your DHCP server does not support IP V6, you may only get 1 IP V6 default gateway address.

Running Individual Test Variations

In certain cases when tests fail, run a single test variation instead of re-running the whole suite. To do this, follow these steps:

  1. Make sure that the IPsecScenario.exe sessions are running on all clients.

  2. Copy individual variations to run from within OffloadV2_logoTests.cmd and run them from a new command window (%SYSTEMDRIVE%\IPsecTestKit\IPSecscenario\Controller

Troubleshooting LAN (Ethernet) Testing

  1. The "IPsec Offloadv2 logo verification (Win7)" jobs stay in the "Scheduler" status and never get run.

    This problem is usually caused by various communication issues between the DTM client and the controller. You can check whether the "Last Heartbeat time" is close to the current time. To force the DTM client that is reporting a heartbeat, you can manually change the status of the machine to Reset or Unsafe in the DTM Studio, and then wait until the status of the machine changes back to "Normal". After the status of all machines that are required to run the job is changed to Normal, the job will be scheduled on the DTM clients. If the machine status changes to Debug, verify whether the DTM client machine is still responsive. Sometimes, the machine status is Normal and the heartbeat is correct, but the job still won't run. This is most likely caused by the firewall or IPsec blocking the communication between the DTM client and the controller. Make sure that the DTM client and controller have the same IPsec configuration. If the client has IPsec turned on but the controller turned off, or vice versa, the job will not get scheduled. The DTM client is designed to work with a firewall, but sometimes the firewall blocks normal traffic between the client and the controller.

  2. "The Job xxx requires a device to be selected, not a driver" when clicking "Add Information".

    The error happens because you have selected a driver, not a test device, in the Device Console to run the test job. If you cannot find a device under the driver in the Device Console, the INF file and driver files that you provided during the logo submission do not match the actual INF file and driver files on the DTM client. Update your INF file and driver files by using the actual INF file and driver files installed on the DTM client.

  3. No "IPsec Offloadv2 logo verification (Win7)" job shows up in the "Device Console".

    Make sure your device is an Ethernet (LAN) device and report media type to NDIS as NdisMedium802_3. This error sometimes happens when the hardware information reported by the DTM client is incomplete. To solve this problem, try to can reboot the DTM client machine and refresh the view of Device Console. If this doesn't work, try to stop and restart the "wttsvc" service on the DTM client, and then refresh the view of Device Console.


Rally Wireless-Vertical Pairing Testing

Rally Vertical Pairing Testing Overview

Preparing for Rally Vertical Pairing Testing

Running the Rally Vertical Pairing Tests

Troubleshooting Rally Vertical Pairing Testing


Rally Vertical Pairing Testing Overview

The procedures presented in this section outline the process for testing your Rally Vertical Pairing device for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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 Windows logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

Rally Vertical Pairing Tests

The lists 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 Rally Vertical Pairing Tests.

Run time: approximately 15 minutes

Hardware requirements

The following hardware is required for Rally Vertical Pairing 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.

  • Wi-Fi network card that supports SoftAP (Ex: D-Link WDA-1320 Desktop Adapter)

Software requirements

The following software is required to run the Rally Vertical Pairing tests:

  • Windows 7 Operating System

  • Test Binary - BluewireLogoTest.exe

Tester knowledge requirements

To run the Rally Vertical Pairing tests, testers must know how to accomplish the following tasks:

  • Install DTM and launch the test from it.


Preparing for Rally Vertical Pairing 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 Rally Vertical Pairing Testing Overview.

Many of the tests in the Windows Logo 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 auto logon functionality on the test system.

Test system configuration

  • The test system should have a Hosted Network compatible wireless card with all drivers installed.

  • Make sure the Hosted Network is up and running and the machine is connected to it.

  • Install and configure DTM client and studio.

  • Run the test when logged in as Administrator.

  • Make sure Network Discovery is enabled.

  • Put the device in provisioning mode.


Running the Rally Vertical Pairing Tests

When you run the test using the DTM studio, the following command line will be executed:

BluewireLogoTest.exe /c PairLogoDevice DevicePIN=[DevicePIN] WCNID={[WDKData_DeviceUUID]} UPnP=[ WDKData_UPnP] WSD=[ WDKData_WSD] WinQualID=[ WDKData_WinQualID] UnPairDevice=[ WDKData_UnPairDevice]

Parameters during submission creation time

If your device is a Wi-Fi device and needs to do Vertical Pairing, set only the following values and leave the others as default values:

  • WDKData_DeviceUUID : WPS ID of the device. Ex. e3248000-80ce-11db-8000-008077d129db

  • WDKData_UPnP : Please specify either Required/NotRequired/Unknown

  • WDKData_WSD: : Please specify either Required/NotRequired/Unknown

  • WDKData_WinQualID : Please specify the WinQualID of the device

  • WDKData_UnPairDevice :Please specify TRUE/FALSE

Parameters to edit in device console when scheduling the test job

Edit parameters and enter the PIN.

DevicePIN : WPS PIN of the device. EX: 12345670


Running the Rally PnPX Logo Test

When you run the test using the DTM studio, the following command line will be executed:

PnPXLogoTest.exe /c PairPnPXDevice DiscoveryProtocol=[ WDKData_DiscoveryProtocol] UPnPID=[WDKData_ UPnPID] WSDID=[ WDKData_ WSDID] WinQualID=[ WDKData_WinQualID]

Parameters during submission creation time

Set the parameters as follows:

  • WDKData_DiscoveryProtocol - Device Discovery Protocol. Specify either WSD or UPnP

  • WDKData_UPnPID - UPnP ID of the device. This should begin with uuid: (Ex: uuid: de1dec0a-9021-426c-9548-f714b5e8ef56)

  • WDKData_WSDID - WSD ID of the device. This should begin with urn:uuid: (Ex: urn:uuid: de1dec0a-9021-426c-9548-f714b5e8ef56)

  • WDKData_WinQualID : Specify the WinQualID of the device


Troubleshooting Rally Vertical Pairing Testing

  • Check the test log to see where the failure is.

  • Check that the Device is in Pairing mode and can be discovered using the Add Device wizard in Devices and Printers folder.

  • If the failure is "Waiting for the device to come online after provisioning," make sure that the device comes back online with an IP address and shows up in the Network folder.


Network Controller Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


Extensible Authentication Protocol (EAP) Test - Authenticator Method

Overview

The Extensible Authentication Protocol (EAP) Test is used by the EAP Certification Program (ECP).

Details

The EAP Test is comprised of testing methods:

  • Peer Method

  • Authenticator Method

  • Network Supplicant

This description applies to the Authenticator Method.

Requirements

Software Requirements

The test tool requires the following software:

  • Windows Server 2008 Release 2

  • Windows 7

  • Windows Server 2008

  • 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

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 Extensible Authentication Protocol (EAP) Test - Authenticator Method

For Authenticator Method:

144.3.1 - EAP Method Submissions MAY include 32-bit X86 binaries

This test verifies submission of 32-bit X86 binary.

Overview

The test performs the following steps:

  • It checks whether submission has X86 binary.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The package path cannot be located.

144.3.2 - EAP Method Submissions MUST include 64-bit X64 binaries

This test verifies submission of 64-bit X64 binary.

Overview

The test performs the following steps:

  • It checks whether submission has at least one X64 binary.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • X64 binary is not present in the package.

144.3.3 - EAP Methods MUST NOT disable or impair the functionality of other system components during their operation.

Overview

Self explanatory

Results interpretation

The test writes the pass/fail results to a log file.

145.3.1 - All ECP EAP Method Submissions will be packaged in an INF.

This test verifies that the submission has packaged INF file.

Overview

The test performs the following steps:

  • Checks for the valid INF file in the package location.

  • Checks for various sections for valid installation of the INF file.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • INF file is not present in the package location.

  • INF file does not contain the valid install section.

145.3.2 - ECP EAP Method Submission INF installers MUST allow for installation and uninstall.

This test verifies that submitted INF installers should allow for installation and uninstallation.

Overview

The test performs the following steps:

  • Checks that Install section is present in the INF file.

  • Checks that Uninstall section is present in the INF file.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • INF file does not contain the install section.

  • INF file does not contain the uninstall section.

145.3.3 - ECP Method Submissions MUST NOT require reboot after installation to function properly

This test verifies that installation of method does not require a reboot.

Overview

The test performs the following steps:

  • Uninstall the method if it is already installed.

  • Install the method.

  • Checks for certain registry locations which need to be updated if reboot is need for install.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Installation process adds the entries to certain registry location which are necessary for reboot.

145.3.4 - EAP Methods MUST NOT disable or otherwise modify other installed components as part of installation.

This test verifies that installation of method does not modify the registry or file system, other than its own space.

Overview

The test performs the following steps:

  • Uninstall the method if it is already installed.

  • Install the method.

  • Verifies that all the registry updates are done as part of installation under the following key:

    HKLM\System\CurrentControlSet\Services\EapHost\Methods\AuthId\TypeId

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Installation process adds the entries to registry location other than the one specified.

    reboot.

145.3.5 - EAP Methods MUST remove all configuration data and files on removal/uninstall.

This test verifies that uninstall should remove all the configuration data.

Overview

The test performs the following steps:

  • Get the list of all the files copied during installation

  • Check if all these files have been removed.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If there is a mismatch between the files copied during installation and files removed during uninstall.

145.3.6 - Removal of an EAP method must be performed through device uninstall using the device manager.

This test verifies that uninstall should be done with the help of device manager.

Overview

The test performs the following steps:

  • Uninstalls the package.

  • Check for the absence of registry entries.

  • Install the package.

  • Check for the presence of registry entries.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Uninstall/installation of the package is unsuccessful.

  • Registry entries are present after uninstall.

  • Registry entries are absent after install.

146.3.1 - EAP Authenticator Methods will successfully complete six hours of end-to-end authentications across 50 concurrent separate authentication sessions. There should not be any observable resource leaks.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

No additional Troubleshooting tips available

146.3.2 - EAP Authenticator Methods will successfully survive 1,000,000 cycles of loading and unloading the method DLL without error. There should not be any observable resource leaks.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

146.3.3 - All implemented EAP method APIs will successfully survive 6 hours of comprehensive API fuzz testing without error. There should not be any observable resource leaks.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

146.3.4 - EAP Authenticator Methods will successfully survive end-to-end negative authentication stress for a period of 6 hours.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

147.3.1 - If the method is a password or smart card based test case, it should not write password or pin in traces or event logs (Manual).

This test verifies that EAP method does not write password information in the trace logs. This test case needs user interaction in DTM client side.

Overview

The test performs the following steps:

  • Checks the status of the trace file/event.

  • Runs the Authentication session with the method.

  • Ensure that method has written to trace logs/event channel.

  • Verify that the password is not present in the trace logs/events.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • As part of authentication method writes password information into the trace logs.

User Interactions

User has to do the following tasks for Plain (.log).

  • In the DTM studio, select the log type as "Plain (.log)" and enter "Trace File Path". Schedule the job. At the DTM client, the following interactions are needed:

  • Enable the method specific trace (which will be written to C:\windows\tracing) and then press Ok.

  • An authentication session will be run as part of the test case.

  • Disable the method trace and then press Ok.

  • The trace file will be displayed in notepad.

  • Verify whether the trace has password information

  • Enter the appropriate choice (Yes/No) in the dialog box that follows.

  • End of the test case.

User has to do the following tasks for Windows Event log.

  • Make sure Event is registered. This can be verified using Windows Event Viewer.

  • In the DTM Studio, select log type as "Windows Event" and enter "Channel\Provider Name". Schedule the job. At the DTM client, the following interactions are needed:

  • An authentication session will be run as part of the test case.

  • If event is detected, then the following dialog appears: "Events detected, please open Event Viewer, verify events and answer the below question. Is there password info in the Events?"

  • Verify whether the events contain password information or not.

  • Enter the appropriate choice (Yes/No) in the dialog box.

  • End of the test case.

148.3.1 - All data for a given EAP method will be located under HKLM\SYSTEM\CurrenTControlSet\Services\EAPHost\Methods

This test verifies that installation of method does not modify the registry, other than its allocated space.

Overview

The test performs the following steps:

  • Uninstall the method if it is already installed.

  • Install the method.

  • Verifies that all the registry updates are done as part of installation under the following key:

    HKLM\System\CurrentControlSet\Services\EapHost\Methods\AuthId\TypeId

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Installation process adds the entries to registry location other than the one specified.

148.3.2 - All Vendors who submit methods to the ECP will acquire a valid Enterprise-ID from IANA (Manual).

This test verifies that registry should have the enterprise id at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EAPHost\Methods\<VendorIANAid>

Overview

The test performs the following steps:

  • Validate if the enterprise-id is in the acceptable range.

  • If it's an expanded EAP type, then check if Vendor id is inacceptable range or not.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If there is enterprise id /vendor id is in inacceptable range.

148.3.3 - The Vendor Registry Key under which all vendor method configuration data is stored will contain a string value which identifies the vendor name corresponding to the vendor's enterprise-id.

This test verifies that registry should have the enterprise id at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EAPHost\Methods\<<VendorIANAid>>.

And the registry location has a default string value or a value "Name" which specifies the Vendor name

Overview

The test performs the following steps:

  • Check if the name present at this registry location matches with the Vendor Name corresponding to the vendor's enterprise id.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If there is a mismatch in names.

148.3.4 - All files that are added to the system by the installation package (INF) are to be physically located under the Windows "Program Files: directory in a private sub-directory that reasonably reflects the nature of the ECP submission.

This test verifies that files added by package should be only under Program files.

Overview

The test performs the following steps:

  • Check the install section of inf file. All the files added should be located one folder under Program Files.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If install section tries to copy file at some other location.

148.3.5 - EAP Methods MUST add their default registry keys using regsvr32 facility

This test verifies that method should be installed using regsvr32.exe

Overview

The test performs the following steps:

  • Uninstall the method using regsvr32.

  • Install the method using regsvr32.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If uninstall or install fails.

149.3.1 - EAP Methods will produce a human-readable debug tracing log that enables administrators or other users to investigate and determine the cause of failures

This test verifies that EAP method produce human readable trace logs. This test case needs user interaction in DTM client side (Manual).

Overview

The test performs the following steps:

  • Checks the status of the trace file/event.

  • Runs the Authentication session with the method.

  • Ensure that method has written to trace logs/event channel.

  • Verify that the trace logs/events are human readable.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • As part of authentication method writes non human readable characters to the trace logs.

User Interactions

User has to do the following tasks for Plain (.log).

  • In the DTM studio select the log type as "Plain (.log)" and enter "Trace File Path". Schedule the job. At the DTM client, the following interactions are needed:

  • Enable the method specific trace (which will be written to C:\windows\tracing) and then press Ok.

  • An authentication session will be run as part of the test case.

  • Disable the method trace and then press Ok.

  • The trace file will be displayed in notepad.

  • Verify whether trace file is human readable or not and then close the file.

  • Enter the appropriate choice (Yes/No) in the dialog box that follows.

  • End of the test case.

User has to do the following tasks for Windows Event log.

  • Make sure Event is registered. This can be verified using Windows Event Viewer.

  • In the DTM Studio, select log type as "Windows Event" and enter "Channel\Provider Name". Schedule the job. At the DTM client, the following interactions are needed:

  • An authentication session will be run as part of the test case.

  • If event is detected, then the following dialog appears: "Events detected, please open Event Viewer, verify events and answer the below question. Is the Event readable?"

  • Verify whether the events contain password information or not.

  • Enter the appropriate choice (Yes/No) in the dialog box.

  • End of the test case.

149.3.2 - EAP Method debug tracing may be turned-off by default

This test verifies that Method tracing should be disabled by default.

Overview

The test performs the following steps:

  • Check the state of trace file.

  • Run an authentication session.

  • Check the trace file.

Results Interpretation

The test writes the pass/fail results to a log file.

150.3.1 - The EAP Method Binary MUST export all mandatory APIs listed in the ECP EAP method exports requirement

Overview

EAP method must export at-least the mandatory set of APIs listed in the legal ECP EAP method exports requirement.

Results Interpretation

The test writes the pass/fail results to a log file.

150.3.2 - ECP Submissions MUST NOT include any binaries that are expected to execute in kernel-mode. ECP Submissions are expressly prohibited from shipping kernel-mode drivers of any kind (ie., .SYS, etc)

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.3.3 - EAP Method Submissions MUST NOT take a dependency on .NET framework

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.3.4 - EAP Methods MUST demonstrate successful end-to-end authentication

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Make sure your radius server is available and an end-to-end authentication is happening before executing this case. This case will require the use of Connection.XML and a USER.XML to carry out the end to end Authentication.

150.3.5 - EAP Method MUST NOT make any assumptions about the underlying transport

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Make sure your radius server is available and an end-to-end authentication is happening before executing this case. This case will require the use of Connection.XML and a USER.XML to carry out the end to end Authentication.

150.3.6 - All implemented EAP method APIs will successfully survive comprehensive API fuzz testing without error, including observable resource leaks

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Make sure the location of the method is properly entered in the UI

150.3.7 - EAP Methods MUST NOT load any DLLs or cause to be loaded any DLLs that are not provided with the submission or provided by Windows itself

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.3.8 - EAP Methods MUST NOT initiate, terminate or pass-through any IPC

Overview

Network interaction is prohibited for any EAP method. If the method interacts with the network in anyway (initiate, terminate) then this test will fail.

Results Interpretation

The test writes the pass/fail results to a log file.

150.3.17 - EAP Methods MUST always perform legal state transitions.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

151.3.1 - EAP Method Submissions MUST accurately set appropriate security and property descriptor bits for the EAP method.

Overview

The method must accept these security descriptor. Our tools will test to verify that the methods actually support these

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Please indicate the proper security descriptor during submission. You will be presented with a UI, make sure you click the check boxes that correspond to the security descriptors as the method supports

153.3.1 -EAP Methods that export keys must export them only to EAPHost and to no other destination. The keys will be delivered directly to the lower layer for consumption and use entirely at that layer. Keys may not be distributed outside of the lower layer per RFC. The keys must be exported in the following manner:

MSK using the MS-MPPE extension.

EMSK using the EMSK extension (Manual).

Overview

The method must not handle key distribution. It's potentially very compromising to handle, store, or export these key

Results Interpretation

The test writes the pass/fail results to a log file.


Extensible Authentication Protocol (EAP) Test - Network Supplicant

Overview

The Extensible Authentication Protocol (EAP) Test is used by the EAP Certification Program (ECP).

Details

The EAP Test is comprised of testing methods:

  • Peer Method

  • Authenticator Method

  • Network Supplicant

This description applies to the Supplicant Method.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows Server 2008 Release 2

  • Windows 7

  • Windows Server 2008

  • 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

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 Extensible Authentication Protocol (EAP) Test - Network Supplicant

144.5.1 - EAP Supplicant Submissions MAY include 32-bit X86 binaries

This test verifies submission of 32-bit X86 binary.

Overview

The test performs the following steps:

  • It checks whether submission has x86 binary to launch supplicant application or service.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The package path cannot be located.

144.5.2 - EAP Supplicant Submissions MUST include 64-bit X64 binaries

This test verifies submission of 64-bit X64 binary.

Overview

The test performs the following steps:

  • It checks whether submission has at least one X64 binary to launch supplicant application or service.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • X64 is not present in the package.

144.5.3 - EAP Supplicants MUST NOT disable or impair the functionality of other system components during operation

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

145.5.1 - All ECP EAP Supplicant Submissions will be packaged in an INF.

This test verifies that the submission has packaged INF file.

Overview

The test performs the following steps:

  • Checks for the valid INF file in the package location.

  • Checks for various sections for valid installation of the INF file.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • INF file is not present in the package location.

  • INF file does not contain the valid install section.

145.5.2 - ECP EAP Supplicant Submission INF installers MUST allow for installation and uninstall.

This test verifies that submitted INF installers should allow for installation and uninstall.

Overview

The test performs the following steps:

  • Checks that Install section is present in the INF file.

  • Checks that Uninstall section is present in the INF file.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • INF file does not contain the install section.

  • INF file does not contain the uninstall section.

145.5.3 - EAP Supplicants MUST NOT disable or otherwise modify other installed components as part of installation.

This test verifies that installation of supplicant does not modify the registry or file system, other than its own space.

Overview

The test performs the following steps:

  • Uninstall the supplicant if it is already installed.

  • Install the supplicant.

  • Verifies that all the registry updates are done as part of installation under the following keys:

    HKLM\CurrentControlSet\Services\EAPHost\Supplicant\<Vendor IANA ID>\<Vendor Supplicant ID>

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Installation process adds the entries to registry other than the location specified.

145.5.4 - ECP Supplicant Submissions MUST NOT require a reboot after installation to function properly

This test verifies that installation of supplicant does not require a reboot.

Overview

The test performs the following steps:

  • Uninstall the supplicant if it is already installed.

  • Install the supplicant.

  • Checks for certain registry locations which need to be updated if reboot is need for install.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Installation process adds the entries to certain registry location which are necessary for reboot.

145.5.6 - Removal of an EAP supplicant must be performed through device uninstalls using the device manager.

This test verifies that uninstall should be done with the help of device manager.

Overview

The test performs the following steps:

  • Uninstalls the package.

  • Check for the absence of registry entries.

  • Install the package.

  • Check for the presence of registry entries.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Uninstall/installation of the package is unsuccessful.

  • Registry entries are present after uninstall.

  • Registry entries are absent after install.

146.5.1 - EAP Supplicants will successfully complete 1000 end-to-end EAP authenticated connection without error or failure of any kind. There should not be any observable resource leaks.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.2 - EAP Supplicants must support scriptable control for connect, disconnect and authenticate functionalities

Overview

To validate this, user is asked to provide full path to this script. The script will be used to control, connect and disconnect

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Make sure you're able to connect and disconnect using this script before attempting to submit. Also make sure that you provide the full path to this script. If this script fails potentially many other supplicant cases will fail without being run

155.5.7 - EAP supplicants must support EapHostPeerFreeErrorMemory API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.8 - EAP supplicants must support EapHostPeerFreeMemory API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.9 - EAP supplicants must support EapHostPeerGetMethods API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.10 - EAP supplicants must support EapHostPeerInvokeConfigUI API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.11 - EAP supplicants must support EapHostPeerInvokeInteractiveUI API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.14 - EAP supplicants must support EapHostPeerBeginSession API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.15 - EAP supplicants must support EapHostPeerClearConnection API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.16 - EAP supplicants must support EapHostPeerEndSession API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.17 - EAP supplicants must support EapHostPeerFreeEapError API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.18 - EAP supplicants must support EapHostPeerGetAuthStatus API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.19 - EAP supplicants must support EapHostPeerGetResponseAttributes API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.20 - EAP supplicants must support EapHostPeerGetResult API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.21 - EAP supplicants must support EapHostPeerGetSendPacket API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.22 - EAP supplicants must support EapHostPeerGetUIContext API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.23 - EAP supplicants must support EapHostPeerInitialize API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.24 - EAP supplicants must support EapHostPeerProcessReceivedPacket API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.25 - EAP supplicants must support EapHostPeerSetResponseAttributes API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.26 - EAP supplicants must support EapHostPeerSetUIContext API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.27 - EAP supplicants must support EapHostPeerUninitialize API.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.28 - NotificationHandler must be implemented and passed to EAPHost API through EapHostPeerBeginSession

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.30 - Supplicant MUST always perform legal call sequences to EAPHost

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.31 - EAP Supplicants MUST NOT load any DLLs or cause to be loaded any DLLs that are not provided with the submission or provided by Windows itself

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.32 - EAP Supplicants must not execute with higher privileges than network service

Overview

The test performs the following steps:

  1. Run the supplicant script

  2. Get the supplicant process's access token

  3. Get all the privileges with which the supplicant process is running.

  4. Verify that supplicant process will not run with higher privilege than network service.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Supplicant process has privileges higher than network service.

  • Supplicant process runs with local system or local service account.

155.5.33 - EAP Supplicants MUST support EAPHost-based Network Access Protection

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

155.5.34 - All Vendors who submit methods to the ECP will acquire a valid Enterprise-ID from IANA. For example, Microsoft's Enterprise-ID is 311

This test verifies that registry should have the enterprise id at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EAPHost\Supplicant\<Vendor IANA ID>

Overview

The test performs the following steps:

  • Validate if the enterprise-ID is in the acceptable range.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If there is enterprise id /vendor id is in inacceptable range.

155.5.35 - All EAP Supplicant configuration data will be entirely contained within the Windows Registry

This test verifies that installation of supplicant does not modify the registry, other than its allocated location.

Overview

The test performs the following steps:

  • Uninstall the supplicant if it is already installed.

  • Install the supplicant.

  • Verifies that all the registry updates are done as part of installation under the following keys:

    HKLM\CurrentControlSet\Services\EAPHost\Supplicant\<Vendor IANA ID>\<Vendor Supplicant ID>

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Installation process adds the entries to registry other than the location specified.

155.5.36 - All EAP Supplicant configuration data will be located under a single registry sub key under HKLM. Per user configuration data may be stored under a single registry sub key for each user in HKCU.

This test verifies that registry should have the enterprise id at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EAPHost\Supplicant\<Vendor IANA ID>

Overview

The test performs the following steps:

  • Check if the name present at this registry location matches with the Vendor Name corresponding to the vendor's enterprise id.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If there is a mismatch in names.

Troubleshooting Tips

The enterprise name can be in "" or "Name" registry value, where if "" value is present than "Name" value is ignored.

""=Microsoft

Name=Microsoft

155.5.37 - All files that are added to the system by the installation package, INF are to be physically located under the Windows Program Files, directory in a private sub-directory.

This test verifies that files added by package should be only under Program files.

Overview

The test performs the following steps:

  • Check the install section of INF file. All the files added should be located one folder under Program files.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If install section tries to copy file at some other location.

156.5.1 - EAP Supplicants will produce a human-readable debug tracing log that enables administrators or other users to investigate and determine the cause of failures (Manual).

This test verifies that EAP supplicant produce human readable trace logs. This test case needs user interaction in DTM client side (Manual).

Overview

The test performs the following steps:

  • Checks the status of the trace file.

  • Runs the Authentication session with the supplicant.

  • Ensure that supplicant has written to trace logs.

  • Verify that the trace logs are human readable.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • As part of authentication supplicant writes non human readable characters to the trace logs.

User Interactions

User has to do the following tasks.

  • In the DTM studio schedule the job which has the Test case id as 156.5.1, then at the DTM client the following interactions are needed.

  • Enable the supplicant specific trace (which will be written to C:\windows\tracing) and then press Ok.

  • An authentication session will be run as part of the test case.

  • Disable the supplicant trace and then press Ok.

  • The trace file will be displayed in notepad.

  • Verify whether trace file is human readable or not and then close the file.

  • Enter the appropriate choice (Yes/No) in the dialog box that follows.

  • End of the test case.

156.5.3 - EAP Supplicant must write events to the event log for use by the user oradministrator.

This test verifies that events are logged by supplicant.

Overview

The test performs the following steps:

  • Run an authentication session.

  • Check if any event is logged.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If there is no event logged during the authentication session.

157.5.1 - EAP Supplicant that consumes keys must consume then locally; and not provide them or derived keys outside the supplicant.

Overview

Self explanatory.

Results Interpretation

The test writes the pass/fail results to a log file.


Extensible Authentication Protocol (EAP) Test - Peer Method

Overview

The Extensible Authentication Protocol (EAP) Test is used by the EAP Certification Program (ECP).

Details

The EAP Test is comprised of testing methods:

  • Peer Method

  • Authenticator Method

  • Network Supplicant

This description applies to the Peer Method.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows Server 2008 Release 2

  • Windows 7

  • Windows Server 2008

  • 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

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 Extensible Authentication Protocol (EAP) Test - Peer Method

For Peer Method:

144.1.1 - EAP Method Submissions MAY include 32-bit X86 binaries

This test verifies submission of 32-bit x86 binary.

Overview

The test performs the following steps:

  • It checks whether submission has X86 binary.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • The package path cannot be located.

144.1.2 - EAP Method Submissions MUST include 64-bit X64 binaries

This test verifies submission of 64-bit X64 binary.

Overview

The test performs the following steps:

  • It checks whether submission has at least one X64 binary.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • X64 binary is not present in the package.

144.1.3 - EAP Methods MUST NOT disable or impair the functionality of other system components during their operation.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

145.1.1 - All ECP EAP Method Submissions will be packaged in an INF.

This test verifies that the submission has packaged INF file.

Overview

The test performs the following steps:

  • Checks for the valid INF file in the package location.

  • Checks for various sections for valid installation of the INF file.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • INF file is not present in the package location.

  • INF file does not contain the install section.

145.1.2 - ECP EAP Method Submission INF installers MUST allow for installation and uninstall.

This test verifies that submitted INF installers should allow for installation and uninstall.

Overview

The test performs the following steps:

  • Checks that Install section is present in the INF file.

  • Checks that Uninstall section is present in the INF file.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • INF file does not contain the install section.

  • INF file does not contain the uninstall section.

145.1.3 - ECP Method Submissions MUST NOT require reboot after installation to function properly

This test verifies that installation of method does not require a reboot.

Overview

The test performs the following steps:

  • Uninstall the method if it is already installed.

  • Install the method.

  • Checks for certain registry locations which need to be updated if reboot is need for install.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Installation process adds the entries to certain registry locations which are necessary for reboot.

145.1.4 - EAP Methods MUST NOT disable or otherwise modify other installed components as part of installation.

This test verifies that installation of method does not modify the registry or file system, other than its own space.

Overview

The test performs the following steps:

  • Uninstall the method if it is already installed.

  • Install the method.

  • Verifies that all the registry updates are done as part of installation under the following key:

    HKLM\System\CurrentControlSet\Services\EapHost\Methods\<Author ID>\<Method Type ID>

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Installation process adds the entries to registry location other than the one specified.

145.1.5 - EAP Methods MUST remove all configuration data and files on removal or uninstall.

This test verifies that uninstall should remove all the configuration data.

Overview

The test performs the following steps:

  • Get the list of all the files copied during installation

  • Check if all these files have been removed.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If there is a mismatch between the files copied during installation and files removed during uninstall.

145.1.6 - Removal of an EAP method must be performed through device uninstall using the device manager.

This test verifies that uninstall should be done with the help of device manager.

Overview

The test performs the following steps:

  • Uninstalls the package.

  • Check for the absence of registry entries.

  • Install the package.

  • Check for the presence of registry entries.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Uninstall/installation of the package is unsuccessful.

  • Registry entries are present after uninstall.

  • Registry entries are absent after install.

146.1.1 - EAP Peer Methods will successfully complete one hour of end-to-end authentications. There should not be any observable resource leaks.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

146.1.2 - EAP Peer Methods will successfully survive 100,000 cycles of loading and unloading the method DLL without error. There should not be any observable resource leaks.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

146.1.3 - All implemented EAP method APIs will successfully survive one hour of comprehensive API fuzz testing without error. There should not be any observable resource leaks.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

146.1.4 - EAP Peer Methods will successfully survive end-to-end negative authentication stress for a period of one hour

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Update the USER.XML only with a bad password. Everything else needs to remain valid for this test to complete successfully.

147.1.1 - If the method is a password or smart card based test case, it should not write password or pin in traces or event logs (Manual).

This is a manual sign off item. This test verifies that EAP method does not write password information in the trace logs. This test case needs user interaction in DTM client side.

Overview

The test performs the following steps:

  • Checks the status of the trace file/event.

  • Runs the Authentication session with the method.

  • Ensure that method has written to trace logs/event channel.

  • Verify that the password is not present in the trace logs/events.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • As part of authentication method writes password information into the trace logs.

User Interactions

User has to do the following tasks for Plain (.log).

  • In the DTM studio, select the log type as "Plain (.log)" and enter "Trace File Path". Schedule the job. At the DTM client, the following interactions are needed:

  • Enable the method specific trace (which will be written to C:\windows\tracing) and then press Ok.

  • An authentication session will be run as part of the test case.

  • Disable the method trace and then press Ok.

  • The trace file will be displayed in notepad.

  • Verify whether the trace has password information

  • Enter the appropriate choice (Yes/No) in the dialog box that follows.

  • End of the test case.

User has to do the following tasks for Windows Event log.

  • Make sure Event is registered. This can be verified using Windows Event Viewer.

  • In the DTM Studio select log type as "Windows Event" and enter "Channel\Provider Name". Schedule the job, and then at the DTM client the following interactions are needed.

  • An authentication session will be run as part of the test case.

  • If event is detected, then the following dialog is displayed: "Events detected, please open Event Viewer, verify events and answer the below question. Is there password info in the Events?"

  • Verify whether the events contain password information or not.

  • Enter the appropriate choice (Yes/No) in the dialog box.

  • End of the test case.

148.1.1 - All data for a given EAP method will be located under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EAPHost\Methods; entirely contained within the EAP Method's own private EAP Method registry sub-key.

This test verifies that installation of method does not modify the registry, other than its allocated space.

Overview

The test performs the following steps:

  • Uninstall the method if it is already installed.

  • Install the method.

  • Verifies that all the registry updates are done as part of installation under the following key:

    HKLM\System\CurrentControlSet\Services\EapHost\Methods\<Author ID\< Method Type ID>

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • Installation process adds the entries to registry location other than the one specified.

148.1.2 - All Vendors who submit methods to the ECP will acquire a valid Enterprise-ID from IANA (Manual).

This test verifies that registry should have the enterprise id at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EAPHost\Methods\<Vendor IANA ID>

Overview

The test performs the following steps:

  • Validate if the enterprise-id is in the acceptable range.

  • If it's an expanded EAP type, then check if Vendor id is inacceptable range or not.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If there is enterprise id /vendor id is in inacceptable range.

148.1.3 - The Vendor Registry Key under which all vendor method configuration data is stored will contain a string value that identifies the vendor name corresponding to the vendor's enterprise-id.

This test verifies that registry should have the enterprise id at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EAPHost\Methods\<<Vendor IANA ID>>

And the registry location has a default string value or a value "Name" which specifies the Vendor name

Overview

The test performs the following steps:

  • Check if the name present at this registry location matches with the Vendor Name corresponding to the vendor's enterprise id.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If there is a mismatch in names.

148.1.4 - All files that are added to the system by the installation package (INF) are to be physically located under the Windows Program Files directory in a private sub-directory that reasonably reflects the nature of the ECP submission.

This test verifies that files added by package should be only under Program files.

Overview

The test performs the following steps:

  • Check the install section of INF file. All the files added should be located one folder under Program Files.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If install section tries to copy file at some other location.

148.1.5 - EAP Methods MUST add their default registry keys using regsvr32 facility

This test verifies that method should be installed using regsvr32.exe

Overview

The test performs the following steps:

  • Uninstall the method using regsvr32.

  • Install the method using regsvr32.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • If uninstall or install fails.

149.1.1 - EAP Methods will produce a human-readable debug tracing log that enables administrators or other users to investigate and determine the cause of failures (Manual)

This test verifies that EAP method produce human readable trace logs. This test case needs user interaction in DTM client side.

Overview

The test performs the following steps:

  • Checks the status of the trace file/event.

  • Runs the Authentication session with the method.

  • Ensure that method has written to trace logs/event channel.

  • Verify that the trace logs/events are human readable.

Results Interpretation

The test writes the pass/fail results to a log file.

The test fails if:

  • As part of authentication method writes non human readable characters to the trace logs.

User Interactions

User has to do the following tasks for Plain (.log).

  • In the DTM studio, select the log type as "Plain (.log)" and enter "Trace File Path". Schedule the job, and then at the DTM client, the following interactions are needed.

  • Enable the method specific trace (which will be written to C:\windows\tracing) and then press Ok.

  • An authentication session will be run as part of the test case.

  • Disable the method trace and then press Ok.

  • The trace file will be displayed in notepad.

  • Verify whether trace file is human readable or not and then close the file.

  • Enter the appropriate choice (Yes/No) in the dialog box that follows.

  • End of the test case.

User has to do the following tasks for Windows Event log.

  • Make sure Event is registered. This can be verified using Windows Event Viewer.

  • In the DTM Studio select log type as "Windows Event" and enter "Channel\Provider Name". Schedule the job, and then at the DTM client the following interactions are needed.

  • An authentication session will be run as part of the test case.

  • If event is detected, then the following dialog is displayed: "Events detected, please open Event Viewer, verify events and answer the below question. Is the Event Readable?"

  • Verify whether the events contain password information or not.

  • Enter the appropriate choice (Yes/No) in the dialog box.

  • End of the test case.

149.1.2 - EAP Method debug tracing may be turned-off by default

This test verifies that Method tracing should be disabled by default.

Overview

The test performs the following steps:

  • Check the state of trace file.

  • Run an authentication session.

  • Check the trace file.

Results Interpretation

The test writes the pass/fail results to a log file.

150.1.1 - The EAP Method Binary MUST export all mandatory EAP APIs

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Make sure the location of the method DLL is properly entered in the UI

150.1.2 - ECP Submissions MUST NOT include any binaries that are expected to execute in kernel-mode. ECP Submissions are expressly prohibited from shipping kernel-mode drivers of any kind (i.e. SYS, etc)

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.1.3 - EAP Method Submissions MUST NOT take a dependency on .NET framework

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.1.4 - EAP Methods MUST demonstrate successful end-to-end authentication

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Make sure your radius server is available and an end-to-end authentication is happening before executing this case. This case will require the use of connection.xml and a user.xml to carry out the end to end authentication.

150.1.5 - EAP Method MUST NOT make any assumptions about the underlying transport

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Make sure your radius server is available and an end-to-end authentication is happening before executing this case. This case will require the use of connection.xml and a user.xml to carry out the end to end authentication.

150.1.6 - All implemented EAP method APIs will successfully survive comprehensive API fuzz testing without error. There should not be any observable resource leaks.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Make sure the location of the method is properly entered in the UI

150.1.7 - EAP Methods MUST NOT load any DLLs or cause to be loaded any DLLs that are not provided with the submission or provided by Windows itself

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.1.8 - EAP Methods MUST NOT initiate, terminate or pass-through any IPC

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.1.10 - EAP Method Submissions MUST include a peer method implementation

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.1.28 - EAP Methods MUST support UI suppression request bit through EapHostPeerBeginSession() suppressing informational UI.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.1.29 - EAP Methods MUST support alternate credentials bit through EapHostPeerBeginSession().

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.1.30 - EAP Methods MUST always perform legal state transitions.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.1.31 - EAP Methods must implement Peer runtime routines for all these functions

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

150.1.32 - EAP Methods MUST provide an XML schema that defines and is used to validate XML configuration documents.

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Make sure the full path to the location of your XML schema file (.xsd) is entered correctly in the DTM UI

150.1.33 - EAP Methods MUST pass configuration XML to BLOB, configuration BLOB to XML inter-conversion test

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Make sure your XML files are entered correctly in the DTM file. Make sure your XML files are valid and the data inside them adhere to the XML standards

151.1.1 - EAP Method Submissions MUST accurately set appropriate security and property descriptor bits for the EAP method (peer).

Overview

Self explanatory

Results Interpretation

The test writes the pass/fail results to a log file.

Troubleshooting tips

Please indicate the proper security descriptor during submission. Your will be presented with a UID, make sure you click the check boxes that corresponds to the security descriptor as the method supports

153.1.1 - EAP Methods that export keys must export them only to EAPHost and to no other destination. The keys will be delivered directly to the lower layer for consumption and use entirely at that layer. Keys may not be distributed outside of the lower layer per RFC. The keys must be exported in the following manner: MSK using the MS-MPPE extension. EMSK using the EMSK extension (Manual).

Overview

The method must not handle key distribution it's potentially very compromising to handle store or export these key

Results Interpretation

The test writes the pass/fail results to a log file.


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 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

  • "Cannot initialize the FaxRcv Routing Extension"

    Verify Faxrcv.dll is in the same directory as Faxvrfy.exe.

  • "There are no Fax Ports installed"

    Verify that the modem is installed correctly.

  • "No Dial Tone"

    Verify that a working phone line is plugged into the modem.

  • "Busy"

    Verify that the Send to and Receive on phone numbers are correct, or verify that the phone numbers are not busy.

  • "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.

  • "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.

  • "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.

  • "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.

  • "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.

  • "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.

  • "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.

  • "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.


IrDA Transport

Type: Automated Test

Overview

IrDA Transport is a socket-level test tool that is used to test IrDA drivers. This tool tests IrDA drivers by checking if other IrDA devices in range can be detected and data can be sent and received by using the IrDA devices without any errors.

Details

The following list describes what test does:

  • Random Sock Connect/Disconnect. A socket number is being randomly generated and a client connects to the server by using this random socket. After the connection is established, the socket is disconnected immediately. There is 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 by 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. The 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. The 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, the test program opens connections to a server computer, and sends the data '01010101b'. The sockets are used one at a time to send and receive the data. You select the buffer length and the value for the sent buffer size is ranges 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, the test program opens connections to a server computer, and sends random data. The sockets are used one at a time to send and receive the data. You select the buffer length and the value for the sent buffer size ranges 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, the test program opens connections to a server computer, and sends the data '01010101b'. The sockets are used one at a time to send and receive the data. The buffer length is selected randomly and the value for the sent buffer size ranges 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, the 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 the value for the sent buffer size ranges 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, the test program opens connections to a server computer, and sends the data '01010101b'. The buffer length is selected by the user and the value for the sent buffer size ranges 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, the test program opens connections to a server computer, and sends random data. The buffer length is selected by the user and the value for the sent buffer size ranges 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, the test program opens connections to a server computer, and sends the data '01010101b'. The buffer length is selected randomly and the value for the sent buffer size ranges 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, the test program opens connections to a server computer, and sends random data. The buffer length is selected randomly and the value for the sent buffer size ranges 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. The buffer size is 4 kilobytes. The integrity of transferred data is verified. After all threads are terminated, the test exits.

Run Time:
Log File: irwhql.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

An IrDA device must be present on both the systems on which the test will be run. The transceivers of the two devices must be facing each other and should be positioned at no more than one meter away from each other.

Command Syntax

Command option | Description
/s | Start the IrWHQL server.
/c | Start the IrWHQL client running default tests.
/logo | Start the 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, there is no device in range or there is more than one device in range. You can find out the error from the log file that the test tool generates.

Code Tour

File Manifest

File | Location
* | [WTT\TestBinRoot]\nttest\nettest\irda\TransportTest


LLD2 Responder Verification Tests

Type: Automated Test

Overview

The LLD2 verification tool runs a series of tests against a device that implements 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 Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 LLD2 Responder Verification Tests

To run this tool manually, do the following:

  1. Install the RawEther driver. You can find this driver under \nttest\NetTest\netxp\homenet\lld2\tools in the DTM controller's tests directory.

  2. In this same directory, run instrawether -i to install the driver.

  3. Next, run net start rawether from the command line as an administrator to start the driver.

  4. Copy veritool to a local directory to run it. You can find this tool in the \nttest\NetTest\netxp\veritool directory on the DTM controller.

You can run Veritool with the following options:
Usage: VeriTool [options] <responder address> <test id>
Options:
-v : verbose
-s : save trace
-e : enumerate the adapters
-a <adapter index> : specify the adapter to use
-t : list available tests

Note Using a wildcard character (*) for your test ID runs all working tests. If you use 1 for your test ID, all in the 1.x range will be run.

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
-v | Verbose
-s | Save the trace
-e | Enumerate adapters
-a <adapter index> | Specify the adapter to use
-t | List available tests

Cautions

If you have multiple responders that are connected to the IGD, errors might occur during testing. Also, if the responder is not directly connected to the IGD, the test might have failures because of packet loss on the intermediate device.

Troubleshooting

The LLD2 tests rely on the proper MAC address being entered for the device's wired LAN side. In DTM, this address is added properly when setting the IGD_Mac dimension in the router configuration job. If an LLD2 job stops responding (that is, "hangs"), and the Job Monitor window says "Scheduler" for the status, you likely do not have the LAN dimension set as True for the machines that are connected to the LAN side of the IGD.

If the tests are running, but you are getting failures, try to run the test manually. Also, try running a network analyzer to help understand what is going on with the LLTD traffic.

Code Tour

File Manifest

File | Location
veritool.exe | nttest\NetTest\netxp\veritool

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: NETWORK-0071 Router, WLAN AP, or Wireless Router has properly formatted metadata for mandatory TLVs according to LLTD
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 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: NETWORK-0071 Router, WLAN AP, or Wireless Router has properly formatted metadata for mandatory TLVs according to LLTD
Additional Information: The responder transmits Probe/Train frame when it receives the Emit frame and reports observed Probe frames when it receives the Query frame.
The responder must properly detect rogue mapping sessions.
Test Assertion GUID: 1F011CDB-33F2-4d4c-B4FA-0FE8DB44E9CD
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 can attend only 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: NETWORK-0071 Router, WLAN AP, or Wireless Router has properly formatted metadata for mandatory TLVs according to LLTD
Additional Information: Some of the frames from the mapper, such as Charge, Emit and Query frame, carries sequence number. 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: NETWORK-0071 Router, WLAN AP, or Wireless Router has properly formatted metadata for mandatory TLVs according to LLTD
Additional Information: The responder should keep the previous session's generation number and update its current generation number when it receives 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: NETWORK-0073 Router, WLAN AP, or Wireless Router has properly formatted metadata for mandatory TLVs according to LLTD
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.


NETWORK-0290 - WMC AQ - Ethernet device_driver must support HD media streaming requirements (a) 1 HD stream in the transmit direction

Type: Automated

Overview

The NETWORK-0290 requirement contains High Definition (HD) streaming content Additional Qualifications for the Windows 7 Windows Media Center. The Additional Qualifications (AQ) consists of a 1 HD Stream AQ Test and a 2 HD Stream AQ Test.

Details

This 1 HD Stream AQ test is a wired Ethernet Additional Qualifications test that qualifies a network interface card (NIC) and its driver for Windows Media Center. One HD stream is used for the test. The HD stream must meet the following requirements to pass the test:

  • 22 Mbps minimum

  • 1 Hour duration

  • Less than 0.1% packet loss

Run Time: 60 minutes
System Restart Required: No
Program: Additional Qualifications for Windows 7 Media Center

Requirements

Software Requirements

The test tool requires the following software:

  • Software components included with the device that is being tested

  • The NIC Driver

  • The test tool runs on the following Windows operating systems:
    • Windows Vista
    • Windows 7

Hardware Requirements

The test tool requires the following hardware:

  • Switch/Router without DHCP must be a standard consumer grade gigabit switch.

  • The test computer must meet the following minimum requirements:
    • The device under test
    • 1 GHz processor
    • 1 GB of system RAM
    • 40 GB free hard drive space
    • Audio support
    • Windows keyboard
    • A two button pointing device
    • Minimum Graphics Card and Display Support:
      • DirectX 9 or Greater support
      • Supported WDDM Driver
      • 128 MB of on-board graphics card memory
      • Pixel Shader 2.0 support
      • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the NETWORK-0290 1 HD Stream AQ Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures. Review the test results in the log file for specific details about failures. The configuration in the following figure is required for this test.

Diagram illustrating running the NETWORK-0290 1 HD Stream AQ Test

To run the NETWORK-0290 1 HD Stream AQ Test:

  1. Set up the test configuration.

  2. Set up one Windows Vista SP1 and one Windows 7 client, both using the same processor architecture (x86 or amd64). The NIC and Driver under test must be NIC 1 on Windows 7.

  3. Configure these test computers following the instructions outlined for setup of computers DTM Client 1 ("Remote Test Machine" - this should be the computer running Windows Vista OS) and DTM Client 2 ("Local Test Machine" - this computer should be the one running Windows 7) in LAN (Ethernet) Testing Overview.

    Note For the configuration tests to succeed, it is not strictly necessary that DTM Client 2 have three Ethernet adapters. The Network WMC AQ tests only make use of the Local Message Device and Local Test Device on that computer. However, other related jobs may require all three network adapters to be present for configuration.

  4. Create a machine pool and add the Windows 7 and Vista SP1 clients.

  5. Verify that the test machines are fully set up (in machine pool, in Ready state, and all configuration jobs finished).

  6. From the DTM Studio Main Menu, click Explorers, and then click Device Console.

  7. On the Device Console, create a new device submission. In the Data Store field, select the data store and in the Submission field, select <New Submission>.

  8. On the Create New Submission page, select Windows 7 Client or Windows 7 Client x64 (depending upon your client architecture), and then click Next.

  9. On the next Create New Submission page, in the Select Category list box, click Device Submission, and then click Next.

  10. On the next Create New Submission page, in the Logo Type list box, click Network > LAN (Ethernet), and then click Next.

  11. On the next Create New Submission page, in the Qualification Level list box, select Logo, and then click Next.

  12. On the next Create New Submission page, in the Name for new submission text box, type a name for the submission, select the Machine Pool to which the two clients belong, and then click Next.

  13. On the next Create New Submission page, in the Name for new submission text box, type a name for the submission, select the Machine Pool to which the two clients belong, and then click Next.

  14. On the next Create New Submission page, in the Additional Qualifications list box, click the MediaCenter check box, and then click Next.

  15. On the next Create New Submission page, review the settings and then click Finish to complete the Wizard.

  16. The tree view of the Device Console contains your newly created submission and the two Additional Qualifications tests (NETWORK-0290) are listed under the LAN (Ethernet) node in the Available Jobs pane.

  17. In the Available Jobs pane, select the check box next to the NETWORK-0290 test containing (a) 1 HD stream in the transmit direction, and any other tests that you want to run, and click Add Selected to load the test or tests. Your device must pass all tests for the submission to qualify for the logo, but you can run one or more or all at a time.

  18. Schedule the test or tests to run by selecting the test and then click Schedule Jobs.

    Network tests related to the Windows Media Center Additional Qualifier can be found in Job Explorer on the Feature tab under the Additional Qualifications node of the Networking category. The Additional Qualifications jobs can only be run from the Device Console page.


NETWORK-0290 - WMC AQ - Ethernet device_driver must support HD media streaming requirements (b) 1 HD stream in the transmit direction and 1 HD stream in the receive direction

Type: Automated

Overview

The NETWORK-0290 requirement contains High Definition (HD) streaming content Additional Qualifications for the Windows 7 Windows Media Center. The Additional Qualifications (AQ) consists of a 1 HD Stream AQ Test and a 2 HD Stream AQ Test.

Details

This 2 HD Stream AQ test is a wired Ethernet Additional Qualifications test that qualifies a network interface card (NIC) and its driver for Windows Media Center. Two HD streams are used for the test. The 2 HD streams both must meet the following requirements to pass the test:

  • 22 Mbps minimum

  • 1 Hour duration

  • Less than 0.1% packet loss

Run Time: 60 Minutes
System Restart Required: No
Program: Additional Qualifications for Windows 7 Media Center

Requirements

Software Requirements

The test tool requires the following software:

  • The NIC Driver

  • The test tool runs on the following Windows operating systems:
    • Windows Vista
    • Windows 7

Hardware Requirements

The test tool requires the following hardware:

  • Switch/Router without DHCP must be a standard consumer grade gigabit switch.

  • The test computer must meet the following minimum requirements:
    • The device under test
    • 1 GHz processor
    • 1 GB of system RAM
    • 40 GB free hard drive space
    • Audio support
    • Windows keyboard
    • A two button pointing device
    • Minimum Graphics Card and Display Support:
      • DirectX 9 or Greater support
      • Supported WDDM Driver
      • 128 MB of on-board graphics card memory
      • Pixel Shader 2.0 support
      • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the NETWORK-0290 2 HD Stream AQ Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures. The configuration in the following figure is required for this test.

Diagram illustrating running the NETWORK-0290 2 HD Stream AQ Test

To run the NETWORK-0290 2 HD Stream AQ Test:

  1. Follow the steps for the 1 HD Stream test for NETWORK-0290, except when selecting the job to run, in the Available Jobs pane, select the check box next to the NETWORK-0290 test containing (b) 1 HD stream in the transmit direction and 1 HD stream in the receive direction and any other tests that you want to run, and then click Add Selected to load the test or tests.

  2. Schedule the test or tests to run by selecting the test, and then click Schedule Jobs.


NETWORK-0291 - WMC AQ - A wireless home router or WLAN AP must meet HD media streaming requirements for 2.4 GHz

Type: Automated

Overview

The NETWORK-0291 requirement contains 2.4 GHz Wireless Router High Definition (HD) streaming content Additional Qualifications for the Windows 7 Windows Media Center.

Details

This 1 HD Stream AQ test is a 2.4 GHz wireless home router Additional Qualifications test that qualifies a 2.4 GHz wireless home router for Windows Media Center. One HD stream is used for the test. The HD stream must meet the following requirements to pass the test:

  • 2.4 GHz

  • 22 Mbps minimum

  • 1 Hour duration

  • Less than 0.1% packet loss

Run Time: 60 minutes
System Restart Required: No

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows Vista

  • Windows 7

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the NETWORK-0291 2.4 GHz Wireless Router AQ Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

To run the NETWORK-0291 2.4 GHz Wireless Router AQ Test:

  1. Set up the test configuration, as shown in the following diagram. Diagram illustrating running the NETWORK-0291 2.4 GHz Wireless Router AQ Test

  2. Configure the test computers and the machine pool following the instructions in Wireless Router Logo Program Testing.

  3. Create a Network > Wireless Router submission following the procedure in Wireless Router Logo Program Testing.

  4. On the next Create New Submission page, type the device BSSID, MAC Address, and DevicePIN for the Wireless Router under test, and then click Next.

  5. Complete the Wizard.

  6. Select the 2.4 GHz Additional Qualifications test and any other tests you want to run, and then click Add Selected.

  7. Select the jobs and click Schedule Jobs to run the jobs.


NETWORK-0291 - WMC AQ - A wireless home router or WLAN AP must meet HD media streaming requirements for 5.0 GHz (if implemented)

Type: Automated

Overview

The NETWORK-0291 requirement contains 5.0 GHz Wireless Router High Definition (HD) streaming content Additional Qualifications for the Windows 7 Windows Media Center.

Details

This 1 HD Stream AQ test is a 5.0 GHz wireless home router Additional Qualifications test that qualifies a 5.0 GHz wireless home router for Windows Media Center. One HD stream is used for the test. The HD stream must meet the following requirements to pass the test:

  • 5.0 GHz

  • 22 Mbps minimum

  • 1 Hour duration

  • Less than 0.1% packet loss

Run Time: 60 minutes
System Restart Required: No

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows Vista

  • Windows 7

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the NETWORK-0291 5.0 GHz Wireless Router AQ Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

To run the NETWORK-0291 5.0 GHz Wireless Router AQ Test:

  1. Set up the test configuration.

  2. Configure the test computers and the machine pool following the instructions outlined for setup of computers in Wireless Router Logo Program Testing.

  3. Create a Network > Wireless Router submission following the procedure in Wireless Router Logo Program Testing.

  4. On the next Create New Submission page, type the device BSSID, MAC Address, and DevicePIN for the Wireless Router under test, and then click Next.

  5. Complete the Wizard.

  6. Select the 5.0 GHz Additional Qualifications test and any other tests you want to run, and then click Add Selected.

  7. Select the jobs and click Schedule Jobs to run the jobs.


NETWORK-0293 - WMC AQ - A home router must meet HD media streaming requirements on the LAN ports (a) 1 HD stream in the transmit direction

Type: Automated

Overview

The NETWORK-0293 requirement contains Wired Home Router High Definition (HD) streaming content Additional Qualifications for the Windows 7 Windows Media Center. The Additional Qualifications (AQ) consists of a 1 HD Stream AQ Test and a 2 HD Stream AQ Test.

Details

This 1 HD Stream AQ test is a wired Ethernet Additional Qualifications test that qualifies a Wired Home Router for Windows Media Center. One HD stream is used for the test. The 1 HD stream must meet the following requirements to pass the test:

  • 22 Mbps minimum

  • 1 Hour duration

  • Less than 0.1% packet loss

Run Time: 60 minutes
System Restart Required: No

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows Vista

  • Windows 7

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the NETWORK-0293 Home Router 1-HD Stream AQ Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

To run the NETWORK-0293 Home Router 1-HD Stream AQ Test:

  1. Set up the test configuration, as shown in the following diagram. Diagram illustrating running the NETWORK-0293 Home Router 1-HD Stream AQ Test

  2. Configure the test computers and the machine pool following the instructions in Router Logo Program Test Lab Setup (non-wireless).

  3. Create a Network > Wireless Router submission following the procedure in Router Logo Program Test Lab Setup (non-wireless).

  4. On the next Create New Submission page, type the device MAC Address for the Wired Router under test, and then click Next.

  5. Complete the Wizard.

  6. In the Available Jobs pane, select the check box next to the NETWORK-0293 test containing (a) 1 HD stream in the transmit direction, and any other tests that you want to run, and click Add Selected to load the test or tests. Your device must pass all tests for the submission to qualify for the logo, but you can run one or more or all at a time.

  7. Select the jobs and then click Schedule Jobs to run the jobs.


NETWORK-0293 - WMC AQ - A home router must meet HD media streaming requirements on the LAN ports (b) 1 HD stream in the transmit direction and 1 HD stream in the receive direction

Type: Automated

Overview

The NETWORK-0293 requirement contains Wired Home Router High Definition (HD) streaming content Additional Qualifications for the Windows 7 Windows Media Center. The Additional Qualifications (AQ) consists of a 1 HD Stream AQ Test and a 2 HD Stream AQ Test.

Details

This 2 HD Stream AQ test is a wired Ethernet Additional Qualifications test that qualifies a Wired Home Router for Windows Media Center. Two HD streams are used for the test. The 2 HD streams both must meet the following requirements to pass the test:

  • 22 Mbps minimum

  • 1 Hour duration

  • Less than 0.1% packet loss

Run Time: 60 minutes
System Restart Required: No

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows Vista

  • Windows 7

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the NETWORK-0293 Home Router 2-HD Stream AQ Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

To run the NETWORK-0293 Home Router 2-HD Stream AQ Test:

  1. Set up the test configuration:

  2. Configure the test computers and the machine pool following the instructions in Router Logo Program Test Lab Setup (non-wireless).

  3. Create a Network > Wireless Router submission following the procedure in Router Logo Program Test Lab Setup (non-wireless).

  4. On the next Create New Submission page, type the device MAC Address for the Wired Router under test, and then click Next.

  5. Complete the Wizard.

  6. In the Available Jobs pane, select the check box next to the NETWORK-0293 test containing (b) 1 HD stream in the transmit direction and 1 HD stream in the receive direction and any other tests that you want to run, and then click Add Selected to load the test or tests.

  7. Select the jobs and then click Schedule Jobs to run the jobs.


NDISTest 6.0

Type: Automated Test

Overview

The NDISTest 6.0 test is used to test and validate the functionality of a network device and driver.

Details

NDISTest 6.0 exercises various functionality that a Microsoft Windows network driver implements. Examples include sending and receiving data traffic and querying and setting various configuration for the device and advanced hardware capabilities like power management, task offload, and so on.

NDISTest 6.0 provides tests for the following device classes:

  • Ethernet

  • Modem

  • IrDa

  • ISDN

For more information about setting up NDISTest 6.0, see the Driver Test Manager (DTM) Help documentation for Network logo programs.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Setup of two machine is required.

  • Network switch

Processor

  • x86

  • x64

  • Itanium

Cautions

Try to keep the test channel as isolated as possible. Traffic from other devices on the network can cause packet drops that interfere with the test results.

Troubleshooting

To troubleshoot the NDISTest, try attaching a debugger to the test machine.


NDISTest 6.5

Type: Automated Test

Overview

The NDISTest 6.5 test is used to test and validate the functionality of a network device and driver.

Details

NDISTest 6.5 exercises various functionalities that a Microsoft Windows network driver implements. Examples include sending and receiving data traffic querying, as well as setting various configurations for the device and advanced hardware capabilities, such as power management, task offload, interrupt moderation, and so on.

This test requires you to manually install .NET v2.0 on Windows Server 2003 and Windows XP systems.

The "NDISTest 6.5 (Premium)" job tests to verify the support of six Wake-on-LAN patterns.

The "NDISTest 6.5 (MPE)" job is a testing methodology (Multi-path Exerciser) that repeatedly schedules multiple tasks in parallel looking for severe driver failures. It requires a system that supports standby in order to qualify a NIC. Activities for this job include the following:

  • Sending and receiving packets

  • Resetting the driver

  • Managing power on the host machine

  • Querying OIDs

  • Pausing and restarting the driver

  • Halting and initializing the driver

Some of these problems can be difficult to diagnose, but MPE is effective at diagnosing them.

NDISTest 6.5 provides tests for the following device classes:

  • Ethernet

  • Wireless LAN

  • Mobile Broadband (only in Windows 7)

For more information about setting up NDISTest 6.5, see Network Controller Testing.

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Setup of two machines is required (three machine for Wireless Lan tests)

  • Network switch

Cautions

Try to keep test channel as isolated as possible. Traffic from other devices on the network can cause packet drops that interfere with the test results. Wireless LAN in particular is very susceptible to incorrect test results when packet interference occurs.

Troubleshooting

To troubleshoot the NDISTest, try attaching a debugger to the test machine.


NIC Tests

Type: Automated Test

Overview

This test tool sends packets with invalid and randomized contents to test NIC's offload processing.

Details

The necessary tools are copied to the machine that has DTM installed, but installation of the tools occurs as part of the DTM job. Manual installation can be performed with the same command lines that are 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 create different packet sequences. The protocol driver on the host machine allows its actions to bypass the Windows TCP/IP stack and any checks it would perform. Most of the packet sequences contain invalid fields or headers. Others are either boundary values or randomized. The packets are designed to catch flaws in packet processing by NICs performing any sort of hardware offload operations. ARP, IPv4, IPv6, ICMP, IGMP/MLD, UDP, and TCP are tested.

An administrative service is installed on the test machine to control its higher level actions, such as opening sockets, and querying information for additional checks. The Microsoft Windows TCP/IP stack and the NIC's driver and hardware determine all responses on the test machine.

Run Time: 4 hours
Log File: Each script that runs generates an NTLog file with a similar name and a WTTLog file named Cscript.wtl.
System Restart Required: Yes
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows XP

  • Windows Server 2003

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Two NICs on two machines.

  • The device under test should be on a private network.

Processor

  • x86

  • x64

  • Itanium


QOS RouterLogo (LMS)

Type: Automated Test

Overview

The RouterLogo (LMS) tool verifies the correct behavior of the infrastructure devices (router, AP, and so on) regarding QOS (DSCP, 802.1p, WiFi WMM, and LLTD QoS/qWave listeners).

Details

To perform this test, you will need the following hardware:

  • A client computer with the following hardware:
    • LAN_P: NIC with 802.1p support enabled (for example, Intel Pro/100 Family with "802.1p QoS Packet Tagging" set to Enabled in the Advanced tab). This interface should have DHCP enabled to obtain an address from the router.
    • LAN: NIC with 802.1p support disabled (for example, Intel Pro/100 Family with "802.1p QoS Packet Tagging" set to Disabled in the Advanced tab). This interface should have DHCP enabled to obtain an address from the router.
    • WIRELESS: WMM-capable Wireless NIC (Native WIFI preferred). This interface should have DHCP enabled to obtain an address from the router.
    • DTM: Any NIC for backchannel purposes. This interface should be in the same network as the Microsoft Windows Driver Kit (WDK) controller.
  • A remote computer with the following hardware:
    1. WAN: NIC with 802.1p support disabled (for 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. WIRELESS: WMM-capable Wireless NIC (Native WIFI preferred).
    3. DTM: Any NIC for backchannel purposes. This interface should be in the same network as the WDK controller.

A wireless router that supports WMM and has integrated LLTD responder. The WAN port of the Router should have a DHCP IP address to be able to talk with NIC1 of the Remote PC.

Note We recommend the Intel Pro100/Family NICs because they correctly implement the 802.1p behavior.

This tool is divided in four different categories:

  1. 802.1p and DSCP Tag Tests. Sends 1000 packets (marked with either 802.1p tag, DSCP or no tag) and verifies that all of the packets were received at the remote side with the correct 802.1p/DSCP tag.

    1.1. DSCP test 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

    1.1.2. From LAN to WLAN using UDP

    1.1.3. From WLAN to LAN using TCP

    1.1.4. From WLAN to LAN using UDP

    1.2. No tag test 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.2.1. From LAN to WLAN using TCP

    1.2.2. From LAN to WLAN using UDP

    1.2.3. From WLAN to LAN using TCP

    1.2.4. From WLAN to LAN using UDP

  2. LLTD Implementation Tests. Tests LLTD implementation of the Router 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% (25% from WLAN to Router) for bottleneck bandwidth and available bandwidth, the test fails, as well if any of the samples contains no data. Tests 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

    2.1.2. Test LLTD from LAN with cross traffic

    2.1.3. Test LLTD from WLAN

    2.1.4. Test LLTP from WLAN with cross traffic

  3. RTT Tests. For these tests, cycles through 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. Calculates that the RTT time shouldn't be more than 10 ms (for both marked and non-marked packets). Verifies 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

    3.2. RTT Test from LAN to WLAN

    3.3. RTT Test from WLAN to LAN

    3.4. RTT Test from WLAN to WAN

  4. Two Stream Priority Tests. In these tests, create two streams, each one marked with a different tag (that is, Stream1: DSCP 0x38 , Stream2: DSCP 0x28), send those packets by using the available bandwidth, and 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 sends two flows, each one with a different DSCP value to verify priority. 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

    4.1.2. TCP flows from WLAN to LAN.

    4.1.3. UDP flows from LAN to WLAN.

    4.1.4. UDP flows from WLAN to LAN.

    4.2. L2(802.1p) priority sends two 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.2.1. TCP flows from LAN to WLAN. Two TCP Flows from Lan to WLan.

    4.3.2. TCP flows from WLAN to LAN. Two TCP Flows from WLan to Lan.

    4.3.3. UDP flows from LAN to WLAN. Two UDP Flows from Lan to WLan.

    4.3.4. UDP flows from WLAN to LAN. Two UDP Flows from WLan to Lan.

Run Time: 60 min
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 QOS RouterLogo (LMS)

Before the test begins, do the following:

  1. Set NIC1 in the client computer with 802.1p enabled. (Advanced properties, 802.1p enabled.)

  2. Associate wireless NIC (WNIC in the client computer and WNIC in the remote computer) to the router.

  3. Add a route for the WAN address. Route Add 17.0.0.0 mask 255.0.0.0 192.168.1.1.

Cautions

For wireless tests, we recommend that you perform this test in a clean wireless environment to avoid possible interference from other wireless routers.

Troubleshooting

Verify that the WDK process installed the NDIS_LWF. You can use the Sc query ndislwf command to verify that the filter driver is running.

Verify that you have QoS enabled in the network interfaces.

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 Router, WLAN AP, or Wireless Router does not drop packets tagged with the 802.1Q priority value
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 Router, WLAN AP, or Wireless Router does not drop packets tagged with the 802.1Q priority value
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 drop packets tagged with the 802.1Q priority value
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 drop packets tagged with the 802.1Q 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 does not drop packets tagged with the 802.1Q priority value
Additional Information: This assertion maps to the LLTD implementation tests (Section 3 of the test description document).


Wireless Router Wifi Performance Tests

Type: Automated Test

Overview

STATS is a UDP traffic generator tool that provides both client as well as server functionality.

Details

The STATS tool, Stats.exe, is a stream (UDP) generating tool. STATS requires input command line parameters.

This section describes STATS input parameters that are required for the logo test.

Stats can be run in two modes, SERVER and CLIENT.

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 per second. Applicable in SERVER and CLIENT modes.
-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 a uniform way.
-h | Runs the tool with a high priority class.
-i | Sampling interval in seconds.
-x | Time in seconds for the first frame/packet. If a frame is not received within the specified time, the program terminates.
-y | Waiting time in seconds for stable traffic. This is time after which the actual sampling measurement starts.
-q | Allowed packet loss in %.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Cautions

The firewall will block the UDP traffic and, in turn, all the tests will fail. Besides Windows Firewall, turn of any existing firewalls.

Troubleshooting

This tip will help you test the ability of your machines to send/receive higher bit rates using an Ethernet connection. Use this test to validate how the actual configuration is able to deal with requested bit rates. If the following simple configuration fails, it will likely fail for a wireless link as well.

Ethernet Test:

  1. Setup two machines (S and C) so that these are connected with Ethernet connection only.

  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 command prompt and run the Stats.exe tool at the Machine C with the following parameters:

    Stats.exe -z DISCARD -i 20 -x 50 -y 30 -r 20000000 -c 3600 -l -h -u

    (Refer to the table in the Details section earlier in this topic.)

  5. Open the command prompt and run the Stats.exe tool at the Machine S with following parameters:

    Stats.exe -d 10.0.0.3 -r 20000000 -c 4200 -l -h -u

    (Refer to the table in the Details section earlier in this topic.)

  6. Observe the output of Step 4 and Step 5.

Conclusion:

If output of either Step 4 or Step 5 shows any failures, your machines cannot make bit rates using wireless adapters.

Code Tour

File Manifest

File | Location
STATS.EXE | [SystemDrive]\WifiPerf
Wireless Profiles | [SystemDrive]\WifiPerf\Profiles\*
Various scripts | [SystemDrive]\WifiPerf\Scripts\*

Test Assertions

Wireless Router can sustain throughput at a range for given time with specified packet loss.
Test Assertion GUID: E8A7274C-AD03-44e7-B8A7-7BD6EE5B47DD
Windows Logo Program: NETWORK-0057 Device can sustain throughput at range for given time with specified packet loss


TCPIP Offload Engine Logo Verification

Type: Automated Test

Overview

The TCP/IP Offload Engine functional logo tests test verifies the TCP behavior of a TOE (TCP/IP Offload Engine) network card. It checks protocol conformance and offload mechanisms.

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 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: Each script that runs generates an NTLog file and a WTTLog file with a similar name.
System Restart Required: Yes
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Cautions

Reboots are required to enable or disable User Account Protection (UAP). Changes to the default configuration are made, but will not persist unless an unforeseen error occurs.

Code Tour

File Manifest

File

Location

autosrv.exe sparta.drv.sys

nttest\nettest\transports\sparta\
nttest\nettest\transports\sparta\


TCPIP Offload Engine Stress Tests

Type: Automated Test

Overview

The TCP/IP Offload Engine logo (stress) test verifies the TCP behavior of a TOE (TCP/IP Offload Engine) network card.

Details

The necessary tools are copied to the machine with the DTM

Two machines are required for the tests. One machine (the host) stresses the second machine (the test machine) by exchanging a large number of TCP packets over several thousand TCP connections. After exchanging specified amounts of data over a TCP connection, the tests close that connection and create a new one. At random intervals, tests attempt to switch the offload state of a specified portion of current TCP connections.

The objective is to test the behavior of the TCP/IP stack in conjunction with TCP chimney offload-capable NIC when they are subjected to a large number of TCP connections and continuous stream of TCP packets being sent or received. At the same time, some connections are randomly offloaded/uploaded to ensure that the TCP/IP stack and TCP chimney offload-capable NIC can handle such state transitions gracefully.

Run Time: 24 hours
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Code Tour

File Manifest

File

Location

offloadstress.exesockdiec.exe sockdics.exe

nttest\nettest\transports\offload\stress\
nttest\nettest\winsock\stress\
nttest\nettest\winsock\stress\


UPnP IGD Byte Counter Tests

Type: Automated Test

Overview

The UPnP IGD Byte Counter 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:

Counters are implemented

Counters are updated consistently

Counters are rolled over properly

Counter values are returned within a reasonable period of time when the device is queried

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 routines 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 Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Internet Gateway Device

Processor

  • x86

  • x64

  • Itanium

Running UPnP IGD Byte Counter Tests

  1. Make sure the IGD has the UPnP setting turned on.

  2. Make sure that a firewall exception is configured to allow UPnP traffic on each test computer.

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 stopped responding when the test was running. If so, restart 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 and pass a different port number.

Code Tour

File Manifest

File | Location
IGDTestTool.exe | [WTT\TestBinRoot]\nttest\admintest\drizzle\bin

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 four more 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 actionAssign 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 >= DataSizeRepeat steps 3-6 four more 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 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.Create a thread and transfer 100 MB of 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 completed. Note the current time stamp as previous. Invoke the GetTotalBytesSent action. Note the current time stamp as current. Verify that current - previous <= 1000 ms. Expected Result: The GetTotalBytesSent action always returns within 1000 ms
GetTotalBytesReceived_Returns_ASAP GetTotalBytesReceived action returns within 1000 milliseconds
Test Assertion GUID: c51bf39e-5d12-4516-bfe4-a52d833246ef
Windows Logo Program: NETWORK-0050 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.Create a thread and download 100 MB of 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 completed. Note the current time stamp as previous. Invoke the GetTotalBytesReceived action. Note the current time stamp as current. Verify that current - previous <= 1000 ms Expected Result: The GetTotalBytesReceived action always returns within 1000 ms.
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 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.Create a thread and transfer 100 MB of data to a computer on the WAN side of the device. Create five threads and in each thread perform steps 4 to 8 below until the transfer is completed. Note the current time stamp as previous. Invoke the GetTotalBytesSent action. Note the current time stamp 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.
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 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.Create a thread and transfer 100 MB of data to a computer on the WAN side of the device. Create five threads and in each thread perform steps 4 to 8 below until the transfer is completed. Note the current time stamp as previous. Invoke the GetTotalBytesReceived action. Note the current time stamp 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.
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 correctly implements GetTotalBytesSent and GetTotalBytesReceived as defined in the UPnP IGD 1.0 specification
Additional Information: Procedure: Connect two 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 of 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 completed. Note the current time stamp as previous.Invoke the GetTotalBytesSent action.Note the current time stamp 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.
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 correctly implements GetTotalBytesSent and GetTotalBytesReceived as defined in the UPnP IGD 1.0 specification
Additional Information: Procedure: Connect two 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 of 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 completed. Note the current time stamp as previous. Invoke the GetTotalBytesReceived action. Note the current time stamp 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.


VirtualWiFi Stress

Type: Automated Test

Overview

This test stresses the WiFi capability of a device and driver to support the Windows 7 logo requirement "Network - 0217."

In WLK 1.5, the test is in preview mode, which means that it is optional and does not need to pass in order to obtain a logo. In WLK 1.6, the test is required to obtain a logo.

Details

Run Time: 3 hours
Log File: None
System Restart Required: Yes
Test Category: Wireless LAN (802.11)
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: VWiFiStress.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

You need one computer with the Device Under Test. Also, make sure that the latest version of BIOS is installed on the computer and the system can reliably resume from sleep.

The test also needs two WiFi routers to run successfully:

WiFi Router #1:

  • Required Settings:

    • Security configuration: WPA-PSK/TKIP
    • SSID - VWIFI-S1
    • Passphrase - stressap1

Note If you have a wireless router configuration that is different from any of the Recommended Settings, please change job parameters (Router1SSID and Router1Passphrase) accordingly.

WiFi Router #2:

  • Required Settings:

    • Security configuration: WPA2-PSK/AES
    • SSID - VWIFI-S2
    • Passphrase - stressap2

Note If you have a wireless router configuration that is different from any of the Recommended Settings, please change job parameters (Router2SSID and Router2Passphrase) accordingly.

We recommend any wireless router that has obtained a Windows 7 logo. To view this list of routers, please visit the following Microsoft Web site: http://winqual.microsoft.com/hcl/default.aspx

Note Make sure that the Device Under Test can connect as well as send/receive data from the WiFi routers above.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Troubleshooting

To open and view log files, follow these steps:

  1. Open Job Monitor in Windows DTM Studio. To do this, click Explorers, and then click Job Monitor.

  2. Identify the pool under which tests were run.

  3. Identify the machine under which test was run.

  4. In Job Execution Status, identify and select the failed job.

  5. In Task Execution Status, right-click the task (either "Run pre-stress job to validate wireless settings" or "Run stress"), and select View Task Log.

To resolve failures in the "Run pre-stress job to validate wireless settings" task, open the log file from above and look for error messages from the bottom. If you cannot identify the root cause of failure, try the following troubleshooting steps for common issues:

  1. How many WiFi adapters are present in the system? If there is more than one WiFi adapter, then disable all WiFi adapters (except for the Device under Test) and re-run stress.

  2. Can you connect to WiFi routers from another machine? If not, reboot the routers and try again.

  3. Can you connect to WiFi routers manually from this machine? If not, place the routers within the range of the machine and/or reset the wireless adapter.

  4. If the machine under test can manually connect to these routers, but the job continues to fail despite repeated attempts, email all of the logs, especially. all *.log and *.xml files, to Microsoft and we will assist you.)

To resolve failures in the "Run stress" task, open the log file from above and look for error messages from the bottom. If you cannot identify the root cause of failure, email all of the logs, especially. all *.log and *.xml files, to Microsoft and we will assist you.


WCN Logo Test

Type: Automated Test

Overview

The WCN Logo test tool verifies that device implements "Wi-Fi Simple Config" protocol and is interoperable with Windows Vista. The tool verifies WCN-Ethernet types of devices. WCN-Ethernet devices use UPnP protocol as the underlying transport.

The WCN Logo tool consists of two parts. One part uses Windows 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 WCN Logo tool checks both end-to-end registration process between the device and Windows Vista computer 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 is passing performance tests while working with Windows Vista computer (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 Windows Vista registrars 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 Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 ports used by UPnP standard are blocked by firewall, the devices won't be able to be discovered by Windows Vista registrars. Because of that, test tools require the firewall to be disabled at all time during tests.

The device that is tested should be connected to the same network as the Windows Vista computer on which the user is running the tests.

Because some tests use native APIs to create a wireless profile, the Windows Vista test computer needs to have a wireless card, with its drivers installed. Because "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 Windows Vista registrars will not configure an already configured device. Because of that, devices should be reset to "unconfigured" state between tests. This will require the user to intervene in 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.

Cautions

The firewall will block all the UPnP protocol traffic and all the tests will fail. Besides Windows Firewall, we advise you turn off 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 that all the files specified in Installation section of this document are placed.

All tests require a discovery for the device and the device UUID is used for discovery. The UPnP discovery application that ships with the kit provides the UUID for the device. The UUID is usually the device's GUID. In case of the discovery failure, make sure the firewall is disabled, the Ethernet cable is plugged to both the Windows Vista computer and the device, Windows Vista computer can ping the device, the device is a visible UPnP certified device (User can verify that using a tool that displays all the visible UPnP certified 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.

Reference Documentation

Wi-Fi Simple Config Proposal

Code Tour

File Manifest

File | Location
fvt.exe | <system drive>\WCNLogo
UPnP.dll | <system drive>\WCNLogo
wscutilswrapper.dll | <system drive>\WCNLogo
wcnlogoremoteobject.dll | <system drive>\WCNLogo
wcnlogotestcontroller.exe | <system drive>\WCNLogo
microsoft.wcn.config.dll | <system drive>\WCNLogo
Wireless Profiles | <system drive>\WCNLogo

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 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
Additional Information: Description: The device should be discovered by Windows Vista registrar in the given period of time. In order for the Windows 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.
Windows Vista registrar should be able to configure the device
Test Assertion GUID: 8A91B280-C2FB-485f-9101-33C1A88CE4A4
Windows Logo Program: NETWORK-0086 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
Additional Information: Description: For WCN-Ethernet device, this test verifies that the Windows 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 two 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 of device_password parameter. Procedure: The test calls Windows Vista registrar's transfer profile API to transfer profile to the device. the profile is an open authentication WEP encryption protocolExpected Result: The profile should be transferred correctly and the device should be able to access the network with the profile. Note: Simple Config compliant devices must implement proxy functionality although this is not explicitly tested in logo test suite. Shortly, proxy functionality enables the device act as a proxy between the Windows Vista registrar and another wireless enrollee. This test can be used to verify the proxy functionality if the following procedure is followed: 1) Start the AP, and plug to the same network as the Windows Vista registrar.2) Start the registrar service. At the Windows Vista computer, open a command prompt, running as administrator. Enter the following command: net start wcncsvcThis will start the registrar service if it is not already started.3) Wait for 90 seconds. This wait is required to make sure the Windows Vista registrar discovers the device and registers to the events that are sent by the device.4) Turn on the wireless device that implements Simple-Config as a wireless enrollee. Wait until the device is up and finishes its initial protocol with the AP. This takes approximately 30 seconds.5) Run the test. Use the "unique device ID" and "device password" of the wireless enrollee this time as test parameters. Test will try to configure the wireless device over the proxy. if both the device and the wireless enrollee implement the protocol correctly, the test will pass.
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 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
Additional Information: Description: Metadata should be represented correctly in messages. Also. for best experience with Windows Vista WCN wizards, the displayed device info should be correctly set. And that the device can be correctly configured by Windows Vista WCN wizard. The data displayed in wizard is manufacturer name and primary device type. Job parameters: The job requires four parameter values to be set. User should enter the device UUID in the value of device_uuid parameter. The parameter must be entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter manufacturer name and device type as the values of manufacturer_name and device_type parameters. The device type field value 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", or "Windows Mobile" The manufacturer name should exactly be the same as it is encoded in M1 message. Note that both manufacturer name and device type values are case sensitive.Procedure: This test calls discovery API and waits until the specified device is discovered. This test then queries for the manufacturer name and primary device type. Expected Result: The device should send the manufacturer name and primary device type with M1 message, and the Windows 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 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
Additional Information: Description: The device can be discovered by multiple registrars. However, after M2 reception, the device must only associate with single registrar during one configuration and registration session. If in any case, the registration fails to complete, the device must be available again for registration of other registrars. Job parameters: The job requires two parameter values to be set. User should enter the device UUID in the value of DeviceUUID parameter. The parameter must be entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter device PIN in the value 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 Windows Vista registrar during configuration. Messages sent by other registrars during configuration must be discarded and the device must either ignore or reply with a NACK message. Test involves target device (D) and two registrars (R1 and R2) Below is the expected flow of events for this test:R1 invokes GetDeviceInfo of D and D must return a correct M1R1 invokes PutMessage to send M2. D must reply back with M3R2 invokes PutMessage to send M2. D might send a NAK to this message, or terminate connection. R1 invokes PutMessage to send M4. D must reply back with M5. The configuration protocol must not be affected by the other registrars sending messages 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 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
Additional Information: Description: The device can be discovered by multiple registrars. Normally, when a registrar sends M2, it means the registrar wants to configure the device. But when a registrar sends an M2D, it means the registrar doesn't have the device password information and the message is sent so that the device is aware of the registrar. Upon receipt of M2D, the device must not expect to be configured and must not create an association. Job parameters: The job requires two parameter values to be set. User should enter the device UUID in the value of DeviceUUID parameter. The parameter must be 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. The first registrar will send an M2D. The device is expected to reply with an ACK and must not associate with this registrar. The second registrar will send an M2 and expect to receive an M3 which means the device is associated with the second registrar. Test involves target device (D) and two registrars (R1 and R2) Below is the expected flow of events for this test:R1 invokes GetDeviceInfo of D and D must return a correct M1R1 invokes PutMessage to send M2D. D can reply with an ACK message, or stay silent. It must not reply with an M3, and must be available for another configuration attemptR2 invokes GetDeviceInfo of D and D must return a correct M1R2 invokes PutMessage to send M2 and D returns M3 Expected Result: The device must respond to M2D in the proper way, and must create an association for the second registrar.
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 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
Additional Information: Description: During configuration, with the only exception of authentication errors - errors caused by device password knowledge-- device must ignore messages that contain errors. Possible errors that can happen are: out of sequence messages, missing TLV values, ill-formatted message, authenticator error, and so on. In that case the device must discard the message without replying anything and wait for a valid message without dropping the association. Job parameters: The job requires two 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. Test involves target device (D) and one registrar (R1) Below is the expected flow of events for this test:R1 invokes GetDeviceInfo of D and D must return a correct M1R1 invokes PutMessage to send M2 and D returns M3R1 invokes PutMessage to send M4. While creating M4, the control point modifies the message. It might drop a required field, the authenticator may be incorrect, or the message sent may be out of sync. Device must not terminate the configuration protocol with a NAK; it must wait for a correct message for a given time. Device must not reply with anything to this message R1 creates a correct M4 this time and send it using PutMessage to D. D must reply with M5 Expected Result: In case of an error in the message, 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 NAK immediately and drop the association and reset the state
Test Assertion GUID: 76E0EE6A-A40B-4b04-8BFF-AD28F1858051
Windows Logo Program: NETWORK-0086 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
Additional Information: Description: The device must drop the association and reset the state if it receives a message with authentication error to be protected from brute force attacks from rogue registrars which send messages using random passwords. Job parameters: The job requires two parameter values to be set. User should enter the device UUID in the value of DeviceUUID parameter. The parameter must be 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 device password and try to continue configuration with correct device password. Test involves target device (D) and two registrars (R1 and R2) Below is the expected flow of events for this test:R1 invokes GetDeviceInfo of D and D must return a correct M1R1 invokes PutMessage to send M2 and D returns M3R1 invokes PutMessage to send M4. While creating M4, the control point uses an incorrect device password. D must check the hash values and conclude that the device password knowledge is not correct. It can send a NAK, stay silent, or terminate connection. Our recommendation is D sends a NAK R2 invokes GetDeviceInfo of D and D must return a correct M1. After an unsuccessful configuration, device must be ready for a new configuration attempt without user intervention. R2 invokes PutMessage to send M2 and D returns M3 Expected Result: The second registrar trying to configure the device should succeed.
Transfer of a supported profile to the device should be completed within 2 minutes
Test Assertion GUID: BCF9F868-0A8D-410f-AFC6-D455C2948378
Windows Logo Program: NETWORK-0086 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
Additional Information: Description: The configuration should be completed in 2 minutes. Job parameters: The job requires two 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 tests if the transfer profile is completed in 2 minutes. 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 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
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 three 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.For example: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 the 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 supports. 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 Windows Vista registrar will not configure an already configured device. Expected Result: All configuration attempts should be successful.
Device should tear down association and send a NAK 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 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
Additional Information: Description: During configuration, the registrar and the device exchanges information for encryption/authentication types that they support. If the registrar doesn't support any authentication/encryption types, the configuration must be terminated with a NAK message and the association must be dropped. Job parameters: The job requires two parameter values to be set. User should enter the device UUID in the value of DeviceUUID parameter. The parameter must be entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter device PIN in the value of DevicePIN parameter. Procedure: Upon receipt of M1 message, the registrar will create an M2, such as the supported encryption/authentication type doesn't match the device capabilities. When device receives M2, it is expected to send a NAK and drop the association. Test involves target device (D) and one registrar (R1) Below is the expected flow of events for this test:R1 invokes GetDeviceInfo of D and D must return a correct M1. R1 parses DeviceInfo (M1 message), and, based on "Encryption Type Flags" and "Authentication Type Flags" values, creates an M2. The M2 message will contain "Encryption Type Flags" and "Authentication Type Flags" values that don't match the device's. If device supports all configuration mechanisms, test ends at this step with success.R1 invokes PutMessage to send M2 and D can return with a NAK, stay silent, or terminate connection. We recommend D sends a NAK. D must not send M3 to the registrar. Expected Result: After device receives M2, it must either send a NAK or terminate connection. The configuration protocol should be reset to initial state.
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 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
Additional Information: Description: During configuration, the registrar and the device create an association and the entire messages sent by other registrars will be ignored during association. To prevent DOS in case the registrar goes offline during configuration, the device must drop the association after 30 seconds passed over a valid message. Job parameters: The job requires two 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 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 occurs, test will try to continue configuration. Test involves target device (D) and two registrars (R1 and R2) Below is the expected flow of events for this test:R1 invokes GetDeviceInfo of D and D must return a correct M1R1 invokes PutMessage to send M2 and D returns M3R1 stays silent for 30 seconds ( R1 doesn't invoke any action)R1 invokes PutMessage to send M4 to D. D must ignore this message. It can send a NAK, terminate the condition, or stay silent. Our recommendation is for D to send a NAK.R2 invokes GetDeviceInfo of D and D must return a correct M1R2 invokes PutMessage to send M2 and D returns M3 Expected Result: After the timeout occurred, device must drop the association, discard all state information, and, when registrar sends the next message, the device must be available for a new configuration without user intervention.
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 Wireless Router or WLAN AP implements WCN-Ethernet and WCN-Wi-Fi
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 that displays 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.


WolWin7Pattern

Type: Automated Test

Overview

Wake on Lan (WoL) is the standand that allow a user to wake up a computer from sleep/standby state (S1, S2 or S3). The test verifies the WoL function of a miniport.

Details

Before putting a network adapter into a wake up state, the system passes to the adapter driver a list of sample frames and corresponding byte masks. Each sample frame is an example frame that should wake up the system. Each byte mask defines which bytes of the incoming frames should be compared with the corresponding sample frame in order to determine whether or not to accept the incoming frame as a wake-up event. Wake pattern is a pair of sample frame and byte mask. This test verify the correctly handling of 8 wake patterns including six win7 offload wake patterns and two random wake patterns. Six offload wake patterns are TCPv4 SYN, TCPv6 SYN, LLMNRv4, LLMNRv6, NetBIOS name query, and Neighbor Solicitation. Two random wake patterns are 128-bytes and random size patterns. The test also verify if a miniport support the storing of 6 wake patterns.

Run Time: 20 to 50 minutes
Log File: WolWin7Pattern.htm
System Restart Required: No
Test Category: automated test
Program: WolWin7Pattern.dll

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Hardware Requirements

The test tool requires the following hardware setup:

  • Two computers, one as server and one as client.

  • Each computer has two network adapters including the test target.

  • All network adapters are connected to the same network.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running WolWin7Pattern

  1. Run NDISTest.exe on server and client computers with administrator privilege.

  2. Allow the program to go through the firewall.

  3. On server NDISTest GUI, click "Server" on the "File" menu, select "Message Device" and "Support Devices", and click "Start".

  4. On client NDISTest GUI, click "Client" on the "File" menu, select "Test Target", "Test Device"and "Support Device". The "Support Devices" has to be a network adapter on server. Under "Jobs", click WolWin7Pattern, and click "start"

All test cases return PASS or FAIL. Review the test results in WolWin7Pattern.htm for specific details about failures.

The test might return SKIP if the system do not support Wake on Lan.

Command Syntax

Command option | Description
NDISTest.exe | NDISTest GUI starts

Code Tour

File Manifest

File | Location
NDISTest.exe | [testbinroot]\nttest\nettest\ndis\NDISTest.Net\
WolWin7Pattern.dll | [testbinroot]\nttest\nettest\ndis\NDISTest.Net\sdk\test\lan


Network Media Device Testing

Network Media Device Testing Overview
Preparing for Network Media Device Testing
Running the Digital Media Server Tests
Running the Digital Media Renderer and Digital Media Controller Tests
Troubleshooting Network Media Device Testing
Network Media Device Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Network Media Device Testing Overview

The procedures that are presented in this section outline the process for testing your Network Media Device for correct functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that 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 logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Network Media Device Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested.

Run time: up to 72 hours

Hardware Requirements

The following hardware is required for Network 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.

  • The device to be tested.

  • A computer with the following:
    • One x86-based or x64-based processor with a minimum speed of 450 MHz and a WinSAT CPU score of at least 5.2
    • 512 MB of RAM
    • One AGP or PCI display adapter

  • One 17-inch monitor with at least 1024x768x24 bits per pixel (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

Software Requirements

The following software is required to run the Network Media Device tests:

  • Windows 7

  • Any drivers that are not shipped with the operating system

  • The current release of the Windows Logo Kit (WLK)

Tester Knowledge Requirements

To run the Network Media Device tests, testers must know how to accomplish the following tasks:

  • Install the Network Media Device hardware

  • Install the manufacturer-supplied device driver, if necessary

  • Install the operating system from the product DVD

  • Install the WLK

This section includes:

Preparing for the Network Media Device Testing

Running the Digital Media Server Tests

Running the Digital Media Renderer and Digital Media Controller Tests

Troubleshooting the Network Media Device Testing


Preparing for Network 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, please go to Network Media Device Testing Overview.

Many of the tests in the Windows Logo 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.

Network Media Device Testing

In order to run the Network Media Device logo tests, you will need the following configuration.

Diagram illustrating the hardware configuration for network media device testing

Network Configuration

  1. Set your Windows 7 client network to Private.

  2. Set your routers IP LAN address to 192.168.0.1.

  3. Set your Windows 7 client PC LAN IP address to 192.168.0.10.

  4. Set your Windows 7 client PC Wireless IP address to 192.168.0.11.

For complete details on running the Rally tests, please go to WCN Logo Test and LLD2 Responder Verification Tests.

Server 2003 Controller Installation

The Windows DTM must be installed on Server 2003. For complete installation instructions please see Install.htm - Installation Guide

We recommend that you share out the WTTInstall folder so other PCs can install the Studio or the Client. The WTTInstall folder is located in the following location:

<DRIVE>:\Program Files\Microsoft Driver Test Manager\Controller\WTTInstall

To share out the folder, follow these steps:

  1. Right-click the folder.

  2. Choose Properties from the menu.

  3. Choose the Sharing tab.

  4. Select Share this folder. (Note The default share name will be DTMInstall.)

  5. Click OK.

Network Media Test Content Installation

Due to the size of the content files, the Network Media Test Content files are located on a separate ISO. To download the test content files, please go here

After the download, copy the test files to the Device Controller. To do this, follow these steps:

  1. The devices kit must already be installed. On the server that has the WLK controller installed, go to the following location:

    C:\Program Files\Microsoft Driver Test Manager\Tests\x86fre\NTTEST\MULTIMEDIATEST\Sharing\NetMediaLogoTests

  2. Create a new folder called Media.

  3. Copy the contents from the Media ISO CD to this new folder.

WLK Studio Installation

Most test environments do not require a separate PC to host the WLK Studio. The WLK Studio can be installed from the DTM server and controller from the following location:

<DRIVE>:\Program Files\Microsoft Driver Test Manager\Controller\WTTInstall\Studio

For complete installation instructions, please see Install.htm - Installation Guide.

WLK Client Installation

The WLK Client is the Windows 7 PC that will execute the test runs. The Windows 7 PC must be connected to the WLK Studio through a wired connection.

For complete installation instructions, please see Install.htm - Installation Guide.

Device Setup

Once the client has been successfully installed, the next step is to attach the device, if it is not attached already. Wireless devices should be connected to the router via the wireless network. Wired devices should be connected to the router via Ethernet cable.

Before testing, validate that your device is correctly discovered, and note the device identifiers. To do this, follow these steps:

  1. Type Network in the search bar of the Start menu.

  2. Click Network under Programs to open the network folder.

  3. Find your device in the network folder. If your device is not listed, then check that your network is configured correctly.

  4. Right-click your network media device to view its properties.

  5. From the Properties dialog box, note the following information:
    a. MAC Address
    • Include the colons in the address.
    • Example: 00:a0:b0:94:5b:fb
    b. Unique Identifier (UDN)
    • Include the dashes in the address.
    • Example: 4a96edf6-0aa0-11de-904a-00a0b0945bfb

  6. Write down these numbers, including the dashes and colons. You will be asked to provide this data during device testing.

Verify that your LLTD responder is working correctly

  1. Go to the Network and Sharing Center. You can access this by typing network and sharing center in the search bar of the Start menu.

  2. Click See full map.

  3. Verify that your device appears correctly in the network map.

Configure the Windows 7 Client in WLK Studio

Now that the client and server are connected, the WLK needs to be configured to run the Network Media Device tests.

Create a Machine Pool

In the studio, follow these steps to create a machine pool. (For more information, please go to Grouping Client Computers into Machine Pools.)

  1. Run the DTM Studio.

  2. On the top menu of DTM Studio, select Explorers and then Job Monitor.

  3. Create a machine pool. Right click $ and then select Add machine pool.

  4. In the Name field, type in your machine pool name.

    Note Job Delivery Agent should be set to the name of your Controller..

  5. Click OK to close the dialog.

The next step is to add your Windows 7 client PC to the machine pool.

Add your Windows 7 Machine to the Machine Pool

To add your machine to the pool, follow these steps:

  1. Run the DTM Studio

  2. On the top menu of DTM Studio select Explorers and then Job Monitor.

  3. Click Default Pool in the Machine Pool tab. Your Windows 7 PC name should appear in the Machines window.

    Note If your Windows 7 PC is not listed, please confirm that you installed the client correctly in the WLK Client installation section. For complete installation instructions on installing the WLK Client, please see Install.htm - Installation Guide

  4. Click your Windows 7 PC Client icon under Machines.

  5. Drag and drop your Windows 7 PC Client from the machines list on the right into your Machine Pool that you created earlier.

  6. Select your Machine Pool by clicking on your machine pool name in the Machine Pool tree. Your Windows 7 PC name should appear in the Machines window.

  7. Right-click your Windows 7 PC and select Change Status and then Reset. This configures your Windows 7 PC to include the MCU policy. This also resets the Windows 7 Client PC and allows it to execute the job. Notice that the Status is set to Reset.

  8. The Windows 7 PC Client will reboot as part of the configuration process. A new user account will be created on the PC for DTMLLUAdminUser.

  9. While the job is still executing, the Windows 7 PC Client Status is Running.

    Note The DTM studio does not refresh its UI automatically. You must press F5 to see the updated Status.

  10. IMPORTANT You must wait for this operation to complete before any tests may be run. The operation is complete when the Status of the Windows 7 PC Client is Ready.

  11. Continue to press F5 until the Windows 7 PC Status is Ready.

Your machine and device are now configured for test execution. You may need to do additional steps, depending on the specific Network Media Device class that you are testing.

Log in as DTMLLUAdminUser

During MCU policy installation, your Windows 7 machine will have rebooted. You should now log in as DTMLLUAdminUser. The password is Testpassword,1.

When you have logged in, set up your network to be Private. To do this, follow these steps:

  1. Go to the Network and Sharing Center. You can access this by typing network and sharing center in the search bar of the Start menu.

  2. Select View your active networks.

  3. If your network is set to Public, click the hyperlink Public and change it to Work.

  4. Click OK to close the dialog.

  5. Close the Network and Sharing Center.

Check network connections

Make sure that all network connections are set to Private in the Network Center in the Control Panel.

To make sure that your test network remains set to Private, you can set a policy to do this automatically by running gpedit.msc as an Administrator, and then modifying the settings for Unidentified Networks, as illustrated in the screenshots below.


Running the Digital Media Server Tests

To run Digital Media Server testing, you must first manually copy the test media files to the Digital Media Server.

To manually copy the media files to the Digital Media Server, follow these steps:

  1. From the Windows 7 client, locate the media files on your controller. The media can be found in the following location:

    \\<controller>\Tests\x86fre\NTTest\multimediatest\sharing\netmedialogotests\media

  2. Copy all of the files in the media folder. If the files are not present on the controller, please go to "Preparing for the Network Media Device Testing."

After you have successfully copied all of the files and folders to the DMS, ensure that they have been shared out. Failure to copy the files and folders will result in test failures. It is acceptable to have additional files on the server for testing.

To run the logo tests and create a submission cabinet file to send to WHQL for logo approval, either run the logo tests from a previously saved device job schedule file, or create a new submission. To do this, follow these steps:

  1. Run the DTM Studio

  2. Open a Device Console window from the Explorers menu.

  3. Select your DTM controller from the drop-down box at the upper left of the Device Console window.

  4. Click Submission.

  5. 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.

  6. Choose the logo tests to run. To do this, follow these steps:
    a. Select the operating system and processor architecture to test (Windows 7 Client), and then click Next.
    b. Select a submission category (Device Submission), and then click Next.
    c. Select the appropriate logo program under Network Media Device - Digital Media Server or Digital Media Server Wireless, and then click Next.
    d. Select a Qualification Level (logo), and then click Next.
    e. Enter a name for the submission, click the machine pool you created earlier, and then click Next.
    f. Select I am not providing an INF or driver package in the lower left hand corner, and then click Next.
    g. Select Device Not Listed, and then click Next.
    h. Fill in the Create New Submission form:
    • Enter your DLNA Certificate ID. Example: REGXXXXXXXX.
    • Identify if this device is a Mobile Handset.
    • Enter the MAC Address. This information was noted in Device Setup. The MAC Address must include the colons. Example: 00:a0:b0:94:5b:fb
    • Enter the discovery protocol. It should be UPnP protocol.
    • Enter the device's UPnP UUID. This should begin with uuid: (Ex: uuid: de1dec0a-9021-426c-9548-f714b5e8ef56)
    • Enter the device's WSD UUID, if applicable. This should begin with uuid: (Ex: uuid: de1dec0a-9021-426c-9548-f714b5e8ef56)
    • Enter the device's UDN or WPS (Wifi protected setup) UUID, if applicable. This information was noted in Device Setup. The unique identifier must include the dashes. Example: 4a96edf6-0aa0-11de-904a-00a0b0945bfb.

    • Enter the device's WinQual ID, also known as the vendor ID, used in your hardware ID.

      Note Failure to fill in the correct values may cause the tests to prompt you for additional input.

  7. Select and schedule logo tests. You can either:
    • Specify the tests to run.
    • Specify individual tests by expanding the Digital Media Server and Rally trees and selecting just a few tests:
      a. Click the Add Selected button.
      b. The jobs selected are displayed in the bottom pane.
      c. Click the Schedule button. The DTM will begin launching your tests.

Monitoring the logo test progress

You can monitor the testing progress from the Job Monitor. The Job Monitor is run from the Explorers menu.

  1. When the Job Monitor comes up, press F5 to refresh, and you should be able to see which test is running.

  2. By continually refreshing, you can:
    • Observe logo test progress and manually intervene if required by test.
    • 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. After the logo tests have all passed successfully, you can submit the logo test results to WHQL for approval.

Reviewing Test Errors

To evaluate your Network Media Device error, you will need to do the following.

  1. Locate the error in the Job Execution Status pane of the Job Monitor.

  2. Click the error. This will bring up the tasks in the Task Execution pane.

  3. Locate the RunNetMediaLogoTests.exe in Task Execution Status of the Job Monitor.

  4. Right-click the Run NetMediaLogoTests.exe and choose View Task Log. This will provide you with a report of the failures.


Running the Digital Media Renderer and Digital Media Controller Tests

To implement Digital Media Renderer testing, you must manually copy the media files to the Windows 7 DTM Client. To do this, follow these steps:

  1. From the Windows 7 client, locate the media files on your controller. The media can be found in the following location:

    \\<controller>\Tests\x86fre\NTTest\multimediatest\sharing\netmedialogotests\media

  2. Copy all of the files in the media folder to a folder to be shared out. For example: C:\WLKContent

    Note If the files are not present on the controller, please go to "Preparing for the Network Media Device Testing"

  3. Share out the copied files. Right-click the folder you created (for example: C:\WLKContent) and select Include in Library.

  4. Select Music, and repeat the steps for Pictures and Videos.

  5. Run Windows Media Player and ensure that streaming is enabled.

  6. To enable streaming, from the Stream menu, select Turn on media streaming...

  7. Click Turn on media streaming.

To run the logo tests and create a submission cabinet file to send to WHQL for logo approval, either run the logo tests from a previously saved device job schedule file, or create a new submission. These procedures are as follows:

Use the Create New Submission Wizard to Select and Run Logo Tests

  1. Run the DTM Studio

  2. Open a Device Console window from the Explorers menu.

  3. Select your DTM controller from the drop-down box at the upper left of the Device Console window.

  4. Click the Submission drop down.

  5. 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.

  6. Choose the logo tests to run:
    a. Select the operating system and processor architecture to test, and then click Next.
    b. Select a submission category, and then click Next.
    c. Select the appropriate logo program under Network Media Device - Digital Media Renderer or Digital Media Renderer Wireless, and then click Next.
    d. Select a Qualification Level, and then click Next.
    e. Enter a name for the submission, click the machine pool you created earlier, and then click Next.
    f. Select I am not providing an INF or driver package in the lower left hand corner, and then click Next.
    h. Select the Device Not Listed box, and then click Next.
    h. Fill in the Create New Submission form:
    • Enter your DLNA Certificate ID. The format should look like: REGXXXXXXXX.
    • If your device supports Windows Media Audio or Video, then your device must use a certified chip. Enter the Microsoft IC Certified Decoder ID in this box. If your device does not support Windows Media formats, n/a.
    • Specify if you device supports WMA, WMV, neither, or both.
    • Identify if the device supports remote volume control.
    • Specify if the device supports Windows Media DRM Link Protection.
    • Specify if the device is also a DMP or can work as a DMC (does the DMR include a MSCP enabling user control?).
    • Enter the MAC Address. This information was noted in Device Setup. The MAC Address must include the colons. For example: 00:a0:b0:94:5b:fb
    • Enter the discovery protocol. It should be UPnP protocol.
    • Enter the device's UPnP UUID. This should begin with uuid: (Ex: uuid: de1dec0a-9021-426c-9548-f714b5e8ef56)
    • Enter the device's WSD UUID, if applicable. This should begin with uuid: (Ex: uuid: de1dec0a-9021-426c-9548-f714b5e8ef56)
    • Enter the device's UDN or WPS (Wifi protected setup) UUID, if applicable. This information was noted in Device Setup. The unique identifier must include the dashes. Example: 4a96edf6-0aa0-11de-904a-00a0b0945bfb.

    • Enter the device's WinQual ID, also known as the vendor ID, used in your hardware ID.

      Note Failure to fill in the correct values may cause the tests to prompt you for additional input.

  7. Click NEXT on the additional qualifications.

  8. Click FINISH to close the dialog.

  9. Select and schedule logo tests:
    a. Select the "Available Jobs" specified for your Windows Client.
    b. Click Add Selected.
    c. the jobs selected are displayed in the bottom pane.
    d. Click Schedule.
  10. Monitor logo test progress:
    • Observe logo test progress by using Job Monitor, and manually intervene if required by test.
    • 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.

Reviewing Test Errors

To evaluate your Network Media Device error, you will need to do the following.

  1. Locate the error in the Job Execution Status pane of the Job Monitor.

  2. Click the error. This will bring up the tasks in the Task Execution pane.

  3. Locate the RunNetMediaLogoTests.exe in Task Execution Status of the Job Monitor.

  4. Right-click the Run NetMediaLogoTests.exe and choose View Task Log. This will provide you with a report of the failures.

Running the Rally LLTD and WCN Tests

In order to implement the Rally tests, it is important to make sure your network is configured correctly. The LLTD test will turn wireless on and off, and it uses the specified IP addresses to ensure its success. Failure to configure your network correctly will cause LLTD failures.

As specified in the Network Configuration, set the following:

  1. Set your Windows 7 client network to Private.

  2. Set your routers IP LAN address to 192.168.0.1.

  3. Set your Windows 7 client PC LAN IP address to 192.168.0.10.

  4. Set your Windows 7 client PC Wireless IP address to 192.168.0.11.

For complete details on running the Rally tests, please go to WCN Logo Test and LLD2 Responder Verification Tests.


Troubleshooting Network Media Device Testing

When running the tests individually, you can avoid pop up dialogs on the Windows 7 Client if you fill in the NetMediaLogoTest.XML.

The XML file is located in the following location:

<drive>:\Program Files\Microsoft Driver Test Manager\ tests\x86fre\NTTest\multimediatest\sharing\netmedialogotests

(Where x86fre is the platform you are testing)

The XML contains the following fields that can be edited:

<DigitalMediaServerUdn>udn</DigitalMediaServerUdn>

Where the UDN is the unique identified ID of the server for testing. This should only be specified for DMS testing. The UDN must include the dashes.

For example: 4a96edf6-0aa0-11de-904a-00a0b0945bfb

Changing this value for DMR testing may cause failures in testing.

<DigitalMediaRendererUdn>udn</DigitalMediaRendererUdn>

Where the UDN is the unique identified ID of the server for testing. This should only be specified for DMR testing. The UDN must include the dashes.

For example: 4a96edf6-0aa0-11de-904a-00a0b0945bfb

<DLNACertificationID>string</DLNACertificationID >

Where the string value is the certificate ID of the device to be tested.

<DmsMhdCertified>no</DmsMhdCertified>

This value specifies if the server is a mobile hand held device. Valid values are "yes" and "no".

<DMR_AudioCapable>no</DMR_AudioCapable >

This value specifies if the device supports volume control either via remote or physical device. Valid values are "yes" and "no".

Common Problems to All Devices

  • "The <device> could not be located."

    If all of your NMD tests report "The <device> could not be located," this generally means that you did not enter the UUID correctly in the Device Console. You can confirm this by reviewing the test log in the job explorer. Confirm that the UUID of the device that is discovered matches the one that the test was searching for.

    To fix this problem, you must create a new submission and enter the correct data when prompted in the wizard.

  • "The media file <name> could not be found on the local DMS"

    If you encountered this error, you may have failed to copy the content to the DMS. To fix this, ensure that you have obtained the test content as specified in "Preparing for the Network Media Device Testing." Also, ensure that you have copied the test content to the server, as specified in "Running the Digital Media Server Tests" and "Running the Digital Media Renderer and Digital Media Controller Tests."

  • All LLTD tests fail

    If you have implemented LLTD correctly, the failures are generally caused by your DTM configuration. Errors can occur in testing if there are multiple network cards, and they are not configured correctly.


Network Media Device Tests

Digital Media Server Tests

NETMEDIA-0002

Overview:

This test verifies whether the device under test (DUT) is a DLNA-certified Digital Media Server (DMS).

Details:

As part of configuring the DMS tests, the setup page asks the user to type the DLNA Certificate ID.

Note If the test is run individually from Job Explorer, the test is manual, and the Windows 7 client is prompted to enter the DLNA Certificate ID.

NETMEDIA-0008

Overview:

This test validates that the DMS device under test (DUT) has provided pnpx-ssdp schema support.

Details:

The pnpx:X_hardwareId, pnpx:X_compatibleId, pnpx:X_deviceCategory, and df:X_deviceCategory metadata elements must be included in the UPnP DDD of a DMS. See the following code example for element details:

<pnpx:X_hardwareId>
 VEN_XXXX&DEV_YYYY&REV_ZZ VEN_0033&DEV_0001&REV_01
</pnpx:X_hardwareId>

<pnpx:X_compatibleId>
 MS_DigitalMediaDeviceClass_DMS_V001
</pnpx:X_compatibleId>

<pnpx:X_deviceCategory>
 MediaDevices
</pnpx:X_deviceCategory>

<df:X_deviceCategory>
 Multimedia.DMS
</df:X_deviceCategory>

The XML namespace (XMLNS) declaration for PNPX and DF should be placed in the root element as shown in the following example:

<root xmlns="urn:schemas-upnp-org:device-1-0"
 xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/11"

xmlns:df="http://schemas.microsoft.com/windows/2008/09/devicefoundation"

NETMEDIA-0011

Overview:

This manual test validates that if the DMS device under test (DUT) supports Wake on Lan (WoL), it can be awakened and responds by sending five ALIVE messages within 20 seconds.

Details:

This is manual test that requires you put the DMS to sleep, if the device supports sleep. After the DMS is asleep, the test performs an M-SEARCH discovery to determine that the device is no longer discoverable. When the DMS cannot be found, the test attempts to send five WoL packages. The test then waits 20 seconds. After 20 seconds, the test issues three M-SEARCH requests, each three seconds apart, to rediscover the DMS. If the DMS is discovered, the test tries to find and stream one audio, one video, and one image file.

NETMEDIA-0017

Overview:

This manual test verifies whether the DMS device under test (DUT) provides a valid URI to a valid Web page that can be used to change the friendly name of the device.

Details:

The test completes the following steps:

  1. Downloads the device description document of the device under test.

  2. Tries to find the presentation URL entry in the DDD.

  3. Tries to validate the URL by downloading the page.

  4. If the URL is valid, the test loads the page in Internet Explorer and prompts the user to change the friendly name.

  5. When the name is changed, the test rediscovers the device under test and verifies whether the name was changed.

NETMEDIA-0021

Overview:

The test verifies if the DMS device under test (DUT) can stream Windows Media video formats.

Details:

The test completes the following steps:

  1. Discovers the required content on the DMS.

  2. For each file, verifies the DLNA PN, resolution, duration, and size.

  3. Tries to stream the content by using a HTTP GET request.

  4. Passes a request for the HTTP header contentfeatures.dlna.org

  5. Validates that the DMS is able to stream the content and verifies that the HTTP header contentfeatures.dlna.org was received as part of the HTTP GET response.

NETMEDIA-0022

Overview:

The test verifies whether the DMS device under test (DUT) can stream Windows Media audio formats.

Details:

The test completes the following steps:

  1. Discovers the required content on the DMS.

  2. For each file, verifies the DLNA PN, duration, and size.

  3. Tries to stream the content by using a HTTP GET request.

  4. Passes a request for the HTTP header contentfeatures.dlna.org.

  5. Validates that the DMS is able to stream the content and verifies that the HTTP header contentfeatures.dlna.org was received as part of the HTTP GET response.

NETMEDIA-0026

Overview:

This test verifies whether the DMS device under test (DUT) supports search capabilities.

Details:

This test queries the server for known metadata properties that are affiliated with the media files that are copied to the server in the test preparation phase.

NETMEDIA-0029

Overview:

This test verifies whether or not the DMS device under test (DUT) shares album art images as photos.

Details:

This test queries the server for photos. It verifies that the album art images that are provided to the server in the test preparation phase are not returned.

NETMEDIA-0032

Overview:

This test verifies whether the DMS device under test (DUT) provides the required metadata fields.

Details:

This test queries the server for images, videos, and audio, looking for specific metadata.

NETMEDIA-0036

Overview:

This test verifies whether the DMS device under test (DUT) correctly supports MP3 files.

Details:

The test completes the following steps:

  1. Discovers the required content on the DMS.

  2. For each file, verifies the DLNA PN, duration, and size.

  3. Tries to stream the content by using a HTTP GET request

  4. Passes a request for the HTTP header contentfeatures.dlna.org.

  5. Validates that the DMS is able to stream the content and verifies that the HTTP header contentfeatures.dlna.org was received as part of the HTTP GET response.

NETMEDIA-0037

Overview:

This test verifies whether the DMS device under test (DUT) correctly supports MP4 files.

Details:

The test completes the following steps:

  1. Discovers the required content on the DMS.

  2. For each file, the test verifies the DLNA PN, resolution, duration, and size.

  3. Tries to stream the content by using a HTTP GET request.

  4. Passes a request for the HTTP header contentfeatures.dlna.org.

  5. Validates that the DMS is able to stream the content and verifies that the HTTP header contentfeatures.dlna.org was received as part of the HTTP GET response.

NETMEDIA-0039

Overview:

This test verifies whether the DMS device under test (DUT) correctly supports AVI files.

Details:

The test completes the following steps:

  1. Discovers the required content on the DMS.

  2. For each file, the test verifies the resolution, duration, and size.

  3. Tries to stream the content by using a HTTP GET request

  4. Passes a request for the HTTP header contentfeatures.dlna.org.

  5. Validates that the DMS is able to stream the content and verifies that the HTTP header contentfeatures.dlna.org was received as part of the HTTP GET response.

NETMEDIA-0043

Overview:

This test verifies whether the DMS device under test (DUT) correctly supports MP4 audio.

Details:

The test completes the following steps:

  1. Discovers the required content on the DMS.

  2. For each file, the test verifies the DLNA PN, resolution, duration, and size.

  3. Tries to stream the content by using a HTTP GET request.

  4. Passes a request for the HTTP header contentfeatures.dlna.org.

  5. Validates that the DMS is able to stream the content and verifies that the HTTP header contentfeatures.dlna.org was received as part of the HTTP GET response.

NETMEDIA-0047

Overview:

This test verifies whether the DMS device under test (DUT) can stream supported media for 24 hours.

Details:

This test tries to play supported media content for 24 hours uninterrupted.

NETMEDIA-0049

Overview:

This test verifies whether the DMS device under test (DUT) correctly supports JPEG files.

Details:

The test completes the following steps:

  1. Discovers the required content on the DMS.

  2. For each file, the test verifies the DLNA PN, resolution, and size.

  3. Tries to stream the content by using a HTTP GET request.

  4. Passes a request for the HTTP header contentfeatures.dlna.org.

  5. Validates that the DMS is able to stream the content and verifies that the HTTP header contentfeatures.dlna.org was received as part of the HTTP GET response.

NETMEDIA-0053

Overview:

This test verifies whether the DMS device under test (DUT) can stream high definition content.

Details:

This test tries to play various HD content.

NETMEDIA-0054

Overview:

This test verifies whether the DMS device under test (DUT) can support multiple HTTP connections.

Details:

This test tries to stream two media files at the same time.

NETMEDIA-0059

Overview:

This test verifies whether the DMS device under test (DUT) will provide album art to DMPs.

Details:

This test browses the server, looking for known music. The test validates that the album art is returned to the server on browse requests and play requests. The test verifies by using WMA, MP3, and M4A files with embedded and non-embedded album art.

NETMEDIA-0060

Overview:

This test verifies if the DMS device under test (DUT) will provide the DLNA specified thumbnail for images.

Details:

This test validates that for the provided images, the server returns the JPEG_TN as defined in the DLNA specification.

NETMEDIA-0061

Overview:

This test verifies whether the DMS device under test (DUT) will provide the DLNA specified thumbnail for videos.

Details:

This test validates that for a specific video file, the server returns the JPEG_TN as defined in the DLNA specification.

NETMEDIA-0066

Overview:

This test verifies whether the DMS device under test (DUT) supports seek requests.

Details:

The test checks whether the DMS supports byte-based or time-based seek requests. The test tries to seek by using each method that is provided by the DMS. The test fails if there is no support for seek for these file types.

NETMEDIA-0078

Overview:

This test verifies whether the DMS device under test (DUT) declares support for low power mode.

Details:

This test queries the DDD to determine whether the server supports low power mode. The device must provide the following XML:

<Microsoft:magicPacketWakeSupported
 Xmlns:Microsoft="urn:schemas-microsoft-com:WMPNSS-1-0">
VALUE
</Microsoft:magicPacketWakeSupported >

The value can be 1 or 0 depending on whether the DMS supports low power. If you do not provide this XML, by default you specify a value of 0.

Digital Media Controller Tests

NETMEDIA-0004

Overview:

This test verifies whether the device under test (DUT) is a DLNA certified Digital Media Controller (DMC).

Details:

As part of configuring the DMC tests, the setup page asks the user to type the DLNA Certificate ID.

Note If the test is run individually from Job Explorer, the test is manual, and the Windows 7 client is prompted to enter the DLNA Certificate ID.

NETMEDIA-0074

Overview:

This test verifies whether the device under test (DUT) supports waking a device that is in sleep mode.

Details:

This is a manual test. The Windows 7 client computer goes to sleep, and the DMC must be capable of waking the computer.

Digital Media Renderer Tests

NETMEDIA-0001

Overview:

This test verifies whether the device under test (DUT) uses Microsoft certified WMA/WMV IC decoders. The test is applicable only for devices that support audio playback in WMA, WMV, or both.

Details:

As part of configuring the DMR tests, the setup page asks the user to type the certified IC that is used for the device. For more information about IC, see http://wmlicense.smdisp.net/ic_approved.

Note If the test is run individually from Job Explorer, the test is manual, and the Windows 7 client is prompted to enter IC.

This test also validates that WMA and WMV profiles are supported and validates that the device can correctly play those profiles.

The test tries to render on the DMR any of the WMA or WMV profiles that the device claims support for. If the device specifies a "*" instead of the DLNA PN, the test renders all the known DLNA WMA or WMV profiles to the DMR.

NETMEDIA-0003

Overview:

This test verifies whether the device under test (DUT) is a DLNA-certified Digital Media Renderer (DMR).

Details:

As part of configuring the DMR tests, the setup page asks the user to type the DLNA certificate ID.

Note If the test is run individually from Job Explorer, the test is manual, and the Windows 7 client is prompted to enter the DLNA Certificate ID.

NETMEDIA-0009

Overview:

This test validates that the DMR has provided pnpx-ssdp schema support.

Details:

The test validates that the DMR provides the following metadata in its DDD:

The pnpx:X_hardwareId, pnpx:X_compatibleId, pnpx:X_deviceCategory and df:X_deviceCategory metadata elements must be included in the UPnP DDD of a DMR. See the following example for element details:

<pnpx:X_hardwareId>
 VEN_XXXX&DEV_YYYY&REV_ZZ VEN_0033&DEV_0006&REV_01
</pnpx:X_hardwareId>

<pnpx:X_compatibleId>
 MS_DigitalMediaDeviceClass_DMR_V001
</pnpx:X_compatibleId>

<pnpx:X_deviceCategory>
 MediaDevices
</pnpx:X_deviceCategory>

<df:X_deviceCategory>
 Multimedia.DMR
</df:X_deviceCategory>

The XML namespace (XMLNS) declarations for PNPX and DF should be placed in the root element as shown in the following example:

<root xmlns="urn:schemas-upnp-org:device-1-0"
 xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/11"

xmlns:df="http://schemas.microsoft.com/windows/2008/09/devicefoundation"

NETMEDIA-0012

Overview:

This test verifies whether the DMR device under test (DUT) can wake up a sleeping DMS by using Wake on LAN (WoL) capability.

Details:

This is a manual test for DMRs that also implement a Media Server Control Point. If the device also implements a Media Server Control Point, the computer running Windows 7 is forced into sleep mode. When the computer is in sleep mode, use the device's control point to wake the Windows 7 computer.

The Windows 7 DTM Client computer must have a wired connection to the network and the NIC must be enabled for WoL.

NETMEDIA-0018

Overview:

This manual test verifies whether the DMR device under test (DUT) provides a valid URI to a Web page that can be used to change the friendly name of the device.

Details:

The test completes the following steps:

  1. Downloads the device description document for the device under test.

  2. Tries to find the presentation URL entry in the DDD.

  3. Tries to validate the URL by downloading the page.

  4. If URL is valid, loads the page in Internet Explorer, and prompts the user to change the friendly name.

  5. When the name is changed, the test rediscovers the device under test and verifies whether the name was changed.

NETMEDIA-0025

Overview:

This test verifies whether the DMR device under test (DUT) can select a suitable resolution element for the device from many elements.

Details:

This test provides the DMR with a URL to play. The URL provides a series of RES elements. The native format of the URL that is provided cannot be played by the device. The device needs to skip this RES element and choose from one of the other RES elements to play. The test validates that the DMR goes into a playback state.

NETMEDIA-0041

Overview:

This test verifies whether the DMR device under test (DUT) returns an error and goes to a STOP state when a file cannot be played.

Details:

The test simulates the following error situations:

  • No DMS on the network: The DMS is no longer available on the network. This scenario might happen if the server is either shut down, asleep, or disconnected from the network. The DMR gets the URI and a playback request, but any request to the server times out.

  • Invalid URI: The DMS is available on the network, but the URI is no longer valid. This scenario can happen if the media item that was sent for playback was removed from the server.

  • Access denied: The DMS is available on the network, and the DMC computer has access to the DMS, but the DMR does not have access to this server. In this case, the DMR will get a valid URI for playback, but the server will not allow access to that content.

NETMEDIA-0042

Overview:

This test verifies that the DMR device under test (DUT) that is published on the network is capable of rendering streams.

Details:

This test validates that a discovered DMR is able to render streams. The manual test for this requirement is to verify that if the device supports multiple modes, when the device is booted in another mode, it either does not publish itself or can switch back and render content when requested by the DMC.

NETMEDIA-0048

Overview:

This test verifies that the DMR device under test (DUT) can stream for 24 hours without user input.

Details:

This test streams 24 hours of supported content to the DMR. The DMR must remain in an active playing state for the duration of the test. The test tries to render various media formats, native and transcoded, depending on the DMR capabilities.

NETMEDIA-0050

Overview:

The DMR must be able to receive a DIDL-Lite with at least 50 RES elements and metadata inclusively. For memory constrained devices, the DMR might need to drop some RES elements, but the device must successfully play the content.

Details:

This test sends a DIDL-Lite with at least 50 RES elements and metadata to the device. The test verifies that the device is still responsive following this test.

NETMEDIA-0051

Overview:

If the device supports WMDRM-ND Link Protection System, this test validates WMDRM-ND functionality.

Details:

This test tries to play a WMDRM protected file on the device. It then verifies that the DMR will successfully play back DRM content with no additional user input. This test is only for devices that support Windows Media DRM-ND.

NETMEDIA-0057

Overview:

The DMR must be able to receive a SetAVTansportURI while in a playing state, and it should start playback of the new item without requiring any other play request.

Details:

This test sends a SetAVTansportURI while the device is currently in a playing state. The test validates that the device begins playback of the new item, without another play request being required.

NETMEDIA-0062

Overview:

When the DMR playback has finished playback or enters a stopped state, if the DMR receives a play request, the DMR must restart playback from time 0 without requiring another SetAVTansportURI.

Details:

This test validates that the device that is entering a stopped state accepts a play request, and replays the item previously entered in the SetAVTansportURI.

NETMEDIA-0070

Overview:

This test verifies that the DMR device under test (DUT) can seek video streams if the device supports video.

Details:

If the DMR supports video playback, the DMR is tested to validate seek functionality. If the DMR supports seek functionality, the device will pass this test.

NETMEDIA-0071

Overview:

This test verifies that the DMR device under test (DUT) can pause the audio and video streams.

Details:

The DMR is asked to pause a video and or an audio file, depending on the device capabilities. To pass this test, the device must report back that the content was paused.

NETMEDIA-0072

Overview:

This test verifies that the DMR device under test (DUT) for devices that support volume control also conform to the DLNA requirement for renderer volume control.

Details:

As part of the setup for this device, identify whether the device can be controlled by using an external remote. If the device does support the external volume control, the test validates this by playing a series of files and adjusting the volume.

NETMEDIA-0075

Overview:

This test verifies that the DMR devices under test (DUT) that support a Media Server Control Point and metadata update also UpdateObject within .5 seconds.

Details:

This is a manual test only for DMRs that also implement a Media Server Control Point and metadata edit. During this manual test, the device is prompted to change the ratings on a given file. Success is obtained when the device reports the change by using the UpdateObject.


Portable Devices Testing

This section describes how to test Portable Devices in order to qualify them for Windows Logo Program certification.

It includes the following topics:

  • Portable Devices: General Testing Overview

  • Digital Still Camera Testing Overview

  • Portable Media Player Testing Overview

  • Cellular Handset Testing Overview

  • Portable Media Devices Tests

  • Other Portable Testing Overview

  • Portable Devices Tests

See the following sections to ensure that your device is tested completely in accordance with the published logo requirements for Portable Devices:

  • Bus and Controller Testing

  • Device Fundamental Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Portable Devices: General Testing Overview

The procedures presented in this section outline the general process for testing your Portable Media Device for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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.

For specific requirements about testing a Portable Media Device over Terminal Server, see Terminal Server PNP Redirection Testing Overview.


Preparing for Portable Device Testing

Before running the portable media device tests, you must configure the system and install the operating system. This section summarizes additional related procedures.

Test system configuration

To prepare your machine pool to run Portable Media Device tests, you need to first set the logo test dimension. Setting the logo test dimension allows you to dedicate a machine pool for testing a Portable Media Device. For information on creating a machine pool, see Grouping Client Computers into Machine Pools. Setting the test dimension will only need to be performed once for each machine pool that you create. From the Driver Test Manager (DTM) studio:

  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. Create a Machine Pool and move the test clients to that pool.

For additional testing requirements, see the specific device under test topics that follow.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Cellular Handset Testing

Cellular Handset Testing Overview

Preparing for Cellular Handset Testing

Running the Cellular Handset Tests

Troubleshooting Cellular Handset Testing


Cellular Handset Testing Overview

The procedures presented in this section outline the process for testing your Cellular Handset for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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

Cellular Handset Testing Overview

Preparing for Cellular Handset Testing

Running the Cellular Handset Tests

Troubleshooting Cellular Handset Testing

Cellular Handset Tests

The list of tests needed to be run depends 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 Running the Cellular Handset Tests.

Run time: Approximately 24-48 hours

Hardware requirements

The following hardware is required for Cellular Handset 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.

  • System that supports USB 2.0

  • A USB cable for the device you are testing

  • For the Windows Vista Client Cellular Phone Logo, in order to also run the Terminal Server Plug and Play (PnP) tests, two computers running Windows Vista are required. These two computers need to be of the same processor architecture (either x86 or amd64), and both need to have either an internal or external USB port connected. USB 2.0 is recommended.

Other Device Requirements

The following is required to run the Cellular Handset device testing component of the WLK:

Note There are specific tests that apply only to Cellular Handsets devices that install third-party (vendor-supplied) WPD drivers. If you are not providing a WPD driver for your Cellular Handset device, you are not required to run these tests for your device, even though the jobs might appear in the Device Console.

  • For Windows XP and Windows SP2, your device must appear under the Windows Portable Devices category in Device Manager.

  • For Windows Vista and later versions, your device must appear under the Portable Devices category in Device Manager.

  • Windows 7 devices must install with the Microsoft Media Transfer Protocol class driver. The device must connect to the PC in MTP Mode during testing.

  • The battery on the device should be fully charged before testing is started.

  • Some PTP or MTP devices are required to include sample content on the devices local storage before testing. If your devices meets any of the following criteria, include sample content on the device for each of the formats that the device supports to complete testing:
    • Device under test has a DCF compatible file system.
    • Device has read only stores.
    • Device does not support SendObject and SendObjectInfo.
    • Device does not support SendObject and SendObjectPropList

  • If the device supports removable media, the media must be added before testing.

Software requirements

The following software is required to run the Cellular Handset tests:

  • On Windows XP with Service Pack 2 (SP2), you must have the Windows Portable Devices and the User Mode Driver Framework binaries installed.

    Note If you are not sure whether or not you have these binaries installed on the client computer or you do not know how to install them, you can install Windows Media Player 11, which installs the binaries.

  • For Windows Vista Basic logo, the driver that came with your Windows Portable Devices cellular phone. The driver installation file (INF) must install the device as a WPD class with the following ClassGUID:
    • Class=WPD
    • ClassGUID={EEC5AD98-8080-425f-922A-DABF3DE3F69A}

Tester knowledge requirements

To run the Cellular Handset tests, testers must know how to accomplish the following tasks:

  • Switch a device to a computer connectivity mode before plugging it in.

  • Plug a device into a USB port of the computer and maintain the connectivity throughout the test run.

  • Provide continuous power to the device during throughout 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.


Preparing for Cellular Handset 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 Cellular Handset Testing Overview.

Test system configuration

Refer to Using DTM for Logo Testing for detailed instructions on test system configuration.


Running the Cellular Handset Tests

Logo Program: Windows Vista Client - Basic (x86, x64) and the Windows XP (x86) Logos

  1. Connect your Cellular Phone Device to the DTM Test Client Machine.

  2. Install your Cellular Phone Driver for the device under test on the Test Client Machine.

  3. From DTM studio, go to Explorers Device Console. Select your Machine Pool from the drop down list. Select View By Machine and then locate your device in Available Devices.
    • If DTM Studio is running on Windows Vista Ultimate, your device can found under Portable Devices.
    • If DTM Studio is running on Windows XP or other SKUs of Windows Vista, your device can be found under WPD. Because WPD is a relatively new device class, you may see a generic icon associated with the device node.
  4. Ensure that your device is powered on and registered in Device Console.
    • Right-click the device and select View Device XML. Verify the entries such as DeviceID, DriverDate, DriverVersion, and ImagePath for your driver and device.
    • If your device does not appear or if you are seeing stale entries for previously connected devices, you may need to wait a few minutes and refresh the Device Console and/or reconnect the device.

  5. For Windows Vista Client (x86, x64), repeat steps 1 through 4 for one additional machine with an identical device. You need to setup two machines to complete the TS Plug and Play Redirection tests as part of your current submission.

  6. Create a new submission:
    a. From Device Console, select View By Submission.
    b. From the Submission drop down list, select <New Submission>.
    c. Select OS from the available options.
    d. Select Category: Device Submission.
    e. In the Create New Submission dialog box, select Portable Devices > Cellular Handsets.
    f. In the Create New Submission dialog box, select Basic under Qualification Level.
    g. Enter a name for your submission, and select your machine pool.
    h. Driver Install File (INF) [Required for submission]:
    • For Windows Vista Client Logo, browse and load both the driver and the TS-redirection driver INF files. The version numbers must match exactly with what you have installed on the DTM client test machines.
    • For Windows XP Logo, browse and load the driver INF file. The version number must match exactly with what you have installed on the DTM client test machine. The TS-redirection INF is not required.
    i. Click Finish to complete and load the new submission.

  7. Depending on how your INF file is authored, you may see multiple entries for your device. For the Windows Vista Client submission, select the device entry that corresponds to the driver INF, not the TS-redirection driver INF. For your convenience, one way to differentiate between the driver and the TS-redirection INF files is to author them with slightly different DriverVer or Manufacturer entries.

  8. With the correct device selected, from the Available Jobs, you can now add jobs from the first Cellular Handsets category. If your device connects via USB, you will see USB jobs in addition to the WPD Compliance Tests jobs. For requirements on running these jobs, please see Supplemental Tests or view the job details in Job Explorer.

    See the table below for a list of applicable jobs.

Logo Program: Windows Vista Client - Premium (x86, x64) and Windows 7 (x86, x64) Logos

  1. Connect a MTP Cellular Handset to the DTM Test Client Machine.

    Note If the device supports mode switching, make sure that the device is in a mode that uses MTP.

  2. From DTM studio, go to Explorers Device Console. Select your Machine Pool from the drop down list. Select View By Machine and then locate your device in Available Devices. Your device can found under Portable Devices.

  3. Ensure that your device is powered on and registered in Device Console.
    • Right-click the device and select View Device XML. Verify the entries such as ModelID, DeviceID, and ImagePath for your driver and device.
    • If your device does not appear or if you are seeing stale entries for previously connected devices, you may need to wait a few minutes and refresh the Device Console and/or reconnect the device.

  4. For Windows Vista Client (x86, x64), repeat steps 1 through 4 for one additional machine with an identical device. You need to setup two machines to complete the TS Plug and Play Redirection tests as part of your current submission.

  5. Create a new submission:
    a. From Device Console, select View By Submission.
    b. From the Submission drop down list, select <New Submission>.
    c. Select OS from the available options.
    d. Select Category: Device Submission.
    e. In the Create New Submission dialog box, select Portable Devices > Cellular Handsets.

    f. In the Create New Submission dialog box under Qualification Level, select Premium for Windows Vista or Logo for Windows 7.

    Note that if you are planning to submit for an Additional Qualification, that submission type may appear.

    g. Enter a name for your submission, and select your machine pool.
    h. Click Finish to complete and load the new submission.

  6. With the correct device selected, from the Available Jobs, you can now add jobs from the first Cellular Handsets category. If your device connects via USB, you will see USB jobs in addition to the WPD Compliance Tests jobs. For requirements on running these jobs, please see Portable Media Devices Tests or view the job details in Job Explorer.

The following table indicates which jobs are required based on connectivity type that must be run:

Test Name | Windows XP |  |  |  | Windows Vista |  |  |  | Windows 7
 | USB | BT | IP | Other | USB | BT | IP | Other | USB | BT | IP | Other
Connectivity Tests - PCI
PCI Hardware Compliance Test For a Single Device (PCIHCT) |  |  |  |  |  |  |  |  |  |  |  | X
Connectivity Tests - USB
USB Address Description Test (Automated) | X |  |  |  | X |  |  |  | X |  |  |
USB Descriptor test (Automated) | X |  |  |  | X |  |  |  | X |  |  |
USB Device Control Requests (Automated) | X |  |  |  | X |  |  |  | X |  |  |
USB Enumeration Stress (Automated) | X |  |  |  | X |  |  |  | X |  |  |
USB Selective Suspend (Automated) | X |  |  |  | X |  |  |  | X |  |  |
USB Specification Compliance (Automated) | X |  |  |  | X |  |  |  | X |  |  |
USB Isochronous Alternate Interface Presence (Automated) | X |  |  |  | X |  |  |  | X |  |  |
USB HIDView (CV) (Manual) | X |  |  |  | X |  |  |  | X |  |  |
USB Device Framework (CV) (Manual) | X |  |  |  | X |  |  |  | X |  |  |
USB Serial Number (Automated) | X |  |  |  | X |  |  |  | X |  |  |
USB System Suspend Resume Test | X |  |  |  | X |  |  |  | X |  |  |
USB Disable Enable (Automated) |  |  |  |  | X |  |  |  | X |  |  |
Connectivity Test - 1394
1394 Industry Certification Test ID Entry (MANUAL) |  |  |  |  |  |  |  | X |  |  |  | X
Device Fundamentals Tests
Web Services for Devices |  |  |  |  | X | X | X |  | X | X | X |
Run INFTest against a single INF | X | X | X |  | X | X | X |  | X | X | X |
Device Path Exerciser | X | X | X |  | X | X | X |  | X | X | X |
Plug and Play Driver Test | X | X | X |  | X |  |  |  | X |  |  |
Concurrent Hardware And OS Test (CHAOS) |  |  |  |  | X |  |  |  | X |  |  |
Embedded Signature Verification |  |  |  |  | X |  |  |  | X |  |  |
WDF Logo Tests |  |  |  |  | X |  |  |  | X |  |  |
Sleep Stress With IO | X |  |  |  | X |  |  |  | X |  |  |
Disable Enable With IO | X |  |  |  | X |  |  |  | X |  |  |
Common Scenario Stress With IO | X |  |  |  | X |  |  |  | X |  |  |
Reinstall With IO |  |  |  |  | X |  |  |  | X |  |  |
Portable Devices Tests for Cellular Handset
WPD Compliance Tests - ALL SERVICES |  |  |  |  |  |  |  |  | X | X | X |
WPD Compliance Tests - CONTACT SERVICE |  |  |  |  |  |  |  |  | X | X | X |
WPD Compliance Tests - METADATA SERVICE |  |  |  |  |  |  |  |  | X | X | X |
WPD Compliance Tests - HINTS SERVICE |  |  |  |  |  |  |  |  | X | X | X |
WPD Compliance Tests - MODEL_ID |  |  |  |  |  |  |  |  | X | X | X |
WPD Compliance Tests - FUID |  |  |  |  |  |  |  |  | X | X | X |
WPD Compliance Tests - NOTES SERVICE |  |  |  |  |  |  |  |  | X | X | X |
WPD Compliance Tests - RINGTONE SERVICE |  |  |  |  |  |  |  |  | X | X | X |
WPD Compliance Tests - STATUS SERVICE |  |  |  |  |  |  |  |  | X | X | X |
Verify Portable Media Device correctly supports Selective Suspend (MANUAL) |  |  |  |  |  |  |  |  | X |  |  |
WMDM Compliance Tests |  |  |  |  | X | X | X | X | X | X | X | X
WMDM Sync Test (MANUAL) |  |  |  |  | X | X | X | X | X | X | X | X
Digital Still Camera Windows HD Imaging Additional Qualification Test (MANUAL) |  |  |  |  |  |  |  |  | X | X | X | X
MTP Compliance Test - Cell Phones |  |  |  |  |  |  |  |  | X |  |  |
Cell Phone [Windows Vista Premium Logo] MTP Compliance Test |  |  |  |  | X |  |  |  |  |  |  |
WPD Compliance Tests (WPDCopytest) | X | X | X |  | X | X | X |  |  |  |  |
WPD Compliance Stress Tests (WPDCopytest) | X | X | X |  | X | X | X |  |  |  |  |
WPD Compliance Tests (WPDCopytest - TS Redirection) |  |  |  |  | X |  |  |  |  |  |  |
WPD Compliance Stress Tests (WPDCopytest - TS Redirection) |  |  |  |  | X |  |  |  |  |  |  |
WPD Compliance Tests (MANUAL) |  |  |  |  |  |  |  |  | X | X | X |
WPD Compliance Stress Tests |  |  |  |  |  |  |  |  | X | X | X |

Many Cellular Handsets have the ability to connect to a PC using multiple modes. If the device is capable of connecting to the PC and appears as one of the following devices, additional testing is required:

  • If the device also functions as a Digital Media Renderer, Digital Media Server, or Digital Media Controller, you must submit results as a Network Media Device. For more information, please see Network Media Device Testing Overview.

  • A device that loads a driver for other modes must pass the Device Fundamental Tests in order to digitally sign the driver. For more information, please see Device Fundamental Tests.


Troubleshooting Cellular Handset Testing

This topic describes how to troubleshoot the cellular handset logo tests.

If the tests do not run after you schedule them, the tests require the WPD\PortableDeviceType Exists constraint before you can run them.

To enable this constraint, you must apply the Wdk\ConfigureCellularHandsetsPortableDevice dimension on your test machine pool. (For more information about applying this dimension, see the "Test system configuration" section of Preparing for Portable Media Device Testing.)

If your computer is running Windows XP with Service Pack (SP2), you also must install the Windows Portable Devices and User Mode Driver Framework binaries before you run the cellular handset logo tests. For more information, 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 and not disabled (yellow exclamation point). Re-enable or re-install the device when that happens.

  • Browse the device's contents in My Computer by viewing objects or files in the device storage. If the device stops responding (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 re-insert the batteries.

If the WDK\PortableMediaType dimension on your machine is empty or incorrect, and you have verified that your device is plugged in correctly, the dimensions may not be refreshing properly. You can force a refresh by selecting CellularHandsetsPortableDevices Master Config Job and clicking Rerun from Job Monitor.

Viewing Results

To view the results after each test run:

  1. Open the Job Monitor window.

  2. Select the machine that ran the job.

  3. In the Job Execution Status pane, select the job.

  4. In the Task Execution Status pane, right-click the Process Logged Messages task, and click View Task Log.

  5. From the list at the top left of the window, select ContextTree. The log file will be displayed in an organized fashion according to PCI function and further organized into test sections.

  6. Expand or collapse sections by clicking on the nodes.


Digital Still Camera Testing

Digital Still Camera Testing Overview

Preparing for Digital Still Camera Testing

Running the Digital Still Camera Tests

Troubleshooting the Digital Still Camera Testing


Digital Still Camera Testing Overview

The procedures presented in this section outline the process for testing your Digital Still Camera for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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 logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

Digital Still Camera 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 Running the Digital Still Camera Tests.

Run time: Approximately 24-48 hours, depending on device capabilities

Hardware requirements

The following hardware is required for Digital Still Camera 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.

  • System that supports USB 2.0

  • A USB cable for the device you are testing

Other Device Requirements

The following is required to run the portable media device testing component of the WLK:

  • Your device must install with the Microsoft Media Transfer Protocol class driver.

  • For Windows Vista and later versions, your device must appear under the Portable Devices category in Device Manager.

  • The battery on the device should be fully charged before testing is started.

  • Device must include at least one sample of each format type supported by the device.

  • If the device supports removable media, the media must be added before testing.

Software requirements

The following software is required to run the Digital Still Camera tests:

  • No additional software is needed.

Tester knowledge requirements

To run the Digital Still Camera tests, testers must know how to accomplish the following tasks:

  • Switch a device to a computer connectivity mode before plugging it in.

  • Plug a device into a USB port of the computer and maintain the connectivity throughout the test run.

  • Provide continuous power to the device during throughout 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.


Preparing for Digital Still Camera 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 and Digital Still Camera Testing Overview topics...

Test system configuration

Refer to Using DTM for Logo Testing for detailed instructions on test system configuration.


Running the Digital Still Camera Tests

Logo Program: Windows Vista Client - Basic (x86, x64) Logos

  1. Connect your Digital Still Camera to the DTM Test Client Machine.

  2. Install your Digital Still Camera for the device under test on the Test Client Machine.

  3. From DTM studio, go to Explorers Device Console. Select your Machine Pool from the drop down list. Select View By Machine and then locate your device in Available Devices.
    • If DTM Studio is running on Windows Vista Ultimate, your device can found under Portable Devices.
  4. Ensure that your device is powered on and registered in Device Console.
    • Right-click the device and select View Device XML. Verify the entries such as DeviceID, ModelID, DriverDate, DriverVersion, and ImagePath for your driver and device.
    • If your device does not appear or if you are seeing stale entries for previously connected devices, you may need to wait a few minutes and refresh the Device Console and/or reconnect the device.
  5. Create a new submission:
    a. From Device Console, select View By Submission.
    b. From the Submission drop down list, select <New Submission>.
    c. Select OS from the available options.
    d. Select Category: Device Submission.
    e. In the Create New Submission dialog box, select Portable Devices > Digital Still Camera.
    f. In the Create New Submission dialog box, select Basic under Qualification Level.
    g. Enter a name for your submission, and select your machine pool.
    h. Click Finish to complete and load the new submission.

  6. Depending on how your INF file is authored, you may see multiple entries for your device. For the Windows Vista Client submission, select the device entry that corresponds to the driver INF, not the TS-redirection driver INF. For your convenience, one way to differentiate between the driver and the TS-redirection INF files is to author them with slightly different DriverVer or Manufacturer entries.

  7. With the correct device selected, from the Available Jobs, you can now add jobs from the first Digital Still Camera category. If your device connects via USB, you will see USB jobs in addition to the WPD Compliance Tests jobs. For requirements on running these jobs, please see Supplemental Tests or view the job details in Job Explorer.

    See the table below for a list of applicable jobs.

Logo Program: Windows Vista Client - Premium (x86, x64) and Windows 7 (x86, x64) Logos

  1. Connect a MTP Digital Still Camera to the DTM Test Client Machine.

    Note If the device supports mode switching, make sure that the device is in a mode that uses MTP.

  2. From DTM studio, go to Explorers Device Console. Select your Machine Pool from the drop down list. Select View By Machine and then locate your device in Available Devices. Your device can found under Portable Devices.

  3. Ensure that your device is powered on and registered in Device Console.
    • Right-click the device and select View Device XML. Verify the entries such as ModelID, DeviceID, and ImagePath for your driver and device.
    • If your device does not appear or if you are seeing stale entries for previously connected devices, you may need to wait a few minutes and refresh the Device Console and/or reconnect the device.

  4. For Windows Vista Client (x86, x64), repeat steps 1 through 4 for one additional machine with an identical device. You need to setup two machines to complete the TS Plug and Play Redirection tests as part of your current submission.

  5. Create a new submission:
    a. From Device Console, select View By Submission.
    b. From the Submission drop down list, select <New Submission>.
    c. Select OS from the available options.
    d. Select Category: Device Submission.
    e. In the Create New Submission dialog box, select Portable Devices > Digital Still Camera.

    f. In the Create New Submission dialog box under Qualification Level, select Premium for Windows Vista or Logo for Windows 7.

    Note that if you are planning to submit for an Additional Qualification, that submission type may appear.

    g. Enter a name for your submission, and select your machine pool.
    h. Click Finish to complete and load the new submission.

  6. With the correct device selected, from the Available Jobs, you can now add jobs from the first Digital Still Camera category. If your device connects via USB, you will see USB jobs in addition to the WPD Compliance Tests jobs. For requirements on running these jobs, please see Portable Media Devices Tests or view the job details in Job Explorer.

The following table indicates which jobs are required based on connectivity type that must be run:

Test Name | Windows Vista |  |  |  | Windows 7
 | USB | BT | IP | Other | USB | BT | IP | Other
Connectivity Tests - PCI
PCI Hardware Compliance Test For a Single Device (PCIHCT) |  |  |  |  |  |  |  | X
Connectivity Tests - USB
USB Address Description Test (Automated) | X |  |  |  | X |  |  |
USB Descriptor test (Automated) | X |  |  |  | X |  |  |
USB Device Control Requests (Automated) | X |  |  |  | X |  |  |
USB Enumeration Stress (Automated) | X |  |  |  | X |  |  |
USB Selective Suspend (Automated) | X |  |  |  | X |  |  |
USB Specification Compliance (Automated) | X |  |  |  | X |  |  |
USB Isochronous Alternate Interface Presence (Automated) | X |  |  |  | X |  |  |
USB HIDView (CV) (Manual) | X |  |  |  | X |  |  |
USB Device Framework (CV) (Manual) | X |  |  |  | X |  |  |
USB Serial Number (Automated) | X |  |  |  | X |  |  |
USB System Suspend Resume Test | X |  |  |  | X |  |  |
USB Disable Enable (Automated) | X |  |  |  | X |  |  |
Connectivity Test - 1394
1394 Industry Certification Test ID Entry (MANUAL) |  |  |  | X |  |  |  | X
Device Fundamentals Tests
Web Services for Devices | X | X | X | X | X | X | X | X
Run INFTest against a single INF | X | X | X | X | X | X | X | X
Device Path Exerciser | X | X | X | X | X | X | X | X
Plug and Play Driver Test | X | X | X | X | X | X | X | X
Concurrent Hardware And OS Test (CHAOS) | X | X | X | X | X | X | X | X
Embedded Signature Verification | X | X | X | X | X | X | X | X
WDF Logo Tests | X | X | X | X | X | X | X | X
Sleep Stress With IO | X | X | X | X | X | X | X | X
Disable Enable With IO | X | X | X | X | X | X | X | X
Common Scenario Stress With IO | X | X | X | X | X | X | X | X
Reinstall With IO | X | X | X | X | X | X | X | X
Portable Devices Tests for Digital Still Camera
WPD Compliance Tests - ALL SERVICES |  |  |  |  | X | X | X | X
WPD Compliance Tests - CONTACT SERVICE |  |  |  |  | X | X | X | X
WPD Compliance Tests - METADATA SERVICE |  |  |  |  | X | X | X | X
WPD Compliance Tests - HINTS SERVICE |  |  |  |  | X | X | X | X
WPD Compliance Tests - MODEL_ID |  |  |  |  | X | X | X | X
WPD Compliance Tests - FUID |  |  |  |  | X | X | X | X
WPD Compliance Tests - NOTES SERVICE |  |  |  |  | X | X | X | X
WPD Compliance Tests - RINGTONE SERVICE |  |  |  |  | X | X | X | X
WPD Compliance Tests - STATUS SERVICE |  |  |  |  | X | X | X | X
Verify Portable Media Device correctly supports Selective Suspend (MANUAL) |  |  |  |  | X | X | X | X
Digital Still Camera Windows HD Imaging Additional Qualification Test (MANUAL) |  |  |  |  | X | X | X | X
MTP Compliance Test - Cameras |  |  |  |  | X |  |  |
Camera or Camcorder [Windows Vista Premium Logo] MTP Compliance Test | X |  |  |  |  |  |  |
Camera or Camcorder [Windows Vista Basic Logo] MTP, PTP Compliance Test | X |  |  |  |  |  |  |

If the Digital Still Camera has the ability to connect to a PC over other modes, additional testing is required.


Troubleshooting the Digital Still Camera Testing

This topic describes how to troubleshoot the digital still camera logo tests.

To troubleshoot the Digital Still Camera Logo Tests, try the following steps:

  1. Check if the camera appears in device manager under Portable Devices before scheduling the jobs.

  2. For some cameras, the automated test may pop up a dialog box asking for the user to plug out and plug back in the camera before proceeding with the test.

  3. Check if a user with administrator privileges has logged into the client test machine.

To run the digital still camera logo tests manually, do the following:

  1. Plug in the device that is being tested.

  2. Run Mtpinfup.exe. This application updates or disables the in-box driver to a test driver and then generates an XML file that contains the list of active devices.

  3. Place the 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 and you can browse the device's contents My Computer.

Note

You must unplug some devices and plug them back in every time the driver (that is, the INF file) has been updated.

If the device has gone into a persistent bad state, reset the device or remove and re-insert the batteries.

To update drivers, you must have Administrator privileges.

Viewing Results

To view the results after each test run:

  1. Open the Job Monitor window.

  2. Select the machine that ran the job.

  3. In the Job Execution Status pane, select the job.

  4. In the Task Execution Status pane, right-click the Process Logged Messages task, and click View Task Log.

  5. From the list at the top left of the window, select ContextTree. The log file will be displayed in an organized fashion according to PCI function and further organized into test sections.

  6. Expand or collapse sections by clicking on the nodes.


Media Player Testing

Media Player Testing Overview

Preparing for Media Player Testing

Running the Media Player Tests

Troubleshooting Media Player Testing


Media Player Testing Overview

The procedures presented in this section outline the process for testing your Media Player for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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 logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

Media Player Tests

The list of tests needed to be run depends 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 Media Player Tests.

Run time: Approximately 24-48 hours

Hardware requirements

The following hardware is required for Media Player 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.

  • System that supports USB 2.0

  • A USB cable for the device you are testing

Other Device Requirements

The following is required to run the portable media device testing component of the WLK:

  • Your device must install with the Microsoft Media Transfer Protocol class driver.

  • For Windows Vista and later versions, your device must appear under the Portable Devices category in Device Manager.

  • The battery on the device should be fully charged before testing is started.

  • Device must include at least one sample of each format type supported by the device.

  • If the device supports removable media, the media must be added before testing.

Software requirements

The following software is required to run the Media Player tests:

  • No additional software is needed.

Tester knowledge requirements

To run the Digital Still Camera tests, testers must know how to accomplish the following tasks:

  • Switch a device to a computer connectivity mode before plugging it in.

  • Plug a device into a USB port of the computer and maintain the connectivity throughout the test run.

  • Provide continuous power to the device during throughout 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.


Preparing for Media Player 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 Media Player Testing Overview.

Test system configuration

Refer to Using DTM for Logo Testing for detailed instructions on test system configuration.

Logo Program: Windows Vista Client - Basic (x86, x64) Logos

  1. Connect your Media Player to the DTM Test Client Machine

  2. Install your Media Player for the device under test on the Test Client Machine

  3. From DTM studio, go to Explorers Device Console. Select your Machine Pool from the drop down list. Select View By Machine and then locate your device in Available Devices.
    • If DTM Studio is running on Windows Vista Ultimate, your device can found under Portable Devices.
  4. Ensure that your device is powered on and registered in Device Console.
    • Right-click the device and select View Device XML. Verify the entries such as DeviceID, ModelID, DriverDate, DriverVersion, and ImagePath for your driver and device.
    • If your device does not appear or if you are seeing stale entries for previously connected devices, you may need to wait a few minutes and refresh the Device Console and/or reconnect the device.
  5. Create a new submission:
    a. From Device Console, select View By Submission.
    b. From the Submission drop down list, select <New Submission>.
    c. Select OS from the available options.
    d. Select Category: Device Submission.
    e. In the Create New Submission dialog box, select Portable Devices > Media Player.
    f. In the Create New Submission dialog box, select Basic under Qualification Level.
    g. Enter a name for your submission, and select your machine pool.
    h. Click Finish to complete and load the new submission.

  6. With the correct device selected, from the Available Jobs, you can now add jobs from the first Media Player category. If your device connects via USB, you will see USB jobs in addition to the WPD Compliance Tests jobs. For requirements on running these jobs, please see Supplemental Tests or view the job details in Job Explorer.

    See the table below for a list of applicable jobs.

Logo Program: Windows Vista Client - Premium (x86, x64) and Windows 7 (x86, x64) Logos

  1. Connect a MTP Media Player to the DTM Test Client Machine.

    Note If the device supports mode switching, make sure that the device is in a mode that uses MTP.

  2. From DTM studio, go to Explorers Device Console. Select your Machine Pool from the drop down list. Select View By Machine and then locate your device in Available Devices. Your device can found under Portable Devices.

  3. Ensure that your device is powered on and registered in Device Console.
    • Right-click the device and select View Device XML. Verify the entries such as ModelID, DeviceID, and ImagePath for your driver and device.
    • If your device does not appear or if you are seeing stale entries for previously connected devices, you may need to wait a few minutes and refresh the Device Console and/or reconnect the device.

  4. For Windows Vista Client (x86, x64), repeat steps 1 through 4 for one additional machine with an identical device.

  5. Create a new submission:
    a. From Device Console, select View By Submission.
    b. From the Submission drop down list, select <New Submission>.
    c. Select OS from the available options.
    d. Select Category: Device Submission.
    e. In the Create New Submission dialog box, select Portable Devices > Media Player.

    f. In the Create New Submission dialog box under Qualification Level, select Premium for Windows Vista or Logo for Windows 7.

    Note that if you are planning to submit for an Additional Qualification, that submission type may appear.

    g. Enter a name for your submission, and select your machine pool.
    h. Click Finish to complete and load the new submission.

  6. With the correct device selected, from the Available Jobs, you can now add jobs from the first Media Player category. If your device connects via USB, you will see USB jobs in addition to the WPD Compliance Tests jobs. For requirements on running these jobs, please see Portable Media Devices Tests or view the job details in Job Explorer.

The following table indicates which jobs are required based on connectivity type that must be run:

Test Name | Windows Vista |  |  |  | Windows 7
 | USB | BT | IP | Other | USB | BT | IP | Other
Connectivity Tests - PCI
PCI Hardware Compliance Test For a Single Device (PCIHCT) |  |  |  |  |  |  |  | X
Connectivity Tests - USB
USB Address Description Test (Automated) | X |  |  |  | X |  |  |
USB Descriptor test (Automated) | X |  |  |  | X |  |  |
USB Device Control Requests (Automated) | X |  |  |  | X |  |  |
USB Enumeration Stress (Automated) | X |  |  |  | X |  |  |
USB Selective Suspend (Automated) | X |  |  |  | X |  |  |
USB Specification Compliance (Automated) | X |  |  |  | X |  |  |
USB Isochronous Alternate Interface Presence (Automated) | X |  |  |  | X |  |  |
USB HIDView (CV) (Manual) | X |  |  |  | X |  |  |
USB Device Framework (CV) (Manual) | X |  |  |  | X |  |  |
USB Serial Number (Automated) | X |  |  |  | X |  |  |
USB System Suspend Resume Test | X |  |  |  | X |  |  |
USB Disable Enable (Automated) | X |  |  |  | X |  |  |
Connectivity Test - 1394
1394 Industry Certification Test ID Entry (MANUAL) |  |  |  | X |  |  |  | X
Device Fundamentals Tests
Web Services for Devices | X | X | X | X | X | X | X | X
Run INFTest against a single INF | X | X | X | X | X | X | X | X
Device Path Exerciser | X | X | X | X | X | X | X | X
Plug and Play Driver Test | X | X | X | X | X | X | X | X
Concurrent Hardware And OS Test (CHAOS) | X | X | X | X | X | X | X | X
Embedded Signature Verification | X | X | X | X | X | X | X | X
WDF Logo Tests | X | X | X | X | X | X | X | X
Sleep Stress With IO | X | X | X | X | X | X | X | X
Disable Enable With IO | X | X | X | X | X | X | X | X
Common Scenario Stress With IO | X | X | X | X | X | X | X | X
Reinstall With IO | X | X | X | X | X | X | X | X
Portable Devices Tests for Media Players
WPD Compliance Tests - ALL SERVICES |  |  |  |  | X | X | X | X
WPD Compliance Tests - CONTACT SERVICE |  |  |  |  | X | X | X | X
WPD Compliance Tests - METADATA SERVICE |  |  |  |  | X | X | X | X
WPD Compliance Tests - HINTS SERVICE |  |  |  |  | X | X | X | X
WPD Compliance Tests - MODEL_ID |  |  |  |  | X | X | X | X
WPD Compliance Tests - FUID |  |  |  |  | X | X | X | X
WPD Compliance Tests - NOTES SERVICE |  |  |  |  | X | X | X | X
WPD Compliance Tests - RINGTONE SERVICE |  |  |  |  | X | X | X | X
WPD Compliance Tests - STATUS SERVICE |  |  |  |  | X | X | X | X
Verify Portable Media Device correctly supports Selective Suspend (MANUAL) |  |  |  |  | X | X | X | X
WMDM Compliance Test | X | X | X | X | X | X | X | X
WMDM Sync Test (MANUAL) | X | X | X | X | X | X | X | X
MTP Compliance Test - Media Players |  |  |  |  | X |  |  |
Media Player [Windows Vista Basic Logo] MTP Compliance Test | X |  |  |  |  |  |  |
Media Player [Windows Vista Premium Logo] MTP Compliance Test | X |  |  |  |  |  |  |
WPD Compliance Tests (MANUAL) |  |  |  |  | X | X | X | X
WPD Compliance Stress Tests |  |  |  |  | X | X | X | X
WPD Compliance Tests (WPDCopytest) | X | X | X | X |  |  |  |
WPD Compliance Stress Tests (WPDCopytest) | X | X | X | X |  |  |  |
WPD Compliance Tests (WPDCopytest-TS Redirection) | X | X | X | X |  |  |  |
WPD Compliance Stress Tests (WPDCopytest-TS Redirection) | X | X | X | X |  |  |  |

If the Media Player has the ability to connect to a PC over other modes, additional testing is required.


Running the Media Player Tests

Logo Program: Windows Vista Client - Logo (x86, x64) and Windows 7 (x86, x64) Logos

  1. Please refer to Terminal Server PNP Redirection Testing Overview for details on how to setup Terminal Server Logo Tests. This involves scheduling and running an automated setup job to configure the TS Client and Server machines. Recommended Setup:
    • TS Server: The same DTM client machine that was used to run the Media Player Logo Tests should be set up as the TS Server machine. Install the TS-redirected driver on this machine. You should unplug your device from this machine.
    • TS Client: An additional DTM client machine with the same processor architecture (x86 or x64) as the TS Server machine. Connect your device to this machine, and install the (non TS-redirected) driver on this machine. Only 1 device is needed, and it should be connected to the TS Client machine.
    • Schedule the TS_PNPRedirection - WDK setup job on your machine pool after editing the LMS_Client constraint.
  2. When you complete setting up the machines for Terminal Server Redirection testing, you will be required to run the following test cases for the redirected driver on the TS Server machine:
    • Windows Portable Devices Driver Compliance Test (TS Redirection)
    • Select the same submission that you have created previously, and refresh Device Console. You may need to wait a few minutes until the device appears correctly (no stale entries).
    • Right click the device, select View Device XML, and verify the entries such as DeviceID, DriverDate, DriverVersion, and ImagePath for your driver and device. The DeviceID should begin with the prefix TS (see Troubleshooting Terminal Server PNP Redirection Testing for more information).
  3. Select the TS redirected device and schedule the following TS Redirection jobs from the second Media Player category. The other jobs are not required for this test:
    • WPD Compliance Tests (WPDCopytest - TS Redirection)
    • WPD Compliance Stress Tests (WPDCopytest - TS Redirection)

Note Because these jobs are run within the same submission as the non TS logo jobs, the logs from these jobs will be bundled together in the same package.


Troubleshooting Media Player Testing

This topic describes how to troubleshoot the Media Player tests.

To troubleshoot the Media Player Logo Tests try the following steps:

  1. Check if the device appears in device manager under Portable Devices before scheduling the jobs.

  2. For some devices, the automated test may pop up a dialog box asking for the user to plug out and plug back in the camera before proceeding with the test.

  3. Check if a user with administrator privileges has logged into the client test machine.

To run the media player logo tests manually, do the following:

  1. Plug in the device that is being tested.

  2. Run Mtpinfup.exe. This application updates or disables the in-box driver to a test driver and then generates an XML file that contains the list of active devices.

  3. Place the 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 and you can browse the device's contents My Computer.

Note

You must unplug some devices and plug them back in every time the driver (that is, the INF file) has been updated.

If the device has gone into a persistent bad state, reset the device or remove and re-insert the batteries.

To update drivers, you must have Administrator privileges.

Viewing Results

To view the results after each test run:

  1. Open the Job Monitor window.

  2. Select the machine that ran the job.

  3. In the Job Execution Status pane, select the job.

  4. In the Task Execution Status pane, right-click the Process Logged Messages task, and click View Task Log.

  5. From the list at the top left of the window, select ContextTree. The log file will be displayed in an organized fashion according to PCI function and further organized into test sections.

  6. Expand or collapse sections by clicking on the nodes.


Other Portable Testing

Other Portable Testing Overview

Preparing for Other Portable Testing

Running the Other Portable Tests

Troubleshooting Other Portable Testing


Other Portable Testing Overview

The procedures presented in this section outline the process for testing your Other Portable for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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 topics:

  • Other Portable Testing Overview

  • Preparing for Other Portable Testing

  • Running the Other Portable Tests

  • Troubleshooting Other Portable Testing

Other Portable Tests

The list of tests needed to be run depends on the capabilities of the device being tested. To see the complete list of tests that could be required for your device, please see Running the Other Portable Tests.

Run time: Approximately 24-48 hours

Hardware requirements

The following hardware is required for Other Portable 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 any additional hardware requirements.

  • System with at least one USB 2.0 Hi-Speed port

  • A USB cable for the device you are testing

Other Device Requirements

The following items are required to run the Other Portable device testing component of the WLK:

  • Windows 7 devices must install with the Microsoft Media Transfer Protocol class driver.
    • The device must connect to the PC in MTP Mode during testing.

  • The battery on the device must be fully charged before you start testing.

  • Some PTP or MTP devices are required to include sample content on the devices local storage prior to testing. If your devices meet any of the following criteria, include sample content on the device for each of the formats that the device supports to complete testing:
    • Device under test has a DCF compatible file system.
    • Device has read only stores.
    • Device does not support SendObject and SendObjectInfo.
    • Device does not support SendObject and SendObjectPropList

  • If the device supports removable media, the media must be added prior to testing.

Software requirements

The following software is required to run the Other Portable tests:

  • Windows 7

Tester knowledge requirements

To run the Other Portable tests, testers must know how to accomplish the following tasks:

  • Switch a device to a computer connectivity mode before plugging it in (if applicable).

  • Plug a device into a USB port of the computer and maintain the connectivity throughout the test run.

  • Provide continuous power to the device during throughout the test run (fully charged battery if the device is portable and does not charge over USB).

  • Troubleshoot device installation by checking if the device is installed successfully in Device Manager or by looking at the SetupAPI device installation logs.


Preparing for Other Portable 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 Other Portable Testing Overview

Test system configuration

Refer to "Using DTM for Logo Testing" for detailed instructions on test system configuration.


Running the Other Portable Tests

Logo Program: Windows 7 (x86, x64) Logos

  1. Connect MTP Other Portable to the DTM Test Client Machine.

    Note If the device supports mode switching, make sure that the device is in a mode that uses MTP.

  2. From DTM studio, Explorers Device Console, select your Machine Pool from the drop-down list. Select View By Machine, and locate your device in Available Devices.

    Note You can find your device under "Portable Devices".

  3. Ensure that your device is powered on and registered in Device Console.
    • Right-click the device, select View Device XML, and verify the entries such as ModelID, DeviceID, and ImagePath for your device.
    • If your device does not appear or if you are seeing stale entries for previously connected devices, you may need to wait a few minutes and refresh the Device Console and/or reconnect the device.
  4. Create a new submission:
    a. From Device Console, select View By Submission.
    b. From the Submission drop down list, select <New Submission>.
    c. Select OS. The available options are Windows 7 Client or Windows 7 x64
    d. Select Category: Device Submission.
    e. Logo Program: Portable Devices Other Portable.

    f. Qualification Level: For Windows 7, select Logo:

    Note If you are planning to submit for an Additional Qualification, that submission type may appear.

  5. Enter a name for your submission, and select your machine pool.

  6. Click Finish to complete and load the new submission.

  7. With the correct device selected, from the Available Jobs, you can now add jobs from the first Other Portables category. If your device connects via USB, you will see USB jobs in addition to the WPD Compliance Tests jobs. For requirements on running these jobs, please refer to the "Portable Devices Tests" section or view the job details in Job Explorer.

The following table indicates which jobs are required based on connectivity type and features supported that must be run:

Test Name | Windows 7
 | USB | BT | IP
Connectivity Tests - USB
USB Address Description Test (Automated) | X |  |
USB Descriptor test (Automated) | X |  |
USB Device Control Requests (Automated) | X |  |
USB Enumeration Stress (Automated) | X |  |
USB Selective Suspend (Automated) | X |  |
USB Specification Compliance (Automated) | X |  |
USB Isochronous Alternate Interface Presence (Automated) | X |  |
USB HIDView (CV) (Manual) | X |  |
USB Device Framework (CV) (Manual) | X |  |
USB Serial Number (Automated) | X |  |
USB System Suspend Resume Test | X |  |
USB Disable Enable (Automated) | X |  |
Device Fundamentals Tests
Web Services for Devices | X | X | X
Run INFTest against a single INF | X | X | X
Device Path Exerciser | X | X | X
Plug and Play Driver Test | X |  |
Concurrent Hardware And OS Test (CHAOS) | X |  |
Embedded Signature Verification | X |  |
WDF Logo Tests | X |  |
Sleep Stress With IO | X |  |
Disable Enable With IO | X |  |
Common Scenario Stress With IO | X |  |
Reinstall With IO | X |  |
Portable Devices Tests for Other Portable
WPD Compliance Tests - ALL SERVICES | X | X | X
WPD Compliance Tests - CONTACT SERVICE | X | X | X
WPD Compliance Tests - METADATA SERVICE | X | X | X
WPD Compliance Tests - HINTS SERVICE | X | X | X
WPD Compliance Tests - MODEL_ID | X | X | X
WPD Compliance Tests - FUID | X | X | X
WPD Compliance Tests - NOTES SERVICE | X | X | X
WPD Compliance Tests - RINGTONE SERVICE | X | X | X
WPD Compliance Tests - STATUS SERVICE | X | X | X
Verify Portable Media Device correctly supports Selective Suspend (MANUAL) | X |  |
WMDM Compliance Tests | X | X | X
MTP Compliance Test - Other Portable | X |  |
WPD Compliance Tests (MANUAL) | X | X | X

Many Other Portable devices have the ability to connect to a PC using multiple modes. If the device is capable of connecting to the PC and appears as one of the following devices, additional testing is required:

  • If the device also functions as a Digital Media Renderer, Digital Media Server, or Digital Media Controller, you must submit results as a Network Media Device. For more information, go to Portable Devices Tests.

  • A device that loads a driver for other modes must pass the Device Fundamental Tests in order to digitally sign the driver.


Troubleshooting Other Portable Testing

If the tests do not run after you schedule them, the tests require the WPD\PortableDeviceType Exists constraint before you can run them.

To enable this constraint, you must apply the Wdk\ConfigureOtherPortablePortableDevice dimension on your test machine pool. (For more information about applying this dimension, see the "Test system configuration" section of Preparing for Portable Device Testing.)

If many tests start to fail after some time, especially when you are running the Stress test, perform the following steps 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 and not disabled (yellow exclamation point). Re-enable or re-install the device if that occurs.

  • 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 may have gone into a bad state.

If the device has gone into a persistent bad state, reset the device or remove and re-insert the batteries if possible.

If the "WDK\PortableMediaType" dimension on your machine is empty or incorrect, and you have verified that your device is plugged in correctly, the dimensions may not be refreshing properly. You can force a refresh by selecting OtherPortablePortableDevices Master Config Job, and clicking Rerun from Job Monitor.

Viewing Results

To view the results after each test run, follow these steps:

  1. Open the Job Monitor window.

  2. Select the machine that ran the job.

  3. In the Job Execution Status pane, select the job.

  4. In the Task Execution Status pane, right-click Process Logged Messages, and click View Task Log.

  5. From the list at the top left of the window, select ContextTree. The log file will be displayed in an organized fashion according to PCI function and further organized into test sections.

  6. Expand or collapse sections by clicking on the nodes.


Portable Devices Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


Camera or Camcorder [Windows Vista Basic Logo] MTP, PTP Compliance Test

Type: Automated Test

Overview

The Camera or Camcorder [Windows Vista Basic Logo] MTP, PTP Compliance Test validates compliance with Picture Transfer Protocol (PTP) and Media Transfer Protocol (MTP). This suite of tests ensures that devices that use the MTP class driver that ships with Windows Vista comply with PTP and/or MTP implementation standards. This tool is directed at Camera or Camcorder devices that use the MTP protocol. This test is used to validate compliance with defined protocols based on requirements documented in the Windows Logo Program.

This test does not cover the following items:

  • Digital Rights Management validation

  • Devices that are not PTP or MTP-based or devices that use proprietary (third-party) drivers that work with the Windows Portable Device (WPD) driver stack

Details

The Camera or Camcorder [Windows Vista Basic Logo] MTP, PTP Compliance Test requires that a PTP or MTP-compatible device is installed. The test is fully automated with Pass/Fail results for each requirement.

This test is divided into the following functional categories:

  • Device Capabilities tests

  • Operations tests

  • Object Property tests

Each functional category above contains child test cases, which test the subcomponents that fall under the corresponding category.

The test will validate that the following operations are supported by the device:

  • OpenSession

  • CloseSession

  • GetDeviceInfo

  • GetStorageIDs

  • GetStorageInfo

  • GetNumObjects

  • GetObjectHandles

  • GetObjectInfo

  • GetObject

  • GetDevicePropDesc

  • GetDevicePropValue

  • DeleteObject

The test validates that the following formats are supported:

  • Association

  • EXIF/JPEG

All other supported operations, device properties, and object properties are considered optional and therefore will be validated according to implementation details defined in the Picture Transfer Protocol (PTP) for Digital Still Photography Devices, Version 1.0 (PIMA15740) and Media Transfer Protocol (MTP), Revision 1.0.

Run Time: Test duration depends on the number of supported capabilities, formats, and operations. Run time is approximately 2 hours.
Log File: MtpTestLog.xml
System Restart Required: No
Test Category: Digital Still Camera
Supported operating systems for logo testing:
Windows Vista
Program: MtpTest.exe

Requirements

Software Requirements

The Camera or Camcorder [Windows Vista Basic Logo] MTP, PTP Compliance Test tool runs on the following Windows operating systems:

  • Windows Vista

  • Software components included with the device under test

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Tester Knowledge Requirements

To run the portable media device tests, testers must know how to:

  • Switch a device to a computer connectivity mode before plugging it in.

  • Plug a device into a USB port of the computer and maintain the connectivity throughout 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.

Processor

The Camera or Camcorder [Windows Vista Basic Logo] MTP, PTP Compliance Test tool runs on the following processor architectures:

  • x86

  • x64

Running the Camera or Camcorder [Windows Vista Basic Logo] MTP, PTP Compliance Test

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. Upon completion of the test, Mtpinfup.exe will update the driver back to the original in-box driver Wpdmtp.inf. If an optional capability is not supported by the device, the test will skip that test case.

Before launching the test, ensure that the device is fully charged. The device under test MUST have a sample of each media type supported in its local storage.

Command Syntax

Command option | Description
mtptest.exe | With no options, launches the GUI.
-hct (or /hct) | Runs the test in logo mode.
/p:DscSilverTestsProfile.xml | Uses the Basic test profile for Cameras to validate logo compliance.
/g:DscSilverTestGuids.xml | Uses test case GUID mapping for Basic logo for Cameras.
/r:PtpCamera.xml | Uses specific test profile to validate required operations for the Camera device class.
/id:"[WDKDeviceID]" | Used to identify target device under test, if there are more than one device attached.

Code Tour

The following files are included to support the execution of Camera or Camcorder [Windows Vista Basic Logo] MTP, PTP Compliance Test.

File Manifest

File | Location
MtpTest.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
wpdmtpwrapper.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpHelperLibrary.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpLib.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpUtils.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
mtpinfup.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
Mtptest.inf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
MtpTest.cat | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
PropertySpecifications.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
HugeWmaFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.asf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.avi | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.bmp | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.gif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.html | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.jpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mp3 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.png | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.script | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.tif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.txt | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wav | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wmv | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
DscSilverTestGuids.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
DscSilverTestsProfile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
PtpCamera.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\

Cautions

Run the 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 the following files:

  • Mtptest.inf

  • PtpCamera.xml

  • TestFile.xml

  • MtpCamera-recommended.xml

  • PropertySpecifications.xml

  • DscSilverTestGuids.xml

  • DscSilverTestsProfile.xml

Troubleshooting

  • Make sure that the device is plugged in and active before commencing the test.

  • Make sure that the device shows up in Device Manager under Windows Portable Devices.

  • Check the test log file for any error logging.

  • Log in as Administrator ( this test involves updating to a test driver and reverting back to the original driver).

Test Assertions

The following test assertions are high-level Assertions are validated by one or more child test cases. The test validates that the required capabilities are supported, and will test other capabilities if implemented. Refer to the "Details" section above for the list of required capabilities.

Digital still camera supports PTP (ISO 15740) in its firmware if it does not support MTP

Device Requirements Test Cases

Test Assertion GUID: {19392760-9662-484c-a4b5-01b4cef0ffff}

Windows Logo Program: PORTABLE-0004 Digital still camera supports required mandatory MTP operations, Properties, Events, Responses and Formats in its firmware

Additional Information: Portable-0004: Digital still camera supports PTP (ISO 15740) in its firmware if it does not support MTP. These tests verify that the basic requirements for PTP/MTP are met by the device.

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: {581f906f-bdd9-423d-b337-d4ac7b8fa4b3}

Windows Logo Program: PORTABLE-0005 Digital still camera supports required mandatory MTP operations, Properties, Events, Responses and Formats in its firmware

Additional Information: All MTP and PTP Digital still camera must work with inbox MTP drivers.Portable-0005: These test cases verify that the device can manage transfer of content properly and handle cancel requests, resets, etc.

All MTP and PTP Digital still camera connect to Windows by using inbox MTP class drivers and can transfer content to the PC

Miscellaneous Test Cases

Test Assertion GUID: {710dbfbd-8b55-44dc-ba38-2a8f6c442811}

Windows Logo Program: PORTABLE-0005 Digital still camera supports required mandatory MTP operations, Properties, Events, Responses and Formats in its firmware

Additional Information: All MTP and PTP Digital still camera must work with inbox MTP drivers.Portable-0005: These test cases validate the devices ability to manage requests for property groups.

All MTP and PTP Digital still camera connect to Windows by using inbox MTP class drivers and can transfer content to the PC

PlaysForSure Test Cases

Test Assertion GUID: {9c844b0b-f7dd-4046-80fd-a7081fb82cf9}

Windows Logo Program: PORTABLE-0005 Digital still camera supports required mandatory MTP operations, Properties, Events, Responses and Formats in its firmware

Additional Information: All MTP and PTP Digital still camera must work with inbox MTP drivers.Portable-0005: This test verifies that Play Lists can be copied to the device and Album Art if supported.

Digital still camera supports PTP (ISO 15740) in its firmware if it does not support MTP

Operations Test Cases

Test Assertion GUID: {7e51f7de-7f3a-45fe-8f0e-9cace4b686f3}

Windows Logo Program: PORTABLE-0004 Digital still camera supports required mandatory MTP operations, Properties, Events, Responses and Formats in its firmware

Additional Information: Portable-0004: Digital still camera supports PTP (ISO 15740) in its firmware if it does not support MTP. These test cases verify that a device accurately reports operations such as GetDevicePropValue.

Digital still camera supports PTP (ISO 15740) in its firmware if it does not support MTP

DeviceProperties Test Cases

Test Assertion GUID: {7a355c3a-05fb-4ef8-a56e-cbfdd5c8d15e}

Windows Logo Program: PORTABLE-0004 Digital still camera supports required mandatory MTP operations, Properties, Events, Responses and Formats in its firmware

Additional Information: Portable-0004: Digital still camera supports PTP (ISO 15740) in its firmware if it does not support MTP. These test cases verify that a device accurately reports properties such as Image Size.

Digital still camera supports PTP (ISO 15740) in its firmware if it does not support MTP

ObjectProperties Test Cases

Test Assertion GUID: {ee6658ab-b567-4563-9dc7-4516db5398e1}

Windows Logo Program: PORTABLE-0004 Digital still camera supports required mandatory MTP operations, Properties, Events, Responses and Formats in its firmware

Additional Information: Portable-0004: Digital still camera supports PTP (ISO 15740) in its firmware if it does not support MTP. These test cases verify that a device accurately reports object properties such as Object Format and Date Created.


Cell Phone [Windows Vista Premium Logo] MTP Compliance Test

Type: Automated Test

Overview

The Cell Phone [Windows Vista Premium Logo] MTP Compliance Test validates compliance with Picture Transfer Protocol (PTP) and Media Transfer Protocol (MTP). This suite of tests ensures that devices use the MTP class driver that ships with Windows Vista comply with PTP and/or MTP implementation standards. This tool is directed at Cell Phone devices that use the MTP protocol. This test is used to validate compliance with defined protocols based on requirements documented in the Windows Logo Program.

This test does not cover the following items:

  • Digital Rights Management validation

  • Devices that are not MTP-based

  • Devices that use proprietary (third-party) drivers that work with the Windows Portable Device (WPD) driver stack

Details

The Cell Phone [Windows Vista Premium Logo] MTP Compliance Test requires that an MTP-compatible device is installed. The test is fully automated with Pass/Fail results for each requirement.

This test is divided into the following functional categories:

  • Device Capabilities tests

  • Operations tests

  • Device Properties

  • Object Property tests

Each functional category above contains child test cases, testing the sub components that fall under the corresponding category.

The test validates that the following Operations are supported by the device:

  • OpenSession

  • CloseSession

  • GetDeviceInfo

  • GetStorageIDs

  • GetStorageInfo

  • GetObject

  • GetDevicePropDesc

  • GetDevicePropValue

  • SetDevicePropValue

  • DeleteObject

  • SendObject

  • GetNumObjects

  • GetObjectHandles

  • GetObjectInfo

  • SendObjectInfo

  • GetPartialObject

  • GetObjectPropsSupported

  • GetObjectPropDesc

  • GetObjectPropValue

  • SetObjectPropValue

  • GetObjectReferences

  • SetObjectReferences

The test validates that the following device properties are supported:

  • Synchronization Partner

  • Device Friendly Name

The test validates that the following formats are supported:

  • Undefined

  • Association

  • ASF

  • WMA

  • WMV

  • MP3

  • AbstractAudioAlbum

  • AbstractAudioVideoPlaylist

For AbstractAudioAlbum, the following properties are verified:

  • Genre

  • AlbumArtist

The test validates that the following Object Properties are supported for each supported format:

  • StorageID

  • ObjectFormat

  • ProtectionStatus

  • ObjectSize

  • ObjectFileName

  • ParentObject

  • PersistentUniqueObjectIdentifier

  • Name

  • Non-Consumable

For supported Image formats, the test looks for these additional Object Properties:

  • Width

  • Height

For supported Video formats, the test looks for these additional Object Properties:

  • Width

  • Height

  • SampleRate

  • NumberOfChannels

  • ScanType

  • Audio WAVE CODEC

  • AudioBitRate

  • VideoFourCCCodec

  • VideoBitrate

  • Frames PerThousand Second

  • Encoding Profile

For supported Audio formats, the test looks for these additional Object Properties:

  • Artist

  • Track

  • AlbumName

  • AlbumArtist

  • SampleRate

  • NumberOfChannels

  • AudioBitRate

  • AudioWaveCodec

All other supported operations, device properties, and object properties are considered optional and therefore will be validated according to implementation details defined in the Picture Transfer Protocol (PTP) for Digital Still Photography Devices, Version 1.0 (PIMA15740) and Media Transfer Protocol (MTP), Revision 1.0.

Run Time: Test duration depends on the number of supported capabilities, formats, and operations. Run time is approximately 2 hours.
Log File: MtpTestLog.xml
System Restart Required: No
Test Category: Cellular Handset
Supported operating systems for logo testing:
Windows Vista
Program: MtpTest.exe

Requirements

Software Requirements

The Cell Phone [Windows Vista Premium Logo] MTP Compliance Test tool runs on the following Windows operating systems:

  • Windows Vista

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Tester Knowledge Requirements

To run the portable media device tests, testers must know how to:

  • Switch a device to a computer connectivity mode before plugging it in.

  • Plug a device into a USB port of the computer and maintain the connectivity throughout 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.

Processor

The Cell Phone [Windows Vista Premium Logo] MTP Compliance Test tool runs on the following processor architectures:

  • x86

  • x64

Running the Cell Phone [Windows Vista Premium Logo] MTP Compliance Test

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. Upon completion of the test, Mtpinfup.exe will update the driver back to the original in-box driver Wpdmtp.inf. If an optional capability is not supported by the device, the test will skip that test case.

Before launching the test, ensure that the device is fully charged. The device under test MUST have a sample of each media type supported in its local storage.

Command Syntax

Command option | Description
mtptest.exe | With no options, launches the GUI.
-hct (or /hct) | Runs the test in logo mode.
/p:DscGoldTestsProfile.xml | Uses the Premium test profile for Cell Phone to validate logo compliance.
/g:DscGoldTestGuids.xml | Uses test case GUID mapping for Premium logo for Cell Phones.
/r:pmpMDVideo.xml | Uses specific test profile to validate required operations for the Cell Phone device class.
/id:"[WDKDeviceID]" | Used to identify target device under test, if there are more than one device attached.

Code Tour

The following files are included to support the execution of Cell Phone [Windows Vista Premium Logo] MTP Compliance Test.

File Manifest

File | Location
MtpTest.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
wpdmtpwrapper.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpHelperLibrary.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpLib.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpUtils.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
mtpinfup.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
Mtptest.inf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
MtpTest.cat | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
PropertySpecifications.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
HugeWmaFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.asf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.avi | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.bmp | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.gif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.html | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.jpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mp3 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.png | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.script | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.tif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.txt | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wav | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wmv | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
DscGoldTestGuids.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
DscGoldTestsProfile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
pmpMDVideo.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\

Cautions

Run the test with only one device connected at a time.

For Windows Logo Program for Hardware requirements, run the test with the provided test case selection profiles.

Do not modify the following files:

  • Mtptest.inf

  • pmpMDVideo.xml

  • TestFile.xml

  • PropertySpecifications.xml

  • DscGoldTestGuids.xml

  • DscGoldTestsProfile.xml

Troubleshooting

  • Make sure that the device is plugged in and active before commencing the test.

  • Make sure that the device shows up in Device Manager under Windows Portable Devices.

  • Check the test log file for any error logging.

  • Log in as Administrator, as this test involves updating to a test driver and reverting back to the original driver.


Digital Still Camera Windows HD Imaging Additional Qualification Test (MANUAL)

Type: Manual Test

Overview

The Digital Still Camera Windows HD Imaging Additional Qualification Test (MANUAL) is a simple manual test that verifies compliance with the Windows HD Imaging Additional Qualification (AQ). Digital Still Cameras that pass this test qualify for the Windows HD Imaging AQ and can market the device as such.

Details

The Digital Still Camera Windows HD Imaging Additional Qualification Test (MANUAL) prompts the user to answer the following question:

To qualify for the Windows HD Imaging Additional Qualification the Digital Camera must support one (or more) of the following image formats:

  • RAW with WIC codec (32 and 64-bit)

  • HD Photo

  • JPEG XR

Does this camera support one of these formats?

  • Yes

  • No

Run Time: Less than 1 minute
Log File: Shell Prompt
System Restart Required: No
Test Category: Digital Still Camera
Supported operating systems for Logo testing:

  • Windows 7

Program: Windows Logo Kit (WLK) test shell

Requirements

Software Requirements

The Digital Still Camera Windows HD Imaging Additional Qualification Test (MANUAL) tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The Digital Still Camera Windows HD Imaging Additional Qualification Test (MANUAL) tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

The Digital Still Camera Windows HD Imaging Additional Qualification Test (MANUAL) tool returns PASS or FAIL based on user input.

Refer to the specific "Testing Overview" section for the device under test.

Test Assertions

This is a manual test case that does not include Test Assertions.


Media Player [Windows Vista Basic Logo] MTP Compliance Test

Type: Automated Test

Overview

The Media Player [Windows Vista Basic Logo] MTP Compliance Test validates compliance with Picture Transfer Protocol (PTP) and Media Transfer Protocol (MTP). This suite of tests ensures that devices use the MTP class driver that ships with Windows Vista comply with PTP and/or MTP implementation standards. This tool is directed at Media Player devices that use the MTP protocol. This test is used to validate compliance with defined protocols based on requirements documented in the Windows Logo Program.

This test does not cover the following items:

  • Digital Rights Management validation

  • Devices that are not MTP-based

  • Devices that use proprietary (third-party) drivers that works with the Windows Portable Device (WPD) driver stack

Details

The Media Player [Windows Vista Basic Logo] MTP Compliance Test requires that a MTP-compatible device is installed. The test is fully automated with Pass/Fail results for each requirement.

This test is divided into the following functional categories:

  • Device Capabilities tests

  • Operations tests

  • Device Properties

  • Object Property tests

Each of the functional categories mentioned above contain child test cases, testing the sub components that fall under the corresponding category.

The test will validate that the following Operations are supported by the device:

  • OpenSession

  • CloseSession

  • GetDeviceInfo

  • GetStorageIDs

  • GetStorageInfo

  • GetObject

  • GetDevicePropDesc

  • GetDevicePropValue

  • SetDevicePropValue

  • DeleteObject

  • SendObject

  • GetNumObjects

  • GetObjectHandles

  • GetObjectInfo

  • SendObjectInfo

  • GetPartialObject

  • GetObjectPropsSupported

  • GetObjectPropDesc

  • GetObjectPropValue

  • SetObjectPropValue

  • GetObjectReferences

  • SetObjectReferences

The test validates that the following device properties are supported:

  • Synchronization Partner

  • Device Friendly Name

The test validates that the following formats are supported:

  • Undefined

  • Association

  • ASF

  • WMA

  • WMV

  • MP3

  • AbstractAudioAlbum

  • AbstractAudioVideoPlaylist

For AbstractAudioAlbum, the following properties are verified:

  • Genre

  • AlbumArtist

The test validates that the following Object Properties are supported for each supported format:

  • StorageID

  • ObjectFormat

  • ProtectionStatus

  • ObjectSize

  • ObjectFileName

  • ParentObject

  • PersistentUniqueObjectIdentifier

  • Name

  • Non-Consumable

For supported Image formats, the test looks for these additional Object Properties:

  • Width

  • Height

For supported Video formats, the test looks for these additional Object Properties:

  • Width

  • Height

  • SampleRate

  • NumberOfChannels

  • ScanType

  • Audio WAVE CODEC

  • AudioBitRate

  • VideoFourCCCodec

  • VideoBitrate

  • Frames PerThousand Second

  • Encoding Profile

For supported Audio formats, the test looks for these additional Object Properties:

  • Artist

  • Track

  • AlbumName

  • AlbumArtist

  • SampleRate

  • NumberOfChannels

  • AudioBitRate

  • AudioWaveCodec

All other supported operations, device properties, and object properties are considered optional and therefore will be validated according to implementation details defined in the Picture Transfer Protocol (PTP) for Digital Still Photography Devices, Version 1.0 (PIMA15740) and Media Transfer Protocol (MTP), Revision 1.0.

Run Time: Test duration depends on the number of supported capabilities, formats, and operations. Run time is approximately 2 hours.
Log File: MtpTestLog.xml
System Restart Required: No
Test Category: Portable Media Player
Supported operating systems for logo testing:
Windows Vista
Program: MtpTest.exe

Requirements

Software Requirements

The Media Player [Windows Vista Basic Logo] MTP Compliance Test tool runs on the following Windows operating systems:

  • Windows Vista

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Tester Knowledge Requirements

To run the portable media device tests, testers must know how to:

  • Switch a device to a computer connectivity mode before plugging it in.

  • Plug a device into a USB port of the computer and maintain the connectivity throughout 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.

Processor

The Media Player [Windows Vista Basic Logo] MTP Compliance Test tool runs on the following processor architectures:

  • x86

  • x64

Running the Media Player [Windows Vista Basic Logo] MTP Compliance Test

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. Upon completion of the test, Mtpinfup.exe will update the driver back to the original in-box driver Wpdmtp.inf. If an optional capability is not supported by the device, the test will skip that test case.

Before launching the test, ensure that the device is fully charged. The device under test MUST have a sample of each media type supported in its local storage.

Command Syntax

Command option | Description
mtptest.exe | With no options, launches the GUI.
-hct (or /hct) | Runs the test in logo mode.
/p:DscSilverTestsProfile.xml | Uses the Basic test profile for Media Players to validate logo compliance.
/g:DscSilverTestGuids.xml | Uses test case GUID mapping for Basic logo for Media Players.
/r:pmpMDVideo.xml | Uses specific test profile to validate required operations for the Media Player device class.
/id:"[WDKDeviceID]" | Used to identify target device under test, if there are more than one device attached.

Code Tour

The following files are included to support the execution of Media Player [Windows Vista Basic Logo] MTP Compliance Test.

File Manifest

File | Location
MtpTest.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
wpdmtpwrapper.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpHelperLibrary.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpLib.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpUtils.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
mtpinfup.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
Mtptest.inf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
MtpTest.cat | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
PropertySpecifications.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
HugeWmaFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.asf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.avi | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.bmp | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.gif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.html | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.jpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mp3 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.png | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.script | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.tif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.txt | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wav | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wmv | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
DscSilverTestGuids.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
DscSilverTestsProfile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
pmpMDVideo.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\

Cautions

Run the test with only one device connected at a time.

For Windows Logo Program for Hardware requirements, run the test with the provided test case selection profiles.

Do not modify the following files:

  • Mtptest.inf

  • pmpMDVideo.xml

  • TestFile.xml

  • PropertySpecifications.xml

  • DscSilverTestGuids.xml

  • DscSilverTestsProfile.xml

Troubleshooting

  • Make sure that the device is plugged in and active before commencing the test.

  • Make sure that the device shows up in Device Manager under Windows Portable Devices.

  • Check the test log file for any error logging.

  • Log in as Administrator, as this test involves updating to a test driver and reverting back to the original driver.


Media Player [Windows Vista Premium Logo] MTP Compliance Test

Type: Automated Test

Overview

The Media Player [Windows Vista Premium Logo] MTP Compliance Test validates compliance with Picture Transfer Protocol (PTP) and Media Transfer Protocol (MTP). This suite of tests ensures that devices use the MTP class driver that ships with Windows Vista comply with PTP and/or MTP implementation standards. This tool is directed at Media Player devices that use the MTP protocol. This test is used to validate compliance with defined protocols based on requirements documented in the Windows Logo Program.

This test does not cover the following items:

  • Digital Rights Management validation

  • Devices that are not MTP-based

  • Devices that use proprietary (third-party) drivers that works with the Windows Portable Device (WPD) driver stack

Details

The Media Player [Windows Vista Premium Logo] MTP Compliance Test requires that a MTP-compatible device is installed. The test is fully automated with Pass/Fail results for each requirement.

This test is divided into the following functional categories:

  • Device Capabilities tests

  • Operations tests

  • Device Properties

  • Object Property tests

Each of the functional categories mentioned above contain child test cases, testing the sub components that fall under the corresponding category.

The test will validate that the following Operations are supported by the device:

  • OpenSession

  • CloseSession

  • GetDeviceInfo

  • GetStorageIDs

  • GetStorageInfo

  • GetObject

  • GetDevicePropDesc

  • GetDevicePropValue

  • SetDevicePropValue

  • DeleteObject

  • SendObject

  • GetNumObjects

  • GetObjectHandles

  • GetObjectInfo

  • SendObjectInfo

  • GetPartialObject

  • GetObjectPropsSupported

  • GetObjectPropDesc

  • GetObjectPropValue

  • SetObjectPropValue

  • GetObjectReferences

  • SetObjectReferences

The test validates that the following device properties are supported:

  • Synchronization Partner

  • Device Friendly Name

The test validates that the following formats are supported:

  • Undefined

  • Association

  • AbstractAudioAlbum

  • AbstractAudioVideoPlaylist

For AbstractAudioAlbum, the following properties are verified:

  • Genre

  • AlbumArtist

The test validates that the following Object Properties are supported for each supported format:

  • StorageID

  • ObjectFormat

  • ProtectionStatus

  • ObjectSize

  • ObjectFileName

  • ParentObject

  • PersistentUniqueObjectIdentifier

  • Name

  • Non-Consumable

For supported Image formats, the test looks for these additional Object Properties:

  • Width

  • Height

For supported Video formats, the test looks for these additional Object Properties:

  • Width

  • Height

  • SampleRate

  • NumberOfChannels

  • ScanType

  • Audio WAVE CODEC

  • AudioBitRate

  • VideoFourCCCodec

  • VideoBitrate

  • Frames PerThousand Second

  • Encoding Profile

For supported Audio formats, the test looks for these additional Object Properties:

  • Artist

  • Track

  • AlbumName

  • AlbumArtist

  • SampleRate

  • NumberOfChannels

  • AudioBitRate

  • AudioWaveCodec

All other supported operations, device properties, and object properties are considered optional and therefore will be validated according to implementation details defined in the Picture Transfer Protocol (PTP) for Digital Still Photography Devices, Version 1.0 (PIMA15740) and Media Transfer Protocol (MTP), Revision 1.0.

Run Time: Test duration depends on the number of supported capabilities, formats, and operations. Run time is approximately 2 hours.
Log File: MtpTestLog.xml
System Restart Required: No
Test Category: Portable Media Player
Supported operating systems for logo testing:
Windows Vista
Program: MtpTest.exe

Requirements

Software Requirements

The Media Player [Windows Vista Premium Logo] MTP Compliance Test tool runs on the following Windows operating systems:

  • Windows Vista

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Tester Knowledge Requirements

To run the portable media device tests, testers must know how to:

  • Switch a device to a computer connectivity mode before plugging it in.

  • Plug a device into a USB port of the computer and maintain the connectivity throughout 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.

Processor

The Media Player [Windows Vista Premium Logo] MTP Compliance Test tool runs on the following processor architectures:

  • x86

  • x64

Running the Media Player [Windows Vista Premium Logo] MTP Compliance Test

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. Upon completion of the test, Mtpinfup.exe will update the driver back to the original in-box driver Wpdmtp.inf. If an optional capability is not supported by the device, the test will skip that test case.

Before launching the test, ensure that the device is fully charged. The device under test MUST have a sample of each media type supported in its local storage.

Command Syntax

Command option | Description
mtptest.exe | With no options, launches the GUI.
-hct (or /hct) | Runs the test in logo mode.
/p:DscGoldTestsProfile.xml | Uses the Premium test profile for Media Players to validate logo compliance.
/g:DscGoldTestGuids.xml | Uses test case GUID mapping for Premium logo for Media Players.
/r:pmpMDVideo.xml | Uses specific test profile to validate required operations for the Media Player device class.
/id:"[WDKDeviceID]" | Used to identify target device under test, if there are more than one device attached.

Code Tour

The following files are included to support the execution of Media Player [Windows Vista Premium Logo] MTP Compliance Test.

File Manifest

File | Location
MtpTest.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
wpdmtpwrapper.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpHelperLibrary.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpLib.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpUtils.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
mtpinfup.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
Mtptest.inf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
MtpTest.cat | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\LH\
PropertySpecifications.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
HugeWmaFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.asf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.avi | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.bmp | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.gif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.html | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.jpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mp3 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.png | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.script | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.tif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.txt | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wav | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wmv | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
DscGoldTestGuids.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
DscGoldTestsProfile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
pmpMDVideo.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\

Cautions

Run test with only one device connected at a time.

For Windows Logo Program for Hardware requirements, run the test with the provided test case selection profiles.

Do not modify the following files:

  • Mtptest.inf

  • pmpMDVideo.xml

  • TestFile.xml

  • PropertySpecifications.xml

  • DscGoldTestGuids.xml

  • DscGoldTestsProfile.xml

Troubleshooting

  • Make sure that the device is plugged in and active before commencing the test.

  • Make sure that the device shows up in Device Manager under Windows Portable Devices.

  • Check the test log file for any error logging.

  • Log in as Administrator, as this test involves updating to a test driver and reverting back to the original driver.


MTP Compliance Test - Cameras

Type: Automated Test

Overview

The MTP Compliance Test - Cameras validates compliance with Picture Transfer Protocol (PTP) and Media Transfer Protocol (MTP). This suite of tests ensures that devices that use the MTP class driver that ships with Windows Vista comply with PTP and/or MTP implementation standards. This tool is directed at Camera or Camcorder devices that use the MTP protocol. This test is used to validate compliance with defined protocols based on requirements documented in the Windows Logo Program.

This test does not cover the following items:

  • Digital Rights Management validation

  • Devices that are not PTP or MTP-based

  • Devices that use proprietary (third-party) drivers that works with the Windows Portable Device (WPD) driver stack

Details

The MTP Compliance Test - Cameras requires that a PTP or MTP-compatible device is installed. The test is fully automated with Pass/Fail results for each requirement.

This test is divided into the following functional categories:

  • Device Capabilities tests

  • Operations tests

  • Device Properties

  • Object Property tests

Each of the functional categories mentioned above contain child test cases, testing the sub components that fall under the corresponding category.

The test will validate that the following operations are supported by the device:

  • OpenSession

  • CloseSession

  • GetDeviceInfo

  • GetStorageIDs

  • GetStorageInfo

  • GetNumObjects

  • GetObjectHandles

  • GetObjectInfo

  • GetObject

  • GetDevicePropDesc

  • GetDevicePropValue

  • DeleteObject

The test validates that the following device properties are supported:

  • BatteryLevel (required starting June 2010)

The test validates that the following formats are supported:

  • Association

  • EXIF/JPEG

All other supported operations, device properties, and object properties are considered optional and therefore will be validated according to implementation details defined in the Picture Transfer Protocol (PTP) for Digital Still Photography Devices, Version 1.0 (PIMA15740) and Media Transfer Protocol (MTP), Revision 1.0.

Run Time: Test duration depends on the number of supported capabilities, formats, and operations. Run time can vary up to 2 hours.
Log File: WTTTestLog.xml
System Restart Required: No
Test Category: Digital Still Camera
Supported operating systems for logo testing:
Windows 7
Program: MtpTest.exe

Requirements

Software Requirements

The MTP Compliance Test - Cameras tool runs on the following Windows operating systems:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Tester Knowledge Requirements

To run MTP Compliance Test - Cameras test, testers must know how to:

  • Switch a device to a computer connectivity mode before plugging it in.

  • Plug a device into a USB port of the computer and maintain the connectivity throughout 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.

Processor

The MTP Compliance Test - Cameras tool runs on the following processor architectures:

  • x86

  • x64

Running the MTP Compliance Test - Cameras

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. Upon completion of the test, Mtpinfup.exe will update the driver back to the original in-box driver Wpdmtp.inf. If an optional capability is not supported by the device, the test will skip that test case.

Before launching the test, ensure that the device is fully charged. The device under test MUST have a sample of each media type supported in its local storage.

The MTP Test tool will copy the appropriate test content to the device to test the device.

Command Syntax

Command option | Description
mtptest.exe | With no options, launches the GUI.
-hct (or /hct) | Runs the test in logo mode with auto start and auto end.
/p:WpdMtptestProfile.xml | Uses the Basic test profile for Cameras to validate logo compliance.
/g:WpdMtptestGuids.xml | Uses test case GUID mapping for Basic logo for Cameras.
/r:MtpCamera.xml | Uses specific test profile to validate required operations for the Camera device class.

Code Tour

The following files are included to support the execution of MTP Compliance Test - Cameras.

File Manifest

File | Location
MtpTest.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
wpdmtpwrapper.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpHelperLibrary.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpLib.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpUtils.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
mtpinfup.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
Mtptest_win7.inf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
MtpTest.cat | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
PropertySpecifications.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
HugeWmaFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.asf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.avi | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.bmp | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.gif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.html | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.jpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mp3 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.png | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.script | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.tif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.txt | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wav | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wmv | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
WpdMtptestGuids.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
WpdMtptestProfile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpCamera.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\

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 the following files:

  • Mtptest_win7.inf

  • MtpCamera.xml

  • TestFile.xml

  • WpdMtptestGuids.xml

  • WpdMtptestProfile.xml

  • PropertySpecifications.xml

Troubleshooting

  • Make sure that the device is plugged in and active before commencing the test.

  • Make sure that the device shows up in Device Manager under Windows Portable Devices.

  • Check the test log file for any error logging.

  • Log in as Administrator, as this test involves updating to a test driver and reverting back to the original driver.


MTP Compliance Test - Cell Phones

Type: Automated Test

Overview

The MTP Compliance Test - Phones validates compliance with the Media Transfer Protocol (MTP), Revision 1.0. This suite of tests ensures that devices that use the MTP class driver that ships with Windows 7. This tool is directed at Cell Phone devices that connect using the MTP protocol. This test is used to validate compliance with defined protocols based on requirements documented in the Windows Logo Program.

This test does not cover the following items:

  • Digital Rights Management validation

  • Devices that are not PTP or MTP-based

  • Devices that use proprietary (third-party) drivers that works with the Windows Portable Device (WPD) driver stack

Details

The MTP Compliance Test - Cell Phones test requires that a MTP-compatible device is installed. The test is fully automated with Pass/Fail results for each requirement.

This test is divided into the following functional categories:

  • Device Capabilities tests

  • Operations tests

  • Device Properties

  • Object Property tests

Each of the functional categories mentioned above contain child test cases, testing the sub components that fall under the corresponding category.

The test will validate that the following Operations are supported by the device:

  • OpenSession

  • CloseSession

  • GetDeviceInfo

  • GetStorageIDs

  • GetStorageInfo

  • GetObject

  • GetDevicePropDesc

  • GetDevicePropValue

  • SetDevicePropValue

  • DeleteObject

  • SendObject

  • GetNumObjects

  • GetObjectHandles

  • GetObjectInfo

  • SendObjectInfo

  • GetPartialObject

  • GetObjectPropsSupported

  • GetObjectPropDesc

  • GetObjectPropValue

  • SetObjectPropValue

  • GetObjectReferences

  • SetObjectReferences

The test validates that the following device properties are supported:

  • Synchronization Partner

  • Device Friendly Name

The test validates that the following formats are supported:

  • Undefined

  • Association

  • AbstractAudioAlbum

  • AbstractAudioVideoPlaylist

For AbstractAudioAlbum, the following properties are verified:

  • Genre

  • AlbumArtist

The test validates that the following Object Properties are supported for each supported format:

  • StorageID

  • ObjectFormat

  • ProtectionStatus

  • ObjectSize

  • ObjectFileName

  • ParentObject

  • PersistentUniqueObjectIdentifier

  • Name

  • Non-Consumable

For supported Image formats, the test looks for these additional Object Properties:

  • Width

  • Height

For supported Video formats, the test looks for these additional Object Properties:

  • Width

  • Height

  • SampleRate

  • NumberOfChannels

  • ScanType

  • Audio WAVE CODEC

  • AudioBitRate

  • VideoFourCCCodec

  • VideoBitrate

  • Frames PerThousand Second

  • Encoding Profile

For supported Audio formats, the test looks for these additional Object Properties:

  • Artist

  • Track

  • AlbumName

  • AlbumArtist

  • SampleRate

  • NumberOfChannels

  • AudioBitRate

  • AudioWaveCodec

All other supported operations, device properties, and object properties are considered optional and therefore will be validated according to implementation details defined in the Picture Transfer Protocol (PTP) for Digital Still Photography Devices, Version 1.0 (PIMA15740) and Media Transfer Protocol (MTP), Revision 1.0.

Run Time: Test duration depends on the number of supported capabilities, formats, and operations. Run time can vary up to 2 hours.
Log File: WTTTestLog.xml
System Restart Required: No
Test Category: Cellular Handset
Supported operating systems for logo testing:
Windows 7
Program: MtpTest.exe

Requirements

Software Requirements

The MTP Compliance Test - Cell Phones tool runs on the following Windows operating systems:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Tester Knowledge Requirements

To run MTP Compliance Test - Cell Phones test, testers must know how to:

  • Switch a device to a computer connectivity mode before plugging it in.

  • Plug a device into a USB port of the computer and maintain the connectivity throughout 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.

Processor

The MTP Compliance Test - Cell Phones tool runs on the following processor architectures:

  • x86

  • x64

Running the MTP Compliance Test - Cell Phones

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. Upon completion of the test, Mtpinfup.exe will update the driver back to the original in-box driver Wpdmtp.inf. If an optional capability is not supported by the device, the test will skip that test case.

Before launching the test, ensure that the device is fully charged. The device under test MUST have a sample of each media type supported in its local storage.

The MTP Test tool will copy the appropriate test content to the device to test the device.

Command Syntax

Command option | Description
mtptest.exe | With no options, launches the GUI.
-hct (or /hct) | Runs the test in logo mode with auto start and auto end.
/p:WpdMtptestProfile.xml | Uses the Basic test profile for Cell Phones to validate logo compliance.
/g:WpdMtptestServiceGuids.xml | Uses test case GUID mapping for logo for Cell Phones.
/r:MtpCellphone.xml | Uses specific test profile to validate required operations for the Cell Phone device class.

Code Tour

The following files are included to support the execution of MTP Compliance Test - Cell Phones.

File Manifest

File | Location
MtpTest.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
wpdmtpwrapper.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpHelperLibrary.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpLib.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpUtils.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
mtpinfup.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
Mtptest_win7.inf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
MtpTest.cat | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
PropertySpecifications.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
HugeWmaFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.asf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.avi | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.bmp | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.gif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.html | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.jpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mp3 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.png | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.script | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.tif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.txt | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wav | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wmv | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
WpdMtptestGuids.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
WpdMtptestProfile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpCellphone.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\

Cautions

Run test with only one device connected at a time.

For Windows Logo Program Hardware requirements, run the test with the provided test case selection profiles.

Do not modify the following files:

  • Mtptest_win7.inf

  • MtpCellphone.xml

  • TestFile.xml

  • WpdMtptestGuids.xml

  • WpdMtptestProfile.xml

  • PropertySpecifications.xml

Troubleshooting

  • Make sure that the device is plugged in and active before commencing the test.

  • Make sure that the device shows up in Device Manager under Windows Portable Devices.

  • Check the test log file for any error logging.

  • Log in as Administrator, as this test involves updating to a test driver and reverting back to the original driver.


MTP Compliance Test - Media Players

Type: Automated Test

Overview

The MTP Compliance Test - Media Players validates compliance with the Media Transfer Protocol (MTP), Revision 1.0. This suite of tests ensures that devices use the MTP class driver that ships with Windows 7. This tool is directed at Portable Media Player devices that connect using the MTP protocol. This test is used to validate compliance with defined protocols based on requirements documented in the Windows Logo Program.

This test does not cover the following items:

  • Digital Rights Management validation

  • Devices that are not PTP or MTP-based

  • Devices that use proprietary (third-party) drivers that works with the Windows Portable Device (WPD) driver stack

Details

The MTP Compliance Test - Media Players test requires that a MTP-compatible device is installed. The test is fully automated with Pass/Fail results for each requirement.

This test is divided into the following functional categories:

  • Device Capabilities tests

  • Operations tests

  • Device Properties

  • Object Property tests

Each of the functional categories mentioned above contain child test cases, testing the sub components that fall under the corresponding category.

The test will validate that the following Operations are supported by the device:

  • OpenSession

  • CloseSession

  • GetDeviceInfo

  • GetStorageIDs

  • GetStorageInfo

  • GetObject

  • GetDevicePropDesc

  • GetDevicePropValue

  • SetDevicePropValue

  • DeleteObject

  • SendObject

  • GetNumObjects

  • GetObjectHandles

  • GetObjectInfo

  • SendObjectInfo

  • GetPartialObject

  • GetObjectPropsSupported

  • GetObjectPropDesc

  • GetObjectPropValue

  • SetObjectPropValue

  • GetObjectReferences

  • SetObjectReferences

The test validates that the following device properties are supported:

  • Synchronization Partner

  • Device Friendly Name

The test validates that the following formats are supported:

  • Undefined

  • Association

  • AbstractAudioAlbum

  • AbstractAudioVideoPlaylist

For AbstractAudioAlbum, the following properties are verified:

  • Genre

  • AlbumArtist

The test validates that the following Object Properties are supported for each supported format:

  • StorageID

  • ObjectFormat

  • ProtectionStatus

  • ObjectSize

  • ObjectFileName

  • ParentObject

  • PersistentUniqueObjectIdentifier

  • Name

  • Non-Consumable

For supported Image formats, the test looks for these additional Object Properties:

  • Width

  • Height

For supported Video formats, the test looks for these additional Object Properties:

  • Width

  • Height

  • SampleRate

  • NumberOfChannels

  • ScanType

  • Audio WAVE CODEC

  • AudioBitRate

  • VideoFourCCCodec

  • VideoBitrate

  • Frames PerThousand Second

  • Encoding Profile

For supported Audio formats, the test looks for these additional Object Properties:

  • Artist

  • Track

  • AlbumName

  • AlbumArtist

  • SampleRate

  • NumberOfChannels

  • AudioBitRate

  • AudioWaveCodec

All other supported operations, device properties, and object properties are considered optional and therefore will be validated according to implementation details defined in the Picture Transfer Protocol (PTP) for Digital Still Photography Devices, Version 1.0 (PIMA15740) and Media Transfer Protocol (MTP), Revision 1.0.

Run Time: Test duration depends on the number of supported capabilities, formats, and operations. Run time can vary up to 2 hours.
Log File: WTTTestLog.xml
System Restart Required: No
Test Category: Portable Media Player
Supported operating systems for logo testing:
Windows 7
Program: MtpTest.exe

Requirements

Software Requirements

The MTP Compliance Test - Media Players tool runs on the following Windows operating systems:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Tester Knowledge Requirements

To run MTP Compliance Test - Media Players test, testers must know how to:

  • Switch a device to a computer connectivity mode before plugging it in.

  • Plug a device into a USB port of the computer and maintain the connectivity throughout 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.

Processor

The MTP Compliance Test - Media Players tool runs on the following processor architectures:

  • x86

  • x64

Running the MTP Compliance Test - Media Players

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. Upon completion of the test, Mtpinfup.exe will update the driver back to the original in-box driver Wpdmtp.inf. If an optional capability is not supported by the device, the test will skip that test case.

Before launching the test, ensure that the device is fully charged. The device under test MUST have a sample of each media type supported in its local storage.

The MTP Test tool will copy the appropriate test content to the device to test the device.

Command Syntax

Command option | Description
mtptest.exe | With no options, launches the GUI.
-hct (or /hct) | Runs the test in logo mode with auto start and auto end.
/p:WpdMtptestProfile.xml | Uses the Basic test profile for a Media Player to validate logo compliance.
/g:WpdMtptestServiceGuids.xml | Uses test case GUID mapping for logo for Media Player.
/r:MtpMediaPlayer.xml | Uses specific test profile to validate required operations for the Media Player device class.

Code Tour

The following files are included to support the execution of MTP Compliance Test - Media Players.

File Manifest

File | Location
MtpTest.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
wpdmtpwrapper.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpHelperLibrary.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpLib.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpUtils.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
mtpinfup.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
Mtptest_win7.inf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
MtpTest.cat | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
PropertySpecifications.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
HugeWmaFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.asf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.avi | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.bmp | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.gif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.html | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.jpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mp3 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.png | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.script | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.tif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.txt | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wav | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wmv | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
WpdMtptestGuids.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
WpdMtptestProfile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpMediaPlayer.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\

Cautions

Run the test with only one device connected at a time.

For Windows Logo Program Hardware requirements, run the test with the provided test case selection profiles.

Do not modify the following files:

  • Mtptest_win7.inf

  • MtpMediaPlayer.xml

  • TestFile.xml

  • WpdMtptestGuids.xml

  • WpdMtptestProfile.xml

  • PropertySpecifications.xml

Troubleshooting

  • Make sure that the device is plugged in and active before commencing the test.

  • Make sure that the device shows up in Device Manager under Windows Portable Devices.

  • Check the test log file for any error logging.

  • Log in as Administrator, as this test involves updating to a test driver and reverting back to the original driver.


MTP Compliance Test - Other Portable

Type: Automated Test

Overview

MTP Compliance Test - Other Portable validates compliance with the Windows implementation of the Media Transfer Protocol (MTP), Revision 1.0. This suite of tests ensures that devices use the MTP class driver that ships with Windows 7. This tool is directed at Other Portable devices that connect using the MTP protocol. This test is used to validate compliance with defined protocols based on requirements documented in the Windows Logo Program.

This test does not cover the following:

  • Digital Rights Management validation

  • Devices that are not MTP-based or PTP-based

  • Devices that use proprietary (third-party) drivers that replace MTP functionality

Details

This test requires that an MTP-compatible device is installed. The test is fully automated with Pass/Fail results for each requirement.

This test is divided into the following functional categories:

  • Device Capabilities tests

  • Operations tests

  • Device Properties

  • Object Property tests

Each of the functional categories above contains child test cases that test the subcomponents under each corresponding category.

The test validates that the following Operations are supported by the device:

  • GetDeviceInfo

  • OpenSession

  • CloseSession

  • GetStorageIDs

  • GetStorageInfo

  • GetNumObjects

  • GetObjectHandles

  • GetObjectInfo

  • GetObject

  • GetDevicePropDesc

  • GetDevicePropValue

The test validates that the following Device Property is supported:

  • Device Friendly Name

The test validates that the following Object Format is supported:

  • Association

Optional Capabilities

Other Portable devices are not required to support audio, video, or image formats. However, if supported, MTP Compliance Test - Other Portable validates that the following is supported based on the format type(s) declared and supported by the device.

The test validates that the following Object Properties are supported for each supported format:

  • StorageID

  • ObjectFormat

  • ProtectionStatus

  • ObjectSize

  • ObjectFileName

  • ParentObject

  • PersistentUniqueObjectIdentifier

  • Name

  • Non-Consumable

  • DateModified

For supported Video formats, the test looks for the following additional Object Properties:

  • Width

  • Height

For supported Image formats, the test looks for the following additional Object Properties:

  • Width

  • Height

  • Use Count

  • SampleRate

  • NumberOfChannels

  • ScanType

  • Audio WAVE CODEC

  • AudioBitRate

  • VideoFourCCCodec

  • VideoBitrate

  • Frames PerThousand Second

  • Encoding Profile

For supported Audio formats, the test looks for the following additional Object Properties:

  • Artist

  • Track

  • Genre

  • UseCount

  • AlbumName

  • AlbumArtist

  • SampleRate

  • NumberOfChannels

  • AudioBitRate

  • AudioWaveCodec

All other supported operations, device properties, and object properties are considered optional and are validated according to implementation details defined in the Picture Transfer Protocol (PTP) for Digital Still Photography Devices, Version 1.0 (PIMA15740) and Media Transfer Protocol (MTP), Revision 1.0.

Run Time: Test duration depends on the number of supported capabilities, formats, and operations. Run time is approximately 1 hour.
Log File: MtpTestLog.log, MtpTestLog.xml
System Restart Required: No
Test Category: Other Portable
Supported operating systems for logo testing: Windows 7
Program: MtpTest.exe

Requirements

Software Requirements

The MTP Compliance Test - Other Portable tool runs on the following Windows operating systems:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. You may 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.

  • Device under test

  • Computer that meets the minimum requirements defined in "System Requirements" in Install.htm - Installation Guide

  • System must be USB 2.0 compliant

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Tester Knowledge Requirements

To run MTP Compliance Test - Other Portable, you must know how to perform the following actions:

  • Switch a device to the correct mode to connect to a computer.

  • Connect the device under test to a USB on the computer, and maintain the connectivity throughout 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.

Processor

The MTP Compliance Test - Other Portable tool runs on the following processor architectures:

  • x86

  • x64

Running MTP Compliance Test - Other Portable

The MTP device should be active and plugged in before commencing the test. The tool Mtpinfup.exe updates the driver for the attached MTP device to a signed test .inf file Mtptest_win7.inf. When the test is complete, Mtpinfup.exe updates the driver back to the original in-box driver Wpdmtp_win7.inf. If an optional capability is not supported by the device, the test will skip that test case.

  • If the device has a battery, make sure that the device is fully charged before launching the test.

  • If the device under test supports audio, video, or image formats, it must have a sample of each media type supported in the appropriate folder in its local storage.

    The MTP Test tool will copy the appropriate test content to the device to test the device.

Command Syntax

Command option | Description
mtptest.exe | With no options, launches the GUI.
-hct (or /hct) | Runs the test in logo mode.
/p:WpdMtptestProfile.xml | Uses the Basic test profile for an Other Portable device to validate logo compliance.
/g:WpdMtptestServiceGuids.xml | Uses test case GUID mapping for logo for Other Portable devices.
/r:MtpOtherPortable.xml | Uses specific test profile to validate required operations for the Media Player device class.

Code Tour

The following files are included to support the execution of MTP Compliance Test - Other Portable.

File Manifest

File | Location
MtpTest.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
wpdmtpwrapper.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpHelperLibrary.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpLib.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpUtils.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
mtpinfup.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
Mtptest_win7.inf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
MtpTest.cat | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPInfUpdater\Win7\
PropertySpecifications.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
HugeWmaFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.asf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.avi | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.bmp | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.gif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.html | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.jpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mp3 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.mpg | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.png | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.script | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.tif | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.txt | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wav | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.wmv | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
TestFile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\resources\
WpdMtptestServiceGuids.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
WpdMtptestProfile.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\
MtpOtherPortable.xml | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\MTPTest\

Cautions

Run the test with only one device connected at a time.

For Windows Logo Program Hardware requirements, run the test with the provided test case selection profiles.

Do not modify these files:

  • Mtptest_win7.inf

  • MtpOtherPortable.xml

  • TestFile.xml

  • WpdMtptestServiceGuids.xml

  • WpdMtptestProfile.xml

  • PropertySpecifications.xml

Troubleshooting

  • Before starting the test, make sure that the device is plugged in and active.

  • Make sure that the device shows up under Device Manager Windows Portable Devices.

  • Check the test log file for any error logging.

  • Because you must update to a test driver and revert back to the original driver, log in as Administrator.


Verify Portable Media Device correctly supports Selective Suspend (MANUAL)

Type: Manual Test

Overview

This test verifies that the device is capable of entering into and resuming from selective suspend state. The test verifies this manually by:

  1. Connecting the device to the machine.

  2. Enabling the selective suspend feature from the Device Manager.

  3. Idling the device for 30 seconds and confirming that the device enters the D2 state.

  4. Verifying that the device is still immediately usable by opening a file from the device storages through the Windows shell and confirming that the device state resumes to the D0 state.

Details

Prerequisites:

  1. Ensure that the device is on and connected to the machine through USB.

  2. Ensure that the device is not being used by other system resources during testing that would read or write to the device.

  3. 30 second timer.

Run Time: ~3 minutes
Log File: No log file.

System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: WinUSB.sys

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

There are no additional software requirements. However, this test is not supported on N- or Server- skus unless the desktop experience expansion pack is installed to enable WPD functionality.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

This test will PASS if the device idles after 30 seconds of inactivity, and resumes without issue when a read or write operation is sent to the device. The test will FAIL if the device does not selective suspend gracefully: (e.g. surprise removes from the machine), or does not resume gracefully (e.g. stays suspended in D2 state after the device is accessed for a read or write operation).

Command Syntax

None.

Troubleshooting

If the device does not respond after selective suspend, unplug and replug in the device. This is known as the surprise removal event, and the test should be marked fail in this case.

Cameras typically do not allow files to be added to the storage, e.g. drag and drop or copy and paste. However, read operations are supported and should bring the device out of the D2 power state.

Code Tour

None.

Test Assertions

None.


Windows Media Device Manager (WMDM) Compliance Tests

Type: Automated tests

Overview

The Windows Media Device Manager (WMDM) Compliance Tests cover common WMDM scenarios for Portable Media Devices. The tests exercise content transfer, device initialization, and content cancellation scenarios at the WMDM level.

Details

The following three tests make up the WMDM Compliance Tests:

  • Device storage initialization

  • Transfer cancellation from PC to Device

  • Transfer cancellation from Device to PC

Initialize Device Storage

This test initializes (formats) the device using the WMDM device interface. Device must be Windows Portable Device (WPD) compliant and support the WMDM interface. No other setup is required.

Command line: WmdmCopy WmdmCopy.exe -a -r -c "WmdmCopy_Initialize_Device_Storage.pro" -l "s98wtt.dll"

  1. Get WMDM interface

    Note Test will be skipped if device does not support WMDM.

  2. Get device data

  3. IF WMDM interface exists and can be initialized
    a. Get root storage (IWMDMStorageGlobals)
    b. Initialize storage
    c. Sleep 5 seconds //some devices reboot after format
    d. Set MaxFormatRetryCount to 10
    e. WHILE WMDM device is not found
    i. Refresh the device list
    ii. If WMDM device exists break
    iii. If retry count greater than 10
    1. FAIL test
    2. break
    iv. ENDIF
    v. Sleep 2 seconds
    f. ENDWHILE

  4. ENDIF

Transfer Cancellation from PC to Device

This test verifies cancellation while transferring content to the device using WMDM device interface. Device must be WPD compliant and support the WMDM interface. No other setup is required.

Command line: WmdmCopy.exe -a -r -c "WmdmCopy_Content_Transfer_Cancellation.pro" -l "s98wtt.dll"

  1. Get WMDM interface

    Note Test will be skipped if device does not support WMDM.

  2. Get device data

  3. IF WMDM interface exists and can be initialized
    a. Get test content directory
    b. FOR count of 10
    i. Transfer test file from PC to WMDM device
    ii. Cancel transfer before completed
    iii. IF transfer passed FAIL test
    c. ENDFOR
    d. Transfer file from PC to WMDM device
    e. IF transfer failed FAIL test

  4. ENDIF

Transfer Cancellation from Device to PC

This test verifies cancellation while transferring content to the device using WMDM device interface. Device must be WPD compliant and support the WMDM interface. No other setup is required.

Command line: WmdmCopy.exe -a -r -c "WmdmCopy_Content_Transfer_From_Device_Cancellation.pro" -l "s98wtt.dll"

  1. Get WMDM interface

    Note Test will be skipped if device does not support WMDM.

  2. Get device data

  3. IF WMDM interface exists and can be initialized
    a. Get test content directory
    b. FOR count of 10
    i. Transfer test file from WMDM device to PC
    ii. Cancel transfer before completed
    iii. IF transfer passed FAIL test
    c. ENDFOR
    d. Transfer file from WMDM device to PC
    e. IF transfer failed FAIL test

  4. ENDIF

Run Time: 15 minutes
Log File: wmdmcopy.log
System Restart Required: No
Test Category: Portable Media Player; Cellular Handset
Supported operating systems for logo testing: Windows 7; Windows Vista
Program: wmdmcopy.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running WLK - WMDM Compliance Tests

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
WmdmCopy.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
-e [string] | Starts the app and runs all tests with ID\String\GUID [string]. The test case specified for this flag will be run regardless of whether it exists in the profile or not.
-l [string] | Runs the test with the s98wtt.dll included.

Code Tour

File Manifest

File | Location
WmdmCopy.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\
proghelp.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\proghelp\
s98wtt.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\common\
test.mp3 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\wdk\
test.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\wdk\
test.asf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\wdk\
WmdmCopy_Initialize_Device_Storage.pro | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\
WmdmCopy_Content_Transfer_Cancellation.pro | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\
WmdmCopy_Content_Transfer_From_Device_Cancellation.pro | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\

Troubleshooting

  • Make sure that the device is plugged in and active before commencing the test.

  • Make sure that the device shows up in Device Manager under Windows Portable Devices.

  • This test copies content to the device, make sure that there is sufficient space on the device to copy the test content over.

  • Check the test log file for any error logging.


Windows Media Device Manager (WMDM) Sync Test (MANUAL)

Type: Automated tests with manual verification upon completion

Overview

These tests use the Windows Media Device Manager (WMDM) interface for media transfer in Windows to validate that a device reports capabilities correctly. The test use Windows Media Player (WMP), which is built on the WMDM and device capabilities to copy media to the device. These scenario-based tests also take advantage of the native Windows media foundation pipeline to transcode content to formats supported by the device as defined by the devices object properties. There is a manual component to the test that requires the tester to validate that a portable device is able to successfully play back the content that was copied to the device.

Details

The WMDM Sync Test (MANUAL) attempts to transfer various audio and video files to the device using the WMP OCX. If the test files are not supported by the device, the test files will be transcoded to a format supported by the device prior to transfer. The test files have been selected to include most common file types with the intent that some files will require transcode and some will not.

Run Time: 15 minutes, plus additional time needed for manual verification of media playback on device (this depends on the devices list of supported formats)
Log File: WmpSync.log
System Restart Required: No
Test Category: Portable Media Player; Cellular Handset
Supported operating systems for logo testing: Windows 7; Windows Vista
Program: testapp.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running WLK - WMDM Sync Test (MANUAL)

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures. The last step is manual, the tester must verify content plays back correctly and content information is correctly displayed on the device.

Automated

  1. Build the WMP playlist containing content from the .\SyncContent folder.

  2. Launch the Windows Media Player device setup dialog box.

Manual

  1. Close the Sync Partnership Creation dialog box (contains directions to create sync relationship).

  2. If device storage capacity is less than 1 GB, a warning dialog will pop up that the device is not recommended for automatic sync. Click Yes to continue with automatic sync.

  3. The Windows Media Player - Device Setup dialog box appears.
    a. Make sure that Sync this device automatically is checked
    b. Verify that WLKSyncPlayList is listed under Playlists to sync.
    c. Select Finish to close the dialog box.

Automated

  • The SYNC PERF dialog appears, which indicates that the playlist is being transferred to device. This can take some time, depending on how many files need to be transcoded.

Manual

  • The Manual Task dialog box appears. Do the following:
    a. Disconnect the device from the PC.
    b. If the device supports playlists, verify that WLKSyncPlayList shows up on the device and the music is in the playlist.
    c. Verify that the following music files are on the device and render correctly:
    i. AAC_256kbps_44_1kHz_Stereo.m4a
    ii. MP3_224kbps_Stereo.mp3
    iii. WMA_192kbps_CBR_Stereo.wma
    d. Verify that the following video files are on the device and render correctly:
    i. 3G2_H264_176x164_AAC.3g2
    ii. 3GP_H264_320x240_AAC.3g
    iii. AVCHD_H264_720p_AC3.m2ts
    iv. DivX_640x480_29_97fps_MP3_48KHz_320kbps.avi
    v. Dvrms_576i_25fps_UFF_3Mbps_VBR.dvr-ms
    vi. MP4_H264_320x240_24fps_AAC.mp4
    vii. MP4_H264_720p_24fps_AAC.mp4
    viii. WMV_320x240_29_97fps_500kbps.wmv
    ix. WMV_720p_29_97fps_10Mbps.wmv
    x. WTV_480i_29_97fps_UFF_3Mbps_VBR.wtv
    e. Reconnect the device to the PC.
    f. Wait for device to enumerate on the PC.
    g. If any of the steps above fail, select Fail in the dialog; otherwise, select Pass.

Command Syntax

Command option | Description
testapp.exe | Without any options, the test enumerates devices.
/c [string] | Starts the application and runs the test cases that are specified in the .profile file.
/a [string] | Starts the application and runs through all of the test cases.
-p [string] | Starts the application and includes the WmpSync.ini
/s 'WmpSync.ini' | This file contains the parameters for the test, storage size limits, location of content, etc.
WmpSync.pro | The .profile which includes the test cases to be run.

Code Tour

File Manifest

File | Location
perftest.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\
testapp.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\
WmpSync.pro | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\perf\PerfTest\
WmpSync.ini | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wpd\perf\PerfTest\
3G2_H264_176x164_AAC.3g2 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
3GP_H264_320x240_AAC.3gp | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
AAC_256kbps_44_1kHz_Stereo.m4a | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
AVCHD_H264_720p_AC3.m2ts | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
DivX_640x480_29_97fps_MP3_48KHz_320kbps.avi | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
Dvrms_576i_25fps_UFF_3Mbps_VBR.dvr-ms | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
MP3_224kbps_Stereo.mp3 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
MP4_H264_320x240_24fps_AAC.mp4 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
MP4_H264_720p_24fps_AAC.mp4 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
WMA_192kbps_CBR_Stereo.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
WMV_320x240_29_97fps_500kbps.wmv | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
WMV_720p_29_97fps_10Mbps.wmv | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\
WTV_480i_29_97fps_UFF_3Mbps_VBR.wtv | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmmftest\data\wlkcontent\

Troubleshooting

  • Make sure that the device is plugged in and active before commencing the test.

  • Make sure that the device shows up in Device Manager under Windows Portable Devices.

  • This test copies content to the device, make sure that there is sufficient space on the device to copy the test content over.

  • Check the test log file for any error logging.


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.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Perl

Hardware Requirements

The test tool requires the following hardware:

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

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:


WMDM Compliance Test - Other portable

Type: Automated Test

Overview

The Windows Media Device Manager (WMDM) Compliance Tests cover common WMDM scenarios for Portable Media Devices. The tests exercise content transfer, device initialization, and content cancellation scenarios at the WMDM level.

Details

The following tests are the WMDM Compliance Tests:

  • Device storage initialization

  • Transfer cancellation from PC to Device

  • Transfer cancellation from Device to PC

Initialize Device Storage

This test initializes (formats) the device using the WMDM device interface. The device must be Windows Portable Device (WPD) compliant and support the WMDM interface. No other setup is required.

Command Line: WmdmCopy WmdmCopy.exe -a -r -c "WmdmCopy_Initialize_Device_Storage.pro" -l "s98wtt.dll"

  1. Get WMDM interface. (Test will be skipped if the device does not support WMDM.)

  2. Get device data.

  3. IF WMDM interface exists and can be initialized:
    a. Get root storage (IWMDMStorageGlobals).
    b. Initialize storage.
    c. Sleep 5 seconds //some devices reboot after format.
    d. Set MaxFormatRetryCount to 10.
    e. WHILE WMDM device is not found:
    i. Refresh the device list.
    ii. If WMDM device exists break.
    iii. If retry count greater than 10:
    a. FAIL test.
    b. Break.
    iv. ENDIF.
    v. Sleep 2 seconds.
    f. ENDWHILE.

  4. ENDIF.

Transfer Cancellation from PC to Device

This test verifies cancellation while transferring content to the device using WMDM device interface. The device must be WPD compliant and support the WMDM interface. No other setup is required.

Command Line: WmdmCopy.exe -a -r -c "WmdmCopy_Content_Transfer_Cancellation.pro" -l "s98wtt.dll"

  1. Get WMDM interface. (Test will be skipped if the device does not support WMDM.)

  2. Get device data.

  3. IF WMDM interface exists and can be initialized:
    a. Get test content directory.
    b. For count of 10:
    i. Transfer test file from PC to WMDM device.
    ii. Cancel transfer before completed.
    iii. IF transfer passed FAIL test:
    c. ENDFOR.
    d. Transfer file from PC to WMDM device.
    e. If transfer failed FAIL test.

  4. ENDIF.

Transfer Cancellation from Device to PC

This test verifies cancellation while transferring content to the device using WMDM device interface. Device must be WPD compliant and support the WMDM interface. No other setup is required.

Command Line: WmdmCopy.exe -a -r -c "WmdmCopy_Content_Transfer_From_Device_Cancellation.pro" -l "s98wtt.dll"

  1. Get WMDM interface. (Test will be skipped if device does not support WMDM.)

  2. Get device data.

  3. IF WMDM interface exists and can be initialized:
    a. Get test content directory.
    b. For count of 10:
    i. Transfer test file from WMDM device to PC.
    ii. Cancel transfer before completed.
    iii. If transfer passed FAIL test.
    c. ENDFOR.
    d. Transfer file from WMDM device to PC.
    e. If transfer failed FAIL test.

  4. ENDIF.

Run Time: 10 minutes
Log File: wmdmcopy.log
System Restart Required: No
Test Category: Other Portable
Supported operating systems for Logo or Signature testing: Windows 7; Windows Vista

Program: WmdmCopy.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
WmdmCopy.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
-e [string] | Starts the app and runs all tests with ID\String\GUID [string]. The test case specified for this flag will be run regardless of whether it exists in the profile or not.
-l [string] | Runs the test with the s98wtt.dll included.

Troubleshooting

  • Before starting the test, make sure that the device is plugged in and active

  • Make sure that the device shows up in Device Manager under Windows Portable Devices.

  • This test copies content to the device. Make sure that there is enough space on the device to copy the test content over.

  • Check the test log file for any error logging.

Code Tour

File | Location
WmdmCopy.exe | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\
proghelp.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\proghelp\
s98wtt.dll | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\common\
test.mp3 | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\wdk\
test.wma | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\wdk\
test.asf | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\wdk\
WmdmCopy_Initialize_Device_Storage.pro | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\
WmdmCopy_Content_Transfer_Cancellation.pro | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\
WmdmCopy_Content_Transfer_From_Device_Cancellation.pro | [TestBinRoot]\NTTEST\MULTIMEDIATEST\wmdm\wmdmcopy\

Test Assertions

PORTABLE-0057 A device that supports MTP must meet mandatory general functionality requirements to ensure expected behavior in Windows.


WPD Compliance Stress Tests (WPDCopytest-WDK)

Type: Automated Test

Overview

The Windows Portable Devices (WPD) Compliance Stress Tests (WPDCopytest-WDK) exercises the driver using the WPD application programming interface (API) and validates that it is compliant with the Windows Logo Program requirements. The target audience for this test tool is developers of third-party device driver vendor who want to verify that their driver or device fulfills the Windows Logo Program requirements to work seamlessly with the WPD stack in a protocol-independent way. This test runs fully automated, and is required to run for at least 24 hours as a long haul driver stress test.

This test does not cover the following items:

  • Legacy driver testing (only WPD class drivers will be tested)

  • Device-protocol-specific requirements (this testing is covered in separate certification tests)

  • Digital Rights Management Testing

Details

The WPD Compliance Stress Tests (WPDCopytest-WDK) runs as a C++ application. When ran outside of the Windows Logo Kit (WLK), there is a test case selection user interface and test suites can be defined using test profiles, as is the case for the WLK. It is fully automated with Pass/Fail for each requirement. The test validates the following for a WPD driver and the device connected to it:

The 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

The device/driver supports the following known function categories:

  • Required object properties and attributes

  • Resources and attributes

Function Category Requirements

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, because 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/or enumeration.

  • 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: 24 hours
Log File: Wdk_stress.log
System Restart Required: No
Test Category: Cellular Handset
Supported operating systems for Logo or Signature testing: Windows Vista; Windows XP

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Stress Tests (WPDCopytest-WDK) requires the following software:

  • Windows Vista

  • Windows XP

  • Software components included with the device under test.

  • If running Windows XP with SP2, Windows Media Player 11 is required.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The WPD Compliance Stress Tests (WPDCopytest-WDK) tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

See Cellular Handset Testing Overview for details on running this test.

Command Syntax

Command option | Description
TestApp.exe | Without any options, the test enumerates devices.
/a [string] | Starts the application and runs all of the test cases; [:flags] may be used to enable/disable modes (a, m, and d for auto, manual, and disabled respectively)
/r | Starts the application and runs the default test cases.
/c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
/p [string] | Private parameters for the application.
/u | This is a private switch for enabling WTT logging in UNICODE mode. Default is ANSI.
Wdk_stress.pro | Uses specific test profile to validate device.

Troubleshooting

  • WPD Compliance Stress Tests (WPDCopytest-WDK) supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

  • Refer to the basic Portable Device Driver Requirements at the following Microsoft Web site: http://www.microsoft.com/whdc/device/media/WPDguide.mspx.

Code Tour

The following files are included to support the execution of WPD Compliance Stress Tests (WPDCopytest-WDK).

File Manifest

File | Location
TestApp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\
WpdCopyTest.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCopytest\wdk
Wdk_stress.pro | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCopyTest\
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCopyTest\Content

Test Assertions

F.1.P.1, D.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: PORTABLE-0016 Cellular phone device driver object properties meet data type requirements
Additional Information: Device/driver must return required property values with valid datatype for Functional objects and 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_PROPERTY_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property. The property vartype requirements are described in the "Basic WPD Compliance Requirements" document. Note: this assertion covers two requirements: PORTABLE-0012 and PORTABLE-0016. If this assertion fails, both requirements will fail.
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: PORTABLE-0016 Cellular phone device driver object properties meet data type requirements
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_PROPERTY_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property. The property vartype requirements are described in the "Basic WPD Compliance Requirements" document. If not writable properties are supported, the test result is skipped. This assertion covers two requirements: PORTABLE-0013 and PORTABLE-0016. If this assertion fails, both requirements will fail.
D.4.P.4, F.4.P.4 Set Properties for Object: Device/driver should support updating of writable property values for the function or device object
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}
Windows Logo Program: PORTABLE-0012 Cellular phone device driver functional objects support required properties
Additional Information: If the device object returns the attribute WPD_PROPERTY_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 result is skipped.
C.4.P.4 Set Properties for Object: Device/driver should support updating of writable property values for content objects
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}
Windows Logo Program: PORTABLE-0013 Cellular phone device driver content objects support required properties
Additional Information: If a content object returns the attribute WPD_PROPERTY_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 result is skipped.
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: PORTABLE-0015 Cellular phone device driver supports the default resource for objects containing data
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: PORTABLE-0015 Cellular phone device driver supports the default resource for objects containing data
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.
D.1.S.1 Check WUDFRd service
Test Assertion GUID: {EDD34A8E-DBB1-4F09-9CE4-BFE1A796A75D}
Windows Logo Program: PORTABLE-0011 Cellular phone device driver is UMDF compliant
Additional Information: The User Mode Driver Framework (UMDF) redirector must be a filter driver for the current device, as described in the "Basic WPD Compliance Requirements" document.
D.1.S.2 Check WUDF CoInstaller
Test Assertion GUID: {6432E010-E541-4157-8A8D-40E4165B175F}
Windows Logo Program: PORTABLE-0011 Cellular phone device driver is UMDF compliant
Additional Information: The User Mode Driver Framework (UMDF) CoInstaller must be specified as a coinstaller for the device, as described in the "Basic WPD Compliance Requirements" document.
C.1.T.9 Device/driver resources should support required attributes
Test Assertion GUID: {6C576634-668A-4a02-9F79-DBF88317BD11}
Windows Logo Program: PORTABLE-0014 Cellular phone device driver resources support required attributes
Additional Information: If a resource is supported, the device/driver must support the required attributes for that resource. For example, if the device/driver supports WPD_RESOURCE_CONTACT_PHOTO on a data object, that resource must support the following attributes: WPD_MEDIA_WIDTH, WPD_MEDIA_HEIGHT, WPD_RESOURCE_ATTRIBUTE_TOTAL_SIZE, WPD_RESOURCE_ATTRIBUTE_FORMAT, WPD_RESOURCE_ATTRIBUTE_CAN_READ (if clients can read this resource), WPD_RESOURCE_ATTRIBUTE_CAN_WRITE (if clients can write to this resource), WPD_RESOURCE_ATTRIBUTE_CAN_DELETE (if clients can delete this resource), WPD_RESOURCE_ATTRIBUTE_OPTIMAL_READ_BUFFER_SIZE (if clients have read access to this resource), WPD_RESOURCE_ATTRIBUTE_OPTIMAL_WRITE_BUFFER_SIZE (if client have write access to this resource).
S.1.CM.1 Required Command: Get Object IDs from PUIDs
Test Assertion GUID: {423DBFED-319F-4766-BCB8-52087EEB0103}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command: WPD_COMMAND_COMMON_GET_OBJECT_IDS_FROM_PERSISTENT_UNIQUE_IDS
S.1.CM.2 Required Commands: Start Find, Find Next, End Find
Test Assertion GUID: {8FAC1FA0-B99F-46f0-BC4A-9E45DCC473D1}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required commands:WPD_COMMAND_OBJECT_ENUMERATION_START_FINDWPD_COMMAND_OBJECT_ENUMERATION_FIND_NEXTWPD_COMMAND_OBJECT_ENUMERATION_END_FIND
S.1.CM.3 Required Command: Get Supported Properties
Test Assertion GUID: {F7D463DA-8DA9-4942-ACF5-F7AAF6EE0DBD}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_SUPPORTED
S.1.CM.4 Required Command: Get Property Attributes
Test Assertion GUID: {A7AC39D0-A3A9-471b-BB09-8937EABF2ADA}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_ATTRIBUTES
S.1.CM.5 Required Command: Get Object Properties
Test Assertion GUID: {99336590-65B8-42f1-8341-187F4F0FF03B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET
S.1.CM.6 Required Command: Get All Object Properties
Test Assertion GUID: {427424F7-4C04-485b-A27A-8B63ED394F22}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_ALL
S.1.CM.7 Required Command: Get Supported Commands
Test Assertion GUID: {0D6161B0-C3C6-4de3-A6DA-CA8FF0CE0399}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_COMMANDS
S.1.CM.8 Required Command: Get Command Options
Test Assertion GUID: {6D34A5EA-E634-447d-82E1-4D771E0457F3}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_COMMAND_OPTIONS
S.1.CM.9 Required Command: Get Supported Functional Categories
Test Assertion GUID: {62B2E21B-6135-459a-93EC-67F4DED7898B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FUNCTIONAL_CATEGORIES
S.1.CM.10 Required Command: Get Functional Objects
Test Assertion GUID: {C49D25C7-A5E5-4a15-81A1-C66E7A526288}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_FUNCTIONAL_OBJECTS
S.1.CM.11 Required Command: Get Supported Content Types
Test Assertion GUID: {FF581789-FC15-4bb8-971E-2A3C21B88B0B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_CONTENT_TYPES
S.1.CM.12 Required Command: Get Supported Formats
Test Assertion GUID: {62AE52F2-DCD1-4b75-8C5A-5212FF8D4974}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FORMATS
S.1.CM.13 Required Command: Get Supported Format Properties
Test Assertion GUID: {EDF140E7-7326-4154-A840-063FE9E1CA69}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FORMAT_PROPERTIES
S.1.CM.14 Required Command: Get Fixed Property Attributes
Test Assertion GUID: {7F9BAFE8-6B2D-4609-AE9D-FA973547CDC5}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_FIXED_PROPERTY_ATTRIBUTES
S.1.CM.15 Required Command: Get Supported Events
Test Assertion GUID: {86F8EBE9-EB76-4068-8EFC-68278C6A9A57}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_EVENTS
S.1.CM.16 Required Command for Functional Category Still Image Capture
Test Assertion GUID: {9E380E24-3F82-4309-BDFF-48C035250430}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command if WPD_FUNCTIONAL_CATEGORY_STILL_IMAGE_CAPTURE is supported:WPD_COMMAND_STILL_IMAGE_CAPTURE_INITIATE
S.1.CM.17 Required Commands for Functional Category Audio Capture or Video Capture
Test Assertion GUID: {F542BB67-B3AA-49c2-9345-6D3DCF46E63A}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following commands if WPD_FUNCTIONAL_CATEGORY_AUDIO_CAPTURE or WPD_FUNCTIONAL_CATEGORY_VIDEO_CAPTURE are supported:WPD_COMMAND_MEDIA_CAPTURE_STARTWPD_COMMAND_MEDIA_CAPTURE_STOP
S.1.CM.18 Required Commands for Functional Category Network Configuration: Process Wireless Profile
Test Assertion GUID: {A6C1FC9C-C104-4530-80AA-B80ADFCE3E22}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command if WPD_FUNCTIONAL_CATEGORY_NETWORK_CONFIGURATION is supported:WPD_COMMAND_PROCESS_WIRELESS_PROFILE
D.1.EVENT.2 The Object Added Event, if supported, should provide required event parameters
Test Assertion GUID: {A17C3367-9532-4a53-ADE2-A21F3A504E8A}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_ADDED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.3 The Object Updated Event, if supported, should provide required event parameters
Test Assertion GUID: {1F96EE57-0B40-41ed-8ED8-5724B45D4E00}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_UPDATED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.4 The Object Removed Event, if supported, should provide required event parameters
Test Assertion GUID: {B8FF10C4-C656-4550-BC4A-CF3356D507EB}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_REMOVED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.5 The Storage Format Event, if supported, should provide required event parameters
Test Assertion GUID: {E4DED9BD-87F8-436b-A3FE-3AB2DC48CD1D}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_STORAGE_FORMAT is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.6 The Capabilities Updated Event, if supported, should provide required event parameters
Test Assertion GUID: {CDC26C77-CA05-42ec-8035-92AB24F20978}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_CAPABILITIES_UPDATED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.7 The Device Reset Event, if supported, should provide required event parameters
Test Assertion GUID: {C688EDC3-D700-4147-A228-6B5C39DE7A25}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_DEVICE_RESET is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.8 The Device Removed Event, if supported, should provide required event parameters
Test Assertion GUID: {CFFE5907-47F7-4090-8957-3C9CB5FA46A9}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver object properties meet data type requirements
Additional Information: If WPD_EVENT_DEVICE_REMOVED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.9 The Transfer Requested Event, if supported, should provide required event parameters
Test Assertion GUID: {01C876CC-50B3-44c7-9976-4E3B1732F00B}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_TRANSFER_REQUESTED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.


WPD Compliance Tests - ALL SERVICES

Type: Automated Test

Overview

The Windows Portable Device (WPD) Compliance Tests - ALL SERVICES test is designed to validate Windows 7 WPD scenarios at the WPD API level. The supported scenarios and device services validated in this test are defined in the MTP Device Services for Windows specification. The MTP Device Services Extension specification defines the required interactions between the device and the MTP driver. This document can be found at http://www.microsoft.com/whdc/device/wpd/default.mspx.

The compliance test maintains a configurations file for each service defined in the MTP Device Services for Windows Specification. Each configuration file defines the inherited services, properties, formats, formats attributes, and format object properties for its corresponding service. The settings in the configuration file will be used in various test cases to validate compliance of each service supported by the device with Windows 7. In addition to the test case descriptions below, all strings (e.g. service, format, property names) are validated to be scriptable per and MTP Device Services Extension Specification.

Device services are optional.

Details

For all services supported by the device, WPD Compliance Tests - ALL SERVICES test will run. This test case attempts to validate the service exposed by the device against the definition in the MTP Device Services for Windows specification. The target services' definition is read from the configuration files packaged with the compliance test, and the actual service characteristics exposed from the device are validated against these predefined settings.

Validating Service Static Definitions

  1. Load the Service definition from configuration for target service

  2. Validate inheritance settings

    Get the expected inheritance setting (NoInheritance, Optional, Required, AtLeastOne)

    Get the actual service inherited services (IPortableDeviceServiceCapabilities::GetInheritedServices)

    IF no service inherited service but inheritance is expected

    Log error and exit

    ENDIF

    FOR each expected inherited Service (H)

    IF the service inherits H

    Save H's GUID to use for validation later

    ELSE

    IF H is required

    Log error and exit

    ENDIF

    ENDIF

    ENDFOR

  3. Validate service properties

    Generate list of expected supported properties

    Including inherited properties (queried by the actual inherited services saved above)

    FOR each expected property P

    IF the service does not supports P and P is required

    Log fatal error

    Continue FOR

    ENDIF

    Validate P's expected attributes (below) against the corresponding property

    WPD_PROPERTY_ATTRIBUTE_NAME

    WPD_PROPERTY_ATTRIBUTE_VARTYPE

    WPD_PROPERTY_ATTRIBUTE_CAN_WRITE

    WPD_PROPERTY_ATTRIBUTE_CAN_READ

    ENDFOR

  4. Validate supported formats

    Generate list of expected formats

    Including inherited formats (queried by the actual inherited services saved above)

    FOR each expected format F

    IF the service does not supports F and F is required

    Log fatal error

    Continue FOR

    ENDIF

    FOR each expected property P in F

    IF the service does not supports P and P is required

    Log fatal error

    Continue FOR

    ENDIF

    Validate P's expected attributes (below) against the corresponding property

    WPD_PROPERTY_ATTRIBUTE_NAME

    WPD_PROPERTY_ATTRIBUTE_VARTYPE

    WPD_PROPERTY_ATTRIBUTE_CAN_WRITE

    WPD_PROPERTY_ATTRIBUTE_CAN_READ

    ENDFOR

    ENDFOR

  5. Validate service supported methods

    Generate list of expected methods

    Including inherited methods (queried by the actual inherited services saved above)

    FOR each expected format M

    IF the service does not supports M and M is required

    Log fatal error

    Continue FOR

    ENDIF

    FOR each expected parameter P in M

    IF the service does not supports P and P is required

    Log fatal error

    Continue FOR

    ENDIF

    Validate P's expected attributes (below) against the corresponding property

    WPD_PARAMETER_ATTRIBUTE_NAME

    WPD_PARAMETER_ATTRIBUTE_VARTYPE

    WPD_PARAMETER_ATTRIBUTE_ORDER

    WPD_PARAMETER_ATTRIBUTE_USAGE

    WPD_PROPERTY_ATTRIBUTE_CAN_READ

    ENDFOR

    ENDFOR

Run Time: Approximately 5 minutes, depending on devices speed
Log File: TestApp.log
System Restart Required: No
Test Category: Cellular Handset; Digital Still Camera; Portable Media Player
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Tests - ALL SERVICES tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The WPD Compliance Tests - ALL SERVICES tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the device does not support specific device services.

Refer to the specific "Testing Overview" section for the device under test.

Command Syntax

Command option | Description
Testapp.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
-e [string] | Starts the application and runs the test case which matched the GUID specified in [string] such as {E45E2AF0-E278-4E78-939C-ABA67EE7479D}.

Troubleshooting

  • The test supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

Code Tour

The following files are included to support the execution of WPD Compliance Tests - ALL SERVICES.

File Manifest

File | Location
WPDCompliance.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\wdk
Testapp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd
Wex.Common.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Logger.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Communication.dll | [OsbinRoot]\WexTest\CuE\TestExecution
wttlog.dll | [OsbinRoot]\wtt
wttlogcm.dll | [OsbinRoot]\wtt
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\ WpdCompliance\Content


WPD Compliance Tests - CONTACT SERVICE

Type: Automated Test

Overview

The Windows Portable Device (WPD) Compliance Tests - CONTACT SERVICE test is designed to validate Windows 7 WPD scenarios at the WPD API level. The supported scenarios and device services validated in this test are defined in the MTP Device Services for Windows specification. The MTP Device Services Extension specification defines the required interactions between the device and the MTP driver. This document can be found at http://www.microsoft.com/whdc/device/wpd/default.mspx.

The compliance test maintains a configurations file for each service defined in the MTP Device Services for Windows Specification. Each configuration file defines the inherited services, properties, formats, formats attributes and format object properties for its corresponding service. The settings in the configuration file will be used in various test cases to validate compliance of each service supported by the device with Windows 7. In addition to the test case descriptions below, all strings (e.g. service, format, property names) are validated to be scriptable per and MTP Device Services Extension Specification.

This test specifically verifies the Contact Service, if supported by the device.

Details

The WPD Compliance Tests - CONTACT SERVICE test attempts to validate the service exposed by the device against the definition in the MTP Device Services for Windows specification. The target services' definition is read from the configuration files packaged with the compliance test and the actual service characteristics exposed from the device are validated against these predefined settings. Support for Contacts is optional, and this test will only execute on devices that support the service.

The test validates predefined settings as follows:

Adding Service Objects

This test case attempts to add supported object(s) with the supported properties to a service while validating that the required object properties are supported.

  1. Load the Service definition from configuration.

  2. Generate object property values (IPortableDeviceValues)

    FOR each expected object property (P) (from configuration)

    IF the service does not supports P

    IF P is a required property

    Log fatal error

    Continue FOR loop

    ENDIF

    Continue FOR loop

    ELSE

    IF (P is writable and not a WPD_OBJECT_PROPERTIES_V1 property and does not have the WPD_PROPERTY_ATTRIBUTE_FORM_OBJECT_IDENTIFIER form)

    Generate Value for property (P)

    ENDIF

    ENDIF

    ENDFOR

  3. Add object to the device IPortableDeviceContent2::CreateObjectWithPropertiesOnly.

  4. Enumerate service content to find the new object Id.

Updating Service Objects

This test case will update object properties on an existing object in a service. It first will add the object it will later attempt update.

  1. Add the service new object (see section 2.2).

  2. Generate new object values.

  3. Update the object with one of the following options:
    • IPortableDeviceProperties::SetValues
    • IPortableDeviceProperties::Delete
    • IPortableDeviceContent2::UpdateObjectWithPropertiesAndData

  4. Get the properties for the object and make sure that the values were updated.

Enumerating Service Content

This test case will enumerate existing objects in a service store.

  1. Obtain the corresponding IPortableDeviceContent2 for the service

  2. Generate Property filter

    IF UseFilter == TRUE

    Only request the following properties:-

    WPD_OBJECT_NAME

    WPD_OBJECT_PARENT_ID

    WPD_OBJECT_SIZE

    WPD_OBJECT_ORIGINAL_FILE_NAME

    WPD_OBJECT_CONTENT_TYPE

    ELSE

    Request all properties

    ENDIF

  3. Query service for objects

    IF current object WPD_OBJECT_CONTENT_TYPE is WPD_CONTENT_TYPE_FOLDER

    Recursively enumerate child folders

    ELSE

    Print the Object's properties values

    ENDIF

Deleting Service Content

This test case will delete the existing objects in a service store.

  1. Obtain the corresponding IPortableDeviceContent2 for the service

  2. Delete the objects IPortableDeviceContent2::Delete

  3. Enumerate the service again to ensure no objects are left

Validate Service Version Property (VIC) Support

This test case will validate that a given service properly updates its VIC properties and the object's modified date property when an object is updated.

  1. Query the service for the following properties:-

    SYNCSVC_SyncFormat

    WPD_FUNCTIONAL_OBJECT_CATEGORY

    FULLENUMSYNC_VersionProps

    ANCHORSYNC_VersionProps

  2. Parse VersionProps byte array for the VIC property keys

    IF neither FULLENUMSYNC_VersionProps or ANCHORSYNC_VersionProps are supported or no Vic property keys are found

    log fatal error and exit

    ENDIF

  3. Check the VIC/Constraint grouping
    a. Add service object obj1 (see section 2.2)

    b. Check object VIC grouping with Windows filter keys (See expected VIC grouping below)

    Contact Service:

    PKEY_ContactObj_MobilePhone

    This test validates that all the properties above along with WPD_OBJECT_PERSISTENT_UNIQUE_ID, WPD_OBJECT_FORMAT, WPD_OBJECT_DATE_MODIFIED and WPD_OBJECT_CONTAINER_FUNCTIONAL_OBJECT_ID are reported back in the same group in a bulk property request (using IPortableDevicePropertiesBulk).

  4. Validate that the VIC gets updated on property updates and delete
    a. Get the current VIC values for obj1
    b. Update object obj1 with IPortableDeviceProperties::SetValues
    c. Check that VIC values are different
    d. Get the current VIC values for obj1
    e. Update object obj1with IPortableDeviceContent2::UpdateObjectWithPropertiesAndData
    f. Check that VIC values are different
    g. Get the current VIC values for obj1
    h. Update obj1 object with IPortableDeviceProperties::Delete
    i. Check that VIC values are different
  5. Test Sync Service support
    a. If FullEnum Supported
    i. Get the knowledge object id (PKEY_FullEnumSyncSvc_KnowledgeObjectID)
    ii. If exist - save the current stream
    iii. Write some data to the knowledge object
    iv. Read the stream back to validate content
    v. If previously existing object restore the original content

    b. If Anchor is supported

    The same knowledge check as above is done for the PKEY_AnchorSyncSvc_KnowledgeObjectID

    i. Lock the device if supported
    ii. Get and parse the current anchor (using METHOD_AnchorSyncSvc_GetChangesSinceAnchor)
    iii. Add a new object
    iv. Get and parse the current anchor (passing anchor from step ii) and ensure that the new object puid is present with the Created change flag
    v. Update the object
    vi. Get and parse the current anchor (passing anchor from step iv) and ensure that the new object puid is present with the Updated change flag
    vii. Delete the object
    viii. Get and parse the current anchor (passing anchor from step vi) and ensure that the new object puid is present with the Deleted change flag
    ix. Pass a blank anchor to get all the object ids
    x. UnLock the device if supported

Run Time: Approximately 5 minutes, depending on devices speed
Log File: TestApp.log
System Restart Required: No
Test Category: Cellular Handset; Digital Still Camera; Portable Media Player
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Tests - CONTACT SERVICE tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The WPD Compliance Tests - CONTACT SERVICE tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the device does not support specific device services.

Refer to the specific "Testing Overview" section for the device under test.

Command Syntax

Command option | Description
Testapp.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
-e [string] | Starts the application and runs the test case which matched the GUID specified in [string] such as {E45E2AF0-E278-4E78-939C-ABA67EE7479D}.

Troubleshooting

  • Test supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

Code Tour

The following files are included to support the execution of WPD Compliance Tests - CONTACT SERVICE.

File Manifest

File | Location
WPDCompliance.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\wdk
Testapp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd
Wex.Common.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Logger.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Communication.dll | [OsbinRoot]\WexTest\CuE\TestExecution
wttlog.dll | [OsbinRoot]\wtt
wttlogcm.dll | [OsbinRoot]\wtt
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\ WpdCompliance\Content


WPD Compliance Tests - FUID

Type: Automated Test

Overview

The Windows Portable Device (WPD) Compliance Tests - FUID validates that a device supports a functional unique identifier. The MTP Device Services for Windows specification defines implementation details for this property, which enables devices to support simultaneous connectivity to a Windows 7 PC over multiple transports (such as USB and Bluetooth). This document can be found at http://www.microsoft.com/whdc/device/wpd/default.mspx.

Details

The WPD Compliance Tests - FUID test validates the WPD_DEVICE_FUNCTIONAL_UNIQUE_ID property on a device is. The test runs against devices that support this property and attempts to read the value. If the property is writable, the test will attempt to set a value (GUID) and read it back. If successful, the test logs a PASS; if writable and cannot set/read the value, then the test FAILs.

Run Time: Less than 1 minute
Log File: TestApp.log
System Restart Required: No
Test Category: Cellular Handset; Digital Still Camera; Portable Media Player
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: TestApp.exe

Requirements

Software Requirements;

The test tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All WPD Compliance Tests - FUID test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the device does not support specific device services.

Refer to the specific "Testing Overview" section for the device under test.

Command Syntax

Command option | Description
Testapp.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
-e [string] | Starts the application and runs the test case which matched the GUID specified in [string] such as {E45E2AF0-E278-4E78-939C-ABA67EE7479D}.

Troubleshooting

  • WPD Compliance Tests - FUID test supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

Code Tour

The following files are included to support the execution of WPD Compliance Tests - FUID.

File Manifest

File | Location
WPDCompliance.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\wdk
Testapp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd
Wex.Common.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Logger.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Communication.dll | [OsbinRoot]\WexTest\CuE\TestExecution
wttlog.dll | [OsbinRoot]\wtt
wttlogcm.dll | [OsbinRoot]\wtt
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\ WpdCompliance\Content


WPD Compliance Tests - HINTS SERVICE

Type: Automated Test

Overview

The Windows Portable Device (WPD) Compliance Tests - HINTS SERVICE test is designed to validate Windows 7 WPD scenarios at the WPD API level. The supported scenarios and device services validated in this test are defined in the MTP Device Services for Windows specification. The MTP Device Services Extension specification defines the required interactions between the device and the MTP driver. This document can be found at http://www.microsoft.com/whdc/device/wpd/default.mspx.

The compliance test maintains a configurations file for each service defined in the MTP Device Services for Windows Specification. Each configuration file defines the inherited services, properties, formats, formats attributes, and format object properties for its corresponding service. The settings in the configuration file will be used in various test cases to validate compliance of each service supported by the device with Windows 7. In addition to the test case descriptions below, all strings (e.g. service, format, property names) are validated to be scriptable per and MTP Device Services Extension Specification.

This test specifically verifies the Hints Service, if supported by the device.

Details

The WPD Compliance Tests - HINTS SERVICE tests validates that the Hints service has been implemented correctly. Support for Hints is optional and this test will only execute on devices that support the service.

This test case attempts to add content to hints locations for all supported content types.

  1. Get supported content types for device.

  2. FOR each supported content type
    a. Get supported formats for content type
    b. Get collection of hint locations for current content type
    c. IF hint locations for current content type is greater than 0
    i. FOR each hints location in collection
    1. Get list of test files for current content type
    2. FOR each test file for the current content type
      a. Transfer Test File to hints location
      b. Verify content transferred
    3. ENDFOR
    ii. ENDFOR
    d. ENDIF

  3. ENDFOR

Run Time: Approximately 5 minutes, depending on devices speed
Log File: TestApp.log
System Restart Required: No
Test Category: Cellular Handset; Digital Still Camera; Portable Media Player
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Tests - HINTS SERVICE tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The WPD Compliance Tests - HINTS SERVICE tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the device does not support specific device services.

Refer to the specific "Testing Overview" section for the device under test.

Command Syntax

Command option | Description
Testapp.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
-e [string] | Starts the application and runs the test case which matched the GUID specified in [string] such as {E45E2AF0-E278-4E78-939C-ABA67EE7479D}.

Troubleshooting

  • WPD Compliance Tests - HINTS SERVICE supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

Code Tour

The following files are included to support the execution of WPD Compliance Tests - HINTS SERVICE.

File Manifest

File | Location
WPDCompliance.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\wdk
Testapp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd
Wex.Common.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Logger.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Communication.dll | [OsbinRoot]\WexTest\CuE\TestExecution
wttlog.dll | [OsbinRoot]\wtt
wttlogcm.dll | [OsbinRoot]\wtt
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\ WpdCompliance\Content


WPD Compliance Tests - METADATA SERVICE

Type: Automated Test

Overview

The Windows Portable Device (WPD) Compliance Tests - METADATA SERVICE test is designed to validate Windows 7 WPD scenarios at the WPD API level. The supported scenarios and device services validated in this test are defined in the MTP Device Services for Windows specification. The MTP Device Services Extension specification defines the required interactions between the device and the MTP driver. This document can be found at http://www.microsoft.com/whdc/device/wpd/default.mspx.

The compliance test maintains a configurations file for each service defined in the MTP Device Services for Windows Specification. Each configuration file defines the inherited services, properties, formats, formats attributes, and format object properties for its corresponding service. The settings in the configuration file will be used in various test cases to validate compliance of each service supported by the device with Windows 7. In addition to the test case descriptions below, all strings (e.g. service, format, property names) are validated to be scriptable per and MTP Device Services Extension Specification.

This test specifically verifies the Metadata Service, if supported by the device.

Details

The WPD Compliance Tests - METADATA SERVICE test validates that the service on the device actually supports metadata which can be pulled from the device. The service is validated to be present and expose the correct attributes (see "Validating Service Static Definitions" in WPD Compliance Tests - ALL SERVICES for more information). Support for Metadata is optional and this test will only execute on devices that support the service.

Run Time: Approximately 5 minutes, depending on devices speed
Log File: TestApp.log
System Restart Required: No
Test Category: Cellular Handset; Digital Still Camera; Portable Media Player
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Tests - METADATA SERVICE tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The WPD Compliance Tests - METADATA SERVICE tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the device does not support specific device services.

Refer to the specific "Testing Overview" section for the device under test.

Command Syntax

Command option | Description
Testapp.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
-e [string] | Starts the application and runs the test case which matched the GUID specified in [string] such as {E45E2AF0-E278-4E78-939C-ABA67EE7479D}.

Troubleshooting

  • WPD Compliance Tests - METADATA SERVICE supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

Code Tour

The following files are included to support the execution of WPD Compliance Tests - METADATA SERVICE.

File Manifest

File | Location
WPDCompliance.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\wdk
Testapp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd
Wex.Common.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Logger.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Communication.dll | [OsbinRoot]\WexTest\CuE\TestExecution
wttlog.dll | [OsbinRoot]\wtt
wttlogcm.dll | [OsbinRoot]\wtt
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\ WpdCompliance\Content


WPD Compliance Tests - MODEL_ID

Type: Automated Test

Overview

The Windows Portable Device (WPD) Compliance Tests - MODEL_ID test is a basic test that validates that the ModelID is supported correctly. The MTP Device Services for Windows specification defines implementation details for ModelID. This document can be found at http://www.microsoft.com/whdc/device/wpd/default.mspx. Additional information on ModelID is also available at http://www.microsoft.com/whdc/device/wpd/default.mspx.

This test specifically verifies the ModelID implementation.

Details

The WPD Compliance - MODEL_ID test verifies that the WPD_DEVICE_MODEL_UNIQUE_ID property on a device is the following:

  • Read only

  • A properly formed GUID

Run Time: Approximately 1 minute
Log File: TestApp.log
System Restart Required: No
Test Category: Cellular Handset; Digital Still Camera; Portable Media Player
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Tests - MODEL_ID tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The WPD Compliance Tests - MODEL_ID tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the device does not support specific device services.

Refer to the specific "Testing Overview" section for the device under test.

Command Syntax

Command option | Description
Testapp.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
-e [string] | Starts the application and runs the test case which matched the GUID specified in [string] such as {E45E2AF0-E278-4E78-939C-ABA67EE7479D}.

Troubleshooting

  • This test supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

Code Tour

The following files are included to support the execution of WPD Compliance Tests - MODEL_ID.

File Manifest

File | Location
WPDCompliance.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\wdk
Testapp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd
Wex.Common.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Logger.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Communication.dll | [OsbinRoot]\WexTest\CuE\TestExecution
wttlog.dll | [OsbinRoot]\wtt
wttlogcm.dll | [OsbinRoot]\wtt
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\ WpdCompliance\Content


WPD Compliance Tests - NOTES SERVICE

Type: Automated Test

Overview

The Windows Portable Device (WPD) Compliance Tests - NOTES SERVICE test is designed to validate Windows 7 WPD scenarios at the WPD API level. The supported scenarios and device services validated in this test are defined in the MTP Device Services for Windows specification. The MTP Device Services Extension specification defines the required interactions between the device and the MTP driver. This document can be found at http://www.microsoft.com/whdc/device/wpd/default.mspx.

The compliance test maintains a configurations file for each service defined in the MTP Device Services for Windows Specification. Each configuration file defines the inherited services, properties, formats, formats attributes, and format object properties for its corresponding service. The settings in the configuration file will be used in various test cases to validate compliance of each service supported by the device with Windows 7. In addition to the test case descriptions below, all strings (e.g. service, format, property names) are validated to be scriptable per and MTP Device Services Extension Specification.

This test specifically verifies the Notes Service, if supported by the device.

Details

The WPD Compliance Tests - NOTES SERVICE test attempts to validate the service exposed by the device against the definition in the MTP Device Services for Windows specification. The target services' definition is read from the configuration files packaged with the compliance test and the actual service characteristics exposed from the device are validated against these predefined settings.

Adding Service Objects

This test case attempts to add supported object(s) with the supported properties to a service while validating that the required object properties are supported.

  1. Load the Service definition from configuration

  2. Generate object property values (IPortableDeviceValues)

    FOR each expected object property (P) (from configuration)

    IF the service does not supports P

    IF P is a required property

    Log fatal error

    Continue FOR loop

    ENDIF

    Continue FOR loop

    ELSE

    IF (P is writable and not a WPD_OBJECT_PROPERTIES_V1 property and does not have the WPD_PROPERTY_ATTRIBUTE_FORM_OBJECT_IDENTIFIER form)

    Generate Value for property (P)

    ENDIF

    ENDIF

    ENDFOR

  3. Add object to the device IPortableDeviceContent2::CreateObjectWithPropertiesOnly

  4. Enumerate service content to find the new object Id

Updating Service Objects

This test case will update object properties on an existing object in a service, it first will add the object it will later attempt update.

  1. Add service new object

  2. Generate new object values

  3. Update the object (with one of the options below)
    • IPortableDeviceProperties::SetValues
    • IPortableDeviceProperties::Delete
    • IPortableDeviceContent2::UpdateObjectWithPropertiesAndData

  4. Get the properties for the object and make sure the values were updated

Enumerating Service Content

This test case will enumerate existing objects in a service store.

  1. Obtain the corresponding IPortableDeviceContent2 for the service

  2. Generate Property filter

    IF UseFilter == TRUE

    Only request the following properties:-

    WPD_OBJECT_NAME

    WPD_OBJECT_PARENT_ID

    WPD_OBJECT_SIZE

    WPD_OBJECT_ORIGINAL_FILE_NAME

    WPD_OBJECT_CONTENT_TYPE

    ELSE

    Request all properties

    ENDIF

  3. Query service for objects

    IF current object WPD_OBJECT_CONTENT_TYPE is WPD_CONTENT_TYPE_FOLDER

    Recursively enumerate child folders

    ELSE

    Print the Object's properties values

Deleting Service Content

This test case will delete the existing objects in a service store.

  1. Obtain the corresponding IPortableDeviceContent2 for the service

  2. Delete the objects IPortableDeviceContent2::Delete

  3. Enumerate the service again to ensure no objects are left

Validate Service Version Property (VIC) Support

This test case will validate that a given service properly updates its VIC properties and the object's modified date property when an object is updated.

  1. Query the service for the following properties:-

    SYNCSVC_SyncFormat

    WPD_FUNCTIONAL_OBJECT_CATEGORY

    FULLENUMSYNC_VersionProps

    ANCHORSYNC_VersionProps

  2. Parse VersionProps byte array for the VIC property keys

    IF neither FULLENUMSYNC_VersionProps or ANCHORSYNC_VersionProps are supported or no Vic property keys are found

    Log fatal error and exit

    ENDIF

  3. Check the VIC/Constraint grouping
    a. Add service object obj1

    b. Check object VIC grouping with Windows filter keys (See expected VIC grouping below)

    Notes Service:

    PKEY_MessageObj_Body

    This test validates that all the properties above along with WPD_OBJECT_PERSISTENT_UNIQUE_ID, WPD_OBJECT_FORMAT, WPD_OBJECT_DATE_MODIFIED and WPD_OBJECT_CONTAINER_FUNCTIONAL_OBJECT_ID are reported back in the same group in a bulk property request (using IPortableDevicePropertiesBulk).

  4. Validate that the VIC gets updated on property updates and delete
    a. Get the current VIC values for obj1
    b. Update object obj1 with IPortableDeviceProperties::SetValues
    c. Check that VIC values are different
    d. Get the current VIC values for obj1
    e. Update object obj1with IPortableDeviceContent2::UpdateObjectWithPropertiesAndData
    f. Check that VIC values are different
    g. Get the current VIC values for obj1
    h. Update obj1 object with IPortableDeviceProperties::Delete
    i. Check that VIC values are different
  5. Test Sync Service support
    a. If FullEnum Supported
    i. Get the knowledge object id (PKEY_FullEnumSyncSvc_KnowledgeObjectID)
    ii. If exist - save the current stream
    iii. Write some data to the knowledge object
    iv. Read the stream back to validate content
    v. If previously existing object restore the original content

    b. If Anchor is supported

    The same knowledge check as above is done for the PKEY_AnchorSyncSvc_KnowledgeObjectID

    i. Lock the device if supported
    ii. Get and parse the current anchor (using METHOD_AnchorSyncSvc_GetChangesSinceAnchor)
    iii. Add a new object
    iv. Get and parse the current anchor (passing anchor from step ii) and ensure that the new object puid is present with the Created change flag
    v. Update the object
    vi. Get and parse the current anchor (passing anchor from step iv) and ensure that the new object puid is present with the Updated change flag
    vii. Delete the object
    viii. Get and parse the current anchor (passing anchor from step vi) and ensure that the new object puid is present with the Deleted change flag
    ix. Pass a blank anchor to get all the object ids
    x. UnLock the device if supported

Run Time: Approximately 5 minutes, depending on devices speed
Log File: TestApp.log
System Restart Required: No
Test Category: Cellular Handset; Digital Still Camera; Portable Media Player
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Tests - NOTES SERVICE tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The WPD Compliance Tests - NOTES SERVICE tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the device does not support specific device services.

Refer to the specific "Testing Overview" section for the device under test.

Command Syntax

Command option | Description
Testapp.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
-e [string] | Starts the application and runs the test case which matched the GUID specified in [string] such as {E45E2AF0-E278-4E78-939C-ABA67EE7479D}.

Troubleshooting

  • WPD Compliance Tests - NOTES SERVICE supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

Code Tour

The following files are included to support the execution of WPD Compliance Tests - NOTES SERVICE.

File Manifest

File | Location
WPDCompliance.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\wdk
Testapp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd
Wex.Common.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Logger.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Communication.dll | [OsbinRoot]\WexTest\CuE\TestExecution
wttlog.dll | [OsbinRoot]\wtt
wttlogcm.dll | [OsbinRoot]\wtt
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\ WpdCompliance\Content


WPD Compliance Tests - RINGTONES SERVICE

Type: Automated Test

Overview

The Windows Portable Device (WPD) Compliance Tests - RINGTONES SERVICE test is designed to validate Windows 7 WPD scenarios at the WPD API level. The supported scenarios and device services validated in this test are defined in the MTP Device Services for Windows specification. The MTP Device Services Extension specification defines the required interactions between the device and the MTP driver. This document can be found at http://www.microsoft.com/whdc/device/wpd/default.mspx.

The compliance test maintains a configurations file for each service defined in the MTP Device Services for Windows Specification. Each configuration file defines the inherited services, properties, formats, formats attributes, and format object properties for its corresponding service. The settings in the configuration file will be used in various test cases to validate compliance of each service supported by the device with Windows 7. In addition to the test case descriptions below, all strings (e.g. service, format, property names) are validated to be scriptable per and MTP Device Services Extension Specification.

This test specifically verifies the RingtonesService, if supported by the device.

Details

The WPD Compliance Tests - RINGTONES SERVICE test attempts to validate the service exposed by the device against the definition in the MTP Device Services for Windows specification. The target services' definition is read from the configuration files packaged with the compliance test and the actual service characteristics exposed from the device are validated against these predefined settings. The WPD Compliance Tests - RINGTONES SERVICE has four significant test cases. The first three corresponds to test cases already described by the CONTACT SERVICE and NOTES SERVICE tests. Support for Ringtones is optional and this test will only execute on devices that support the service.

  1. Validate Ringtone Service definition - See Validating Service Static Definitions in WPD Compliance Tests - ALL SERVICES for details.

  2. Enumerate the Ringtone Service content - See Enumerating Service Content in WPD Compliance Tests - CONTACT SERVICE for details.

  3. Delete Ringtone Service content - See Deleting Service Content in WPD Compliance Tests - CONTACT SERVICE for details.

  4. Add Ringtone to the Ringtone Service - This test case performs all the steps described Adding Service Objects in WPD Compliance Tests - CONTACT SERVICE, except that the service is queried for its supported capabilities then the content is then transcoded before being copied to the device so that the file format is compliant with the service before being transferred to the device.

Run Time: Approximately 5 minutes, depending on devices speed
Log File: TestApp.log
System Restart Required: No
Test Category: Cellular Handset; Digital Still Camera; Portable Media Player
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Tests - RINGTONES SERVICE tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The WPD Compliance Tests - RINGTONES SERVICE tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the device does not support specific device services.

Refer to the specific "Testing Overview" section for the device under test.

Command Syntax

Command option | Description
Testapp.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
-e [string] | Starts the application and runs the test case which matched the GUID specified in [string] such as {E45E2AF0-E278-4E78-939C-ABA67EE7479D}.

Troubleshooting

  • WPD Compliance Tests - RINGTONES SERVICE supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

Code Tour

The following files are included to support the execution of WPD Compliance Tests - RINGTONES SERVICE.

File Manifest

File | Location
WPDCompliance.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\wdk
Testapp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd
Wex.Common.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Logger.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Communication.dll | [OsbinRoot]\WexTest\CuE\TestExecution
wttlog.dll | [OsbinRoot]\wtt
wttlogcm.dll | [OsbinRoot]\wtt
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\ WpdCompliance\Content


WPD Compliance Tests - STATUS SERVICE

Type: Automated Test

Overview

The Windows Portable Device (WPD) Compliance Tests - STATUS SERVICE test is designed to validate Windows 7 WPD scenarios at the WPD API level. The supported scenarios and device services validated in this test are defined in the MTP Device Services for Windows specification. The MTP Device Services Extension specification defines the required interactions between the device and the MTP driver. This document can be found at http://www.microsoft.com/whdc/device/DeviceExperience/default.mspx.

The compliance test maintains a configurations file for each service defined in the MTP Device Services for Windows Specification. Each configuration file defines the inherited services, properties, formats, formats attributes, and format object properties for its corresponding service. The settings in the configuration file will be used in various test cases to validate compliance of each service supported by the device with Windows 7. In addition to the test case descriptions below, all strings (e.g. service, format, property names) are validated to be scriptable per and MTP Device Services Extension Specification.

This test specifically verifies the Status Service, if supported by the device.

Details

The WPD Compliance Tests - STATUS SERVICE test attempts to validate the service exposed by the device against the definition in the MTP Device Services for Windows specification. The target services' definition is read from the configuration files packaged with the compliance test and the actual service characteristics exposed from the device are validated against these predefined settings. Support for Status is optional and this test will only execute on devices that support the service.

The Status Service does not support content. Therefore the content/object based test cases run under the ALL SERVICES test will not be run for this service.

Status Properties

The Status service supports the following two properties:

  • StorageCapacity - represents the total usable storage capacity of the device, in bytes.

  • StorageFreeSpace - represents the total usable free space on the device, in bytes.

Because there is no way to programmatically change the device's storage capacity, this property will simply be validated to be present and expose the correct attributes (see Validating Service Static Definitions in WPD Compliance Tests - ALL SERVICES for more information).

Validating the StorageFreeSpace Property

  1. Query for the current StorageFreeSpace value

  2. Add an object to the legacy store

  3. Query and compare the current StorageFreeSpace value

  4. Delete the object from the device

  5. Query and compare the StorageFreeSpace value with the original value
    a. Save the current value

  6. Add an object to a service store

  7. Query and compare the current StorageFreeSpace value with the saved value

  8. Delete the object from the service

  9. Query and compare the current StorageFreeSpace value with the original value

Optional Status Properties

The following are optional properties that can be exposed by the Status service. However, these properties expose internal state from the device and there is no programmatic way to manipulate these values. These properties will be tested by validating their definition and attributes (see Validating Service Static Definitions in WPD Compliance Tests - ALL SERVICES for more information) and additionally ensure that they can be read correctly from the Status service.

  • TextMessages

  • MissedCalls

  • NetworkTypeString

  • NetworkNameString

  • NewPictureCount

  • ChargingState

  • VoiceMailStatus

  • NetworkRoaming

  • SignalStrength

  • BatteryLife

Run Time: Approximately 5 minutes, depending on devices speed
Log File: TestApp.log
System Restart Required: No
Test Category: Cellular Handset; Digital Still Camera; Portable Media Player
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Tests - STATUS SERVICE tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The WPD Compliance Tests - STATUS SERVICE tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if the device does not support specific device services.

Refer to the specific "Testing Overview" section for the device under test.

Command Syntax

Command option | Description
Testapp.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
-e [string] | Starts the application and runs the test case which matched the GUID specified in [string] such as {E45E2AF0-E278-4E78-939C-ABA67EE7479D}.

Troubleshooting

  • WPD Compliance Tests - STATUS SERVICE supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

Code Tour

The following files are included to support the execution of WPD Compliance Tests - STATUS SERVICE.

File Manifest

File | Location
WPDCompliance.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\wdk
Testapp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd
Wex.Common.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Logger.dll | [OsbinRoot]\WexTest\CuE\TestExecution
Wex.Communication.dll | [OsbinRoot]\WexTest\CuE\TestExecution
wttlog.dll | [OsbinRoot]\wtt
wttlogcm.dll | [OsbinRoot]\wtt
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\ WpdCompliance\Content


WPD Compliance Tests (WPDCopytest-WDK)

Type: Automated Test

Overview

The Windows Portable Devices (WPD) Compliance Tests (WPDCopytest-WDK) validates drivers using the WPD application programming interface (API) and verifies that it is compliant with the Windows Logo Program requirements. The target audience for this test tool is developers of third-party device driver vendor who want to verify that their driver or device fulfills the Windows Logo Program requirements to work seamlessly with the WPD stack in a protocol-independent way.

This test does not cover the following items:

  • Legacy driver testing (only WPD class drivers will be tested)

  • Device-protocol-specific requirements (this testing is covered in separate certification tests)

  • Digital Rights Management Testing

Details

The WPD Compliance Tests (WPDCopytest-WDK) runs as a C++ application. When run outside of the Windows Logo Kit (WLK), there is a test case selection user interface and test suites can be defined using test profiles, as is the case for the WLK. It provides a Pass/Fail for each requirement. 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 the following known function categories:

  • Required object properties and attributes

  • Resources and attributes

Function Category Requirements

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, because 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/or enumeration.

  • 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: 24 hours
Log File: Wdk.log
System Restart Required: No
Test Category: Cellular Handset
Supported operating systems for Logo or Signature testing: Windows Vista; Windows XP

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Tests (WPDCopytest-WDK) tool requires the following software:

  • Windows Vista

  • Windows XP

  • Software components included with the device under test.

  • If running Windows XP with SP2, Windows Media Player 11 is required

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The WPD Compliance Tests (WPDCopytest-WDK) tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Refer to the "Cellular Handset Testing Overview" section of DTM help.

Command Syntax

Command option | Description
TestApp.exe | Without any options, the test enumerates devices.
/a [string] | Starts the application and runs all of the test cases; [:flags] may be used to enable/disable modes (a, m, and d for auto, manual, and disabled respectively)
/r | Starts the application and runs the default test cases.
/c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
/p [string] | Private parameters for the application.
/u | This is a private switch for enabling WTT logging in UNICODE mode. Default is ANSI.
Wdk.pro | Uses specific test profile to validate device.

Troubleshooting

  • WPD Compliance Tests (WPDCopytest-WDK) supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

  • Refer to the basic Portable Device Driver Requirements at the following Microsoft Web site: http://www.microsoft.com/whdc/device/media/WPDguide.mspx.

Code Tour

The following files are included to support the execution of the WPD Compliance Tests (WPDCopytest-WDK).

File Manifest

File | Location
TestApp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\
WpdCopyTest.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCopytest\wdk
Wdk.pro | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCopyTest\
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCopyTest\Content

Test Assertions

F.1.P.1, D.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: PORTABLE-0016 Cellular phone device driver object properties meet data type requirements
Additional Information: Device/driver must return required property values with valid datatype for Functional objects and 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_PROPERTY_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property. The property vartype requirements are described in the "Basic WPD Compliance Requirements" document. Note: this assertion covers two requirements: PORTABLE-0012 and PORTABLE-0016. If this assertion fails, both requirements will fail.
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: PORTABLE-0016 Cellular phone device driver object properties meet data type requirements
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_PROPERTY_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property. The property vartype requirements are described in the "Basic WPD Compliance Requirements" document. If not writable properties are supported, the test result is skipped. This assertion covers two requirements: PORTABLE-0013 and PORTABLE-0016. If this assertion fails, both requirements will fail.
D.4.P.4, F.4.P.4 Set Properties for Object: Device/driver should support updating of writable property values for the function or device object
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}
Windows Logo Program: PORTABLE-0012 Cellular phone device driver functional objects support required properties
Additional Information: If the device object returns the attribute WPD_PROPERTY_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 result is skipped.
C.4.P.4 Set Properties for Object: Device/driver should support updating of writable property values for content objects
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}
Windows Logo Program: PORTABLE-0013 Cellular phone device driver content objects support required properties
Additional Information: If a content object returns the attribute WPD_PROPERTY_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 result is skipped.
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: PORTABLE-0015 Cellular phone device driver supports the default resource for objects containing data
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: PORTABLE-0015 Cellular phone device driver supports the default resource for objects containing data
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.
D.1.S.1 Check WUDFRd service
Test Assertion GUID: {EDD34A8E-DBB1-4F09-9CE4-BFE1A796A75D}
Windows Logo Program: PORTABLE-0011 Cellular phone device driver is UMDF compliant
Additional Information: The User Mode Driver Framework (UMDF) redirector must be a filter driver for the current device, as described in the "Basic WPD Compliance Requirements" document.
D.1.S.2 Check WUDF CoInstaller
Test Assertion GUID: {6432E010-E541-4157-8A8D-40E4165B175F}
Windows Logo Program: PORTABLE-0011 Cellular phone device driver is UMDF compliant
Additional Information: The User Mode Driver Framework (UMDF) CoInstaller must be specified as a coinstaller for the device, as described in the "Basic WPD Compliance Requirements" document.
C.1.T.9 Device/driver resources should support required attributes
Test Assertion GUID: {6C576634-668A-4a02-9F79-DBF88317BD11}
Windows Logo Program: PORTABLE-0014 Cellular phone device driver resources support required attributes
Additional Information: If a resource is supported, the device/driver must support the required attributes for that resource. For example, if the device/driver supports WPD_RESOURCE_CONTACT_PHOTO on a data object, that resource must support the following attributes: WPD_MEDIA_WIDTH, WPD_MEDIA_HEIGHT, WPD_RESOURCE_ATTRIBUTE_TOTAL_SIZE, WPD_RESOURCE_ATTRIBUTE_FORMAT, WPD_RESOURCE_ATTRIBUTE_CAN_READ (if clients can read this resource), WPD_RESOURCE_ATTRIBUTE_CAN_WRITE (if clients can write to this resource), WPD_RESOURCE_ATTRIBUTE_CAN_DELETE (if clients can delete this resource), WPD_RESOURCE_ATTRIBUTE_OPTIMAL_READ_BUFFER_SIZE (if clients have read access to this resource), WPD_RESOURCE_ATTRIBUTE_OPTIMAL_WRITE_BUFFER_SIZE (if client have write access to this resource).
S.1.CM.1 Required Command: Get Object IDs from PUIDs
Test Assertion GUID: {423DBFED-319F-4766-BCB8-52087EEB0103}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command: WPD_COMMAND_COMMON_GET_OBJECT_IDS_FROM_PERSISTENT_UNIQUE_IDS
S.1.CM.2 Required Commands: Start Find, Find Next, End Find
Test Assertion GUID: {8FAC1FA0-B99F-46f0-BC4A-9E45DCC473D1}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required commands:WPD_COMMAND_OBJECT_ENUMERATION_START_FINDWPD_COMMAND_OBJECT_ENUMERATION_FIND_NEXTWPD_COMMAND_OBJECT_ENUMERATION_END_FIND
S.1.CM.3 Required Command: Get Supported Properties
Test Assertion GUID: {F7D463DA-8DA9-4942-ACF5-F7AAF6EE0DBD}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_SUPPORTED
S.1.CM.4 Required Command: Get Property Attributes
Test Assertion GUID: {A7AC39D0-A3A9-471b-BB09-8937EABF2ADA}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_ATTRIBUTES
S.1.CM.5 Required Command: Get Object Properties
Test Assertion GUID: {99336590-65B8-42f1-8341-187F4F0FF03B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET
S.1.CM.6 Required Command: Get All Object Properties
Test Assertion GUID: {427424F7-4C04-485b-A27A-8B63ED394F22}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_ALL
S.1.CM.7 Required Command: Get Supported Commands
Test Assertion GUID: {0D6161B0-C3C6-4de3-A6DA-CA8FF0CE0399}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_COMMANDS
S.1.CM.8 Required Command: Get Command Options
Test Assertion GUID: {6D34A5EA-E634-447d-82E1-4D771E0457F3}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_COMMAND_OPTIONS
S.1.CM.9 Required Command: Get Supported Functional Categories
Test Assertion GUID: {62B2E21B-6135-459a-93EC-67F4DED7898B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FUNCTIONAL_CATEGORIES
S.1.CM.10 Required Command: Get Functional Objects
Test Assertion GUID: {C49D25C7-A5E5-4a15-81A1-C66E7A526288}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_FUNCTIONAL_OBJECTS
S.1.CM.11 Required Command: Get Supported Content Types
Test Assertion GUID: {FF581789-FC15-4bb8-971E-2A3C21B88B0B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_CONTENT_TYPES
S.1.CM.12 Required Command: Get Supported Formats
Test Assertion GUID: {62AE52F2-DCD1-4b75-8C5A-5212FF8D4974}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FORMATS
S.1.CM.13 Required Command: Get Supported Format Properties
Test Assertion GUID: {EDF140E7-7326-4154-A840-063FE9E1CA69}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FORMAT_PROPERTIES
S.1.CM.14 Required Command: Get Fixed Property Attributes
Test Assertion GUID: {7F9BAFE8-6B2D-4609-AE9D-FA973547CDC5}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_FIXED_PROPERTY_ATTRIBUTES
S.1.CM.15 Required Command: Get Supported Events
Test Assertion GUID: {86F8EBE9-EB76-4068-8EFC-68278C6A9A57}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_EVENTS
S.1.CM.16 Required Command for Functional Category Still Image Capture
Test Assertion GUID: {9E380E24-3F82-4309-BDFF-48C035250430}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command if WPD_FUNCTIONAL_CATEGORY_STILL_IMAGE_CAPTURE is supported:WPD_COMMAND_STILL_IMAGE_CAPTURE_INITIATE
S.1.CM.17 Required Commands for Functional Category Audio Capture or Video Capture
Test Assertion GUID: {F542BB67-B3AA-49c2-9345-6D3DCF46E63A}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following commands if WPD_FUNCTIONAL_CATEGORY_AUDIO_CAPTURE or WPD_FUNCTIONAL_CATEGORY_VIDEO_CAPTURE are supported:WPD_COMMAND_MEDIA_CAPTURE_STARTWPD_COMMAND_MEDIA_CAPTURE_STOP
S.1.CM.18 Required Commands for Functional Category Network Configuration: Process Wireless Profile
Test Assertion GUID: {A6C1FC9C-C104-4530-80AA-B80ADFCE3E22}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command if WPD_FUNCTIONAL_CATEGORY_NETWORK_CONFIGURATION is supported:WPD_COMMAND_PROCESS_WIRELESS_PROFILE
D.1.EVENT.2 The Object Added Event, if supported, should provide required event parameters
Test Assertion GUID: {A17C3367-9532-4a53-ADE2-A21F3A504E8A}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_ADDED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.3 The Object Updated Event, if supported, should provide required event parameters
Test Assertion GUID: {1F96EE57-0B40-41ed-8ED8-5724B45D4E00}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_UPDATED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.4 The Object Removed Event, if supported, should provide required event parameters
Test Assertion GUID: {B8FF10C4-C656-4550-BC4A-CF3356D507EB}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_REMOVED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.5 The Storage Format Event, if supported, should provide required event parameters
Test Assertion GUID: {E4DED9BD-87F8-436b-A3FE-3AB2DC48CD1D}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_STORAGE_FORMAT is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.6 The Capabilities Updated Event, if supported, should provide required event parameters
Test Assertion GUID: {CDC26C77-CA05-42ec-8035-92AB24F20978}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_CAPABILITIES_UPDATED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.7 The Device Reset Event, if supported, should provide required event parameters
Test Assertion GUID: {C688EDC3-D700-4147-A228-6B5C39DE7A25}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_DEVICE_RESET is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.8 The Device Removed Event, if supported, should provide required event parameters
Test Assertion GUID: {CFFE5907-47F7-4090-8957-3C9CB5FA46A9}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver object properties meet data type requirements
Additional Information: If WPD_EVENT_DEVICE_REMOVED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.9 The Transfer Requested Event, if supported, should provide required event parameters
Test Assertion GUID: {01C876CC-50B3-44c7-9976-4E3B1732F00B}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_TRANSFER_REQUESTED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.


WPD Compliance Stress Tests

Type: Automated Test

Overview

The Windows Portable Devices (WPD) Compliance Stress Tests exercises the driver using the WPD API and validates that it is compliant with the Windows Logo Program requirements. The target audience for this test tool is developers of third-party device driver vendor who want to verify that their driver or device fulfills the Windows Logo Program requirements to work seamlessly with the WPD stack in a protocol-independent way. This test runs fully automated, and is required to run for at least 24 hours as a long haul driver stress test.

This test does not cover the following items:

  • Legacy driver testing (only WPD class drivers will be tested)

  • Device-protocol-specific requirements (this testing is covered in separate certification tests)

  • Digital Rights Management Testing

Details

The WPD Compliance Stress Tests runs as a C++ application. When run outside of the Windows Logo Kit (WLK), there is a test case selection user interface and test suites can be defined using test profiles, as is the case for the WLK. It is fully automated with Pass/Fail for each requirement. 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 the following known function categories:

  • Required object properties and attributes

  • Resources and attributes

Function Category Requirements

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, because 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/or enumeration.

  • 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: 24 hours
Log File: Wdk_stress.log
System Restart Required: No
Test Category: Cellular Handset
Supported operating systems for Logo or Signature testing: Windows 7

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Stress Tests tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Refer to the "Cellular Handset Testing Overview" section of DTM help.

Command Syntax

Command option | Description
TestApp.exe | Without any options, the test enumerates devices.
/a [string] | Starts the application and runs all of the test cases; [:flags] may be used to enable/disable modes (a, m, and d for auto, manual, and disabled respectively)
/r | Starts the application and runs the default test cases.
/c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
/p [string] | Private parameters for the application.
/u | This is a private switch for enabling WTT logging in UNICODE mode. Default is ANSI.
Wdk_stress.pro | Uses specific test profile to validate device.

Troubleshooting

  • WPD Compliance Stress Tests supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

  • Refer to the basic Portable Device Driver Requirements at the following Microsoft Web site: http://www.microsoft.com/whdc/device/media/WPDguide.mspx.

Code Tour

The following files are included to support the execution of WPD Compliance Stress Tests.

File Manifest

File | Location
TestApp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\
WPDCompliance.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\wdk
Wdk_stress.pro | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCopyTest\
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\Content

Test Assertions

F.1.P.1, D.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: PORTABLE-0016 Cellular phone device driver object properties meet data type requirements
Additional Information: Device/driver must return required property values with valid datatype for Functional objects and 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_PROPERTY_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property. The property vartype requirements are described in the "Basic WPD Compliance Requirements" document. Note: this assertion covers two requirements: PORTABLE-0012 and PORTABLE-0016. If this assertion fails, both requirements will fail.
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: PORTABLE-0016 Cellular phone device driver object properties meet data type requirements
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_PROPERTY_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property. The property vartype requirements are described in the "Basic WPD Compliance Requirements" document. If not writable properties are supported, the test result is skipped. This assertion covers two requirements: PORTABLE-0013 and PORTABLE-0016. If this assertion fails, both requirements will fail.
D.4.P.4, F.4.P.4 Set Properties for Object: Device/driver should support updating of writable property values for the function or device object
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}
Windows Logo Program: PORTABLE-0012 Cellular phone device driver functional objects support required properties
Additional Information: If the device object returns the attribute WPD_PROPERTY_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 result is skipped.
C.4.P.4 Set Properties for Object: Device/driver should support updating of writable property values for content objects
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}
Windows Logo Program: PORTABLE-0013 Cellular phone device driver content objects support required properties
Additional Information: If a content object returns the attribute WPD_PROPERTY_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 result is skipped.
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: PORTABLE-0015 Cellular phone device driver supports the default resource for objects containing data
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: PORTABLE-0015 Cellular phone device driver supports the default resource for objects containing data
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.
D.1.S.1 Check WUDFRd service
Test Assertion GUID: {EDD34A8E-DBB1-4F09-9CE4-BFE1A796A75D}
Windows Logo Program: PORTABLE-0011 Cellular phone device driver is UMDF compliant
Additional Information: The User Mode Driver Framework (UMDF) redirector must be a filter driver for the current device, as described in the "Basic WPD Compliance Requirements" document.
D.1.S.2 Check WUDF CoInstaller
Test Assertion GUID: {6432E010-E541-4157-8A8D-40E4165B175F}
Windows Logo Program: PORTABLE-0011 Cellular phone device driver is UMDF compliant
Additional Information: The User Mode Driver Framework (UMDF) CoInstaller must be specified as a coinstaller for the device, as described in the "Basic WPD Compliance Requirements" document.
C.1.T.9 Device/driver resources should support required attributes
Test Assertion GUID: {6C576634-668A-4a02-9F79-DBF88317BD11}
Windows Logo Program: PORTABLE-0014 Cellular phone device driver resources support required attributes
Additional Information: If a resource is supported, the device/driver must support the required attributes for that resource. For example, if the device/driver supports WPD_RESOURCE_CONTACT_PHOTO on a data object, that resource must support the following attributes: WPD_MEDIA_WIDTH, WPD_MEDIA_HEIGHT, WPD_RESOURCE_ATTRIBUTE_TOTAL_SIZE, WPD_RESOURCE_ATTRIBUTE_FORMAT, WPD_RESOURCE_ATTRIBUTE_CAN_READ (if clients can read this resource), WPD_RESOURCE_ATTRIBUTE_CAN_WRITE (if clients can write to this resource), WPD_RESOURCE_ATTRIBUTE_CAN_DELETE (if clients can delete this resource), WPD_RESOURCE_ATTRIBUTE_OPTIMAL_READ_BUFFER_SIZE (if clients have read access to this resource), WPD_RESOURCE_ATTRIBUTE_OPTIMAL_WRITE_BUFFER_SIZE (if client have write access to this resource).
S.1.CM.1 Required Command: Get Object IDs from PUIDs
Test Assertion GUID: {423DBFED-319F-4766-BCB8-52087EEB0103}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command: WPD_COMMAND_COMMON_GET_OBJECT_IDS_FROM_PERSISTENT_UNIQUE_IDS
S.1.CM.2 Required Commands: Start Find, Find Next, End Find
Test Assertion GUID: {8FAC1FA0-B99F-46f0-BC4A-9E45DCC473D1}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required commands:WPD_COMMAND_OBJECT_ENUMERATION_START_FINDWPD_COMMAND_OBJECT_ENUMERATION_FIND_NEXTWPD_COMMAND_OBJECT_ENUMERATION_END_FIND
S.1.CM.3 Required Command: Get Supported Properties
Test Assertion GUID: {F7D463DA-8DA9-4942-ACF5-F7AAF6EE0DBD}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_SUPPORTED
S.1.CM.4 Required Command: Get Property Attributes
Test Assertion GUID: {A7AC39D0-A3A9-471b-BB09-8937EABF2ADA}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_ATTRIBUTES
S.1.CM.5 Required Command: Get Object Properties
Test Assertion GUID: {99336590-65B8-42f1-8341-187F4F0FF03B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET
S.1.CM.6 Required Command: Get All Object Properties
Test Assertion GUID: {427424F7-4C04-485b-A27A-8B63ED394F22}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_ALL
S.1.CM.7 Required Command: Get Supported Commands
Test Assertion GUID: {0D6161B0-C3C6-4de3-A6DA-CA8FF0CE0399}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_COMMANDS
S.1.CM.8 Required Command: Get Command Options
Test Assertion GUID: {6D34A5EA-E634-447d-82E1-4D771E0457F3}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_COMMAND_OPTIONS
S.1.CM.9 Required Command: Get Supported Functional Categories
Test Assertion GUID: {62B2E21B-6135-459a-93EC-67F4DED7898B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FUNCTIONAL_CATEGORIES
S.1.CM.10 Required Command: Get Functional Objects
Test Assertion GUID: {C49D25C7-A5E5-4a15-81A1-C66E7A526288}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_FUNCTIONAL_OBJECTS
S.1.CM.11 Required Command: Get Supported Content Types
Test Assertion GUID: {FF581789-FC15-4bb8-971E-2A3C21B88B0B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_CONTENT_TYPES
S.1.CM.12 Required Command: Get Supported Formats
Test Assertion GUID: {62AE52F2-DCD1-4b75-8C5A-5212FF8D4974}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FORMATS
S.1.CM.13 Required Command: Get Supported Format Properties
Test Assertion GUID: {EDF140E7-7326-4154-A840-063FE9E1CA69}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FORMAT_PROPERTIES
S.1.CM.14 Required Command: Get Fixed Property Attributes
Test Assertion GUID: {7F9BAFE8-6B2D-4609-AE9D-FA973547CDC5}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_FIXED_PROPERTY_ATTRIBUTES
S.1.CM.15 Required Command: Get Supported Events
Test Assertion GUID: {86F8EBE9-EB76-4068-8EFC-68278C6A9A57}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_EVENTS
S.1.CM.16 Required Command for Functional Category Still Image Capture
Test Assertion GUID: {9E380E24-3F82-4309-BDFF-48C035250430}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command if WPD_FUNCTIONAL_CATEGORY_STILL_IMAGE_CAPTURE is supported:WPD_COMMAND_STILL_IMAGE_CAPTURE_INITIATE
S.1.CM.17 Required Commands for Functional Category Audio Capture or Video Capture
Test Assertion GUID: {F542BB67-B3AA-49c2-9345-6D3DCF46E63A}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following commands if WPD_FUNCTIONAL_CATEGORY_AUDIO_CAPTURE or WPD_FUNCTIONAL_CATEGORY_VIDEO_CAPTURE are supported:WPD_COMMAND_MEDIA_CAPTURE_STARTWPD_COMMAND_MEDIA_CAPTURE_STOP
S.1.CM.18 Required Commands for Functional Category Network Configuration: Process Wireless Profile
Test Assertion GUID: {A6C1FC9C-C104-4530-80AA-B80ADFCE3E22}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command if WPD_FUNCTIONAL_CATEGORY_NETWORK_CONFIGURATION is supported:WPD_COMMAND_PROCESS_WIRELESS_PROFILE
D.1.EVENT.2 The Object Added Event, if supported, should provide required event parameters
Test Assertion GUID: {A17C3367-9532-4a53-ADE2-A21F3A504E8A}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_ADDED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.3 The Object Updated Event, if supported, should provide required event parameters
Test Assertion GUID: {1F96EE57-0B40-41ed-8ED8-5724B45D4E00}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_UPDATED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.4 The Object Removed Event, if supported, should provide required event parameters
Test Assertion GUID: {B8FF10C4-C656-4550-BC4A-CF3356D507EB}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_REMOVED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.5 The Storage Format Event, if supported, should provide required event parameters
Test Assertion GUID: {E4DED9BD-87F8-436b-A3FE-3AB2DC48CD1D}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_STORAGE_FORMAT is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.6 The Capabilities Updated Event, if supported, should provide required event parameters
Test Assertion GUID: {CDC26C77-CA05-42ec-8035-92AB24F20978}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_CAPABILITIES_UPDATED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.7 The Device Reset Event, if supported, should provide required event parameters
Test Assertion GUID: {C688EDC3-D700-4147-A228-6B5C39DE7A25}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_DEVICE_RESET is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.8 The Device Removed Event, if supported, should provide required event parameters
Test Assertion GUID: {CFFE5907-47F7-4090-8957-3C9CB5FA46A9}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver object properties meet data type requirements
Additional Information: If WPD_EVENT_DEVICE_REMOVED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.9 The Transfer Requested Event, if supported, should provide required event parameters
Test Assertion GUID: {01C876CC-50B3-44c7-9976-4E3B1732F00B}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_TRANSFER_REQUESTED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.


WPD Compliance Tests (MANUAL)

Type: Automated Test

Overview

The Windows Portable Devices (WPD) Compliance Tests (MANUAL) exercises the driver using the WPD API and validates that it is compliant with the Windows Logo Program requirements. The target audience for this test tool is developers of third-party device driver vendor who want to verify that their driver or device fulfills the Windows Logo Program requirements to work seamlessly with the WPD stack in a protocol-independent way.

Details

The WPD Compliance Tests (MANUAL) runs as a C++ application. When run outside of the Windows Logo Kit (WLK), there is a test case selection user interface and test suites can be defined using test profiles as is the case for the WLK. It provides a Pass/Fail for each requirement. The test validates the following for a WPD driver and the device connected to it.

The 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

The device/driver supports the following known function categories:

  • Required object properties and attributes

  • Resources and attributes

Function Category Requirements

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 are not strict requirements on the format or content type, because 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/or enumeration.

  • 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: Less than 10 minutes, depending on device speed
Log File: WPDCompliance.log
System Restart Required: No
Test Category: Cellular Handset
Supported operating systems for Logo or Signature testing: Windows 7

Program: TestApp.exe

Requirements

Software Requirements

The WPD Compliance Tests (MANUAL) tool requires the following software:

  • Windows 7

  • Software components included with the device under test.

Hardware Requirements

The following hardware is required to run the portable media device testing component of the WLK. Additional hardware may be needed 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.

  • Device under test

  • Computer that meets the minimum requirements defined in the System Requirements section in Install.htm - Installation Guide

  • USB 2.0 compliant system

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on Operating System partition

  • USB cable to connect to the device

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Please see "Cellular Handset Testing Overview" for details on how to run this test.

Command Syntax

Command option | Description
TestApp.exe | Without any options, the test enumerates devices.
/a [string] | Starts the application and runs all of the test cases; [:flags] may be used to enable/disable modes (a, m, and d for auto, manual, and disabled respectively)
/r | Starts the application and runs the default test cases.
/c [string] | Starts the application and runs the test cases specified in the .pro file specified by [string].
/p [string] | Private parameters for the application.
/u | This is a private switch for enabling WTT logging in UNICODE mode. Default is ANSI.
WPDCompliance.pro | Uses specific test profile to validate device driver.

Troubleshooting

  • WPD Compliance Tests (MANUAL) supports verbose logging when in manual test case selection mode. When the application is running, in Options > Logging Options, select Destination: Window, Level: 10.

  • If "no test cases selected" or no test cases are available from the test case selection tree, make sure that the device is plugged in.

  • Refer to the basic Portable Device Driver Requirements at the following Microsoft Web site: http://www.microsoft.com/whdc/device/media/WPDguide.mspx.

Code Tour

The following files are included to support the execution of WPD Compliance Tests (MANUAL).

File Manifest

File | Location
TestApp.exe | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\
WPDCompliance.dll | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\wdk
WPDCompliance.pro | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\
All content files in | [testbinroot]\NTTEST\MULTIMEDIATEST\wpd\WpdCompliance\Content

Test Assertions

F.1.P.1, D.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: PORTABLE-0016 Cellular phone device driver object properties meet data type requirements
Additional Information: Device/driver must return required property values with valid datatype for Functional objects and 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_PROPERTY_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property. The property vartype requirements are described in the "Basic WPD Compliance Requirements" document. Note: this assertion covers two requirements: PORTABLE-0012 and PORTABLE-0016. If this assertion fails, both requirements will fail.
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: PORTABLE-0016 Cellular phone device driver object properties meet data type requirements
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_PROPERTY_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property. The property vartype requirements are described in the "Basic WPD Compliance Requirements" document. If not writable properties are supported, the test result is skipped. This assertion covers two requirements: PORTABLE-0013 and PORTABLE-0016. If this assertion fails, both requirements will fail.
D.4.P.4, F.4.P.4 Set Properties for Object: Device/driver should support updating of writable property values for the function or device object
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}
Windows Logo Program: PORTABLE-0012 Cellular phone device driver functional objects support required properties
Additional Information: If the device object returns the attribute WPD_PROPERTY_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 result is skipped.
C.4.P.4 Set Properties for Object: Device/driver should support updating of writable property values for content objects
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}
Windows Logo Program: PORTABLE-0013 Cellular phone device driver content objects support required properties
Additional Information: If a content object returns the attribute WPD_PROPERTY_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 result is skipped.
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: PORTABLE-0015 Cellular phone device driver supports the default resource for objects containing data
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: PORTABLE-0015 Cellular phone device driver supports the default resource for objects containing data
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.
D.1.S.1 Check WUDFRd service
Test Assertion GUID: {EDD34A8E-DBB1-4F09-9CE4-BFE1A796A75D}
Windows Logo Program: PORTABLE-0011 Cellular phone device driver is UMDF compliant
Additional Information: The User Mode Driver Framework (UMDF) redirector must be a filter driver for the current device, as described in the "Basic WPD Compliance Requirements" document.
D.1.S.2 Check WUDF CoInstaller
Test Assertion GUID: {6432E010-E541-4157-8A8D-40E4165B175F}
Windows Logo Program: PORTABLE-0011 Cellular phone device driver is UMDF compliant
Additional Information: The User Mode Driver Framework (UMDF) CoInstaller must be specified as a coinstaller for the device, as described in the "Basic WPD Compliance Requirements" document.
C.1.T.9 Device/driver resources should support required attributes
Test Assertion GUID: {6C576634-668A-4a02-9F79-DBF88317BD11}
Windows Logo Program: PORTABLE-0014 Cellular phone device driver resources support required attributes
Additional Information: If a resource is supported, the device/driver must support the required attributes for that resource. For example, if the device/driver supports WPD_RESOURCE_CONTACT_PHOTO on a data object, that resource must support the following attributes: WPD_MEDIA_WIDTH, WPD_MEDIA_HEIGHT, WPD_RESOURCE_ATTRIBUTE_TOTAL_SIZE, WPD_RESOURCE_ATTRIBUTE_FORMAT, WPD_RESOURCE_ATTRIBUTE_CAN_READ (if clients can read this resource), WPD_RESOURCE_ATTRIBUTE_CAN_WRITE (if clients can write to this resource), WPD_RESOURCE_ATTRIBUTE_CAN_DELETE (if clients can delete this resource), WPD_RESOURCE_ATTRIBUTE_OPTIMAL_READ_BUFFER_SIZE (if clients have read access to this resource), WPD_RESOURCE_ATTRIBUTE_OPTIMAL_WRITE_BUFFER_SIZE (if client have write access to this resource).
S.1.CM.1 Required Command: Get Object IDs from PUIDs
Test Assertion GUID: {423DBFED-319F-4766-BCB8-52087EEB0103}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command: WPD_COMMAND_COMMON_GET_OBJECT_IDS_FROM_PERSISTENT_UNIQUE_IDS
S.1.CM.2 Required Commands: Start Find, Find Next, End Find
Test Assertion GUID: {8FAC1FA0-B99F-46f0-BC4A-9E45DCC473D1}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required commands:WPD_COMMAND_OBJECT_ENUMERATION_START_FINDWPD_COMMAND_OBJECT_ENUMERATION_FIND_NEXTWPD_COMMAND_OBJECT_ENUMERATION_END_FIND
S.1.CM.3 Required Command: Get Supported Properties
Test Assertion GUID: {F7D463DA-8DA9-4942-ACF5-F7AAF6EE0DBD}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_SUPPORTED
S.1.CM.4 Required Command: Get Property Attributes
Test Assertion GUID: {A7AC39D0-A3A9-471b-BB09-8937EABF2ADA}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_ATTRIBUTES
S.1.CM.5 Required Command: Get Object Properties
Test Assertion GUID: {99336590-65B8-42f1-8341-187F4F0FF03B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET
S.1.CM.6 Required Command: Get All Object Properties
Test Assertion GUID: {427424F7-4C04-485b-A27A-8B63ED394F22}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_OBJECT_PROPERTIES_GET_ALL
S.1.CM.7 Required Command: Get Supported Commands
Test Assertion GUID: {0D6161B0-C3C6-4de3-A6DA-CA8FF0CE0399}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the required command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_COMMANDS
S.1.CM.8 Required Command: Get Command Options
Test Assertion GUID: {6D34A5EA-E634-447d-82E1-4D771E0457F3}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_COMMAND_OPTIONS
S.1.CM.9 Required Command: Get Supported Functional Categories
Test Assertion GUID: {62B2E21B-6135-459a-93EC-67F4DED7898B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FUNCTIONAL_CATEGORIES
S.1.CM.10 Required Command: Get Functional Objects
Test Assertion GUID: {C49D25C7-A5E5-4a15-81A1-C66E7A526288}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_FUNCTIONAL_OBJECTS
S.1.CM.11 Required Command: Get Supported Content Types
Test Assertion GUID: {FF581789-FC15-4bb8-971E-2A3C21B88B0B}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_CONTENT_TYPES
S.1.CM.12 Required Command: Get Supported Formats
Test Assertion GUID: {62AE52F2-DCD1-4b75-8C5A-5212FF8D4974}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FORMATS
S.1.CM.13 Required Command: Get Supported Format Properties
Test Assertion GUID: {EDF140E7-7326-4154-A840-063FE9E1CA69}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_FORMAT_PROPERTIES
S.1.CM.14 Required Command: Get Fixed Property Attributes
Test Assertion GUID: {7F9BAFE8-6B2D-4609-AE9D-FA973547CDC5}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_FIXED_PROPERTY_ATTRIBUTES
S.1.CM.15 Required Command: Get Supported Events
Test Assertion GUID: {86F8EBE9-EB76-4068-8EFC-68278C6A9A57}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command:WPD_COMMAND_CAPABILITIES_GET_SUPPORTED_EVENTS
S.1.CM.16 Required Command for Functional Category Still Image Capture
Test Assertion GUID: {9E380E24-3F82-4309-BDFF-48C035250430}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command if WPD_FUNCTIONAL_CATEGORY_STILL_IMAGE_CAPTURE is supported:WPD_COMMAND_STILL_IMAGE_CAPTURE_INITIATE
S.1.CM.17 Required Commands for Functional Category Audio Capture or Video Capture
Test Assertion GUID: {F542BB67-B3AA-49c2-9345-6D3DCF46E63A}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following commands if WPD_FUNCTIONAL_CATEGORY_AUDIO_CAPTURE or WPD_FUNCTIONAL_CATEGORY_VIDEO_CAPTURE are supported:WPD_COMMAND_MEDIA_CAPTURE_STARTWPD_COMMAND_MEDIA_CAPTURE_STOP
S.1.CM.18 Required Commands for Functional Category Network Configuration: Process Wireless Profile
Test Assertion GUID: {A6C1FC9C-C104-4530-80AA-B80ADFCE3E22}
Windows Logo Program: PORTABLE-0017 Cellular phone device driver supports required commands
Additional Information: Device/driver must support the following command if WPD_FUNCTIONAL_CATEGORY_NETWORK_CONFIGURATION is supported:WPD_COMMAND_PROCESS_WIRELESS_PROFILE
D.1.EVENT.2 The Object Added Event, if supported, should provide required event parameters
Test Assertion GUID: {A17C3367-9532-4a53-ADE2-A21F3A504E8A}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_ADDED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.3 The Object Updated Event, if supported, should provide required event parameters
Test Assertion GUID: {1F96EE57-0B40-41ed-8ED8-5724B45D4E00}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_UPDATED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.4 The Object Removed Event, if supported, should provide required event parameters
Test Assertion GUID: {B8FF10C4-C656-4550-BC4A-CF3356D507EB}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_OBJECT_REMOVED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.5 The Storage Format Event, if supported, should provide required event parameters
Test Assertion GUID: {E4DED9BD-87F8-436b-A3FE-3AB2DC48CD1D}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_STORAGE_FORMAT is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.6 The Capabilities Updated Event, if supported, should provide required event parameters
Test Assertion GUID: {CDC26C77-CA05-42ec-8035-92AB24F20978}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_CAPABILITIES_UPDATED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.7 The Device Reset Event, if supported, should provide required event parameters
Test Assertion GUID: {C688EDC3-D700-4147-A228-6B5C39DE7A25}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_DEVICE_RESET is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.8 The Device Removed Event, if supported, should provide required event parameters
Test Assertion GUID: {CFFE5907-47F7-4090-8957-3C9CB5FA46A9}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver object properties meet data type requirements
Additional Information: If WPD_EVENT_DEVICE_REMOVED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.
D.1.EVENT.9 The Transfer Requested Event, if supported, should provide required event parameters
Test Assertion GUID: {01C876CC-50B3-44c7-9976-4E3B1732F00B}
Windows Logo Program: PORTABLE-0018 Cellular phone device driver supports required event parameters
Additional Information: If WPD_EVENT_TRANSFER_REQUESTED is supported, the driver must fire the event under the appropriate conditions and return the required event parameters as described in the "Basic WPD Compliance Requirements" document. This requirement does not apply when the driver is running under Terminal Server Plug-and-Play Redirection.


Printer Testing

Printer Testing Overview
Windows HD Imaging Testing
Printer Tests

Note For logo program testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Printer Testing Overview

The procedures that are presented in this section outline the process for testing your printer for correct functionality with the Windows operating system. These procedures use the Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that 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 Program Categories

There are four printing programs in the WLK:

  • Consumer Printing
  • Consumer Printing – Rally Enabled (Network)
  • Enterprise Printing
  • Enterprise Printing – Rally Enabled (Network)

The following sections will help you decide which program is necessary for your device. This is dependent on the capabilities of the device.

Consumer vs. Enterprise

Consumer programs are targeted towards printers to be used in the home environment. Consumer programs will run on the client versions of Windows and receive a Windows client operating system (OS) logo.

Enterprise programs are targeted towards printers designed for the enterprise environment. Enterprise programs will run on the server versions of Windows and receive a Windows server OS logo.

Consumer Printing/Consumer Printing – Rally Enabled (Network) available operating systems:

  • Windows XP
  • Windows Vista
  • Windows 7

Enterprise Printing/Enterprise Printing – Rally Enabled (Network) available operating systems:

  • Windows 2003
  • Windows 2008
  • Windows 2008 R2 (x64)/ Windows 7 (x86)

Note When testing x86 drivers using the Enterprise Printing and Enterprise Printing – Rally Enabled (Network) programs, use the Windows 7 x86 operating system. The device will only receive a Windows Server 2008 R2 logo.

Printing vs. Printing – Rally Enabled (Network)

The Printing programs are designed to test printers over all non-network connections, such as Universal Serial Bus (USB) and Bluetooth.

The Printing – Rally Enabled (Network) programs are designed for all network-attached printers (both wired and wireless). This program tests the device for all Rally requirements. Please visit the LogoPoint website to view the Printing requirements.

Note If your device is able to connect to a network (wired or wireless), and you are testing against Windows 7 or Windows Server 2008 R2 logo program requirements, it must pass the Printing – Rally Enabled (Network) program.

Note You must test the printer over each bus that the printer supports. If a device contains both a USB and an Ethernet bus, you must run both Printing and Printing – Rally Enabled (Network) programs.

Printer Tests

The list of tests you need to run depends on the capabilities of the device or system being tested. For the complete list of tests that could be required for your device, see Printer Tests.

Run time: Approximately 10 hours

Printer – Rally Enabled (Network) tests

When you create a new submission using the Rally Enabled (Network) program, you receive a prompt for "Printer Network Connection Type." Please select one of the following options:

  • If your device supports wireless only, select Wireless Only.
  • If your device supports a wired connection type only, select Wired only.
  • If your device supports both wireless and wired connections, select Wired and Wireless.

Note If you support both connection types, you can configure the device as necessary to run each set of tests appropriately. For example, you can run all print tests and wired tests through the wired connection, and then switch to wireless to run the wireless tests.

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 whether there are additional hardware requirements.

  • Basic WLK test setup (Controller, Studio, and Client systems)

  • At least one printer installed on a Client system (locally or over the network)

For the Additional Qualification - Windows HD Imaging, the Printing kit requires that color printers pass color quality tests. This requires the test lab to have a color measurement device suitable for the output medium. The device must meet ASTM standard E805-01a Standard Practice for Identification of Instrumental Methods of Color or Color-Difference Measurement of Materials, which is available from the ASTM website. These devices are available from multiple manufacturers. Follow your manufacturer's instructions to set up and operate the device. For more information on the color tests, please see the WinColorKit website.

In addition, the testing area must meet the recommended operating guidelines set by both the manufacturer of the color measurement device and the manufacturer of the color device that is being measured.

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 DTM Client

  • Print server to test print server configurations

Note Testing a device for Server Device qualification requires that the system being used to test the device support four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has more than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard disk drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for para-virtualization drivers (as defined by Logo Program Requirement Policy-0020), physical devices and their associated drivers being tested for a server logo or signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, and so on.

Software Requirements

It is good practice to clean-install the operating system on client systems before final test passes to ensure that the system is in a known clean state.

The following software is required to run the printer tests:

  • The correct operating system build on the DTM client for the intended logo program

    Note Windows Server 2008 R2 is supported.

  • AppVerifier

    Note This application is installed during Client setup.

  • The driver package that is being tested on a client system

  • .NET Framework 3.5 for computers with Windows Server 2008 installed. This ensures that the tests run correctly.

    Note This application is installed during Client setup.

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 WLK to create new submissions and package results.

This section includes:

Preparing for the Printer Testing

Running the Printer Tests


Preparing for the Printer Testing

Before tests can be run on the client system, the system must have the operating system installed and configured for the logo that is being obtained and the device that is obtaining the logo. This section summarizes the related procedures to set up the studio in preparation for running the submission.

For a complete list of required hardware, software, and tester knowledge, see Printer Testing Overview.

Many of the tests in the Windows Logo Kit (WLK) 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.

Test System Configuration

You no longer need to configure the multipoint control unit (MCU) policy. The work that was being done during the MCU policy run time is now included in the client setup.

After you have set up the controller, created a machine pool, and moved the client systems to the machine pool, you can begin to create a submission. For information about how to do this, please see Running the Printer Tests.

To add client systems to the new print machine pool, follow the standard WLK instructions for adding clients to a machine pool.


Running the Printer Tests

Running the Printer - Rally Enabled (Network) Tests

The “Rally” tests are only expected to be executed against the wired connection, and the “Wireless Rally” tests are only intended to be executed against the wireless connection.

To run the tests, follow these steps:

  1. Select the operating system and processor architecture to test (Windows 7 Client), and then click Next.
  2. Select a submission category (Device Submission), and then click Next.
  3. Select the appropriate logo program under Printer – Rally Enabled (Network).
  4. Select a Qualification Level (logo), and then click Next.
  5. Enter a name for the submission, click the machine pool you created earlier, and then click Next.
  6. Select I am not providing an INF or driver package in the lower left hand corner, and then click Next.
  7. Select Device Not Listed, and then click Next.
  8. Fill in the Create New Submission form:
    1. Select the appropriate network connection type for the device: Wired only, Wireless only, or Wired and wireless.
    2. Select whether your device supports XPS Thumbnail processing.
    3. Select whether your device supports XPS Discard Control processing.
    4. Enter the MAC Address, as noted in Device Setup. The MAC Address must include the dashes, for example, 00-a0-b0-94-5b-fb.
    5. Enter the Discovery protocol.
    6. Enter the device’s UPnP UUID. This should begin with uuid, for example, uuid: de1dec0a-9021-426c-9548-f714b5e8ef56.
    7. Enter the device’s WSD UUID, if applicable. This should begin with uuid, for example, uuid: de1dec0a-9021-426c-9548-f714b5e8ef56.
    8. Enter the device’s UDN or WPS (Wifi protected setup) UUID, if applicable. This information was noted in Device Setup. The unique identifier must include the dashes, for example, 4a96edf6-0aa0-11de-904a-00a0b0945bfb.
    9. Enter the device’s WinQual ID, also known as the vendor ID, used in your hardware ID, formatted is as follows: VEN_XXXX.
    10. Select the appropriate setting indicating UPnP protocol for your device: Required, NotRequired, Unknown.
    11. Select the appropriate setting indicating WSD protocol for your device: Required, NotRequired, Unknown.
    12. For wireless devices, select whether you would like the device unpaired after the test completes.

Note Failure to fill in the correct values may cause the tests to prompt you for additional input.

For more information about creating a new logo submission and scheduling jobs, see Generic Logo Submission exercise.


Windows HD Imaging Testing

Windows HD Imaging Testing Overview

Preparing for Windows HD Imaging Testing

Running the Windows HD Imaging Tests

Troubleshooting Windows HD Imaging Testing


Windows HD Imaging Testing Overview

The procedures presented in this section outline the process for testing your Windows HD Imaging for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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 logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

Windows HD Imaging Tests

To see the complete list of tests that could be required for your device, see the Windows HD Imaging Tests.

Run time: Approximately 2 hours

Hardware requirements

The following hardware is required for Windows HD Imaging 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.

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Spectrophotometer for color fidelity testing

Software requirements

The following software is required to run the Windows HD Imaging tests:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • .NET 3.5

  • Windows Logo Kit

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Tester knowledge requirements

To run the Windows HD Imaging tests, testers must know how to accomplish the following tasks:

  • Manual validation of printed output


Preparing for Windows HD Imaging 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 Windows HD Imaging Testing Overview.

Many of the tests in the Windows Logo 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.


Running the Windows HD Imaging Tests

For more information, please see the following topics:

  • Test for XPSDrv

  • PrintTicket Test (PTTest2)

  • Print WinColor Test


Troubleshooting Windows HD Imaging Testing

For more information, please see the following topics:

  • Test for XPSDrv

  • PrintTicket Test (PTTest2)

  • Print WinColor Test


Printer Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


AppVerifier

Type: Automated Test

Overview

The AppVerifier application runs during most Print tests to ensure that the driver behaves properly in user mode. For the purposes of this test, AppVerifier is equivalent to DriverVerifier but is intended for user mode code.

Details

AppVerifier is included in the Microsoft Windows Driver it (WDK) as a redistributable package that is publicly available from Microsoft. Please refer to the documentation that was installed with AppVerifier to ensure that you have the latest information. The Print setup documentation will include any necessary information about installing and setting up AppVerifier to run with the WDK.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK


Custom Extension XML File Validation Test

Type: Automated Test

Overview

The Custom Extension XML File Validation Test 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 test will validate the custom extension file and it will dump any XML contents that are deemed invalid. The test can be run against an installed printer or a static file.

If the test is run against an installed printer, it will check if the printer driver has a bidirectional (Bi-Di) extension file that is defined for the TCPMon port monitor.

If the file is defined, it will be loaded and verified. If the test 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

  • x86

  • x64

  • Itanium

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


DocumentProperties Test (ANSI & UniCode)

Type: Automated Test

Overview

The Document Properties Test exercises the DocumentProperties API.

PrintSpy is enabled for this test. For more information, please go to PrintSpy.

Details

The Document Properties Test exercises a printer driver's user interface (UI) by calling the DocumentProperties API with various well-formed and mal-formed parameters and validating the results.

For each test case, the parameters that are used are printed in the log file. The following code example shows a sample log file.

<StartTest
                Title="DocumentPropertiesTEST"
                TUID="" CA="259184628680" LA="259190331028" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</StartTest>
<Msg
                UserText="Testing Parameters permutation:" CA="259184695528" LA="259191739244" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</Msg>
<Msg
                UserText="ParentWindow handle = NULL" CA="259187152000" LA="259197116980" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</Msg>
<Msg
                UserText="PrinterHandle   = 0008B13C" CA="259187274076" LA="259198369668" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</Msg>
<Msg
                UserText="DevName                                         = BadPrinterName" CA="259189194348" LA="259202784116" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</Msg>
<Msg
                UserText="OutDevMode                   = 00000000" CA="259194212632" LA="259205347188" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</Msg>
<Msg
                UserText="InDevMode                      = 0026D838" CA="259194365944" LA="259207533880" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</Msg>
<Msg
                UserText="fMode == 0x5E" CA="259195053008" LA="259208248332" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</Msg>
<Msg
                UserText="DM_COPY | DM_PROMPT | DM_MODIFY | DM_ADVANCED | DM_USER_DEFAULT" CA="259199944896" LA="259209030276" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</Msg>
<Msg
                UserText="Checking return from DocumentProperties():" CA="259578756012" LA="259579142928" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</Msg>
<Msg
                UserText="No Errors found" CA="259581819836" LA="259585130656" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</Msg>
<EndTest
                Title="DocumentPropertiesTEST"
                TUID=""
                Result="Pass"
                Repro="SUCCESS: Variation: 0" CA="259582037324" LA="259586679184" >
                <rti id="2701157395" />
                <ctx id="4071736938" />
</EndTest>

The difference between the Document Properties Test and the Document Properties Test Unicode is that the buffers in Document Properties Test are based on ANSI CHARs and the buffers in the Document Properties Test Unicode are based on Unicode WCHARs.

This test will "pass" if the log file contains no (zero) failures.

This test will "fail" if the log file shows one or more test cases failed.

Run Time: 5 minutes
Log File:docpropapi.log
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Command Syntax

Command option | Description
/p=<Printer Name> | The name of the printer to test.
/l=<Log File Name> | The name of the log file.
/s=<Server Name> | The name of the print server if the printer is remote.
/umdh | Run under memory leak detection.
/r=<Number> | The number of times to run the test.

Test Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK


Enable Filterpipeline Exception Handler

Type: Automated Test

Overview

The Enable Filterpipeline Exception Handler test sets certain registry keys to enable rich exception information and strict enforcement of exception handling policies for filter pipeline-hosted filters.

Details

The Windows Vista Logo requirements state that no crashes (that is, first or second change Structured Exceptions of certain exception codes that are always damaging for the process runtime) should occur in the processes that host third-party printer drivers or filters.
Run Time: 1 minute
Log File: <none>
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Troubleshooting

This test is minimal and should not require troubleshooting.

If the test fails, try to run the test (stand-alone or not) from an elevated credential account--that is, from the Administrator account or as an elevated member of the Administrators group.


GDLCheck

Overview

The GDLCheck tool is a GDL syntax checker that enables you to parse and load GDL files, specify configurations, and obtain XML snapshots.

Details

All parsing errors and debug output from this test are sent to Gdlcheck.xml. The command-line arguments are processed from left to right. Each argument is separated from the next with a space character. You need to specify all options before you specify the GDL root file name.

You can run this test tool from the Microsoft Windows Driver Kit (WDK) or stand-alone from the command prompt. This tool logs results to a WTT log file and you can configure the tool to log information at different verbosity levels. The tool requires the root GPD/GDL file that is being validated and any additional GPD or GDL files that the root file references.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Computer that meets the minimum software requirements

Processor

  • x86

  • x64

  • Itanium

Running GDLCheck

All debug output from GDLCheck is written to the GDLCheck.xml file.

The syntax for this tool is as follows:

GDLCheck.exe [-Verbosity=n], where n is a number from 0 to 4 specifying
the verbosity level of parser messages. Verbosity 4
is the most verbose and Verbosity 0 is the least verbose.
[-Personality[=persona]] Generate Personality Aware snapshot.
(To enable all personalities, use -Personality alone.)
[-DisplaySynthesizedFeatures]
[-GenerateSchema] (GDLschema.xsd) for XML snapshot.
[-DoNotGenerateXMLSnapshot]
[-DisplayOnlyStickyFeatures]
[-DisplayValidatedConfiguration]
[-ParserContext=n] where n is a number from 0 to 9. Initial context is 0.
[-PrefaceFile=<full path to file that holds Preface>]
[-DeviceConfiguration[=Feature1.Option1[:Feature2.Option2[:Feature3.Option3...]]]
[-DocumentConfiguration[=Feature1.Option1[:Feature2.Option2[:Feature3.Option3...]]]
(Always generates XML Snapshot.)
<-PrinterName=<name of an installed printer> | GDL root file path1 [GDL root file path2...]>
[-?] Display this message.

The following list describes some example GDLCheck commands:

  • GDLCheck.exe -DisplayValidatedConfiguration -DeviceConfiguration -DocumentConfiguration basic.gdl

    The preceding command produces an XML snapshot in GDLsnapshot.xml by using the default device and document configurations. basic.gdl implements the basic features that you need to satisfy the root construct productions that are defined in stdschem.gdl. The following debug output shows an example of what occurs if you specify the -DisplayValidatedConfiguration option.

    ==== Validated Configuration ====

    PaperSize:LETTER

    Resolution:Option1

    RESDLL:UniresDLL

    InputBin:UPPER

    If you execute the same command with hplj5si.gdl (instead of basic.gdl), you will see the following debug output.

    ==== 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

  • GDLCheck.exe -GenerateSchema -DoNotGenerateXmlSnapshot basic.gdl

    The preceding command produces the schema for the XML snapshot but not the snapshot itself. You can find the schema in GDLschema.xsd. This command shows the -GenerateSchema option and the -DoNotGenerateXmlSnapshot option, which turns off snapshot creation. The default behavior of Gdlcheck when the -DoNotGenerateXmlSnapshot option is omitted is to produce the XML snapshot.

  • GDLCheck.exe -PrefaceFile=preface.gdl -DisplayValidatedConfiguration -DeviceConfiguration -DocumentConfiguration basic.gdl

    The preceding command shows how you can use the -PrefaceFile option in Gdlcheck to specify a preface file. To perform the preceding test, you should comment out or remove the "*Include: "stdschmx.gdl" line from basic.gdl because preface.gdl already includes this line. The result of running the preceding command should be the same as in the first example command.

  • GDLCheck.exe -DisplaySynthesizedFeatures -DoNotGenerateXmlSnapshot synfea.gdl

    The preceding command shows depicts how you can use the -DisplaySynthesizedFeatures option to verify the creation of synthesized features. The following debug output shows an example of what occurs if you run the preceding command. Because the -DoNotGenerateXmlSnapshot option is used, the XML snapshot will not be created.

    === 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 -DoNotGenerateXmlSnapshot option not a requirement to use the -DisplaySynthesizedFeatures option. You could also use GDLCheck.exe -DisplaySynthesizedFeatures -DisplayValidatedConfiguration -DeviceConfiguration -DocumentConfiguration synfea.gdl, which would produce the following debug output.

    === 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

  • GDLCheck.exe -DisplayValidatedConfiguration -DeviceConfigurationMemory.8192KB:PrinterHardDisk.TRUE -cOrientation.LANDSCAPE_CC90:Resolution.Option2:PaperSize.LEGAL hplj5si.gdl

    The preceding command shows how you can use the -DeviceConfiguration and -DocumentConfiguration options to define the device and document configurations. The usage of these options in the first example causes the default configurations to be used. But this example illustrates how you can define your own configurations. The following debug output shows an example of what you might see from running the preceding command.

    ==== 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

  • You can use the -ParserContext argument in GDLCheck to validate more than one root GDL file within a single execution of GDLCheck. The syntax for this situation is shown below. This example also illustrates the use of the -Personality option that you can use to specify a personality for the generation of the personality aware XML snapshot.

    GDLCheck.exe -Preface=c:\test\preface.gdl -DisplayValidatedConfiguration -DeviceConfiguration -DocumentConfiguration c:\test\basic.gdl -ParserContext=1 -Preface=c:\test\preface.gdl -DisplayValidatedConfiguration -Verbosity=1 -Personality=Persona1 -GenerateSchema -DeviceConfiguration -DocumentConfiguration c:\test\personatest.gdl

Command Syntax

Command option | Description
GDLCheck.exe |
[-PrefaceFile=<PrefaceFile>] | Optional. The name of the file (with full path) that holds the preface.
[-Verbosity=n] | Optional. 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.
[-Personality=Persona] | Optional. A personality and generates a personality aware XML snapshot. -y enables all personalities.
[-DisplaySynthesizedFeatures] | Optional. Display the synthesized features.
[-GenerateSchema] | Optional. Generate schema (GDLSchema.xsd) for the XML snapshot.
[-DoNotGenerateXmlSnapshot] | Optional. Do not generate an XML snapshot. The XML snapshot is generated by default and saved to GDLSnapshot.xml.
[-DisplayOnlyStickyFeatures] | Optional. Display only doc sticky features in the XML snapshot. The default is all features.
[-DisplayValidatedConfiguration] | Optional. Display validated configuration for debug purposes.
[-ParserContext=n] | Optional. Change the parser context where n is a number from 0 to 9. The initial context is 0.
[-DeviceConfiguration[Feature1.Option1:Feature2.Option2:Feature3.Option3]] | Optional. Define the device configuration.
[-DocumentConfiguration[Feature1.Option1:Feature2.Option2:Feature3.Option3]] | Optional. Define the doc configuration.
<-PrinterName=<name of an installed printer> | <GDL root file name> | Required. The name of an installed printer OR the name of the root GDL file (with full path) that is being validated.


INFGate

Type: Automated Test

Overview

The INFGate tool checks the syntax in INF files for print and imaging device drivers.

Details

INFGate is the tool that checks both printing and imaging INF files. INFGate checks syntax, format, and the validity of the INF file. The tool can be run on an installed printer or on a stand-alone INF file. If an installed printer is selected, the tool looks for an INF file for the specified printer, and then runs.

Creating Valid INFs for Virtual Printers

Virtual printers must specify a null hardware ID. To specify a null hardware ID, in the models-section-name of the device's INF file, add a second comma between the install-section-name and the compatible-id.
[models-section-name]
device-description=install-section-name,,[compatible-id]

Run Time: 10 seconds per a model
Log File: <INF file name>.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Command Syntax

Command option | Description
/L <Log File> | Write log file named <Log File>
/O <Dir> | Directory to write html log files to
/B | Launch Default Browser &amp; Display Results
/DO | Don't write summaries for non-device INF files
/DC <Options> | Use Device Class &lt;Options&gt; When Checking INF files
/LO | Verify CopyFiles against Layout.inf
/MS | Internal use only
/WTT | Use WTTLOG
/PA | Check for 'Package Aware' INF files
/N <PrinterName> | Detect INF file by printer name

Code Tour

File Manifest

File | Location
INFGate.exe | tests\%ARCHITECTURE%\nttest\PrintScanTest\printing

Test Assertions

Windows Logo Program: DEVFUND-0001 Device driver must have a properly formatted INF for its device class


IsXPS Conformance Tool

Type: Automated Test

Overview

The command line tool isXPS (isXPS.exe) tests a file's conformity to the XML Paper Specification (XPS) Specification and the Open Packaging Conventions (OPC) Specification.

You can download the XPS and the OPC specifications at XPS: Specification and License Downloads.

Details

Features

  • Generates detailed report of the tests it performs.

  • Can test multiple files in a batch job.

  • Provides a description of every failure in every file tested.

  • Intelligently suggests which rules may have been violated by each failure found.

  • Supports switches that enable custom testing; for example, testing only for OPC conformity.

Syntax

Command line

isXPS.exe /f=file_name_or_pattern [options]

Note:

You can use a hyphen "-" in place of the forward slash "/" and a colon ":" in place of the equal sign "=" in all switches.

Switches

Switch Description

/?

Help for the tool is displayed in the Cmd.exe window. This switch blocks all tests from running. (The switch will also cause the tool to report a failure. This is to ensure that there are no accidental "pass" reports when the test is run in the testing infrastructure of the Windows Driver Kit (WDK).)

/BadDir= path

Specifies a directory where files that fail the conformity test will be copied or moved. They will be moved if the /DelBad switch is used. They will be copied if it is not used.

/DelBad

Specifies that files that fail the conformity test will be deleted from their current directory. (When used with the /BadDir switch, the files are moved to the directory specified by the latter switch. If the /BadDir switch is not used, they are deleted.)

/device=" device_string "

Specifies a custom device string that is used with the Windows Test Technologies (WTT) logger, which is available with the Windows Driver Kit (WDK). (See /logger.)

/doc= Doc_XSD_file

Specifies a custom XML Schema Definition (XSD) file for the validation of the <DocumentStructure> parts of the XPS file. We recommend that you let the tool use its built-in default XSD file instead of a custom file.

/f

Mandatory. Specifies the file or files to test. The standard command line wildcard characters, "?" and "*", can be used in file_name_or_pattern. If there are any spaces in the path or file name, enclose the whole path or file name in quotation marks. The file name extension for XPS files is usually 'xps' but it does not have to be.

/logfile= file_name

Specifies the path and file name for the log file. This switch is ignored unless the /logger switch is set to File. If the /logfile switch is not used and the /logger switch is set to File, the log file is IsXPSLog.txt in the current directory. If the /logsplit switch is used with a value larger than 0, the log file that is specified with /logfile will contain only the Setup Test. The other tests will be in one or more other log files. See /logprefix and /logsplit later in this table for more information, and see later in this topic for a description of all tests.

/logger= log_type

Specifies what kind of output to generate. This can be any of these values:

  • Console (default) - Output is streamed to the Cmd.exe window.

  • File - Output is saved to a text file that is named IsXPSLog.txt in the current directory, unless another path or file name is specified with the /logfile switch.

  • WTT - Output is saved to a Windows Test Technologies log file that is named IsXPSLog.wtl in the current directory. This option is usable only when the test is run in the testing infrastructure of the Windows Driver Kit (WDK).

/logprefix= prefix

Specifies a prefix that will be added to the start of the file names of the log files that are produced when the /logsplit switch is used.

When this switch is used without an explicit /logsplit switch (or with an explicit /logsplit=0), the tool behaves as if /logsplit=1 (see /logsplit later in this table).

/logsplit= number

Specifies whether, and how, the log is split into the multiple files.

When this switch is absent, or is present but set to its default of 0, there is no splitting (unless /logprefix is used anyway, in which case there is splitting and the tool behaves as if /logsplit=1 even when there is an explicit /logsplit=0 switch).

When this switch is set to 1, only the Setup Test will be reported in the file IsXPSlog.txt (or whatever file is specified with the /logfile switch). Each file test (see II. The <file_name> Test later in this topic) will be reported in a separate log file that is named _<file_name>.log where <file_name> is the name of the XPS file being tested. There will be a prefix before the underscore if the /logprefix parameter is used.

When this switch is set to any value larger than 1, it indicates how many file tests are included in each log file. Only the Setup Test will be reported in the file IsXPSlog.txt (or whatever file is specified with the /logfile switch). The other tests will be reported in separate log files that are named _NtoM.log, where NtoM specifies the range of files included in the log file. For example, if five files match the pattern specified with the /f parameter and /logsplit is set to 2, the tool will generate files named _1to2.log, _3to4.log, and _5to5.log. There will be a prefix before the underscore if the /logprefix parameter is used.

This switch is ignored unless the /logger switch is set to File. See later in this topic for a description of all tests.

/NoInterleave

This switch blocks the Interleave Test. See later in this topic for a description of all tests.

/OnlyOPC

Specifies that the input file is to be tested only for OPC conformity, not also XPS conformity. The internal markup of OPC -specific parts is tested. This switch blocks the XPS Package Structure Test from running. See later in this topic for a description of all tests.

/OnlyPkg

Specifies that the parts of the file are tested only to make sure that they are stored in the package correctly, have the correct type of content, and the correct relationships between them. The internal markup of the parts, including the OPC specific parts, is not tested. This switch blocks the Relationships Markup Test part of the OPC Validation Test from running. It also blocks the Fixed Document Sequence Test, Fixed Document Test, or Fixed Page Test parts of the XPS Package Structure Test from running. Finally, it blocks the Validation of Independent Resources Tests from running. See later in this topic for a description of all tests.

/r= Rsc_XSD_file

Specifies a custom XML Schema Definition (XSD) file for the validation of the <ResourceDictionary> parts of the XPS file. We recommend that you let the tool use its built-in default XSD file instead of a custom file.

/s

Specifies that subdirectories will be included in the search for files that match the pattern that is specified with the /f switch. If this switch is not used, subdirectories are not included. The parent directory is the current directory unless a different one is specified with the /f switch.

/SkipResParts

Specifies that independent resources (fonts and images) are not tested. This switch blocks the Validation of Independent Resources Tests from running. See later in this topic for a description of all tests.

/x= S0_XSD_file

Specifies a custom XML Schema Definition (XSD) file for the validation of the <FixedDocumentSequence>, <FixedDocument>, and <FixedPage> parts of the XPS file. We recommend that you let the tool use its built-in default XSD file instead of a custom file.

Run Time:
Log File: isXPSLog.txt
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • .Net Framework 3.0

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Troubleshooting

Log File Interpretation

The output is a series of nested test results. The start of each test is marked by a "+Start Test" line and the end of each test is marked by a "-End Test" line. The root test is the whole set of tests for all the files specified with the /f switch. For example, if the /f switch specifies "s*.xps", the root test is shown in the following example.

Beginning Test ******************************************

+Start Test: isXPS s*.xps

... matter omitted ...

-End Test: isXPS s*.xps Result: Fail

*********Log Rollup**************************************

TestName: isXPS s*.xps

PassRate: 77% Pass: 63 Warn: 0 Fail: 18 Block: 0

*********************************************************

Result: Fail

Notice that the "-End Test" line gives the overall result. If any file fails, the test as whole is marked "Fail".

The "Log Rollup" section summarizes the whole test. The "PassRate" is the percentage of tests that passed. "Pass", "Warning", and "Fail", give the number of tests that passed, passed-with-a-warning, and failed, respectively. ("Block" is a special failure state that is not used with the current version of the tool.)

The overall result is repeated in the last line.

There are two kinds of child tests of the root test:

  • Setup - There is exactly one Setup test in each log.

  • <file_name> - There is a test for each file that matches the pattern specified with the /f switch.

  1. The Setup Test

    The Setup test is used to determine whether the tool can run, parse its command line, and load and compile the XSD files. It has five kinds of child tests:
    1. Logger initialization - There is exactly one of these. It is always logged as "Pass" because if it fails, the log will not be generated anyway.
    2. Command line parsing - There is exactly one of these. If it fails, no details are reported, but help about the tool's syntax is streamed to the console.
    3. Loading and registering of custom XSD files - There will be from zero to three such child tests; one for each of the following switches that is used: /doc, /r, and /x. After an XSD file loads, the tool will register it. If the namespace associated with the XSD applies to more than one part of the XPS markup, it will be registered separately for each part to which it applies. For example, the <DocumentStructure> XSD will be registered for both the <DocumentStructure> and the <StoryFragments> parts. See the example later in this section.

      Note If a custom XSD file cannot load, the tool will not load any remaining XSDs. These include all the built-in XSDs. As a result, most subsequent tests will not run

    4. Loading and registering of the built-in XSD files - Unless a custom XSD cannot load, there will be at least nine of these tests. There will be one additional such test for each of the /doc, /r, and /x switches that is not used. The points made in the previous bullet about registration of custom XSDs apply to the built-in XSDs also.

    5. XSD Compilation - Assuming all the XSD files loaded, there is one compilation test and it will fail if any one of the XSD files cannot compile. If any XSD file cannot load, this test is not run.

      The following is an example of the outcome of a Setup Test. In this example, the /x switch was used to specify an alternative S0 schema.

      +Start Test: Setup

      Pass: Logger Initialized successfully

      Pass: Command line parameters parsed successfully

      Info: Reading stream for S0 schema from .\alternatexsds\s0schema.xsd

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06 and ContentType application/vnd.ms-package.xps-fixedpage+xml from provided stream

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06 and ContentType application/vnd.ms-package.xps-fixeddocument+xml from provided stream

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06 and ContentType application/vnd.ms-package.xps-fixeddocumentsequence+xml from provided stream

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06 and ContentType application/vnd.ms-package.xps-resourcedictionary+xml from provided stream

      Info: No filename specified for Resource Dictionary Key schema. Using default

      Info: No filename specified for Document Structure schema. Using default

      Info: Loading default Schema for Resource Dictionary key. (rdkey.xsd)

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06/resourcedictionary-key and ContentType application/vnd.ms-package.xps-fixedpage+xml from provided stream

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06/resourcedictionary-key and ContentType application/vnd.ms-package.xps-fixeddocument+xml from provided stream

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06/resourcedictionary-key and ContentType application/vnd.ms-package.xps-fixeddocumentsequence+xml from provided stream

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06/resourcedictionary-key and ContentType application/vnd.ms-package.xps-resourcedictionary+xml from provided stream

      Info: Loading default Schema for Document structure (DocStructure.xsd)

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06/documentstructure and ContentType application/vnd.ms-package.xps-documentstructure+xml from provided stream

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06/documentstructure and ContentType application/vnd.ms-package.xps-storyfragments+xml from provided stream

      Info: Loading default Schema for Relationship markup (Relationships.xsd)

      Info: Registering Schema for namespace http://schemas.openxmlformats.org/package/2006/relationships and ContentType application/vnd.openxmlformats-package.relationships+xml from provided stream

      Info: Loading default Schema for Package properties (CoreProperties.xsd)

      Info: Registering Schema for namespace http://schemas.openxmlformats.org/package/2006/metadata/core-properties and ContentType application/vnd.openxmlformats-package.core-properties+xml from provided stream

      Info: Loading default Dublin Schema for Package properties (dc.xsd)

      Info: Registering Schema for namespace http://purl.org/dc/elements/1.1/ and ContentType application/vnd.openxmlformats-package.core-properties+xml from provided stream

      Info: Loading default Dublin terms Schema for Package properties (dcterms.xsd)

      Info: Registering Schema for namespace http://purl.org/dc/terms/ and ContentType application/vnd.openxmlformats-package.core-properties+xml from provided stream

      Info: Loading default Dublin type Schema for Package properties (dcmitype.xsd)

      Info: Registering Schema for namespace http://purl.org/dc/dcmitype/ and ContentType application/vnd.openxmlformats-package.core-properties+xml from provided stream

      Info: Loading the OPC Digital Signature Schema (OPC_DigSig.xsd)

      Info: Registering Schema for namespace http://schemas.openxmlformats.org/package/2006/digital-signature and ContentType application/vnd.openxmlformats-package.digital-signature-xmlsignature+xml from provided stream

      Info: Loading the XML Digital Signature Core Schema (xmldsig-core-schema.xsd)

      Info: Registering Schema for namespace http://www.w3.org/2000/09/xmldsig# and ContentType application/vnd.openxmlformats-package.digital-signature-xmlsignature+xml from provided stream

      Info: Loading default Schema for Digital Signature Definitions (SignatureDefinitions.xsd)

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06/signature-definitions and ContentType CustomSignatureDefinitionTag from provided stream

      Info: Loading default Schema for the Discard Control part (DiscardControl.xsd)

      Info: Registering Schema for namespace http://schemas.microsoft.com/xps/2005/06/discard-control and ContentType application/vnd.ms-package.xps-discard-control+xml from provided stream

      Info: Compiling schemas

      -End Test: Setup Result: Pass

      For information about the Dublin schemas referred to in the example, see The Dublin Core Metadata Initiative.

  2. The <file_name> Test

    Each test of a particular file consists of the following child tests:

    1. Interleave Test - The tool will report whether the file is interleaved or not, and if the file is interleaved, whether it is interleaved correctly. (This test does not run if the /NoInterleave switch is used.) There are two child tests:

      1. Collection of Pieces Test - The tool collects all the embedded pieces of the file. These include each font and image file, the relationship files, and each *.fpage, *.fdoc, *.fdseq, and *.frag file. Below is an example of the log entry for this test. The XPS package being tested has a single fixed document that has a single fixed page, a single font, and a single image.

        +Start Test: Collecting pieces from .\MyFile.xps

        Info: _rels/.rels, collected

        Info: Documents/FixedDocument_1.fdoc, collected

        Info: Pages/_rels/FixedPage_1.fpage.rels, collected

        Info: Pages/FixedPage_1.fpage, collected

        Info: Resources/Fonts/33c063c8-1259-4322-acc8-8fc1964cc064.ODTTF, collected

        Info: Resources/Images/Image_1.png, collected

        Info: [Content_Types].xml, collected

        Info: FixedDocumentSequence.fdseq, collected

        -End Test: Collecting pieces from .\MyFile.xps Result: Pass

      2. Ordering of Parts Test - This test determines whether the order of the parts of the file is the same in the Zip central directory as it is in the Zip local file header. If the order is different the test gives you a "Warn", because the Microsoft Windows XP shell does not allow for editing of zip files in which the order is different.
    2. Validation of Independent Resources Tests - These tests search the entire file for XPS parts that point to font or image content types and the tests verify that each resource is of the correct content type. For example, it verifies that the resource pointed to by a font content type really is a font. (These tests do not run if the /SkipResParts switch or the /OnlyPkg switch is used.)

    3. OPC Validation Test - This test checks the XPS file's conformity to the OPC specification.

      The test has two child tests:

      1. Relationships Markup Test - The tool validates every <Relationships> part in the package, except relationships from the package root. There is a child test for every such part. For example, suppose there is a <Relationships> part called 1.fpage.rels as follows.

        <?xml version="1.0" encoding="utf-8"?>

        <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">

        <Relationship Type="http://schemas.microsoft.com/xps/2005/06/required-resource" Target="../../../Resources/7c1549d5-8780-4db6-8831-19bfe6d8f88d.ttf" Id="Rf50d8565978247c5" />

        <Relationship Type="http://schemas.microsoft.com/xps/2005/06/required-resource" Target="../../../Resources/2884eaa8-9d38-4506-adf8-977a24ff9faa.jpg" Id="R3643335530274b5f" />

        </Relationships>

        The tool would return the following log entry.

        +Start Test: /Documents/1/Pages/_rels/1.fpage.rels Markup

        Info: Validating Markup of Part /Documents/1/Pages/_rels/1.fpage.rels using target namespace "http://schemas.openxmlformats.org/package/2006/relationships"

        Pass: Markup of Part is Complaint according to the XSD supplied

        -End Test: /Documents/1/Pages/_rels/1.fpage.rels Markup Result: Pass

        If the /OnlyPkg switch is used, the log entries for the Relationships Markup Test will just warn that no validation was done.

      2. Package Relationships Markup Test - The tool validates the <Relationships> part, if any, at the root of the XML Paper Specification (XPS) package. For example, suppose there is a <Relationships> part called .rels as follows.

        <?xml version="1.0" encoding="utf-8"?>

        <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">

        <Relationship Type="http://schemas.microsoft.com/xps/2005/06/fixedrepresentation" Target="/FixedDocumentSequence.fdseq" Id="Ra1bd31ccb7f04267" />

        <Relationship Type="http://schemas.openxmlformats.org/package/2006/relationships/digital-signature/origin" Target="/package/services/digital-signature/origin.psdsor" Id="R290472945f4248d7" />

        </Relationships>

        The tool would return the following log entry.

        Info: Found a http://schemas.microsoft.com/xps/2005/06/fixedrepresentation relationship, validating...

        Pass: Valid Relationship to /FixedDocumentSequence.fdseq from a PackageRoot part. RelationshipType: http://schemas.microsoft.com/xps/2005/06/fixedrepresentation

        Info: Found a http://schemas.openxmlformats.org/package/2006/relationships/digital-signature/origin relationship, validating...

        Info: Digital Signature Origin part /package/services/digital-signature/origin.psdsor found, validating...

        ... matter omitted ...

        Pass: Valid Relationship to /package/services/digital-signature/origin.psdsor from a PackageRoot part. RelationshipType: http://schemas.openxmlformats.org/package/2006/relationships/digital-signature/origin

        If the relationship from the root is to an object that has internal markup, such as a <DigitalSignature> part, the validation of that <Relationship> part would include, as a child test, a validation of the target's markup. And the latter test could have its own children. For example, in the previous example, the test of the "Digital Signature Origin part" actually had the following test tree entry in place of "... matter omitted ...".

        +Start Test: Digital Signature Valdiation

        Info: Found a http://schemas.openxmlformats.org/package/2006/relationships/digital-signature/signature relationship, validating...

        Info: Found Digital Signature part /package/services/digital-signature/xml-signature/c613c04b58cb4d619c92bab230c4b0c6.psdsxs, validating...

        +Start Test: /package/services/digital-signature/xml-signature/c613c04b58cb4d619c92bab230c4b0c6.psdsxs Markup

        Info: Validating Markup of Part /package/services/digital-signature/xml-signature/c613c04b58cb4d619c92bab230c4b0c6.psdsxs using target namespace "http://www.w3.org/2000/09/xmldsig#"

        Pass: Markup of Part is Complaint according to the XSD supplied

        -End Test: /package/services/digital-signature/xml-signature/c613c04b58cb4d619c92bab230c4b0c6.psdsxs Markup Result: Pass

        Info: Found a http://schemas.openxmlformats.org/package/2006/relationships/digital-signature/certificate relationship, validating...

        Pass: Valid Relationship to /package/services/digital-signature/certificate/715364A10002007DBA0C.cer from a application/vnd.openxmlformats-package.digital-signature-xmlsignature+xml part. RelationshipType: http://schemas.openxmlformats.org/package/2006/relationships/digital-signature/certificate

        Pass: Valid Relationship to /package/services/digital-signature/xml-signature/c613c04b58cb4d619c92bab230c4b0c6.psdsxs from a application/vnd.openxmlformats-package.digital-signature-origin part. RelationshipType: http://schemas.openxmlformats.org/package/2006/relationships/digital-signature/signature

        -End Test: Digital Signature Valdiation Result: Pass

    4. XPS Package Structure Test - This test walks recursively through the tree of the XPS package. As it does so, it validates the markup of each part and verifies that there is a <Relationship> part for every resource that is referenced in the markup. (This test does not run if the /OnlyOPC is used.)

      The following child tests are included.

      1. Fixed Document Sequence Test - The <FixedDocumentSequence> markup in the *.fdseq file is validated. The following example shows the log report when the test is passed.

        +Start Test: /FixedDocumentSequence.fdseq Markup

        Info: Validating Markup of Part /FixedDocumentSequence.fdseq using target namespace "http://schemas.microsoft.com/xps/2005/06"

        Pass: Markup of Part is Complaint according to the XSD supplied

        -End Test: /FixedDocumentSequence.fdseq Markup Result: Pass

        The following is example shows the log report when the test fails, in this case because the XPS producer mistakenly added text between the <FixedDocumentSequence> begin and end tags.

        +Start Test: /FixedDocumentSequence.fdseq Markup

        Info: Validating Markup of Part /FixedDocumentSequence.fdseq using target namespace http://schemas.microsoft.com/xps/2005/06

        Fail: Markup is not Compliant: Number of errors: 1

        Info: XPSRule: M2.72

        Info: Error #1: At position (1,134) Message: The element 'FixedDocumentSequence' in namespace 'http://schemas.microsoft.com/xps/2005/06' cannot contain text. List of possible elements expected: 'DocumentReference' in namespace 'http://schemas.microsoft.com/xps/2005/06'.

        -End Test: /FixedDocumentSequence.fdseq Markup Result: Fail

        If the /OnlyPkg switch is used, the log entries for the Fixed Document Sequence Test will just warn that no validation was done.

      2. Fixed Document Test - The <FixedDocument> markup in a *.fdoc file is validated. The following example shows the log report when the test is passed.

        +Start Test: /Documents/FixedDocument_1.fdoc Markup

        Info: Validating Markup of Part /Documents/FixedDocument_1.fdoc using target namespace "http://schemas.microsoft.com/xps/2005/06"

        Pass: Markup of Part is Complaint according to the XSD supplied

        -End Test: /Documents/FixedDocument_1.fdoc Markup Result: Pass

        The following example shows the log report when the test fails, in this case because the <FixedDocument> part contains a reference to a page (<PageContent Source="../Pages/FixedPage_3.fpage" />) that is not in the package. Notice that the log provides a list of rules that may have been violated. You can look up errors in the XPS specifications, which are available for download at XPS: Specification and License Downloads.

        Fail: Error getting part: /Pages/FixedPage_3.fpage Message: Specified part does not exist in the package.

        Fail: Reference to non-existant or corrupted part: /Pages/FixedPage_3.fpage from /Documents/FixedDocument_1.fdoc

        Info: Possible violation of OPC rules M1.1, M1.2, M1.5, M1.6, M1.7, M1.8, M1.10, MB.2

        If the /OnlyPkg switch is used, the log entries for the Fixed Document Test will just warn that no validation was done.

      3. Fixed Page Test - The <FixedPage> markup in a *.fpage file is validated. The following example shows the log report when the test is passed.

        +Start Test: /Pages/FixedPage_1.fpage Markup

        Info: Validating Markup of Part /Pages/FixedPage_1.fpage using target namespace "http://schemas.microsoft.com/xps/2005/06"

        Pass: Markup of Part is Complaint according to the XSD supplied

        -End Test: /Pages/FixedPage_1.fpage Markup Result: Pass

        The following example shows the log report when the test fails, in this case because the <FixedPage> part contains an attribute that is not declared in the XPS schema. The log identifies the rule that is violated, and it specifies the exact character position where the erroneous markup starts.

        +Start Test: /Pages/FixedPage_2.fpage Markup

        Info: Validating Markup of Part /Pages/FixedPage_2.fpage using target namespace "http://schemas.microsoft.com/xps/2005/06"

        Fail: Markup is not Compliant: Number of errors: 1

        Info: XPSRule: M2.72

        Info: Error #1: At position (4,55) Message: The 'Stretch' attribute is not declared.

        -End Test: /Pages/FixedPage_2.fpage Markup Result: Fail

        If the /OnlyPkg switch is used, the log entries for the Fixed Page Test will just warn that no validation was done.

      4. Custom Markup Test - This tests for conformity to rules that are not imposed by the XSD files themselves, such as M2.74, M3.7 through M3.14, and M4.3. You can find these rules in the XPS specifications, which are available for download at XPS: Specification and License Downloads.

      5. Page Relationships Test - This test checks every reference to a resource part (a font, image, remote resource dictionary, or International Color Consortium [ICC] profile) in the <FixedPage> markup (the <page_name>.fpage component of an XPS package) and verifies that there is a corresponding required-resource relationship to that resource (in the <page_name>.fpage.rels component) and that the relationship points to the correct type of part. There is a child test for each resource. The following example shows a log entry for a relationship to a font.

        +Start Test: /Documents/1/Pages/3.fpage Relationships

        Info: Validating Relationships of Part /Documents/1/Pages/3.fpage

        Info: Validating Font part: /Resources/86e01f8d-dfc9-438e-9d02-830e7076a3f8.ODTTF ContentType: application/vnd.ms-package.obfuscated-opentype

        Info: Name:Verdana, Embedding rights:Installable, Glyphs count:62

        Pass: Found relationship to resource Part: /Resources/86e01f8d-dfc9-438e-9d02-830e7076a3f8.ODTTF

        -End Test: /Documents/1/Pages/3.fpage Relationships Result: Pass

      6. Unreferenced Parts Test - If any unreferenced parts are found in the package, the log will show a warning. The order of the child tests in the XPS Package Structure Test is as follows.
        • Test <FixedDocumentSequence> part.
        • Test first (or next) <FixedDocument> part referred to in the <FixedDocumentSequence> part.
        • Test the first (or next) <FixedPage> part referred to in the <FixedDocument> part.
        • Test the custom markup, if any, in the <FixedPage> part.
        • Test the <Relationships> part, if any, of the <FixedPage> part. This test has the following child tests.
          1. Test the first (or next) <Relationship> part in the <Relationships> part. Relationships can be to fonts, images, remote resource dictionaries, and International Color Consortium (ICC) profiles.
          2. Repeat step a for every relationship.
        • Repeat Steps 3 through 5 for every page in the document.
        • Repeat Steps 2 through 6 for every document in the sequence.
        • Test for unreferenced parts.

      The following example shows a complete XPS Package Structure Test result for a package with one (two-page) document, one font on each page, and an image on the second page. Notice that on the second page of the second document, the <FixedPage> part has a reference to a "Stretch" attribute that is not declared in the XPS specification. For this reason, the tool fails this page and the package.

      +Start Test: Validating XPS Package structure: .\Spec.xps

      Info: Validating XPSRule M2.14

      Info: Found a http://schemas.microsoft.com/xps/2005/06/fixedrepresentation relationship, validating...

      Pass: Valid Relationship to /FixedDocumentSequence.fdseq from a PackageRoot part. RelationshipType: http://schemas.microsoft.com/xps/2005/06/fixedrepresentation

      Pass: Found a Valid StartPart with ContentType: application/vnd.ms-package.xps-fixeddocumentsequence+xml

      +Start Test: /FixedDocumentSequence.fdseq Markup

      Info: Validating Markup of Part /FixedDocumentSequence.fdseq using target namespace "http://schemas.microsoft.com/xps/2005/06"

      Pass: Markup of Part is Complaint according to the XSD supplied

      -End Test: /FixedDocumentSequence.fdseq Markup Result: Pass

      Pass: Found markup reference to Valid Part with expected ContentType. TargetURI: /Documents/FixedDocument_1.fdoc ContentType: application/vnd.ms-package.xps-fixeddocument+xml

      +Start Test: /Documents/FixedDocument_1.fdoc Markup

      Info: Validating Markup of Part /Documents/FixedDocument_1.fdoc using target namespace "http://schemas.microsoft.com/xps/2005/06"

      Pass: Markup of Part is Complaint according to the XSD supplied

      -End Test: /Documents/FixedDocument_1.fdoc Markup Result: Pass

      Pass: Found markup reference to Valid Part with expected ContentType. TargetURI: /Pages/FixedPage_1.fpage ContentType: application/vnd.ms-package.xps-fixedpage+xml

      +Start Test: /Pages/FixedPage_1.fpage Markup

      Info: Validating Markup of Part /Pages/FixedPage_1.fpage using target namespace "http://schemas.microsoft.com/xps/2005/06"

      Pass: Markup of Part is Complaint according to the XSD supplied

      -End Test: /Pages/FixedPage_1.fpage Markup Result: Pass

      +Start Test: /Pages/FixedPage_1.fpage Custom Markup validation

      -End Test: /Pages/FixedPage_1.fpage Custom Markup validation Result: Pass

      +Start Test: /Pages/FixedPage_1.fpage Relationships

      Info: Validating Relationships of Part /Pages/FixedPage_1.fpage

      Info: Validating Font part: /Resources/Fonts/9aa4ea89-755c-4331-be84-0cd43ff87195.ODTTF ContentType: application/vnd.ms-package.obfuscated-opentype

      Info: Name:Verdana, Embedding rights:Installable, Glyphs count:35

      Pass: Found relationship to resource Part: /Resources/Fonts/9aa4ea89-755c-4331-be84-0cd43ff87195.ODTTF

      -End Test: /Pages/FixedPage_1.fpage Relationships Result: Pass

      Pass: Found markup reference to Valid Part with expected ContentType. TargetURI: /Pages/FixedPage_2.fpage ContentType: application/vnd.ms-package.xps-fixedpage+xml

      +Start Test: /Pages/FixedPage_2.fpage Markup

      Info: Validating Markup of Part /Pages/FixedPage_2.fpage using target namespace "http://schemas.microsoft.com/xps/2005/06"

      Fail: Markup is not Compliant: Number of errors: 1

      Info: XPSRule: M2.72

      Info: Error #1: At position (4,55) Message: The 'Stretch' attribute is not declared.

      -End Test: /Pages/FixedPage_2.fpage Markup Result: Fail

      +Start Test: /Pages/FixedPage_2.fpage Custom Markup validation

      -End Test: /Pages/FixedPage_2.fpage Custom Markup validation Result: Pass

      +Start Test: /Pages/FixedPage_2.fpage Relationships

      Info: Validating Relationships of Part /Pages/FixedPage_2.fpage

      Pass: Found relationship to resource Part: /Resources/Images/Image_1.png

      Info: Validating Font part: /Resources/Fonts/3b85141b-0969-4d9e-b9c8-e705bb7e6543.ODTTF ContentType: application/vnd.ms-package.obfuscated-opentype

      Info: Name:Times New Roman, Embedding rights:Installable, Glyphs count:4

      Pass: Found relationship to resource Part: /Resources/Fonts/3b85141b-0969-4d9e-b9c8-e705bb7e6543.ODTTF

      -End Test: /Pages/FixedPage_2.fpage Relationships Result: Pass

      Pass: No un-referenced parts found

      -End Test: Validating XPS Package structure: .\Spec.xps Result: Fail

Test Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK


Photo Print Test

Type: Automated Test

Overview

The Photo Print Test prints landscape and portrait oriented photos to exercise printer functionality.

PrintSpy is enabled for this test. For more information, please go to PrintSpy.

Details

This test prints five images in both portrait and landscape orientation and the summary page. The test verifies that all of the pages are printed and that the pictures are correctly rotated and fills the page. If a bitmap is printed out in the same orientation twice or does not stretch to fit the page, the test records a failure.

This test prints the following images:

  • Cover page: Portrait

  • Flower: Portrait and landscape

  • Two children: Portrait and landscape

  • Cow: Portrait and landscape

  • City image: Portrait and landscape

  • Standing rock: Portrait and landscape

Run Time: 2 minutes
Log File: photoprinttest.xml; photoprinttest_devicelogger.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 Photo Print Test

There are no specific procedures to run this test.

Troubleshooting

You can identify the failure of this test if no output is produced, the debugger breaks in, incorrect output is produced, or the log file indicates a failure.

The log files are:

  • photoprinttest.xml

  • photoprinttest_devicelogger.xml

Test Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK


Print - Common Scenario Stress with IO

Type: Automated Test

Overview

The Common Scenario Stress with IO job ensures that the device that you are testing accepts and correctly handles numerous Plug and Play (PnP) and power management state change scenarios, including disable/enable and suspend/hibernate/wake scenarios. Additionally, this job ensures that the device is still functional after these state changes 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 that you are testing through its service name or device instance identifier (ID). Additionally, the underlying scenario can run only disable/enable scenarios on disableable devices. A disableable device is a device that has the Disable option available in Windows 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: 3 hours
Log File:
System Restart Required: No
Test Category:

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 the Common Scenario Stress with IO job, you must install the device and driver on the test client computer. Next, install and configure Driver Test Manager (DTM).

To run Common Scenario Stress with IO, do the following:

  1. Open DTM Studio.

  2. 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.

  3. 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 on.

  4. In the Available Jobs pane, click the Common Scenario Stress with IO job.

  5. 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.

  6. Click Schedule Jobs.

  7. 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.

Troubleshooting

The underlying scenario is based on the new Microsoft Windows Device Testing Framework (WDTF). The Windows Driver Kit (WDK) contains extensive documentation about using and extending this framework in your own driver development process. For more information, search the WDK documentation for "Windows Device Testing Framework". For details about the specific operation of this scenario, open the WDK documentation, expand Windows Driver Kit, expand Other Tools, expand Windows Device Testing Framework, and click Automated Scenarios.

You may receive an error message similar to the following: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid." This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

For redundant network paths, add an additional NIC connected to the network.

Some machines will go into standby mode at the end of the test on Windows XP. If this occurs, you must wake the machine manually to complete the test. This is acceptable for Logo submission. If automation is required, you can wake the system by calling PoSetSystemState(ES_USER_PRESENT) from kernel mode.


Print - Disable Enable Test

Type: Automated Test

Overview

The Print - Disable Enable Test exercises the disable and enable behavior of a printer.

Details

This test is similar to the standard Disable Enable With IO test in the Microsoft Windows Driver Kit (WDK) but modified to work with printers. For more information, see the Disable Enable With IO test topic.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK

Troubleshooting

You may receive an error message similar to the following: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid." This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

For redundant network paths, add an additional NIC connected to the network.


Print - Sleep Stress plus Disable Enable with IO Test

Type: Automated Test

Overview

The Print - Sleep Stress plus Disable Enable with IO Test exercises the disable and enable behavior of a printer and puts it through sleep stress.

Details

This test is similar to the standard Sleep Stress plus Disable Enable With IO test in the Microsoft Windows Driver Kit (WDK) but modified to work with printers.

For more information, see the Sleep Stress and Disable Enable With IO test topics.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK

Troubleshooting

You may receive an error message similar to the following: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid." This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

For redundant network paths, add an additional NIC connected to the network.


Print - Sleep Stress with IO Test

Type: Automated Test

Overview

The Print - Sleep Stress with IO Test puts a print driver through sleep stress.

Details

This test is similar to the standard Sleep Stress With IO test in the Microsoft Windows Driver Kit (WDK) but modified to work with printers.

For more information, see the Sleep Stress With IO test topic.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK

Troubleshooting

You may receive an error message similar to the following: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid." This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

For redundant network paths, add an additional NIC connected to the network.

Some machines will go into standby mode at the end of the test on Windows XP. If this occurs, you must wake the machine manually to complete the test. This is acceptable for Logo submission. If automation is required, you can wake the system by calling PoSetSystemState(ES_USER_PRESENT) from kernel mode.


Print Driver Device Capabilities Test (prdevicecapabilities)

Type: Automated Test

Overview

The Print Driver Device Capabilities Test (prdevicecapabilities) test queries the driver to ensure that it returns the proper information for the DeviceCapabilities and GetDeviceCaps API calls.

PrintSpy is enabled for this test. For more information, please go to PrintSpy.

Details

The output for this test is in the form of a XML file called prdevcaps.xml. This file will contain all of the pass and fail information. This test will not produce any output to the physical printer.

Run Time: 2 minutes
Log File: prdevcaps.xml; prdevcaps_DeviceLogger.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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


Print Driver Devmode Corruptor Test

Type: Automated Test

Overview

The Print Driver Devmode Corruptor Test attempts scenarios with good and bad DEVMODE structures to make sure the driver gracefully handles bad data. This test is not meant to have output evaluated.

PrintSpy is enabled for this test. For more information, please go to PrintSpy.

Details

The primary way for applications and users to specify print job settings to the print subsystem is the DEVMODE structure. The print subsystem should treat it as untrusted because it originates from outside the print subsystem. The printer drivers often access this data structure as well.

The Print Driver Devmode Corruptor Test test tool exercises fault injection in the driver-related code paths in the print subsystem and thus checks the driver robustness in dealing with corrupted DEVMODE structures.

This test can generate large quantities of output. You can ignore and discard this output.

Typically, this test prints to a NULL port printer to avoid the physical output.

Run Time: 4 hours
Log File: DevModeCorruptor_DeviceLogger.xml; DevmodeCorrupt.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Command Syntax

Command option | Description
DevModeCorruptW.exe /printer="<printername>" /stress /Logfile=DevmodeCorrupt.xml /timetorun=4 |

Test Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK


Print Driver Rendering Test (pgremlin)

Type: Automated Test

Overview

The Print Driver Rendering Test (pgremlin) checks DDI calls that a driver can make. This test produces numerous pages of output with shapes and gradient fills and alpha blends. It also prints and tests some complex fonts.

Details

Pgremlin tests the possible DDI calls a driver can make. It uses .emf files that are printed out on the device. It can find output problems that a particular driver or device might have when performing a specific DDI call.

The test prints three pages of circular font wheels. The first page contains three font wheels followed by two Korean string lines. The second page contains two font wheels and the third one contains three font wheels. The font wheels should be in the font and size indicated above the wheel. The wheels should be uniform, with all lines of same size and weight. All three pages of font wheels will be printed out for each font download type. Each of the EMF files prints a title bar that contains the full path to the file printed, on the top left corner of the page.

One page with gradient fill bars is printed. The top of the page has seven horizontal gradient fill bars. Output should start at full density and lighten gradually to the right following the pattern that is listed just above the bar. The middle of the page has two triangular gradient fills. The one on the left starts in the middle and fills outward to a black edge. The one on the right starts on the outside and fills to a black center. At the bottom of the page there are seven vertical gradient fills. The darkest part of the fill is at the top with gradual progression to lighter at the bottom.

The following list describes additional test files:

  • ALPBLD00.emf: This test prints six columns of two rectangles. In each column, the two rectangles are connected by a single gray rectangle in the background that runs the entire length of the column. The first column (left) is solid gray rectangles. The remaining five columns use various patterns to fill from red inside, to solid gray on the outside.

  • ALPBLD09.emf: This test prints six columns of two rectangles. In each column, the two rectangles are connected by a single gray rectangle in the background that runs the entire length of the column. The first column (left) is solid black rectangles with a small white rectangle in the middle. The remaining five columns start with a white square on the inside with colored rectangles progressing outward from lighter colors to black on the outside.

  • Binrop00.emf: This test prints two boxes side by side. The boxes consist of a left black rectangle side, gray rectangle right side, and various hatch pattern rectangles as connecting crossbeams inside the box.

  • Bitblt13.emf: This test prints six columns of two rectangles. In each column, the two rectangles are connected by a column (left) and solid black rectangles. The remaining five columns use various patterns to fill from green inside, to solid black on the outside, with an overlaying hatch pattern.

  • Brush15.emf: This test prints six columns of two rectangles. In each column, the two rectangles are connected by a single gray rectangle in the background that runs the entire length of the column. Each of the rectangles has a pair of solid black lines that rung down the approximate middle of the rectangle. The rest of the rectangle is filled with a multicolored checkerboard pattern.

  • Excel_j1.emf: This test prints out a pie chart in Japanese with two circular pie charts on a gradient background at the bottom. The Japanese language is used in most of the part of the page. The first line of the chart is in English and says "Excel 2000 JP20_LET.xls".

  • Mskblt15.emf: This test prints six columns of two rectangles. In each column, the two rectangles are connected by a single gray rectangle in the background that runs the entire length of the column. The first column (left) is solid black rectangles with a white star in the middle. The remaining five columns have a white star in the middle with a hatch pattern on half the inside, and the rest of the rectangle is a gradual gradient fill from gray on the inside to solid black on the outside.

  • Path02.emf: This test prints nine gray vertical rectangles in the background. In the foreground left is reverse filled varying sizes of Arial normal font. On the right foreground is normal fill varying sizes of Arial normal font.

  • Pen09.emf: This test prints two sections of three vertical gray rectangles. The left and right sections have dotted line drawings that are symmetrical and appear to create a four-point star if they met in the middle.

  • Plgblt00.emf: This test prints six columns of two diamonds with a small rectangle in the middle. In each column, the three objects are connected by a single gray rectangle in the background that runs the entire length of the column. The first column (left) is solid black diamonds and rectangle. The remaining five columns start with red in the center and gradient fill outward to a solid black edge.

  • Region00.emf: This test prints four columns of three objects. The first object is a star, the second object is a circle, and the third object is a square. In each column, the three objects are connected by a single gray rectangle in the background that runs the entire length of the column. In the first and the forth column, all the objects are solid hatch filled object (the star actually has a pentagon shaped hole in the middle.) In the second column, all three objects are a hatched outline of the object. In the third column, the objects are solid black but are behind the gray rectangle running the length of the column.

  • Sbmode04.emf: This test prints three rows of four squares. Each of the squares has a coordinate "(0,0)" printed in the upper left corner. Each square starts with white in the center and fills outward to black on the edge.

  • Setdib01.emf: Same as Alpbld09.emf. The only difference here is that the first column is not solid black, but rather is a black rectangle with a dark red smaller rectangle inside it, and a smaller black rectangle inside the dark red one.

  • Strblt03.emf: This test prints six columns of two rectangles. In each column, the two rectangles are connected by a single gray rectangle in the background that runs the entire length of the column. The first column (left) is only the gray background rectangle. All following rectangles in the columns are transparent, which affects how they look when they overlap the background gray rectangle. The second column has solid gray rectangles, with a smaller gray rectangle inside it.

  • Strblt13.emf: This test prints two sets of mirrored rectangles. The top four rectangles consist of two multicolored rectangles with coordinate pairs in the center of the screen "(0,0)" that then mirrored into two top rectangles of the same design. The bottom set of four rectangles follow the same pattern.

  • Strdi03i.emf: Same as description of Strblt03.emf. The only difference is that there is color in the third column.

  • TRNBLT09.emf: This test prints six columns of two rectangles. In each column, the two rectangles are connected by a single gray rectangle in the background that runs the entire length of the column. The first column (left) is solid black rectangles with a small white rectangle in the middle. The remaining five columns start with a white square on the inside with colored rectangles progressing outward from lighter colors to black on the outside.

Run Time: 2 minutes
Log File: Pgremlin.log; Pgremlin.wtl; Pgremlin_DeviceLogger.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 Print Driver Rendering Test (pgremlin)

Test Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK


Print Driver Rendering Test (pgremlin2)

Type: Automated Test

Overview

The Print Driver Rendering Test (pgremlin2) performs rendering tests on a print driver. This test produces numerous pages of output with shapes and gradient fills and alpha blends. It also prints and tests some complex fonts.

Details

PGremlin2 performs rendering tests on a print driver. The rendering tests range from font tests to text extent tests and include printing bitmaps through the print driver. All print drivers are expected to pass this test. The test will fail if the print driver causes any sort of exception during the rendering.

PGremlin2 exercises the following DDs:

  • TransparentBlt

  • GradientFill

  • PlgBlt

  • StretchBlt

  • AlphaBlend

  • SetDIBBitsToDevice

  • PatBlt

  • FillPath

  • StrokeAndFillPath

The actual validation of the rendering is manual and you must perform that validation by looking at the physical paper output from the printer.

Run Time: 2 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK


Print Driver Stress Test

Type: Automated Test

Overview

The Print Driver Stress Test stresses the driver in various ways. This test is not meant to have output evaluated. It must be run for two hours.

PrintSpy is enabled for this test. For more information, please go to PrintSpy.

Details

This test can generate large quantities of output. You can ignore and discard this output.

This test exercises various driver code paths (both the rendering and configuration portion of the driver) on multiple threads. This exercise creates a stress environment for the printer drivers and often bugs are revealed by using this tool.

Typically, this test prints to a NULL port printer to avoid the large quantities of physical output.

Run Time:
Log File: printdrvstress.xml; PrintDrvStress_DeviceLogger.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Command Syntax

Command option | Description
PrintDrvStress.exe /printer="<printername>" /timetorun=120 |


Print Processor API Test

Type: Automated Test

Overview

The Print Processor API test tries to load the given print processor into its own process and verify that all of the required endpoints are available.

Details

The Print Processor API Test calls LoadLibrary on the specified print processor to load it into its own process. It then calls GetProcAddress on the following six required endpoints:

  • OpenPrintProcessor

  • ClosePrintProcessor

  • ControlPrintProcessor

  • EnumPrintProcessorDatatypesW

  • PrintDocumentOnPrintProcessor

  • GetPrintProcessorCapabilities

If the test cannot find one of these required endpoints, it will log a failure.

Due to the large number of possible functions that print processors are capable of, it is impossible to write an automated test that can test any given print processor. It is recommended that the print processors functionality is also tested manually to ensure that it is working as expected.

Command Line Parameters:

Usage: ProcAPITest [-printer:Printer Name] [-proc:Print Processor Name] [-l]

-printer: <Printer Name> name of printer to test.

Use \\Server\Printer for remote printers.

If no printer name is specified, the default printer is tested.

-proc: Name of the print processor to test.

-l: Lists the print processor on the system.

All print processors must be installed on the system before they can be tested. If the print processor is specified, it will be tested in combination with the default printer, or if no printer is installed, it will only be tested on whether or not it supports the required interfaces.

Pass: The Print Processor API test passes if the rollup at the end of the log file contains no failures.

Fail: The Print Processor API test fails if the rollup at the end of the log file contains one or more failures.

Run Time: 5 minutes
Log File: ProcAPITest.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK


PrintSpy

Type: Automated Test

Overview

PrintSpy is a tool that automatically executes debugger commands when there is an Application Verifier break. The debugger commands depend on the stop code.
Note PrintSpy does not introduce new points of failure; it simply makes existing failures associated with Application Verifier easier to discover and diagnose.

Details

Currently, PrintSpy is enabled for the following tests:

  • Documents Properties Test (Ansi)

  • Documents Properties Test (Unicode)

  • Photo Print Test

  • Print Driver Device Capabilities Test (PrDeviceCapabilities) - library job modified

  • Print Driver DevMode Corruptor Test

  • Print Driver Stress Test

  • Printable Area Test

  • Printer Port Monitor MIB Verification Test

  • PrintTicket Test

  • WSDMon Printer Verification Test (Windows 7)

PrintSpy generates XML logs under %SystemDrive%\Printspy on the client machine. To view the files, go to the client and open the XML files in the PrintSpy directory. After the test completes, the XML logs from %SystemDrive%\PrintSpy are copied to the DTM Controller. To view the logs, go to DTM Studio, right-click the test, and select Browse Job Logs.

There are two logs:

  • PrintSpy_[TestName].xml

  • PrintSpy_spoolsv_dbg.xml

If the log has only one line that starts with "PrintSpy was unable to continue...," no AppVerif breaks were hit.

If the log contains tables, it shows which Stop Code(s) were hit, as well as the commands executed by PrintSpy on the debugger.

Note If you are not sure whether the test is running, press Enter in the printspy or debugger window. This executes the last debugger command. If a debugger command is executed, then there has been a stop. Review the printspy logs and perform additional debugging. If nothing occurs, then the test is still running.

System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows XP

  • Windows Server 2003

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64


Print WinColor Test

Type: Automated Test

Overview

The Print WinColor Test validates that a color printer conforms to the Windows Color Compliancy requirements for printers. For more information about the Windows Color Compliancy requirements, see WinColorKit: Windows Color Quality Test Kit for Device OEMs.

Details

The test prints a series of color patches. Each color patch must be measured by 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 that are used and the calculations, see WinColorKit: Windows Color Quality Test Kit for Device OEMs.

Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Running Print WinColor Test

Run PrintColor.exe without any parameters.

To reproduce what the test is doing manually without running the test, see WinColorKit: Windows Color Quality Test Kit for Device OEMs.


Printable Area Test

Type: Automated Test

Overview

The Printable Area Test verifies that a print driver can output lines to the outer edge of the printable area.

PrintSpy is enabled for this test. For more information, please go to PrintSpy.

Details

The Printable Area application generates two single sheets each (portrait and landscape). You should run this test on different paper sizes, such as A4, Letter, Envelope 10, and A5.

Check the following points in the print area test:

  • Four separate lines are drawn; each one runs beyond the clipped region (2 inches larger than the HORZRES and VERTRES).

  • Diagonals are drawn in this rectangle to identify the page center and to facilitate debugging if the reported printable region is incorrect.

  • A second rectangle is drawn to be 1 inch from the physical edge of the page.

  • A 2-inch square is centered horizontally on the page, 1 inch from the top printable region.

  • A line of text is added to indicate the paper size and page orientation and should be centered on the page's printable area.

Run Time: 2 minutes
Log File: PrintArea.txt; PrintArea.wtl; PrintArea_DeviceLogger.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Troubleshooting

You can identify failures of this test if no output is produced, the debugger breaks in, incorrect output is produced, the paper size measurements are incorrect, or the log file indicate a failure.

Paper and print location measurements can vary one-sixteenth (1/16th).

Test Assertions

Windows Logo Program: IMAGING-0011 Printer supports printable regions accurately


Printer Port Monitor MIB Verification Test

Type: Automated Test

Overview

The Printer Port Monitor MIB Verification Test tool verifies that a TCP/IP printer supports the Printer Port Monitor MIB v1.0. This test tool also verifies that the printer supports the minimum components of the Host Resources MIB and Printer MIB that the Standard TCP/IP Port Monitor requires.

PrintSpy is enabled for this test. For more information, please go to PrintSpy.

Details

This test will perform SNMP queries on the device that you are testing. This test will verify that the device supports the minimum components of the Host Resources MIB and Printer MIB that the Standard TCP/IP Port Monitor uses to query device status. This test 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

  • x86

  • x64

  • Itanium

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


PrintTicket Conformance Test (PTConform)

Type: Automated Test

Overview

The PrintTicket Conformance Test (PTConform) is a conformance tool that you can use to check the validity of PrintTicket and PrintCapabilities documents. PTConform checks that a given PrintTicket or PrintCapabilities syntactically and structurally conforms to the public PrintSchema definition.

Details

The Print Schema provides an XML-based format for expressing and organizing a large set of properties that describe either a job format or capabilities of a print queue in a hierarchically structured manner. The PrintSchema has well-defined public framework elements and public keywords.

PTConform reads through an XML document and tests each node to be a valid public framework element. After testing for validity of the framework element, this test checks to see if it defines any public keyword element and checks for the keyword to conform to the PrintSchema.

Note If a framework node does not contain a public keyword but rather a printer driver's private namespace keyword, keyword validation is skipped for that node.

The results of the test are logged in the log file PTConform.log or PTConform.xml depending on the LogType chosen in the command line parameters.

Run Time: 2 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Command Syntax

Command option | Description
PTConform.exe /PrintTicket=PrintTicketXMLFileName /LogType=LogType /Verbosity=LogVerbosityLevel |
PrintTicketXMLFileName | Is the PrintTicket XML saved as a file on disk.
/LogType | LogType - Specifies the type of logging that you want. This option takes one of two values: "wtt" or "txt". When "wtt", a WTT logfile named PTConform.xml is created. When "txt", a text log file named PTConform.log is created. The default value is "txt". To obtain a WTT log, WTTLog.dll must be installed on the system.
LogVerbosityLevel | Specifies the verbosity of the log file that is produced. This option takes the following values: "1" will log only error messages and "2" will log traces and error messages.
PTConform.exe /PrintTicket=XmlFileName | Use PTConform to test a PrintTicket.
PTConform.exe /PrintCapabilities=XmlFileName | Use PTConform to test a PrintCapabilities.
PTConform.exe /Printer=PrintQueueName | Use PTConform to test the default PrintTicket for a specific print queue.

Test Assertions

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK


PrintTicket Test (PTTest2)

Type: Automated Test

Overview

The PrintTicket Test (PTTest2) is used to exercise the unmanaged PrintTicket and PrintCapabilties APIs that are part of Windows Vista.

PrintSpy is enabled for this test. For more information, please go to PrintSpy.

Details

You can use this test to test:

  • A driver's implementation of the PrintTicket/PrintCapabilties COM callable interface: IPrintTicketProvider.

  • A driver plugin's implementation of the PrintTicket or PrintCapabilties COM callable interface: IPrintOEMPrintTicketProvider.

  • A legacy driver's PrintTicket or PrintCapabilties shim layer. You can test the PrintTicket and PrintCapablities API calls for legacy printers that do not support the IPrintTicketProvider interface.

Run Time: 2 minutes
Log File: Pttest.log
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 PrintTicket Test (PTTest2)

If you have the WDKTestSuite at the command line, the test tool will sequentially run the test cases that are mentioned in the TestSuite.xml file. For the WDKTestSuite, the test cases include calling all of the native PrintTicket and PrintCapabilities APIs sequentially with valid input parameters and expect a valid output.

Cautions

Any attempt to change the system default printer while the test is running might lead to inconsistent results.

Test Assertions

Windows Logo Program: IMAGING-0023 Printer driver supports PrintTicket/PrintCapabilities


Test for XPSDrv

Type: Automated Test

Overview

The test for XPSDrv confirms if a driver is an XPSDrv driver. All of the XPS conformance validation occurs in other tests; this simply validates that the driver is an XPS driver. This test is used for the Windows Vista Premium Logo and the Windows HD Imaging AQ.

Details

Run Time: 1 minute
Test Category: Printer, Printer - Vertical Pairing (Wireless)
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: test_for_xpsdrv.vbs

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

This test will PASS if the driver is an XPSDrv driver. This test will FAIL if the driver is not an XPSDrv driver.

Code Tour

File Manifest

File | Location
Test_for_xpsdrv.vbs | [testbinroot]\nttest\printscantest\printing\WDK\test_for_xpsdrv\


Validate Color Profiles

Type: Automated Test

Overview

The Validate Color Profiles test validates the color profiles associated with the color device and that the color profile meets basic profile file format requirements.

Details

The test verifies the following:

  • The color profile that is associated with a device can be opened by using the OpenColorProfile() and WcsOpenColorProfile() functions.

  • A color transform can be created by using the color profiles.

  • The 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 Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:


Verify that MFP devices with multiple identical ports expose the same functionality on all ports (MANUAL)

Type: Manual Test

Overview

The purpose of this test is to ensure that an MFP device with multiple identical ports expose the same functionality on all ports. For example, if an MFP (printer and scanner) has two USB ports, both ports should be able to print and scan. An MFP that exposes print functionality on one port and scan functionality on the other port will fail this test.

Details

This requirement still allows devices to use USB ports for ?PictBridge? or another picture data protocol. For example, an MFP may contain two USB ports with different functionality, where one USB port is for MFP functionality and one port is for ?PictBridge.? However, there must be a clear distinction in functionality on the MFP for each port.

Run Time: 1 minute
Log File: None
System Restart Required: No
Test Category: Printing
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: SMTaske.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

The "Verify that MFP devices with multiple identical ports expose the same functionality on all ports (MANUAL)" tool returns PASS or FAIL, based on user input.

Command Syntax

Command option | Description
SMTask.exe | The test displays the question text.

Troubleshooting

The test will ask ?If this device has multiple, identical physical ports (For example, two USB-B connectors; disregard modem ports), do each of these ports expose the same set of functions (print, scan, fax, storage)?? It will then wait for a button push (Pass, Fail, NotApplicable), and write a WTT pass/fail result.

Code Tour

File Manifest

File | Location
SMTask.exe | [TestBinRoot]\NTTEST\DRIVERSTEST\WDKTools\SMTASK.exe


WCS PluginRobustness Test

Type: Automated Test

Overview

The WCS PluginRobustness Test tests the robustness of WCS color plug-ins to ensure that the plug-ins work as they should, do not crash in edge cases (unusual test cases), and are not vulnerable to malformed input data.

Details

This test enumerates all installed color profiles and tests all installed plug-ins that are referenced by any installed Device Model profile or Gamut Map Model profile. Profiles must be installed and plug-ins must be registered through standard COM procedures before the test is run. Because all installed profiles are tested, some might need to be removed before running the test in order to avoid failures from different third-party plug-ins. The test might issue helpful warning messages about questionable plug-in behavior during the test, but by not crashing, a plug-in passes the robustness test.

Run Time:
Log File: Logfile.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

  • x86

  • Itanium

Test Assertions

Device that uses an ICC or WCS XML profile properly installs the profile and is compliant with the appropriate profile specification.

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


WinFX Markup Content Rendering Test

Type: Automated Test

Overview

The WinFX Markup Content Rendering test loads eight WinFX XAML files and produces output to the specified printer. Seven of these XAML files each produce one letter-sized page of output, while the eighth XAML file, ThreePageDoc.xaml, produces three pages of letter-sized output. Therefore, this test will produce a total of ten pages of printed output.

Note This test cannot run on Windows Server 2008 without first installing Microsoft .NET Framework version 3.0.

Details

Run Time: 1 minute
Log File: PrintSaveXaml.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

With this test tool, you can generate jobs to send to a printer or XPS serialization. It includes options for validating the XPS that is produced, or selecting particular xaml files. This tool exits after printing each file one time.

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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


WSDMon Custom Extension XML File Verification Test

Type: Automated Test

Overview

This WSDMon Custom Extension XML File Verification Test 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 WSDMon Custom Extension XML File Verification Test will validate the custom extension file and it will dump any .xml contents that are deemed invalid. The test can be run against an installed printer or a static file. If the test is run against an installed printer, it will check if the printer driver has a Bi-D- extension file defined for WSDMon. If the file is defined, it will be loaded and verified. If the test 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

  • x86

  • x64

  • Itanium

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


WSDMon Printer Verification Test

Type: Automated Test

Overview

The WSDMon Printer Verification Test attempts to verify that a print device complies with the Web Services on Devices Print Service Definition v1.0. The Print Service Definition can be found at Implementing Web Services on Devices for Printing and Scanning . If the device under test is not a WSD device, the test will simply exit without error.

PrintSpy is enabled for this test. For more information, please go to PrintSpy.

Details

The test registers for the following WSD Print Service events:

  • PrinterElementsChangeEvent

  • PrinterStatusSummaryEvent

  • PrinterStatusConditionEvent

  • PrinterStatusConditionClearedEvent

  • JobStatusEvent

  • JobEndStateEvent

The test also attempts the following WSD Print Service operations:

  1. GetPrinterElements - PrinterDescription

  2. GetPrinterElements - PrinterConfiguration

  3. GetPrinterElements - PrinterStatus

  4. GetPrinterElements - DefaultPrintTicket

  5. GetPrinterElements - PrinterCapabilities

  6. SetEventRate

  7. CreatePrintJob

  8. SendDocument

  9. CancelJob

  10. GetJobElements - JobStatus

  11. GetJobElements - PrintTicket

  12. GetActiveJobs

  13. GetJobHistory

At the end of the test, a single page should output from the device under test. The output page contents will be "This is a sample print job created by the WSD Print logo test." in plain ASCII text.

Run Time: 1 to 5 minutes.
Log File: WsdPrintVerifyLog.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running WSDMon Printer Verification Test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
WsdPrintVerify.exe |
/PRINTER:[string] | The name of the local printer to be tested. This argument is required.

Code Tour

File Manifest

File | Location
WsdPrintVerify.exe | [testbinroot]\nttest\printscantest\printing\wsdmontests\

Troubleshooting

If a failure occurs, examine the test log file to see which operation or event failed. Also, take a Netmon trace between the device and the test system host. The Web Service requests and responses can be visually inspected for errors. Typically, a test case fails because the device does not support a particular operation/event or the device responds with invalid XML.


XPS Content Library

The XPS Content Library tool prints a set of XPS file content that is a representative subset of the XPS specification. It uses a static set of XPS files.

An XPS print filter and/or device is expected to consume all the valid XPS test files successfully and fail gracefully (no crashes, no "hangs," no resource leaks, and so on) on the non-conformant XPS files.

Note This test cannot run on Windows Server 2008 without first installing Microsoft .NET Framework version 3.0.

Test 1 - Valid Content Test

This test first prints a set of valid XPS documents. The XPS print filter and/or device is expected to consume these valid XPS files successfully.

Titles of valid Quality Logic documents that are expected to be printed:

mb01.xps | XPS Paths and Geometries Test
mb02.xps | XPS Brushes Test
mb03.xps | XPS Glyphs Test
mb04.xps | XPS Transforms and Clipping Test
mb05.xps | XPS Resources, Color, Opacity Test
mb06.xps | XPS Document Structure, HyperLinks, Signature, PrintTicket Test
mb07.xps | Saved as XPS from Microsoft Office 2007 Word
mb08.xps | Breakfast Menu
mb09.xps | The Suzuki Guitar (Printed to XPS from Microsoft Office 2007 PowerPoint)

Expected Result

For these files, please compare the output of the printed material with the images below, and make sure that they match:

Images of various geometric shapes and colors displaying the expected results of the XPS Paths and Geometries Test (mb01.xps)

Figure 1: mb01.xps

Images of rectangles and ovals of a variety of colors displaying the expected results of the XPS Brushes Test (mb02.xps)

Figure 2: mb02.xps

Images of a variety of fonts in a number of languages displaying the expected results of the XPS Glyphs Test (mb03.xps)

Figure 3: mb03.xps

Images of geometric figures in different angles and distortions displaying the expected results of the XPS Transforms and Clipping Test (mb04.xps)

Figure 4: mb04.xps

Images of shapes of various colors, opacities, and gradations displaying the expected results of the XPS Resources, Color, and Opacity Test (mb05.xps)

Figure 5: mb05.xps

Image of explanatory text (Page one) describing the XPS Document Structure, HyperLinks, Signature, and PrintTicket Test (mb06.xps) Image of explanatory text (Page two) describing the XPS Document Structure, HyperLinks, Signature, PrintTicket Test (mb06.xps) Image of explanatory text (Page three) describing the XPS Document Structure, HyperLinks, Signature, PrintTicket Test (mb06.xps)

Figure 6: mb06.xps

Image of text with illustrations of color space and the spectrum of electromagnetic radiation (Saved as XPS from Office 2007 Word) (mb07.xps)

Figure 7: mb07.xps

Image of the cover of a Breakfast Menu illustrating bright yellow and blue colors with gradations (mb08.xps)

Figure 8: mb08.xps

Image of an advertisement for the Suzuki guitar with bright, graduated blues and a very detailed photo of a baby holding a guitar (mb09.xps)

Figure 9: mb09.xps

Test 1 - Invalid Content Test

This test then attempts to print a set of XPS documents whose contents violate certain rules in the XPS/OPC specifications and rules of Markup Compatibility. The description of each file and the corresponding rule that it violates is below. The XPS print filter and/or device is expected to fail gracefully (no crashes, no "hangs", no resource leaks etc.) for each of these invalid XPS files and not produce output. It is acceptable for a printer to partially print the document, as long as it never prints the picture of the gumballs.

Streaming Consumers Note Drivers or devices that consume XPS in stream format are not able to detect the failure in M3.14a.xps until after the entire document has been received. As a result, they may complete printing the gumballs below, but they must detect the error and notify the user as soon as the error is encountered.

Documents that violate rules in the OPC specification:

M1.1a.xps | The 1.fpage part is missing a part name.
M1.2a.xps | The Default element in [Content_Types].xml is missing for the jpg type.
M1.2b.xps | The ContentType attribute in [Content_Types].xml is missing for the jpg type.
M1.2c.xps | The ContentType attribute in [Content_Types].xml is empty for the jpg type.
M1.3a.xps | The /Documents/1/Pages/1.fpage part has the name /Documents//Pages/1.fpage.
M1.5a.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages/1.fpage/.
M1.6a.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages#/1.fpage/. ('#' is a gen-delim character by RFC 3986)
M1.6b.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages?/1.fpage/. ('?' is a gen-delim character by RFC 3986)
M1.6c.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages[/1.fpage/. ('[' is a gen-delim character by RFC 3986)
M1.6d.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages]/1.fpage/. (']' is a gen-delim character by RFC 3986)
M1.7a.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages%2F/1.fpage/. (%2F is the percent-encoding for a forward slash.)
M1.7b.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages%5C/1.fpage/. (%5C is the percent-encoding for a backward slash.)
M1.8a.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages%48/1.fpage/. (%48 is the percent-encoding for a zero ("0").)
M1.8b.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages%51/1.fpage/. (%51 is the percent-encoding for a 'q'.)
M1.8c.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages%7E/1.fpage/. (%7E is the percent-encoding for a tilde ("~").)
M1.10a.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages/./1.fpage/.
M1.10b.xps | The /Documents/1/Pages/1.fpage part has the name /Documents/1/Pages/../1.fpage/.
M1.11a.xps | The /Resources/Images/image_0.jpg/image_1.jpg part has a name derived from adding a segment to the part name of the /Resources/Images/image_0.jpg part.
M1.12a.xps | /Resources/Images/image_0.jpg and /Resources/Images/IMAGE_0.JPG exist in the package.
M1.13a.xps | The ContentType attribute in [Content_Types].xml for the jpg type is "image" which breaks the RFC 2616 rule by having a type but no subtype.
M1.13b.xps | The ContentType attribute in [Content_Types].xml for the jpg type is "image/jpeg?" which breaks the RFC 2616 rule by containing a separator.
M1.14a.xps | The ContentType attribute in [Content_Types].xml for the jpg type is "image / jpeg" which contains LWS between the type and subtype.
M1.14b.xps | The ContentType attribute in [Content_Types].xml for the jpg type is " image/jpeg" which contains leading LWS.
M1.14c.xps | The ContentType attribute in [Content_Types].xml for the jpg type is "image/jpeg " which contains trailing LWS.
M1.15a.xps | The Default element in [Content_Types].xml for the jpg type is "image/jpeg <!-- comment -->" which contains an XML comment.
M1.17a.xps | [Content_Types].xml is encoded in ISO-8859-1.
M1.17b.xps | _rels\.rels is encoded in ISO-8859-1.
M1.18a.xps | [Content_Types].xml contains a DTD declaration at the top of the XML markup.
M1.18b.xps | _rels/.rels contains a DTD declaration at the top of the XML markup.
M1.20a.xps | [Content_Types].xml contains an illegal namespace at the top of the XML markup, and an attribute drawn from that namespace in the Default element for the jpg type.
M1.21a.xps | [Content_Types].xml contains an attribute drawn from the "xml" namespace in the Default element for the jpg type.
M1.21b.xps | _rels/.rels contains an attribute drawn from the "xsi" namespace in the Relationship element for the fixed document sequence.
M1.22a.xps | The content type for the Relationships part has a parameter / value pair.
M1.26a.xps | The _rels/.rels part contains two relationships with identical Id attribute values.
M1.26b.xps | The _rels/.rels part contains a relationship with an illegal Id value according to the W3C Recommendation (includes an exclamation point).
M1.27a.xps | The Type attribute of the fixed document sequence relationship is missing.
M1.27b.xps | The Type attribute of the fixed document sequence relationship is incorrect (set to core properties type).
M1.28a.xps | The Target attribute of the fixed document sequence relationship is missing.
M1.28b.xps | The Target attribute of the fixed document sequence relationship is not a URI.
M1.30a.xps | The fixed page relationship part is named incorrectly for a relationship part.
M1.30b.xps | The fixed page relationship part is has an invalid content type in [Content_Types].xml
M2.4a.xps | The fixed document sequence type has no matching Default or Override elements.
M2.5a.xps | The fixed document sequence type has two matching Default elements.
M2.5b.xps | The fixed document sequence type has two matching Override elements.
M2.6a.xps | The Extension attribute is missing for the fixed document sequence type
M2.6b.xps | The Extension attribute is missing a value for the fixed document sequence type.
M2.7a.xps | The PartName attribute is missing for the fixed document sequence type.
M2.7b.xps | The PartName attribute has an empty value for the fixed document sequence type.
M2.10a.xps | The rels type has Markup Compatibility markup.
M2.11a.xps | The fixed document sequence has both a non-interleaved part and an interleaved part.
M2.18a.xps | The _rels/.rels part is missing one piece.
M3.9a.xps | The entire ZIP archive is encrypted, the password is password.
M3.10a.xps | The file item "/[Content_Types].xml" has been renamed to "/Content_Types.xml".
M3.14a.xps | The local file header does not match the file header in the Central Directory for the _rels/.rels part.

Documents that violate rules in the XPS specification:

M1.2a | Package is not a zip archive, it's plain text instead
M2.2a | Missing ContentType attribute
M2.3a | Missing fixedrepresentation relationship
M2.3b | Two fixedrepresentation relationships
M2.3c | Missing FixedDocumentSequence part
M2.4a | Missing FixedDocument part
M2.5a | Missing FixedPage part
M2.6a | Missing Font Part
M2.6b | Missing FontURI attribute
M2.7c | Invalid FontURI attribute
M2.7a | Missing Image Part
M2.7b | Missing ImageSource attribute
M2.7c | Invalid ImageSource attribute
M2.8a | Missing Remote Resource Dictionary Part
M2.8b | Missing FixedPage Resource attribute for Remote Resource Dictionary Part
M2.8c | Invalid FixedPage Resource attribute
M2.10a | Missing Required Resource relationships
M2.10b | Invalid Required Resource relationships
M2.13a | Missing fixedrepresentation relationships
M2.13b | Two fixedrepresentation relationships
M2.14b | Fixedrepresentation relationship pointing to Nonexistence part
M2.17a | Corrupt JPG image
M2.18a | Corrupt PNG image
M2.25a | Corrupt TIF image
M2.35a | Corrupt WDP image
M2.39a | Corrupt ODTTF Font
M2.39b | Corrupt TTF Font
M2.39c | TTF Font treated as obfuscated font
M2.54a | Invalid Obfuscated font Filename
M2.59a | Two PrintTickets related to FixedDocumentSequence
M2.59b | Two PrintTickets related to FixedDocument
M2.59c | Two PrintTickets related to FixedPage
M2.70a | XML is encoded using big5 type
M2.71a | DTD in Relationship markup
M2.71b | DTD in Content_Types markup
M2.71c | DTD in FixedPage markup
M2.72a | Invalid XML file
M2.72b | Contain elements that do not conform with XPS XSD schema
M2.72c | Contain attributes that do not conform with XPS XSD schema
M2.73a | Xml:id attribute in FixedPage markup
M2.73b | Xsi:SchemaLocation attribute on <FixedPage> element
M2.74a | Duplicate attribute (FixedPage::Width)
M2.74b | Duplicate element (Path::Fill)
M2.74c | Duplicate attribute/element (<Path> has Fill attrib and <Path.Fill> child element)
M2.75a | Xml:space attribute on <FixedDocument> element
M2.75b | Xml:space attribute on <PageContent> element
M2.75c | Xml:space attribute on <FixedPage> element
M2.75d | Xml:space attribute on <Path> element
M2.77a | Missing Source attribute
M2.77b | Invalid Source attribute
M3.2a | Missing DocumentReference::Source attribute
M3.2b | Invalid DocumentReference::Source attribute
M3.3a | Multiple <DocumentReference> elements pointing to same FixedDocument
M3.5a | Missing PageContent::Source attribute
M3.5b | Invalid PageContent::Source attribute
M3.6a | Multiple <PageContent> elements pointing to same FixedPage
M3.6b | Multiple <PageContent> elements pointing to same FixedPage (from different FixedDocuments)
M3.20a | Missing x:Key attribute for Canvas
M3.20b | Invalid x:Key attribute for Canvas
M4.1a | Missing x:Key attribute for Path
M4.1b | Invalid x:Key attribute for Path
M4.2a | Missing x:Key attribute for PathGeometry
M4.2b | Invalid x:Key attribute for PathGeometry
M4.3a | Duplicate PathFigure
M5.2a | Missing UnicodeString / Indices
M5.2b | Missing Indices and Invalid UnicodeString ("")
M5.2c | Missing Indices and Invalid UnicodeString ("{}")
M5.3a | Missing x:Key attribute for Glyphs
M5.3b | Invalid x:Key attribute for Glyphs
M5.4a | <Glyphs> element with an Indices attribute that contains an invalid Glyph Index for the specified font
M5.4b | <Glyphs> element that has more entries in the indices attribute than the UnicodeString attribute
M5.7a | <Glyphs> element that has a UnicodeString attribute that starts with {
M5.15a | <Glyphs> element that has both BidiLevel and isSideways attributes
M6.1a | Missing x:Key attribute for SolidColorBrush
M6.1b | Invalid x:Key attribute for SolidColorBrush
M6.2a | Missing x:Key attribute for ImageBrush
M6.2b | Invalid x:Key attribute for ImageBrush
M6.3a | Missing ImageSource attribute
M6.3b | Invalid ImageSource attribute (<ImageBrush> element that references a font part)
M6.4a | Missing x:Key attribute for VisualBrush
M6.4b | Invalid x:Key attribute for VisualBrush
M6.5a | Missing x:Key attribute for LinearGradientBrush
M6.5b | Invalid x:Key attribute for LinearGradientBrush
M6.6a | Missing x:Key attribute for RadialGradientBrush
M6.6b | Invalid x:Key attribute for RadialGradientBrush
M7.2a | Missing namespace declaration in ResourceDictionary
M7.2b | Invalid namespace declaration in ResourceDictionary
M7.5a | Remote resource dictionary that references another remote resource dictionary
M7.6a | ResourceDictionary that has both Source and ResourceDefinitions set
M7.11a | Missing x:Key attribute for MatrixTransform
M7.11b | Invalid x:Key attribute for MatrixTransform
M8.14a | ContextColor value contains exponent form numbers
M9.10a | Name attribute in RemoteResourceDictionary
M9.10b | Name attribute in ResourceDictionary
M12.2a | A FixedDocument is referenced twice in DocumentSequence
M12.3a | A FixedPage is referenced twice in a single FixedDocument
M12.3b | A FixedPage is referenced twice in different FixedDocument(s)
M12.5a | FixedDocumentSequence with two PrintTickets
M12.5b | FixedDocument with two PrintTickets
M12.5c | FixedPage with two PrintTickets
M12.7a | ContentType attribute containing a Parameter (ContentType="image/jpeg;q=0")

Documents that violate Markup Compatibility rules:

M1.1a

The Canvas element in the FixedPage markup contains an BadMustUnderstand attribute in the Markup Compatibility namespace.

The XML in the \Documents\1\Pages\1.fpage part is invalid: <Canvas mc:BadMustUnderstand="v1">

M1.2a

The Canvas element in the FixedPage markup contains a BadMustUnderstand attribute in the Markup Compatibility namespace.

The XML in the \Documents\1\Pages\1.fpage part is invalid: <Canvas mc:BadMustUnderstand="v1">

M2.14a

The Canvas element in the FixedPage markup contains a ProcessContent attribute that doesn't belong to a namespace that is identified by the Ignoreable attribute on the Canvas element.

The XML in the \Documents\1\Pages\1.fpage part is invalid:
<Canvas mc:Ignorable="v3" mc:ProcessContent="v2:Blink">

M2.17a

The Canvas element in the FixedPage markup contains a ProcessContent attribute that doesn't belong to a namespace that is identified by the Ignoreable attribute on the Canvas element.

The XML in the \Documents\1\Pages\1.fpage part is invalid:
<Canvas mc:Ignorable="v2" mc:ProcessContent="v2:Blink">
<v2:Blink xml:lang="en-US">

M2.27a

The Canvas element in the FixedPage markup contains a MustUnderstand attribute that isn't understood.

The XML in the \Documents\1\Pages\1.fpage part is invalid:
<Canvas mc:MustUnderstand="v2">

M2.27b

The Canvas element in the FixedPage markup contains a MustUnderstand attribute that isn't understood. Even though it is specified as Ignorable.

The XML in the \Documents\1\Pages\1.fpage part is invalid:
<Canvas mc:Ignorable="v2">
<Canvas mc:MustUnderstand="v2">

M2.30a

The AlternateContent element in the FixedPage markup does not contain a Choice child element.

The XML in the\Documents\1\Pages\1.fpage part is invalid:
<mc:AlternateContent>
<mc:Fallback>

M2.31a

The AlternateContent element in the FixedPage markup contains two Fallback child elements.

The XML in the \Documents\1\Pages\1.fpage part is invalid:

M2.32a

The AlternateContent element in the FixedPage markup contains Fallback child element that precedes a Choice element.

The XML in the \Documents\1\Pages\1.fpage part is invalid:

M2.33a

The AlternateContent element in the FixedPage markup is a child of another AlternateContent element.

The XML in the \Documents\1\Pages\1.fpage part is invalid:

M2.35a

AlternateContent element has an attribute that is unprefixed

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:AlternateContent Ignorable="v2">

M2.36a

AlternateContent element has a child that is neither understood nor ignorable

The XML in the \Documents\1\Pages\1.fpage part is invalid (as a child of AlternateContent): <v2:Circle Center="13,20" Radius="20" Color="Yellow" Opacity="0.5" Luminance="13" />

M2.36b

AlternateContent has an attribute that belongs to a namespace that is neither understood nor ignorable.

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:AlternateContent v2:Blink="Blink" />

M2.41a

Choice element contains an attribute from a namespace that is neither understood nor ignorable.

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:Choice Requires="v2" v2:bad="bad">

M2.41b

Fallback element contains an attribute from a namespace that is neither understood nor ignorable.

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:Fallback v2:bad="bad">

M2.42a

Choice element has a MustUnderstand attribute that identifies a namespace it does not understand, which is v2

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:Choice Requires="v2" mc:MustUnderstand="v2">

M2.42b

Fallback element has a MustUnderstand attribute that identifies a namespace it does not understand, which is v2

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:Fallback mc:MustUnderstand="v2">

M2.43a

AlternateContent element has the xml:lang attribute

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:AlternateContent xml:lang="en-US">

M2.43b

AlternateContent element has the xml:space attribute

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:AlternateContent xml:space="default">

M2.48a

Choice element has an unprefixed attribute

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:Choice Ignorable="v3" Requires="v2">

M2.49a

Choice element has the xml:lang attribute.

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:Choice xml:lang="en-US" Requires="v2">

M2.49b

Choice element has the xml:space attribute.

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:Choice xml:space="default" Requires="v2">

M2.50a

Choice element has a Requires attribute that specifies a non-visible namespace.

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:Choice Requires="v5">

M2.52a

Choice element has a Requires attribute that has the Markup Compatibility prefix

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:Choice mc:Requires="v2">

M2.55a

Fallback element has an attribute that has no prefix

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:Fallback Ignorable="v2">

M2.56a

Fallback element has an xml:lang attribute.

The XML in the \Documents\1\Pages\1.fpage part is invalid: <mc:Fallback xml:lang="en">

Documents that deal with Thumbnails -- Optional:

Note Invoking this job should only print one page. The page should be titled "Valid Thumbnail" and contain a red square box.

M2.36a | FixedPage with 2 thumbnails
M2.37a | FixedPage with TIF thumbnail
Thumbnail.xps | Valid XPS file containing a thumbnail

Documents that deal with Discard Control -- Optional:

Note Invoking this job should only print one page. The page should be titled "Valid Discard Control" and contain a multi-color circle inside a black square box.

M10.6a | DiscardControl references itself (TargetUri)
M10.6b | DiscardControl references itself (SentinelUri)
M10.23a | Multiple DiscardControl package relationships
DiscardControl.xps | Valid XPS file containing a discard control


XPS Content Library - Discard Control Processing (MANUAL)

Type: Manual Test

Overview

This test loads both valid and invalid XPS documents that contain Discard Control, and attempts to print them to the specified printer. This test is optional - it will only need to be run if the consumer supports Discard Control processing.

Details

With this test tool, you can generate jobs to send to a printer or XPS serialization. This tool includes options for validating the XPS that is produced, or selecting particular xml files. The tool exits after printing each file one time.

Run Time: 1 minute.
Log File: <FileName>.wtl (For example, XPS_M10.6a.wtl)
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: Print_XPS_File.cmd.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

The devices being tested should only print one file. The file that is printed should be titled "Valid Discard Control" and contain a multi-colored circle inside a black square box. If it fully prints any other file, then it fails the test, because those other files are invalid.

Documents that deal with Discard Control -- Optional:

Note Invoking this job should only print one page. The page should be titled "Valid Discard Control" and contain a multi-color circle inside a black square box.

M10.6a | DiscardControl references itself (TargetUri)
M10.6b | DiscardControl references itself (SentinelUri)
M10.23a | Multiple DiscardControl package relationships
DiscardControl.xps | Valid XPS file containing a discard control

Command Syntax

Command option | Description
Print_XPS_File.cmd | Without any options, the test enumerates devices.

Code Tour

File Manifest

File | Location
Print_XPS_File.cmd | [TestBinRoot]\nttest\printscantest\printing\


XPS Content Library - Thumbnail Processing (MANUAL)

Type: Manual Test

Overview

This test loads both valid and invalid XPS documents that contain thumbnails, and attempts to print them to the specified printer. This test is optional - it will only need to be run if the consumer supports thumbnail processing.

Details

With this test tool, you can generate jobs to send to a printer or XPS serialization. This tool includes options for validating the XPS that is produced, or selecting particular xml files. The tool exits after printing each file one time.

Run Time: 1 minute
Log File: <FileName>.wtl (for example, XPS_M2.37a.wtl)
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: Print_XPS_File.cmdRequirements

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

The devices being tested should only print one file. The file that is printed should be titled "Valid Thumbnail" and should contain a red square box. If it fully prints any other file, then it fails the test, because those other files are invalid.

Documents that deal with Thumbnails -- Optional:

Note Invoking this job should only print one page. The page should be titled "Valid Thumbnail" and contain a red square box.

M2.36a | FixedPage with 2 thumbnails
M2.37a | FixedPage with TIF thumbnail
Thumbnail.xps | Valid XPS file containing a thumbnail

Command Syntax

Command option | Description
Print_XPS_File.cmd | Without any options, the test enumerates devices.

Code Tour

File Manifest

File | Location
Print_XPS_File.cmd | [WTT\WOW64TestBinRoot]\nttest\printscantest\printing\

Test Assertions

This test enforces the following Windows Logo Requirement
IMAGING-0010


XPS Content Rendering Test

Type: Automated Test

Overview

The XPS Content Rendering test loads a valid xps document and prints it to the specified printer.

Note This test cannot run on Windows Server 2008 without first installing Microsoft .NET Framework version 3.0.

Details

With this test tool, you can generate jobs to send to a printer or XPS serialization. This tool includes options for validating the XPS that is produced, or selecting particular xaml files. The tool exits after printing each file once.

Run Time: 1 minute
Log File: PrintSaveXaml.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Troubleshooting

If a failure occurs, a relevant stack trace should be logged:

  • Exceptions with LoadObjectFromFile in the stack usually indicate problems with setup. Make sure all necessary files have been copied for the test, and that WinFX is properly installed.

  • Exceptions with XpsDocumentWriter.Write in the stack usually indicate problems with printing. If the exception is a ComException instance, make note of that in the HResult field.


XPS Rendering Verification Test

Type: Automated Test

Overview

The XPS Rendering Verification test validates the correctness of an XPS rendering engine. The XPS Rendering Verification Test provides for fuzzy image comparison with adjustable tolerance levels, so that pixel-by-pixel matching is not a strict requirement.

Details

The XPS Rendering Verification test validates the correctness of an XPS rendering engine. A typical mode of execution is as follows:

The user can create multipage TIFF raster images (from XPS files in the Content Library job, for example) by using a rendering engine with the XPS Rendering Verification test. The user then verifies only once that the raster images are "correct." The user can then use the raster images and the XPS Rendering Verification Test on a continuous build-to-build manner as a thorough regression test for their rendering engine. This test, then, can be run after each change in rendering code and verify that the look of the document stays the same.

The XPS Rendering Verification test provides for fuzzy image comparison with adjustable tolerance levels, so that pixel-by-pixel matching is not a strict requirement.

Run Time: 2 minutes
Log File: specified on the command line; by default: LooksGood.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Troubleshooting

Try to delete any previous log files in the local directory. Make sure WinFX is installed correctly.


XPS Security Test

Type: Automated Test

Overview

The XPS Security test attempts to load an invalid XPS document and print it to a specified printer.

Note This test cannot run on Windows Server 2008 without first installing Microsoft .NET Framework version 3.0.

Details

With this test, you can generate jobs to send to a printer or XPS serialization. This tool includes options for validating the XPS that is produced, or selecting particular xaml files. The tool exits after printing each file once.

Expected Behavior

This test will output a non-deterministic number of valid and invalid XPS documents. The driver may produce output, but no crashes or hangs in the driver or device are allowed.

Run Time: 1 minute
Log File: PrintSaveXaml.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Troubleshooting

If a failure occurs, a relevant stack trace should be logged:

  • Exceptions with LoadObjectFromFile in the stack usually indicate problems with setup. Make sure all necessary files have been copied for the test, and that WinFX is properly installed.

  • Exceptions with XpsDocumentWriter.Write in the stack usually indicate problems with printing. If the exception is a ComException instance, make note of that in the HResult field.


Storage Testing

The following sections describe how to test storage devices and controllers to qualify them for the Windows logo.

Note Run Storage > Adapter and LAN (Ethernet) test submissions for Windows Server 2008 on systems with a minimum of 4 processor cores and 6 gigabytes of memory. These requirements are in addition to those related to the Dynamic Partitioning (DP) Simulator and Test that all Windows Server 2008 device driver submissions must meet.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Note The storage logo program names have changed. Use the following table to map the old names to the new names.

Old Logo Program Name (used in this documentation) | Change | New Logo Program Name
Storage > Adapter or Controller > ATA | Merged | Storage > Adapter or Controller
Storage > Adapter or Controller > ATA RAID
Storage > Adapter or Controller > Fibre Channel
Storage > Adapter or Controller > iSCSI HBA
Storage > Adapter or Controller > SAS
Storage > Adapter or Controller > SAS-RAID
Storage > Adapter or Controller > SCSI
Storage > Adapter or Controller > SCSI RAID
Storage > Adapter or Controller > Serial ATA
Storage > Adapter or Controller > Serial ATA RAID
Storage > Adapter or Controller > iSCSI Boot Component | Renamed | Storage > iSCSI Boot Component
Storage > CD or DVD Drive | Renamed | Storage > Optical Disk Drive (ODD)
Storage > Hard Drive | Renamed | Storage > Hard Disk Drive (HDD)
Storage > RAID Storage > iSCSI Bridge | Renamed | Storage > Bridge
Storage > RAID Storage > Hardware based RAID System > Fibre Channel | Merged | Storage > Hardware Based RAID (Storage Array)
Storage > RAID Storage > Hardware based RAID System > iSCSI
Storage > RAID Storage > Hardware based RAID System > SAS
Storage > RAID Storage > Hardware based RAID System > SATA
Storage > RAID Storage > Hardware based RAID System > SCSI
Storage > Removable Media | Renamed | Storage > Removable Storage

For troubleshooting information, see Troubleshooting Storage Tests.

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Adapter or Controller Testing

The procedures in this section describe how to test your adapter or controller for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure the full functionality of the device, 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:

Preparing: The preparing topics describe how to configure the system or systems for logo testing.
Running: The running topics describe how to run the tests for your device or system.
Troubleshooting: The troubleshooting section provides information to diagnose adapter and controller failures, warnings, and errors.

Adapter or Controller Tests

The tests that you must run depend on the capabilities of the device or system that you are testing. The following table contains all of the tests that might be required for your test device.

 | iSCSI Boot | iSCSI HBA | Fibre Channel | ATA | SAS | SATA | SCSI
2.2 TB Boot Scenario | X | X | X | X | X | X | X
Device Fundamental Tests |  | X | X | X | X | X | X
Boot Test |  | X | X | X | X | X | X
Crashdump Support Test |  | X | X | X | X | X | X
Disk Stress |  | X | X | X | X | X | X
Disk Verification |  | X | X | X | X | X | X
IFS Test |  | X | X | X | X | X | X
Storage Query Property |  | X | X | X | X | X | X
Syscache Test |  | X | X | X | X | X | X
Separated Cache Solution Evaluation test (NV-Cache only) |  |  |  | X | X | X | X
SCSI Compliance test (RAID only) |  |  |  | X | X | X | X
SCSI Compliance Test 2.0 (LOGO) |  |  |  | X | X | X | X
Optical Media Burning Test |  |  |  | X |  | X |
DMA Test |  |  |  | X |  |  |
HBA API Test |  |  | X |  |  |  |
VDS HCT (VDS only) |  | X | X |  |  |  | X
iSCSI Boot |  | X |  |  |  |  |
iSCSI Digest - Disk (HBA) |  | X |  |  |  |  |
iSCSI Mutual CHAP (Target) |  | X |  |  |  |  |
iSCSI Oneway CHAP (Target) |  | X |  |  |  |  |
iSCSI Persistent Login Test |  | X |  |  |  |  |
iSCSI Ping Test (HBA) |  | X |  |  |  |  |
iSCSI Redirection Test |  | X |  |  |  |  |
iSCSI WMI Verification |  | X |  |  |  |  |
iSCSI Boot Firmware Table Test | X |  |  |  |  |  |

Run Time

Approximately 2 hours for iSCSI boot.

Approximately 4 days for all other programs.

Hardware Requirements

The following hardware is required for adapter or controller testing. Additional hardware might be required if the test device provides bus-specific support. To determine whether there are additional hardware requirements, see the description for each bus-specific test.

  • For Windows 7, Windows Vista, or Windows XP:
    • One dual-core or equivalent processor
    • 4 GB of memory
  • For Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003:
    • One quad-core or equivalent processor
    • 6 GB of memory
    • For Windows Server 2008 only: If the test system does not have a second instance of the test adapter installed, you must have a second system. The second system must also meet the processor and memory requirements for Windows Server 2008 server testing. The second system should contain one instance of the test adapter connected to any storage device. Do not set up the second system to boot from the test adapter. Also, do not set up the storage device that is connected to the test adapter to contain any part of the page file. The storage adapter procedures require that you connect two identical HBAs. Select the device you are not booting from when you are running the Dynamic Partitioning test by using the Device Console Submission view. If you cannot put two identical HBAs in the system because the device is integrated, add two machines with identical HBAs to the machine pool and run the Dynamic Partitioning test against the machine with a test HBA that you are not booting from. In this machine, you should be booting from an additional non-test controller.
    • For Windows Server 2008 only: You must run tests on basic disks, or disks that have only a single partition. Tests might fail when you run tests on Windows Server 2008 running disks that have dynamic volumes. When the setup documentation says to create dynamic volumes that span multiple disks, instead create one partition of the requested size on each disk.
  • One PCI-X or PCIe-based bus (except for 32-bit PCI-only adapters)
  • One logo-compliant ACPI BIOS, with ACPI enabled by default. To find hardware requirements that are specific to the test adapter technologies, see the appropriate "Preparing Adapter or Controller Testing" page.
  • One boot drive with a minimum of 2.2 TB

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), you cannot test physical devices and their associated drivers being tested for Server Logo or Signature in virtual machines by using any form of virtualization. This requirement exists because not all virtualization products support the underlying functionality that is required to pass the tests that relate to Multiple Processor Groups, Device Power Management, Device PCI functionality, and so on.

Software Requirements

The following software is required to run the adapter or controller tests:

  • One of the following operating systems:
    • Windows 7
    • Windows Vista
    • Windows XP Professional with Service Pack 2 (SP2)
    • Windows Server 2003 with Service Pack 2 (SP2), Enterprise Edition
    • Windows Server 2003 with Service Pack 2 (SP2), Datacenter Edition
    • Windows XP Professional x64 Edition
    • Windows Server 2003, Enterprise x64 Edition
    • Windows Server 2003, Datacenter x64 Edition
    • Windows Server 2003 with SP2, Enterprise Edition for Itanium-based Systems
    • Windows Server 2003 with SP2, Datacenter Edition for Itanium-based Systems
    • Windows Server 2008 R2
  • Any drivers that are not available with the operating system
  • The current release of the Windows Driver Kit (WDK)
  • Windows Symbol files

Note You must use the latest version of the WDK to compile your driver for it to pass testing and obtain a logo.

Tester Knowledge Requirements

To run the adapter or controller tests, testers must know how to accomplish the following tasks:

  • Access and change the system BIOS settings
  • Install the test controller and connect the required storage devices
  • Configure a RAID array (if RAID is supported)
  • Install a PCI-to-PCI bridge (if required)
  • Create and format logical drives
  • Install Windows Symbols files
  • Install the operating system from the product CD

Related Links

Windows Marketplace Tested Products List

Windows Symbol Files


Preparing for Adapter or Controller Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures. These procedures are organized by the technology that you are testing. Please see the documentation that corresponds to the adapter or controller that you are testing.

  • ATA/ATAPI Controller Testing
  • Fibre Channel Adapter Testing
  • iSCSI Boot Component Testing
  • iSCSI HBA Testing
  • SAS Controller Testing
  • SATA Controller Testing
  • SCSI Controller Testing


ATA/ATAPI Controller Testing

Before running the Serial ATA controller tests, you must assemble and configure the test system. This section summarizes the related procedures.

Hardware Requirements

  • One computer that meets the general hardware requirements for all adapter or controller testing.
  • If the ATA/ATAPI controller supports RAID:
    • Two identical ATA/ATAPI RAID controllers (the test devices), unless the test device is an integrated controller.
    • One ATA/ATAPI hard disk drive (40 GB minimum) for each channel that the test device supports. If two controllers are required, twice as many hard disks are required.
    • One optical drive.
    • One PCI-to-PCI bridge adapter, unless:
      • The RAID controllers cannot fit into PCI bridge adapters (such as integrated controllers or controllers that can fit only into specially designed 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).
      • You can put one of the RAID controllers into a PCI bus slot that is already behind a PCI bridge.
  • If the ATA/ATAPI Controller does not support RAID:
    • One ATA/ATAPI controller (the test device)
    • Two UDMA-capable ATA/ATAPI hard disk drives (40 GB minimum)
    • One DMA-capable optical recording drive (8x speed minimum)
    • One blank CD-RW
    • One ATA/ATAPI tape drive
    • One blank tape cartridge
  • One bootable controller and hard disk drive (36 GB minimum) if the test device does not support boot.

Configuration Procedure

There are three possible configurations for testing ATA/ATAPI Controllers:

  • If the test device does not support RAID, use the Non-RAID Controller Configuration procedure.
  • If the test device is an integrated controller that supports RAID, use the Integrated RAID Controller Configuration procedure.
  • If the test device is an add-in controller that supports RAID, use the Add-in RAID Controller Configuration procedure.


Add-in RAID Controller Configuration

This section describes how to assemble and configure an add-in RAID controller for logo testing. These procedures apply to add-in ATA/ATAPI, SCSI, SAS, and SATA controllers that support RAID.

Test System Assembly

  1. Install a boot-capable controller (not the test device) and hard disk drive, if the test devices do not support boot.
  2. Install one test controller (Controller 1).
  3. Install a PCI-to-PCI bridge, unless one of the following items is true:
    • The controllers cannot fit into PCI bridge adapters (such as integrated controllers or controllers that can fit only into specially designed slots).
    • The controller is designed and sold only for systems that cannot accept full height PCI-to-PCI bridge adapters (such as blade servers).
    • You can put one of the controllers into a PCI bus slot that is already behind a PCI bridge.
  4. Install a second, duplicate test controller (Controller 2) into the PCI-to-PCI bridge card (or PCI bridge if the bridge card is not required).

  5. Attach the disks to the test devices according to the following table.
    Controller type | Controller 1 | Controller 2
    ATA RAID | One ATA hard disk drive on each supported channel | One ATA hard disk drive on each supported channel
    SATA RAID | One SATA hard disk drive on each supported channel | One SATA hard disk drive on each supported channel
    SAS RAID | One SAS JBOD or 3 SAS hard disk drives | One SAS JBOD or six SATA hard disk drives that are connected by a fanout expander in between twoedge expanders
    SCSI RAID | One SCSI JBOD | One SCSI JBOD

  6. Attach an optical drive to the system, if one is not already attached.

Test System Configuration

  1. Turn on the test system.
  2. Set the system BIOS to support the S3 state.
  3. Create one 60-GB RAID array on Controller 1 and two 60-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.

  4. 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 | 9 | 0
    0 and 5 only | 5 | 9 | 0
    1 and 5 only | 5 | 1 | 1
    0, 1, and 10 | 10 | 1 | 0
    0, 1, and 5 | 5 | 1 | 0
    0, 1, 10, and 5 | 5 | 10 | 0

  5. Install the appropriate Microsoft Windows operating system to a 36-GB NTFS volume on RAID Array 1. If the test controller is not bootable, install a separate hard disk drive on a bootable controller.
  6. If it is necessary, install any drivers that a manufacturer supplies that the devices in the test system require.
  7. Start the test system in the Windows operating system.
  8. Create three 4-GB partitions on RAID Array 2.
  9. If you are testing with a client operating system, create a 4-GB NTFS spanned volume that uses unallocated space on RAID Array 1, RAID Array 2, and RAID Array 3, as the following diagram shows.

    Diagram of the add-in RAID array configuration for Windows client systems

  10. If you are testing with a server operating system, do the following:
    1. Create a software RAID 1 mirror from one of the NTFS partitions on RAID Array 2 to the unallocated space on RAID Array 1, as the following diagram shows.
    2. Create a 4-GB NTFS software RAID 5 array that uses unallocated space on RAID Array 1, RAID Array 2, and RAID Array 3, as the following diagram shows. Diagram of the add-in RAID array configuration for Windows server systems
  11. To set the system page file and enable crashdump, do the following:
    1. Click the Start button, right-click My Computer, and then click Properties.
    2. Click the General tab, and then note the amount of RAM that the computer contains.
    3. Click the Advanced tab (or click Advanced system settings in the left pane for Windows Vista, Windows 7, or Windows Server 2008), and then, in the Performance area, click Settings.

      Note If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.

    4. Click the Advanced tab, and then, in the Virtual Memory area, click Change.
    5. Select Custom Size, and then enter a number in the Initial size (MB) box that is larger than the size of RAM that you noted in step b.
    6. In the Maximum size (MB) text box, enter a maximum size value that is larger than the initial size that you entered in the Initial size (MB) box. (The maximum size is typically 1.5 to 2 times the initial size.)
    7. Click Set, and then click OK two times.
    8. Click OK, and then restart the computer to update the page file size.
  12. Copy the Windows Symbol files to %SystemDrive%\Symbols.
  13. Install DTM client.


Integrated RAID Controller Configuration

This section describes how to assemble and configure an integrated RAID controller for logo testing. These procedures apply to integrated ATA/ATAPI, SCSI, SAS, and SATA controllers that support RAID.

Test System Assembly

  1. Install a boot-capable controller (not the test device) and hard disk drive, if the test devices do not support boot.

  2. Attach the disks to the integrated test controller (Controller 1) according to the following table.

    Controller type | Controller 1
    ATA RAID | One ATA hard disk drive on each supported channel
    SATA RAID | One SATA hard disk drive on each supported channel
    SAS RAID | One SAS JBOD or six SAS hard disk drives
    SCSI RAID | One SCSI JBOD or three SCSI hard disk drives, and one SCSI optical drive (if supported)

  3. Attach an optical drive to the system, if one is not already attached.

Test System Configuration

  1. Turn on the test system.
  2. Set the system BIOS to support the S3 state.
  3. Create two 60-GB RAID arrays on Controller 1.

    If the controller does not support a configuration that includes two arrays, use a non-RAID disk instead of Array 2 for these procedures. For SCSI, create a third 60-GB RAID array (using any supported RAID level).

    The RAID arrays on Controller 1 are referred to as RAID Array 1 and RAID Array 2.

  4. 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 or Non-RAID disk
    0 and 1 only | 1 | 0
    0 and 5 only | 5 | 0 or Non-RAID disk
    1 and 5 only | 5 | 1or Non-RAID disk
    0, 1, and 10 | 10 | 1 or Non-RAID disk
    0, 1, and 5 | 5 | 0 or Non-RAID disk
    0, 1, 10, and 5 | 5 | 10 or Non-RAID disk

  5. Install the appropriate Microsoft Windows operating system to a 36-GB NTFS volume on RAID Array 1. If the test controller is not bootable, install Windows to a separate hard disk drive on a bootable controller.
  6. If it is necessary, install any drivers that a manufacturer supplies that the devices in the test system require.
  7. Start the test system into the Windows operating system.
  8. Use the Windows Disk Management utility to configure all of the disks to be dynamic.
  9. Create three 4-GB NTFS partitions on RAID Array 1. For SCSI adapters, use RAID Array 2 instead.

  10. If you are testing with a client operating system, create a 4-GB NTFS spanned volume that uses unallocated space on RAID Array 1 and RAID Array 2, as the following diagram shows. For SCSI, this volume should also span Array 3, as the first diagram in the following Appendix section shows.

    Diagram of the integrated RAID array configuration for Windows client systems

  11. If you are testing with a server operating system:
    1. Create a software RAID 1 mirror from one of the NTFS partitions on RAID Array 1 to the unallocated space on RAID Array 2, as the following diagram shows.

    2. Create a NTFS software RAID 0 array that uses unallocated space on RAID Array 1 and RAID Array 2, as the following diagram shows. For SCSI, this volume should be a NTFS RAID 5 array instead that uses unallocated space on RAID Array 1, RAID Array 2, and RAID Array 3, as the second diagram in the following Appendix section shows.

      Diagram of the integrated RAID array configuration for Windows server systems

  12. To set the system page file and enable crashdump, do the following:
    1. Click the Start button, right-click My Computer, and then click Properties.
    2. Click the General tab, and then note the amount of RAM that the computer has.
    3. Click the Advanced tab (or click Advanced system settings in the left pane for Windows Vista, Windows 7, or Windows Server 2008), and then, in the Performance area, click Settings.

      Note If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.

    4. Click the Advanced tab, and then, in the Virtual Memory area, click Change.
    5. Select Custom Size, and then enter a number in the Initial size (MB) box that is larger than the size of RAM that you noted in step b.
    6. In the Maximum size (MB) text box, enter a maximum size value that is larger than the initial size that you entered in the Initial size (MB) box. (The maximum size is typically 1.5 to 2 times the initial size.)
    7. Click Set, and then click OK two times.
    8. Click OK, and then restart the computer to update the page file size.
  13. Copy the Windows Symbol files to %SystemDrive%\Symbols.
  14. Install DTM client.

Appendix

Diagram of the SCSI RAID client configuration

Diagram of the SCSI RAID server configuration


Non-RAID Controller Configuration

This section describes how to assemble and configure a non-RAID controller for logo testing. These procedures apply to ATA/ATAPI, SCSI, SAS, and SATA controllers that do not support RAID.

Test System Assembly

  1. Install a boot-capable controller (not the test device) and hard disk drive if the test devices do not support boot.
  2. Install the test device (Controller 1).
  3. For add-in SAS or SCSI controllers, install a PCI-to-PCI bridge, unless you meet the following requirements:
    • The controllers cannot fit into PCI bridge adapters (such as integrated controllers or controllers that can only fit into specially designed slots).
    • The controller is designed and only sold for systems that cannot accept full height PCI-to-PCI bridge adapters (such as blade servers).
    • You can put one of the controllers into a PCI bus slot that is already behind a PCI bridge.
  4. For add-in SAS or SCSI controllers, install a second, duplicate test controller (Controller 2) into the PCI-to-PCI bridge card (or PCI bridge if the bridge card is not required).

  5. Attach the disks to the test devices according to the following table.

    Controller type Controller 1 Controller 2
    ATA/ATAPI controllers

    Primary Master: UDMA HDD (Disk 1)

    Primary Subordinate: Optical recorder

    Secondary Master: UDMA HDD (Disk 2)

    Secondary Subordinate: ATA/ATAPI tape drive

             N/A

    SCSI add-in controllers

    Note Please see the first diagram in the following Appendix section.

    SCSI HDD (Disk 1)

    SCSI optical drive

    SCSI tape drive

    SCSI removable media drive

    SCSI HDD (Disk 2)

    SCSI optical drive

    SCSI integrated controllers

    Note Please see second diagram in the following Appendix section.

    SCSI HDD (Disk 1)

    SCSI optical drive

    SCSI tape drive

    SCSI removable media drive

    SCSI HDD (Disk 2)

            N/A

    SAS add-in controllers

    Note Please see the third diagram in the following Appendix section.

    SAS HDD (Disk 1)

    Edge expander, then Fanout expander, then Edge expander, then SATA HDD (Disk 2)

    SAS integrated controllers

    Note Please see the fourth diagram in the following Appendix section.

    SAS HDD (Disk 1), and Fanout expander, then Edge expander, then SATA HDD (Disk 2)

            N/A
    SATA controllers

    2 SATA HDDs (Disk 1 and 2)

    Optical drive

             N/A

  6. Attach an optical drive to the system, if one is not already attached.

Test System Configuration

  1. Turn on the test system.
  2. Set the system BIOS to support the S3 state.
  3. Install the appropriate Microsoft Windows operating system onto disk 1. Use a newly created NTFS partition with at least 36 GB of disk space.
  4. If it is necessary, install any drivers that a manufacturer supplies that the devices in the test system require.
  5. Create three 4-GB partitions on Disk 2.
  6. Use the following procedure to set the system page file and enable crashdump:
    1. Click the Start button, right-click My Computer, and then click Properties.
    2. Click the General tab, and then note the amount of RAM that the computer has.
    3. Click the Advanced tab (or click Advanced system settings in the left pane for Windows Vista, Windows 7, or Windows Server 2008), and then, in the Performance area, click Settings.

      Note If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.

    4. Click the Advanced tab, and then, in the Virtual Memory area, click Change.
    5. Select Custom Size, and then enter a number in the Initial size (MB) box that is larger than the size of RAM that you noted in step b.
    6. In the Maximum size (MB) text box, enter a maximum size value that is larger than the initial size that you entered in the Initial size (MB) box. (The maximum size is typically 1.5 to 2 times the initial size.)
    7. Click Set, and then click OK two times.
    8. Click OK, and then restart the computer to update the page file size.
  7. Copy the Windows Symbol files to %SystemDrive%\Symbols.
  8. Install DTM client.

Appendix

SCSI add-in controllers

Diagram of an add-in SCSI assembly

SCSI integrated controllers

Diagram of an integrated SCSI assembly

SAS add-in controllers

Diagram of an add-in SAS assembly

SAS integrated controllers

Diagram of an integrated SAS assembly


Fibre Channel Adapter Testing

Before running the Fibre Channel adapter tests, you must configure the computer and install the operating system. This section tells you how to complete these steps.

Hardware Requirements

  • One computer that meets the general hardware requirements for all adapter or controller testing.
  • One Fibre Channel RAID storage subsystem that can support any one of the following: RAID-0, RAID-1, RAID-5, RAID-10, or RAID-6.

    Warning Do not test with a storage subsystem that connects via MPIO.

  • If the Fibre Channel adapter is not bootable, one ATA or SCSI controller.
  • If the Fibre Channel adapter is not bootable, one ATA or SCSI disk drive. The disk must have at least 18 GB of space.
  • One bootable floppy disk drive.
  • One floppy disk.
  • Two identical PCI-X or PCIe-based Fibre Channel adapters (the test devices).
  • Two (or three, if testing RAID-5) Fibre Channel hard disk drives or Fibre Channel JBOD.
  • One PCI-to-PCI bridge adapter.
  • One PCI-to-PCI bridge adapter unless you meet the following:
    • The controllers cannot fit into PCI bridge adapters (such as integrated controllers or controllers that can fit only into specially designed slots).
    • The controller is designed and sold only for systems that cannot accept full height PCI-to-PCI bridge adapters (such as blade servers).
    • You can put one of the controllers into a PCI bus slot that is already behind a PCI bridge.

Test System Assembly

  1. Turn off the test system.
  2. Install one CD 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 either of the following situations apply, connect two (or three for RAID-5 testing) Fibre Channel hard disk drives, or a Fibre Channel JBOD, to the test device and then skip to step 8:
    • The Fibre Channel adapter test device is an integrated controller, there is only one of these controllers in the system, and an equivalent PCI adapter version of the device does not exist.
    • The Fibre Channel adapter is designed for and sold only in a host test system that accepts only a single version of the controller.
  6. Install a PCI-to-PCI bridge in a PCI slot in the test system.

    Note You can also use an existing slot behind a bridge.

  7. Install a secondary, identical Fibre Channel adapter (Test Device 2) into the PCI-to-PCI bridge card.
  8. Connect two (or three for RAID-5 testing) Fibre Channel hard disk drives or a Fibre Channel JBOD to Test Device 2.
  9. Turn on the test system.
  10. Configure the JBOD or disks as Array 2, according to the following list:

    • If the test device supports only one RAID level, configure the JBOD or disks by using that level. Otherwise, configure the JBOD or disks to the RAID levels that are specified in the following table.

      If the device supports RAID level | Use RAID level
      0 and 1 | 1
      0 and 5 | 5
      1 and 5 | Either 1 or 5
      0, 1, and 5 | Either 1 or 5

    • Array 2 should contain at least 60 GB of space.
  11. Configure the RAID system as Array 1 according to the following list:
    • If the RAID system supports only one RAID level, configure it by using that level. Otherwise, configure the RAID system according to the preceding table.
    • Array 2 should contain at least 60 GB of space.

Test System Configuration

  1. If the test Fibre Channel adapter is not bootable, install an ATA or SCSI hard disk drive and an alternate ATA or SCSI boot controller if they are not present.
  2. Turn on the machine.
  3. Install any HBA or RAID system drivers that are necessary to connect to or manage the peripheral devices.
  4. Do one of the following to install the operating system:
    • If the test Fibre Channel adapter is bootable, install the operating system onto a NTFS, 364-GB partition on the RAID system.
    • Install the operating system onto a NTFS-formatted, 36-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
  5. Start the test system in the Microsoft Windows operating system.
  6. Use the Windows Disk Management utility to set up three 4 GB NTFS partitions on Array 1. For more information, see the first diagram in the Add-in RAID Controller Configuration topic.
  7. Use the Windows Disk Management utility to mirror one of the volumes created in step 6 to Array 2. For more information, see the first diagiram in the Add-in RAID Controller Configuration topic.
  8. Use the following procedure to set the system page file and enable crashdump:
    1. Click the Start button, right-click My Computer, and then click Properties.
    2. Click the General tab, and then note the amount of RAM that the computer has.
    3. Click the Advanced tab (or click Advanced system settings in the left pane for Windows Vista, Windows 7, or Windows Server 2008), and then, in the Performance area, click Settings.

      Note If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.

    4. Click the Advanced tab, and then, in the Virtual Memory area, click Change.
    5. Select Custom Size, and then enter a number in the Initial size (MB) box that is larger than the size of RAM that you noted in step b.
    6. In the Maximum size (MB) text box, enter a maximum size value that is larger than the initial size that you entered in the Initial size (MB) box. (The maximum size is typically 1.5 to 2 times the initial size.)
    7. Click Set, and then click OK two times.
    8. Click OK, and then restart the computer to update the page file size.
  9. Copy the Windows Symbol files to %SystemDrive%\Symbols.
  10. Install DTM client.


Fibre Channel Over Ethernet Testing

Before running the Fibre Channel over Ethernet (FCoE) adapter tests, you must first configure the computer and install the operating system. This section tells you how to complete these steps.

Hardware Requirements

  • Two identical PCI-X or PCIe-based dual-port FCoE adapters (the test devices). Four identical FCoE adapters are needed if the adapter is single-ported.
  • Two computers that meet the general hardware requirements for all adapter or controller testing.
  • One FCF (FCoE switch) that supports 10G/E bandwidth for FCoE traffic; FCF is installed with four available FCoE ports/SFP+, and one FC port/SFP+.
  • Copper- or fibre-based FCoE cable and FC cable for the above ports.
  • One Fibre Channel storage array system that can support any one of the following: RAID-0, RAID-1, RAID-5, RAID-10, or RAID-6.
  • If the FCoE adapter is not bootable, one on-board SATA or SAS controller.
  • If the FCoE adapter is not bootable, one SATA or SAS disk drive for OS installation.

Test System Assembly

  1. Turn off the test system.
  2. If the FCoE adapter is not bootable, configure an alternate SATA or SAS on-board boot controller, and then install a respective SATA or SAS hard disk drive if they are not present.
  3. Install one FCoE adapter in the first test system. (Install two FCoE adapters in the first machine if single-ported.)
  4. Connect all ports of the FCoE adapter(s) to the FCF.
  5. Repeat steps 2-4 for the second FCoE adapter in the second test system. (Install two FCoE adapters in the second machine if single-ported.)
  6. Connect the FCF to the storage array.

  7. Create LUN and configure LUN mapping on the storage array system. The array should contain at least 120 GB of disk space for SAN boot configuration. The LUN mapping is only needed for the first test system. Complete this step according to the storage array vendor instructions.
  8. Configure the ports and zoning on the FCF. Complete this step according to the switch vendor instructions.
  9. Turn on the test systems.

Test System Configuration

  1. Install any HBA or RAID system drivers that are necessary to connect to or manage the peripheral devices.
  2. Do one of the following to install the operating system:
    • If the test FCoE adapter is bootable, install the operating system onto a NTFS, 120 GB partition on the RAID system.
    • Install the operating system onto a NTFS-formatted 120 GB partition on the SATA or SAS hard disk drive that is connected to the alternate SATA or SAS boot controller in the test system.
  3. Start the test system in the Microsoft Windows operating system.
  4. Configure MPIO for the first test system only:
    1. Install Windows MPIO feature through Server Manager.
    2. Reboot the system.
    3. Use mpclaim.exe command line utility or edit the MPIO CPL (Control Panel) GUI interface to add the LUN ID to be claimed.
    4. Restart the system.
  5. Use the following procedure to set the system page file and enable crashdump:
    1. Click the Start button, right-click My Computer, and then click Properties.
    2. Click the General tab, and then note the amount of RAM that the computer contains.
    3. Click the Advanced tab (or click Advanced system settings in the left pane for Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2), and then, in the Performance area, click Settings.

      Note If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.

    4. Click the Advanced tab, and then, in the Virtual Memory area, click Change.
    5. Select Custom Size, and then enter a number in the Initial size (MB) box that is larger than the size of RAM that you noted in step b.
    6. In the Maximum size (MB) text box, enter a maximum size value that is larger than the initial size that you entered in the Initial size (MB) box. (The maximum size is typically 1.5 to 2 times the initial size.)
    7. Click Set, and then click OK two times.
    8. Click OK, and then restart the computer to update the page file size.
  6. Copy the Windows Symbol files to %SystemDrive%\Symbols.
  7. Install DTM client.


iSCSI Boot Component Testing

The iSCSI boot component logo program verifies if a system supports using an iSCSI target as the boot disk. The iSCSI boot component can be part of the system BIOS, iSCSI HBA, network card with Extended BIOS, or network card with a preboot execution environment (PXE) and iSCSI boot loader program to start the computer.

The iSCSI boot BIOS or loader program uses the Phoenix Int 13h BIOS interrupt call to allow the operating system to start as if there were a locally attached disk. Disk read and write operations through Phoenix Int 13h extensions are redirected through iSCSI to the remote disk. The iSCSI boot BIOS or loader program creates the iSCSI Boot Firmware table (iBFT) that contains the information that is needed for the Microsoft Windows operating system to continue loading after the operating system loader has completed and the Windows kernel has started.

Note Run Storage Adapter or Controller and LAN (Ethernet) test submissions for Windows Server 2008 on systems with at least four processor cores and 6 GB of memory. These requirements are in addition to the requirements that are related to the Dynamic Partitioning (DP) Simulator and Test that all Windows Server 2008 device driver submissions must meet.

The iSCSI boot component includes the following:
  • Pre-boot initiation code
  • An implementation of iBFT in firmware or BIOS
  • Crashdump support in new or existing drivers
Microsoft provides the following iSCSI boot components:

  • Microsoft iSCSI Software Initiator 2.02Boot +
  • A kernel-mode driver to read iBFT in firmware or BIOS (see Microsoft-iSCSI-Boot-Firmware-Table-Spec-v1.0.doc) or BIOS

Hardware Requirements

  • One computer that meets the general hardware requirements for all adapter or controller testing
  • Hardware and software that contain the iSCSI boot component in the server option ROM, NIC option ROM, firmware, or PXE implementation
  • Two 1-GB network adapters

Test System Assembly

  1. Install the test device that supports iSCSI boot.
  2. Set up an iSCSI environment and record the IP addresses and target names of the devices.

Test System Configuration

  1. Install the appropriate Windows operating system.
  2. If it is necessary, install any drivers that a manufacturer supplies that the devices in the test system require.
  3. Start the test system into the Windows operating system.
  4. Install DTM client.


iSCSI HBA Testing

Before running the iSCSI HBA tests, you must configure the computer and install the operating system. This section tells you how to complete these steps.

Hardware Requirements

You can run the iSCSI HBA tests in a single configuration. However, you can implement this configuration in one of two ways:

  • An iSCSI HBA, iSCSI disk storage system, and iSCSI tape medium changer
  • An iSCSI HBA, a bridge to another bus, a disk storage system, and tape medium changer

The following hardware is required for iSCSI HBA testing:

  • One computer that meets the general hardware requirements for all adapter or controller testing.
  • An iSCSI HBA (the test device).
  • One combination tape drive and medium changer device. If you are testing without a bridge, this device must be an iSCSI device. If you are testing with a bridge, this device must be a device that connects through another bus.

  • Two disk storage systems. If you are testing without a bridge, these systems must be iSCSI disk storage systems. If you are testing with a bridge, these systems must be disk storage systems that connect through another bus.

    Note If the test device supports boot, you need two disk targets. These targets can exist on the same disk storage device, if 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 medium changer device.
  • A monitor, keyboard, and mouse.
  • A boot-capable floppy disk drive, if your device supports boot.
  • Two 1-GB network adapters.

Test System Assembly

  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. Do one of the following:
    • If you are using an iSCSI bridge, connect the disk storage system, combination tape, and medium changer to the bridge.
    • If you are not using an iSCSI bridge, connect the disk storage system, and combination tape, and medium changer to the network.

The following diagram shows the test system configuration without a bridge.

Diagram of a iSCSI controller configuration without a bridge

The following diagram shows the test system configuration with a bridge.

Diagram of a iSCSI controller configuration with a bridge

Test System Configuration

  1. Turn on the test system.
  2. Install the Microsoft Windows operating system on one hard disk drive.

    If the iSCSI HBA supports boot, install the operating system on an iSCSI disk target that is different from the one that you will use for testing.

  3. If it is necessary, install any manufacturer-supplied drivers that the devices in the test system require.
  4. Install the latest version of the iSCSI software initiator by searching for "iSCSI software initiator" in the Microsoft Download Center.

  5. Use the iSCSI Control Panel to log on all target devices. When you log on the targets, select the Automatically restore this connection when the system boots check box.

    Important You must log on all iSCSI target devices that you use for testing. You must not log on any other iSCSI target devices. Otherwise, the WLK tests do not work properly.

  6. Use Disk Management to create three 4-GB NTFS volumes on the disk storage system that does not contain the operating system. Assign each volume a drive letter.
  7. Use the iSCSI Control Panel to bind all of the drive letters that are created in step 6.
  8. Use the following procedure to set the system page file and enable crashdump:
    1. Click the Start button, right-click My Computer, and then click Properties.
    2. Click the General tab, and then note the amount of RAM that the computer has.
    3. Click the Advanced tab (or click Advanced system settings in the left pane for Windows Vista, Windows 7, or Windows Server 2008), and then, in the Performance area, click Settings.

      Note If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.

    4. Click the Advanced tab, and then, in the Virtual Memory area, click Change.
    5. Select Custom Size, and then enter a number in the Initial size (MB) box that is larger than the size of RAM that you noted in step b.
    6. In the Maximum size (MB) text box, enter a maximum size value that is larger than the initial size that you entered in the Initial size (MB) box. (The maximum size is typically 1.5 to 2 times the initial size.)
    7. Click Set, and then click OK two times.
    8. Click OK, and then restart the computer to update the page file size.
  9. Copy the Windows Symbol files to %SystemDrive%\Symbols.
  10. Install DTM client.

When you schedule any iSCSI HBA tests, set up the communication between the HBA (Initiator) and the iSCSI targets. For more information, see the "Scheduling Tests" section of Running the Adapter or Controller Tests.


SAS Controller Testing

Before running the SAS controller tests, you must assemble and configure the test system. This section shows you how to complete these steps.

Hardware Requirements

  • One computer that meets the general hardware requirements for all adapter or controller testing.
  • Two identical SAS controllers (the test devices), unless the test device is an integrated controller.
  • One PCI-to-PCI bridge, unless you meet the following:
    • The RAID controllers cannot fit into PCI bridge adapters (such as integrated controllers or controllers that can fit only into specially designed 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).
    • You can put one of the RAID controllers into a PCI bus slot that is already behind a PCI bridge.
  • If the test device is an add-in SAS RAID controller, one of the following items:
    • Two SAS JBODs (that include at least 3 hard disk drives for one and 6 hard drives for the other)
    • One SAS JBOD (that include at least 6 hard disk drives) and three SAS hard disk drives
    • One SAS JBOD (that include at least 3 hard disk drives) and six SATA hard disk drives
    • Three SAS hard disk drives and six SATA hard disk drives
  • If the test device is an integrated SAS RAID controller, one of the following items:
    • One SAS JBOD (6 hard drive minimum)
    • Six SAS hard disk drives
  • If the SCSI controller does not support RAID, all of the following items:
    • One SAS hard disk drive (40 GB minimum)
    • One SATA hard disk drive (40 GB minimum)
    • Two SAS edge expanders
    • One SAS fanout expander
  • One bootable controller and hard disk drive (36 GB minimum) if the test device does not support boot.

Assembly and Configuration Procedures

There are three possible configurations for testing SAS controllers:

  • If the test device does not support RAID, use the Non-RAID Controller Configuration procedure.
  • If the test device is an integrated controller that supports RAID, use the Integrated RAID Controller Configuration procedure.
  • If the test device is an add-in controller that supports RAID, use the Add-in RAID Controller Configuration procedure.


SATA Controller Testing

Before running the Serial ATA controller tests, you must assemble and configure the test system. This section show you how to complete these steps.

Hardware Requirements

  • One computer that meets the general hardware requirements for all adapter or controller testing.
  • One optical drive.
  • If the SATA controller supports RAID:
    • Two identical SATA RAID controllers (the test devices), unless the test device is an integrated controller.
    • One SATA hard disk drive (40 GB minimum) for each channel that the test device supports. If two controllers are required, twice as many hard disk drives are required.
    • One PCI-to-PCI bridge adapter, unless you meet the following:
      • The RAID controllers cannot fit into PCI bridge adapters (such as integrated controllers or controllers that can fit only into specially designed 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).
      • You can put one of the RAID controllers into a PCI bus slot that is already behind a PCI bridge.
  • If the SATA controller does not support RAID:
    • One SATA controller (the test device)
    • Two SATA hard disk drives (40 GB minimum)
  • One bootable controller and hard disk drive (36 GB minimum) if the test device does not support boot.

Configuration Procedure

There are three possible configurations for testing SATA controllers:

  • If the test device does not support RAID, use the Non-RAID Controller Configuration procedure.
  • If the test device is an integrated controller that supports RAID, use the Integrated RAID Controller Configuration procedure.
  • If the test device is an add-in controller that supports RAID, use the Add-in RAID Controller Configuration procedure.


SCSI Controller Testing

Before running the SCSI controller tests, you must assemble and configure the test system. This section show you how to complete these steps.

Hardware Requirements

  • One computer that meets the general hardware requirements for all adapter or controller testing.
  • Two identical SCSI controllers (the test devices), unless the test device is an integrated controller.
  • One PCI-to-PCI bridge, unless you meet the following:
    • The RAID controllers cannot fit into PCI bridge adapters (such as integrated controllers or controllers that can fit only into specially designed 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).
    • You can put one of the RAID controllers into a PCI bus slot that is already behind a PCI bridge.
  • If the SCSI controller supports RAID:
    • One SCSI JBOD
    • One additional SCSI JBOD or three SCSI hard disk drives, unless the test device is an integrated controller
    • One optical drive
  • If the SCSI controller does not support RAID:
    • Three identical SCSI hard disk drives (40 GB minimum) with Wide SCSI support, if the test device supports it
    • Two SCSI CD drives (at least 8x speed)
    • One SCSI removable media drive
    • One SCSI tape drive with Wide SCSI support, if the test device supports it
    • One blank tape cartridge
  • One bootable controller and hard disk drive (36 GB minimum), if the test device does not support boot.

Assembly and Configuration Procedures

There are three possible configurations for testing SCSI controllers:

  • If the test device does not support RAID, use the Non-RAID Controller Configuration procedure.
  • If the test device is an integrated controller that supports RAID, use the Integrated RAID Controller Configuration procedure.
  • If the test device is an add-in controller that supports RAID, use the Add-in RAID Controller Configuration procedure.


Running the Adapter or Controller Tests

After you prepare a test machine for adapter or controller testing, you can run the logo tests from the DTM Studio.

For more information, see Running the Logo Tests.

Submission Configuration

  1. Add the machine to a machine pool.

    Note For more information, see Grouping Client Computers into Machine Pools.

  2. Click Explorers, and then click Device Console.
  3. In the Create New Submission dialog box, select the operating system, and then click Next.
  4. Type a name for your submission, select the machine pool that you created earlier, and then click Next.
  5. Select Storage > Adapter or Controller when you are prompted for the logo program, and then click Next.
  6. If you are testing a driver, browse to the driver, and then load that driver when you are prompted. Otherwise, select the I am not providing an INF or Driver Package check box, and then click Next.

  7. If you selected the I am not providing an INF or driver package check box, select your test device from the list when you are prompted, and then click Next.

    The Create New Submission dialog box appears.

    Screen shot of the Create New Submission dialog box

  8. From the Bus type connecting adapter to storage list, select the appropriate bus type for your adapter, and then select the check boxes for any additional features that your adapter implements. For more information about features, see the following "Submission Features" section.

    Note For SATA Controllers in PATA emulation mode, select ATA as the bus type.

  9. Click Next, and then click Finish to complete the submission configuration.

Many of the tests in the Microsoft Windows Driver Kit (WDK) require that a test system restart (often more than once) to complete a test run. To enable this restart, DTM configures the client to automatically log on by using the DTMLLUAdminUser account. This configuration occurs when you first create your submission. DTM also turns off workstation locking and prevents the machine from automatically hibernating or sleeping. If you want to open a remote desktop connection to the client after you start a submission, use the DTMLLUAdminUser account.

Submission Features

  • Implements Non-Volatile cache: NV Cache is a storage controller caching feature. Select this feature if your device responds to NV Cache Management operations. For more information, see IOCTL_SCSI_MINIPORT_NVCACHE in the MSDN Library.
  • Implements RAID: Redundant Array of Inexpensive Disks (RAID) is a feature that enables you to combine multiple drives into arrays for increased reliability (redundancy) or performance (striping). Select this feature if your adapter supports any of the common RAID levels (0, 1, 5, 10).
  • Implements VDS Provider: Virtual Disk Service (VDS) is a service that unifies and extends existing storage capabilities under a single API as an end-to-end solution for managed storage hardware and disks. Select this feature if your adapter implements the VDS API as a hardware provider. For more information, see About VDS in the MSDN Library.

Scheduling Tests

When a yellow exclamation mark (!) appears next to a job in the DTM, the DTM requires more information. You must enter that information in a dialog box when you schedule the job by right-clicking the job and clicking Add Information.

  • All iSCSI tests require that you configure communication between the HBA (initiator) and the iSCSI targets.

    Screen shot of the iSCSI HBA Configuration tab

  • The Separated Cache Solution Evaluation Test requires that you direct the logo test to the results file that was created during a manual test execution.
  • The Disk Verification test is a 72-hour test. We recommend that you run this test last or over the weekend, so that you can collect and analyze the results from other tests without waiting for the whole test pass to finish.
  • The Optical Media Burning Test and Disk Stress test write to any optical recording drives on the test controller. If writable media is not present, these tests wait and notify you that you need writable media. Therefore, it requires manual intervention to continue testing. To enable a smooth automated experience, make sure that you have re-writable media in the drive before you run these tests.
  • The Boot Test, Optical Media Burning Test, and iSCSI Ping Test (HBA) require user intervention, so you must run them individually. We recommended that you run the other tests in a group because they are automated.


Troubleshooting Adapter or Controller Testing

For more information about how to troubleshoot adapter or controller tests, see Troubleshooting Storage Tests or the troubleshooting section of a specific storage test.


Optical Disk Drive Testing

Note You must use the latest version of the WDK to compile your driver for it to pass testing and obtain a logo.

The procedures in this section describe how to test your optical disk drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure the full functionality of the device, 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:

Preparing: The preparing topics describe how to configure the system or systems for logo testing.
Running: The running topics describe how to run the tests for your device or system.
Troubleshooting: The troubleshooting section provides information to diagnose optical disk drive failures, warnings, and errors.

Optical Disk Drive Tests

The following table contains all of the tests that might be required for the test device.

 | ATA / ATAPI | IEEE 1394 | PCCard | SATA | SCSI | USB
Device Fundamental Tests | X | X | X | X | X | X
Disk Stress | X | X | X | X | X | X
Media Lock Test | X | X | X | X | X | X
MMC | X | X | X | X | X | X
Optical Logo Test | X | X | X | X | X | X
UDF Formatter | X | X | X | X | X | X
WLK Aggressive Optical Drive Test | X | X | X | X | X | X
WLK CSS Negotiation Region Check Test | X | X | X | X | X | X
WLK DVD Spindown Test | X | X | X | X | X | X
WLK Optical Drive Streaming Mode Test | X | X | X | X | X | X
CardBus Card Configuration Space Register |  |  | X |  |  |
CardBus Card Common Silicon Guidelines |  |  | X |  |  |
CardBus Bridge Power Management Register |  |  | X |  |  |
USB HIDView |  |  |  |  |  | X

Run Time

Approximately 24 hours. This time depends heavily on the amount of profiles that the drive supports because the tests are run for each profile.

Hardware Requirements

The following hardware is required for optical disk drive testing. Additional hardware might be required if the test device provides bus-specific support. To determine whether there are additional hardware requirements, see the test description for each bus-specific test.

  • One computer that has the following items:
    • Dual-core or equivalent processor (Windows Vista / Windows XP)
    • Quad-core or equivalent processor (Windows Server 2008 / Windows Server 2003)
    • 4 GB memory (Windows Vista / Windows XP)
    • 6 GB memory (Windows Server 2008 / Windows Server 2003)
    • One logo-compliant ACPI BIOS, with ACPI enabled by default
    • For Windows Vista and later operating systems, BIOS configuration and SATA controller support of SATA AHCI mode
    • One dual-channel ATA/ATAPI controller that is implemented on the motherboard
    • One host controller of the same bus type as the optical disk drive

      Note The USB controller must be able to wake the system by using ACPI mechanisms.

    • One DMA-capable hard disk drive with at least 10 GB capacity
    • Network adapter
    • One monitor, one keyboard, and one mouse
    • Two identical optical disk drives

      Note If the optical disk drive that you are testing is read-only, you must connect a writer drive in addition to the two drives that you test.

    • Appropriate cables for connecting devices
    • Appropriate host controllers for the optical and hard disk drives
  • Blank media that the test device supports

Note

Testing a device to obtain a logo for Server Device qualification requires that the test system supports four processors and at least 1 GB of RAM. These system capabilities are required for the Dynamic Partitioning (DP) Simulator and Test and the Multiple Processor Group test to run. You do not need a system that actually supports DP capabilities or has more than 64 processors to test your device.

If you use a pool of systems to test devices, at least one system in the pool must contain four processors and at least 1 GB of RAM. Additionally, that system must contain the device and driver under test. The schedule runs on all systems in the pool, as long as the driver is the same on all systems.

For those tests that do not include a driver to test, the DTM scheduler constrains the DP test to run on the default system. You must manually configure this system to have multiple processor groups. The default system is the first system that is listed. In this case, you should make sure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), you cannot test physical devices and their associated drivers being tested for Server Logo or Signature in virtual machines by using any form of virtualization. This requirement exists because not all virtualization products support the underlying functionality that is required to pass the tests that relate to Multiple Processor Groups, Device Power Management, Device PCI functionality, and so on.

Software Requirements

The following software is required to run the optical disk drive tests:

  • One of the following operating systems:
    • Windows XP Professional with Service Pack 2 (SP2)
    • Windows XP Professional x64 Edition
    • Windows Server 2003 with Service Pack 1 (SP1), Enterprise Edition
    • Windows Server 2003 with Service Pack 1 (SP1), Datacenter Edition
    • Windows Server 2003, Enterprise x64 Edition
    • Windows Server 2003, Datacenter x64 Edition
    • Windows Server 2003 with SP1, Enterprise Edition for Itanium-based Systems
    • Windows Server 2003 with SP1, Datacenter Edition for Itanium-based Systems
    • Windows Vista
    • Windows Server 2008
    • Windows Server 2008 R2
    • Windows 7
  • Any drivers that are not available with the operating system
  • The current release of the WLK

Tester Knowledge Requirements

To run the optical disk drive tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive.
  • Format and partition a hard disk drive.
  • Install an optical drive.
  • Access and change the system BIOS settings.
  • Install the operating system.
  • Read and interpret test logs.
  • Submit logo test results by using the online submissions site.


Preparing for Optical 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 Optical Disk Drive Testing.

Many of the tests in the Microsoft Windows Logo Kit (WLK) require that the test system restarts (often more than once) to complete a test run. To enable this restart, DTM configures the client to automatically log on by using the DMLLUAdminUser account. This configuration occurs when you first create your submission. DTM also turns off workstation locking and prevents the machine from automatically hibernating or sleeping. If you want to open a remote desktop connection to the client after you start a submission, use the DTMLLUAdminUser account.

Test System Assembly

  1. Turn off the test system and disconnect it from the power supply.

  2. Install a hard disk drive.

    Note

    For ATA/ATAPI, install the hard disk drive as stand-alone device 0 on the primary ATA/ATAPI channel.

    For SCSI, set the SCSI ID on the SCSI hard disk drive to 0.

  3. If the host controller is not embedded on the system motherboard, install the host controller.

  4. Install the test devices into the test system by attaching it to the host controller.

    Note

    For ATA/ATAPI, install the test device as Device 1 or Cable Select Device 1 on the primary ATA/ATAPI channel. Or install the test device as Device 0, Device 1, Cable Select Device 0, or Cable Select Device 1 on the secondary ATA/ATAPI channel.

    For SCSI, set the SCSI ID on the test device to 6.

    For USB, do not connect the test device to the downstream port of the high-speed USB 2.0 hub directly to the root hub of the USB 2.0 controller.

Test System Configuration

  1. Turn on the test system.
  2. Set the system BIOS to support the S3 state.
  3. Install the appropriate Microsoft Windows operating system on the hard disk drive in the test system.
  4. If it is necessary, install any drivers that the manufacturer supplies that the devices in the test system require.
  5. Install DTM client.
  6. Configure the machine for testing in DTM Studio.
  7. Add the test machine to a machine pool.

    Note For more information, see Grouping Client Computers into Machine Pools.

Note All adapters are operated with BIOS enabled and external termination unless otherwise noted.


Running the Optical Disk Drive Tests

After you prepare the test machine for optical disk drive testing, you can run the logo tests from the DTM Studio. For more information, see Running the Logo Tests.

Submission Configuration

  1. Open Device Console in DTM Studio.
  2. Create a submission for the optical disk drive.

    Note For more information, see Generic Logo Submission exercise.

    1. Under Select OS, choose the operating system and architecture for the logo submission.
    2. Under Select Category, choose the device submission for all optical devices.
    3. Under Logo Type, select Storage > Optical Disk Drive (ODD).
    4. Under Qualification Level, choose the appropriate level.
    5. Name the submission.
    6. Select the appropriate machine pool.

Submission Features

  1. The test device should not require a driver. When you are prompted, select I am not providing an INF or driver package, as the following screen shot shows.

    Screen shot of the Create New Submission dialog box with the I am not providing an INF or Driver Package check box
  2. Select the Optical Drive test from the device list.

  3. Select the injection and ejection options, as the following screen shot shows.

    Screen shot of the Create New Submission dialog box with injection and ejection options

Scheduling Tests

To schedule the tests, select the tests that you want to start, click Add Selected, and then click Schedule.

You can run the tests in any order, but check the run time of the individual tests and the amount of user interaction that is required before you schedule the tests.


Troubleshooting Optical Disk Drive Testing

The following list describes some common issues with optical disk drive tests:

  • Some controllers that use SATA AHCI mode mightcause the CDBs to time out. This time out occurs most frequently in the Start Stop Unit test where the CDB after test unit ready times out without any sense code being returned. Try a different controller or configuration to resolve the issue.
  • Some drives intermittently cannot erase data from a disk. This issue might be caused by rewritable media that has been used too many times. Try to use a new rewritable media.

For more information about how to troubleshoot optical disk drive tests, see Troubleshooting Storage Tests or the troubleshooting section of a specific test in Storage Tests.


Hard Disk Drive (HDD) Testing

Note You must use the latest version of the WLK to compile your driver for it to pass testing and obtain a logo.

The procedures in this section describe how to test a hard disk drive for correct functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure the full functionality of the device, you must run all of the tests that 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:

Preparing: The preparing topics describe how to configure the system or systems for Windows logo testing.
Running: The running topics describe how to run the tests for your device or system.
Troubleshooting: The troubleshooting section provides information to help you diagnose failures, warnings, and errors that occur with the test.

Hard Disk Drive (HDD) Tests

The tests that you must run depend on the capabilities of the device or system that you are testing. The following table contains all of the tests that might be required for your test device.

 | PATA | Fibre Channel | IEEE 1394 | PC CARD | SAS | SATA | SCSI | USB
Disk Verification | X | X | X | X | X | X | X | X
SMART test utility | X |  |  |  |  |  |  |
Disk Stress | X | X | X | X | X | X | X | X
Syscache Test | X | X | X | X | X | X | X | X
System - Sleep Stress with IO | X |  |  |  |  |  |  |
System - Common Scenario Stress with IO |  | X | X | X |  |  |  |
Run INFTest against a single INF | X | X | X | X | X | X | X | X
Hybrid Hard Disk Drive Logo Test | X |  |  |  |  |  |  |
SCSI Compliance test |  | X |  |  | X |  | X |
SCSI Compliance Test 2.0 (LOGO) |  | X |  |  | X |  | X | X
Device Fundamental Tests | X | X | X | X | X | X | X | X
1394 Configuration ROM Test |  |  | X |  |  |  |  |
CardBus Card Configuration Space Register test |  |  |  | X |  |  |  |
CardBus Card Common Silicon Guidelines test |  |  |  | X |  |  |  |
CardBus Bridge Power Management Register Test |  |  |  | X |  |  |  |
SATA IO Sig Test |  |  |  |  |  | X |  |
USB Address Description Test |  |  |  |  |  |  |  | X
USB Descriptor Test |  |  |  |  |  |  |  | X
USB Device Control Requests Test |  |  |  |  |  |  |  | X
USB Device Framework (CV) Test |  |  |  |  |  |  |  | X
USB Enumeration Stress Test |  |  |  |  |  |  |  | X
USB Selective Suspend |  |  |  |  |  |  |  | X
USB Serial Number |  |  |  |  |  |  |  | X
USB Specification Compliance |  |  |  |  |  |  |  | X
USB Isochronous Alternate Interface Presence |  |  |  |  |  |  |  | X
USB HIDView (CV) Test |  |  |  |  |  |  |  | X
USB System Suspend Resume Test |  |  |  |  |  |  |  | X
USB Enable Disable Test |  |  |  |  |  |  |  | X
USB Driver Level Re-Enumeration Test |  |  |  |  |  |  |  | X
USB-IF Test Certification ID Check |  |  |  |  |  |  |  | X
Trim Test |  |  |  |  |  | X |  |
Storage Assessment Test | X |  |  |  |  | X |  |
Enhanced Storage Logo Test* |  |  |  |  |  |  |  | X
IFS Test | X | X | X | X | X | X | X | X
Non-rotating Media Test | X |  |  |  |  | X |  |

* Run this test if the device is an Enhanced Storage class device.

Run Time

Approximately 4 days.

Note Disk verification takes 3 days to finish.


Preparing for Hard Disk Drive (HDD) Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

Many of the tests in the Microsoft Windows Logo Kit (WLK) require that a test system restarts (often more than once) to complete a test run. To enable this restart, Driver Test Manager (DTM) configures the client to automatically log on by using the DTMLLUAdminUser account. This configuration occurs when you first create your submission. DTM also turns off workstation locking and prevents the machine from automatically hibernating or sleeping. If you want to open a remote desktop connection to the client after you start a submission, use the DTMLLUAdminUser account.

The topics in this section describe configuration steps, hardware requirements, and tester knowledge for different bus technologies.

  • PATA
  • Fibre Channel
  • IEEE 1394
  • PC Card
  • SAS
  • SATA
  • SCSI
  • USB


PATA

Test System Configuration

The following procedure describes how to prepare a test system for PATA hard disk drive testing.

To configure a test system for PATA hard disk drive testing

  1. Install the hard disk drive (test device) as a stand-alone Device 0 on the primary ATA/ATAPI channel by using a standard ATA/ATAPI cable.

    This drive is called Drive 1 in the following procedures.

  2. Install the CD-ROM drive by using a standard ATA/ATAPI cable.

    You can install the CD-ROM drive as Device 1 or Cable Select Device 1 on the primary ATA/ATAPI channel. Or, you can install the CD-ROM 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 Drive 1.
  5. If it is necessary, install any drivers that the manufacturers supply tthat devices in the test system require.
  6. With the test system turned off, install an identical hard disk drive by using a standard ATA/ATAPI cable.

    You can install this drive as Device 1 or Cable Select Device 1 on the primary ATA/ATAPI channel. Or, you can install this drive 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 remaining procedures.

  7. If you are testing a hybrid disk, install the disk on a secondary channel and make sure the disk is a secondary disk.
  8. Remove any partitions on Drive 2, and convert the drive to use the MBR partitioning style.
  9. Create three 4-GB NTFS formatted partitions.
  10. Install DTM client and add the machine to a machine pool.

Hardware Requirements

The following hardware is required for PATA hard disk drive testing:

  • One computer with one dual-channel ATA/ATAPI controller on the motherboard
  • Two identical PATA hard disk drives (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

Note

Testing a device to obtain a logo for a server requires that the test system supports four processors and at least 1 GB of RAM. These system capabilities are required for the Dynamic Partitioning (DP) Simulator and Test to run. You do not need a system that actually supports DP capabilities to test your device.

If you use a pool of systems to test devices, at least one system in the pool must contain four processors and at least 1 GB of RAM. Additionally, that system must contain the device and driver that you are testing. As long as the driver is the same on all systems in the pool, the schedule is created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard disk drive, the DTM scheduler constrains the DP test to run on the default system. The default system is the first system that is listed. In this case, you should make sure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), you cannot test physical devices and their associated drivers that are being tested for Server Logo or Signature in virtual machines by using any form of virtualization. This requirement exists because not all virtualization products support the underlying functionality that is required to pass the tests that relate to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Tester Knowledge Requirements

To run the PATA hard disk drive tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive as a Device 0, Device 1, and cable-select Device 0.
  • Install a CD-ROM drive as a stand-alone Device 0, Device 1, and cable-select device.
  • Format and partition a hard disk drive.
  • Use Disk Management to convert a disk that is 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 or DVD.


Fibre Channel

Test System Configuration

The following procedure describes how to prepare a 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 the 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 it is necessary, install any manufacturer-supplied drivers that the devices in the test system require, and then restart the system.
  4. Use the Windows Disk Management utility to delete all existing partitions on the Fibre Channel hard disk drives.
  5. Create two partitions.
  6. Use Disk Management to convert the first and second Fibre Channel hard disk drives (Drive 1 and Drive 2) to dynamic disks.
  7. Use Disk Management to create an NTFS-mirrored volume that is larger than 10 GB on Drive 1 and on Drive 2.
  8. Install DTM client and add the machine to a machine pool.

Hardware Requirements

The following hardware is required for Fibre Channel hard disk drive testing.

  • One computer with one SCSI controller, one monitor, one keyboard, and one mouse (or any pointing or drawing device)
  • Two identical Fibre Channel hard disk drives for the test devices
  • One Fibre Channel controller
  • One SCSI hard disk drive, with at least 10 GB capacity
  • One CD-ROM drive with a minimum of 8x speed
  • One Fibre Channel hub

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.


IEEE 1394

Test System Configuration

The following procedure describes how to prepare a 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 by 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 by using a standard ATA/ATAPI cable.
  3. If the IEEE 1394 controller is not an embedded component, install one IEEE 1394 controller.
  4. Using an IEEE 1394 cable, 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.
  5. Set the system BIOS to support the S3 state.
  6. Install the appropriate Microsoft Windows operating system on the ATA/ATAPI hard disk drive.
  7. If it is necessary, install any manufacturer-supplied drivers that devices in the test system require.
  8. Remove any partitions on the test device, and convert the test device to use the MBR partitioning style.
  9. Install DTM client and add the machine to a machine pool.

Hardware Requirements

The following hardware is required for IEEE 1394 hard disk drive testing:

  • One computer with one dual-channel ATA/ATAPI controller that is implemented on the motherboard and 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 and at least 10 GB capacity
  • One ATA/ATAPI DMA-capable CD-ROM drive
  • One IEEE 1394 cable
  • Two standard ATA/ATAPI cables

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 Device 0.
  • Format and partition a hard disk drive.
  • Install a CD-ROM drive as a stand-alone Device 0.
  • Use Disk Management to convert a disk that is formatted with the GPT disk partitioning style to the MBR disk partitioning style.
  • Install the operating system from the product CD.


PC Card

Test System Configuration

The following procedure describes how to prepare a 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 it is necessary, install any manufacturer-supplied drivers that devices in the test system require.
  6. Remove any partitions on the test device, and convert the test device to use the MBR partitioning style.
  7. Install DTM client and add the machine to a machine pool.

Hardware Requirements

The following hardware is required for PC Card hard disk drive testing:

  • One computer with the following parts:
    • One ultra direct memory access (UDMA)-capable ATA/ATAPI hard disk drive, with at least 10 GB capacity
    • One ATA/ATAPI CD-ROM drive, with a minimum of 8x speed
    • Dual PC Card controllers
    • One monitor, one keyboard, and one mouse (or any pointing or drawing device)
  • Two PC Card hard disk drives for the test devices
  • One PC Card network adapter

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 drive.
  • Install a PC Card hard disk drive.
  • Install a PC Card network adapter.
  • Install the operating system from the product CD.


SAS

Test System Configuration

The following procedure describes how to prepare a test system for testing a SAS hard disk drive.

Note All adapters are operated with BIOS enabled and external termination, unless otherwise noted.

To assemble the test system for SAS hard disk drive testing

  1. If the test system does not contain a SCSI adapter, install the SCSI adapter.
  2. Install a 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 it is necessary, install any manufacturer-supplied drivers that devices in the test system require.
  4. Restart the test system.
  5. Using the Windows Disk Management utility, delete all existing partitions on the SAS hard disk drives.
  6. Use the Windows Disk Management utility to change the SAS hard disk drives into dynamic disks.

    These disk drives are called Drive 1 and Drive 2.

  7. Create two 4-GB NTFS-formatted partitions on Drive 1.
  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.
  9. Install DTM client and add the machine to a machine pool.

Hardware Requirements

The following hardware is required for SAS hard disk drive testing:

  • Two dual-ported SAS controllers
  • Two identical SAS hard disk drives for the test devices
  • One SCSI controller
  • One SCSI hard disk drive with at least a 10 GB capacity
  • One CD-ROM drive with a minimum speed of 8x

Tester Knowledge Requirements

To run the SAS hard disk drive tests, testers must know how to complete 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 drive.
  • Use Disk Management to create dynamic disks and mirrored volumes on a disk.
  • Install the operating system from the product CD.


SATA

Test System Configuration

The following procedure describes how to prepare a test system for Serial ATA (SATA) hard disk drive testing.

To configure the test system for SATA 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 called Drive 1 and Drive 2.

  3. Set the system BIOS to support the S3 state.
  4. Install the appropriate Microsoft Windows operating system on Drive 1.

    During installation, delete any existing partitions on Drive 2 and create three 4-GB NTFS partitions.

  5. If it is necessary, install any drivers that the manufacturer supplies.
  6. Install DTM client and add the machine to a machine pool.

Hardware Requirements

The following hardware is required for SATA hard disk drive testing:

  • One SATA controller with at least two channels
  • One ATA/ATAPI controller
  • Two Serial ATA hard disk drives
  • One ATA/ATAPI CD-ROM drive
  • One SATA cable

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, Device 1, or cable-select Device 1.
  • Format and partition a hard disk drive.
  • Use DiskPart to convert a disk that is formatted with the GPT disk partitioning style to the MBR disk partitioning style with three partitions: 20-GB NTFS, 4-GB NTFS, and 4-GB NTFS.
  • Install the operating system from the product CD to the 20-GB partition.


SCSI

Test System Configuration

The following procedure describes how to prepare a test system for testing a SCSI hard disk drive.

Note All adapters are operated with BIOS enabled and external termination, unless otherwise noted.

To assemble the test system for SCSI hard disk drive testing

  1. Set the SCSI IDs on the hard disk drives (test devices) to the following:
    • 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 from 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 an NTFS-formatted volume on Drive 1.
  3. If it is necessary, install any manufacturer-supplied drivers that the devices in the test system require.
  4. Remove any partitions on Drive 2, and then convert the test device to use the MBR partitioning style.
  5. Create three 4-GB NTFS-formatted partitions on Drive 2.
  6. Install DTM client and add the machine to a machine pool.

Hardware Requirements

The following hardware is required for SCSI hard disk drive testing.

  • One computer with the following:
    • 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 for the test devices
  • One SCSI adapter with the appropriate bus interface for the test device, such as Narrow, Wide, or LVD
  • One bootable SCSI CD-ROM drive

Tester Knowledge Requirements

To run the SCSI hard disk drive tests, testers must know how to complete 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 drive.
  • Install a CD-ROM drive.
  • Use Disk Management to convert a disk that is 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.


USB

Test System Configuration

The following procedure describes how to prepare a test system for USB hard disk drive testing.

To configure the test system for USB hard disk drive testing

  1. If the 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. Set the system BIOS to support the S3 state.
  5. Install the appropriate Microsoft Windows operating system on hard disk drive.
  6. If it is necessary, install any manufacturer-supplied drivers that devices in the test system require.
  7. Remove any partitions on the test device, and convert the test device to use the MBR partitioning style.
  8. Create three 4-GB partitions on the test device.
  9. Install DTM client and add the machine to a machine pool.

Hardware Requirements

The following hardware is required for USB hard disk drive testing.

  • One computer with the following:
    • A USB 2.0 host controller that is embedded on the system motherboard, or a USB 2.0 controller PCI adapter

      Note The USB controller must be able to wake the system by using ACPI mechanisms.

  • Two identical USB hard disk drives for the test devices
  • One UDMA-capable ATA/ATAPI hard disk drive with at least 10 GB capacity
  • One ATA/ATAPI CD-ROM drive, with a minimum speed of 8x speed
  • One USB cable
  • Two standard ATA/ATAPI cables

    Note ATA-66 and ATA-100 controllers require 80-conductor cables.

  • One USB 2.0 high-speed hub

Tester Knowledge Tequirements

To run the USB hard disk drive tests, testers must know how to complete 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 drive.
  • Install the operating system from the product CD.


Running the Hard Disk Drive (HDD) Tests

After you prepare the test machine for hard disk drive testing, you can run the logo tests from the DTM Studio.

  1. Open Device Console in DTM studio.
  2. Create a submission for the Storage > Hard Disk Drive (HDD) category.
  3. If the device has a driver, select a driver INF file when you are prompted. Otherwise, select the I am not providing an INF or driver package check box.
  4. Select the test device from the device list: Drive 1 for SAS; Drive 2 for PATA, SATA, SCSI.

    For a SATA hard disk drive, select the check box to signify that your device is connected through SATA.

  5. In the Create New Submission dialog box, do one of the following:

    • If the device is an Enhanced Storage (IEEE 1667) class device, select Device Supports 1667 protocol.
    • If device can be classified into Hybrid Hard Disk Drive, select Hybrid Hard Disk Drive.
    Screen shot of the Create New Submission dialog box for hard disk drives
  6. Select the tests that you want to start, click Add Selected, and then click Schedule.


Troubleshooting Hard Disk Drive (HDD) Testing

For more information about how to troubleshoot hard disk drive tests, see Troubleshooting Storage Tests or the troubleshooting sections of specific storage tests.


Hardware-based RAID (Storage Array) Testing

The procedures in this section describe how to test a hardware-based RAID (storage array) for correct functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure the full functionality of the device, you must run all of the tests that 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:

Preparing: The preparing topics describe how to configure the system or systems for logo testing.
Running: The running topics describe how to run the tests for your device or system.
Troubleshooting: The troubleshooting section provides information to diagnose failures, warnings, and errors that occur with the test.

Hardware-Based RAID (Storage Array) Tests

The tests that you must run depend on the capabilities of the device or system that you are testing. The following table contains all of the tests that might be required for your test device.

 | Fibre Channel RAID systems | SAS RAID systems | SCSI RAID systems | Serial ATA RAID systems | iSCSI RAID systems
ALUA MPIO Test (LOGO) | X | X | X | X | X
Device Fundamental Tests | X | X | X | X | X
Disk Stress (LOGO) | X | X | X | X | X
Syscache Test (LOGO) | X | X | X | X | X
Disk Verification (LOGO) | X | X | X | X | X
IFS Test for Storage Logo | X | X | X | X | X
VDSHW-Sub | X | X | X | X | X
Multi-Path I/O Test | X | X | X | X | X
SCSI Compliance test (LOGO) | X | X | X | X | X
SCSI Compliance Test 2.0 (LOGO) | X | X | X | X | X
iSCSI Digest - Disk (Target) (LOGO) |  |  |  |  | X
iSCSI Mutual CHAP (Target) (LOGO) |  |  |  |  | X
iSCSI Oneway CHAP (Target) (LOGO) |  |  |  |  | X
iSCSI Ping Test (Target) (Manual Test) |  |  |  |  | X
iSCSI Target iSNS Test |  |  |  |  | X

Run Time

Approximately 96 hours.


Preparing for Hardware-based RAID Systems Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

Many of the tests in the Microsoft Windows Logo Kit (WLK) require that a test system restarts (often more than once) to complete a test run. To enable this restart, DTM configures the client to automatically log on by using the DTMLLUAdminUser account. This configuration occurs when you first create your submission. DTM also turns off workstation locking and prevents the machine from automatically hibernating or sleeping. If you want to open a remote desktop connection to the client after you start a submission, use the DTMLLUAdminUser account.

This section includes the following subsections:

  • Preparing to Test Hardware-based Raid Systems (Fibre Channel / SAS / SCSI / Serial ATA)
  • Preparing to Test Hardware-based Raid Systems (iSCSI)


Preparing to Test Hardware-based Raid Systems (Fibre Channel / SAS / SCSI / Serial ATA)

Test System Configuration

  1. Configure the RAID system by using the RAID system operator panel, by using the command-line tool, or by connecting another system to the RAID system and running the configuration utility.
    1. Check that all RAID devices support only 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:

      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 or 0
      0, 1, and 10 | 10 | 1 | 0
      0 and 5 only | 5 | 5 | 0
      1 and 5 only | 5 | 5 | 1
      0, 1, and 5 | 5 | 1 | 0
      0, 1, 5, and 10 | 5 | 10 | 1 or 0

  2. Turn off the test system.

  3. Install one test-specific type of HBA. For example, if you are testing for a Fibre Channel system, install the Fibre Channel HBA.

    In the test system, connect the HBA to the RAID system by using the appropriate cables for the bus.

    Note If the test RAID system supports more than one bus protocol, you must test and submit your device for a Windows logo one time with each protocol that you want to have it qualified for.

    Note The RAID system should support the PCI-based HBA that you select to test the RAID system. Any drivers that you use 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.

    Note If the device supports MPIO, make sure the HBA has at least two ports. If the HBA has only one port, install another HBA of the same model.

  4. If the RAID system supports multipath drivers, install a second, identical HBA in the test system, and then connect it to the RAID system by using the appropriate cables for the bus.
  5. If both the HBA that you are using to test the RAID system supports boot, and the RAID system supports boot, follow these steps:
    1. Install any HBA or RAID system drivers, including multipath drivers that are required to connect to or manage the test device.
    2. Create a 36-GB NTFS partition on RAID Array 1 and install the appropriate operating system onto this partition.

      Note We recommend SAN-boot configuration, but it is not required.

  6. If you cannot boot the HBA that you are using to test the RAID system, or if the RAID system does not support boot, follow these steps:
    1. Install an alternate boot controller on the test system.
    2. Connect a hard disk drive to the alternate boot controller on the test system.
    3. Install any necessary drivers for the alternate boot controller.
    4. Install the appropriate operating system onto a 36-GB NTFS partition on the hard disk drive.
    5. Install any HBA or RAID system drivers, including multipath drivers that are required to connect to or manage the peripheral devices.

      Note At this point, the system should be installed and booting to the operating system on the test system.

  7. Click Start, and then click Run.
  8. Enter diskmgmt.msc, and then press ENTER.

    Note If the test operating system is Windows Vista or Windows Server 2008, you might be prompted to enter administrator credentials. If you are prompted, enter the credentials.

  9. If the disks appear to be inactive, activate them by right-clicking the disk and then clicking Initialize Disk.
  10. Partition and format all disks:
    1. Right-click each disk, and then click Convert to Basic Disk if it is not basic already.
    2. Right-click each disk, and then click New Partition.

      Note Each partition should be a primary partition, use all of the disk space, use any drive letter, and be formatted in NTFS.

      Note If the HBA that you are using to test the RAID system is bootable, and if the RAID system supports boot, RAID Array 1 should already have a 36-GB partition. Create a new NTFS partition by using the remaining space on this drive.

  11. Restart the operating system to update the page file size.
  12. Install the Microsoft Windows Symbol Files to the C:\Symbols directory.
  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\ConfigureFibreChannelHardwareBasedRaidSystem dimension.

Hardware Requirements

  • One computer with the following parts:
    • Dual-core or equivalent processor (Windows Vista / Windows XP)

      Note An equivalent processor is any processor that appears to Windows as if it contains the specified number of CPUs. You can achieve this status through one or more physical microprocessors.

    • Quad-core or equivalent processor (Windows Server 2008 / Windows Server 2003)

      Note An equivalent processor is any processor that appears to Windows as if it contains the specified number of CPUs. You can achieve this status through one or more physical microprocessors.

    • 2 GB memory (Windows Vista / Windows XP)
    • 6 GB memory (Windows Server 2008 / Windows Server 2003)
    • One logo-compliant ACPI BIOS, with ACPI enabled by default
  • One test-specific type of RAID storage system, including a Fibre Channel, SAS, SCSI, or Serial ATA RAID storage system (for example, a SAS Raid Storage system for a SAS system test). This device is the test device.

    Note The RAID system must be a single cabinet that consists of an array controller that is enclosed in an external subsystem with hard disk drives, or it must be an external array controller that connects to a RAID JBOD. The RAID system cannot consist of only a PCI-based controller and one RAID JBOD.

  • One PCI-based, test-specific type of host bus adapter (HBA).

    If the test system supports multipath, Two HBA ports in the HBA or two identical HBAs, if each of them has just only one port.

    Note The RAID system should support the PCI-based HBA that you select to test the RAID system. Any drivers for the HBA that you use on the test system for this HBA must have a Windows logo, and the HBA model must be included in the Windows Catalog.

  • One bootable ATA, SCSI, or SATA (only for Serial ATA Hardware-based RAID Systems testing) hard disk drive, if the RAID system does not support boot. This drive must have at least a capacity of 36 GB.

Note

  • All hardware (except the test device, monitor, keyboard, mouse and the floppy disk drive) must be listed in the Windows Catalog.

  • To test a device and obtain a logo for Server Device qualification, the system that you are using to test the device must support four processors and at least 1 GB of RAM. These system capabilities are required for the Dynamic Partitioning (DP) Simulator and Test and the Multiple Processor Group test to run. You do not need a system that actually supports DP capabilities or has more than 64 processors to test your device.

    If you use a pool of systems to test devices, at least one system in the pool must contain four processors and at least 1 GB of RAM. Additionally, that system must contain the device and driver that you are testing. As long as the driver is the same on all systems in the pool, the schedule is created to run against all systems.

    For those tests that do not include a driver to test, such as testing a hard disk drive, the DTM scheduler constrains the DP test to run on the default system. You should manually configure this system to have multiple processor groups. The default system is the first system that is listed. In this case, you should make sure that this first system meets these minimum hardware requirements.

  • Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), you cannot test physical devices and their associated drivers that are being tested for Server Logo or Signature in virtual machines by using any form of virtualization. This requirement occurs because not all virtualization products support the underlying functionality that is required to pass the tests that relate to Multiple Processor Groups, Device Power Management, and Device PCI functionality.

Software Requirements

  • Any drivers that are not available with the operating system
  • The current release of WLK
  • Windows Symbol files (WHDC Symbols)
  • One of the following operating systems:
    • Windows Vista
    • Windows XP Professional with Service Pack 2 (SP2)
    • Windows Server 2003 with Service Pack 1 (SP1), Enterprise Edition
    • Windows Server 2003 with Service Pack 1 (SP1), Datacenter Edition
    • Windows XP Professional x64 Edition
    • Windows Server 2003, Enterprise x64 Edition
    • Windows Server 2003, Datacenter x64 Edition
    • Windows Server 2003 with SP1, Enterprise Edition for Itanium-based Systems
    • Windows Server 2003 with SP1, Datacenter Edition for Itanium-based Systems
    • Windows Server 2008 R2

Tester Knowledge Requirements

As a tester, you must know how to perform 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 Windows Symbol files.
  • Install the operating system from the product CD.
  • Read test logs.
  • Report bugs in the standard format.
  • For SATA Hardware-based RAID Systems test, install SATA hard disk drives.


Preparing to Test Hardware-based Raid Systems (iSCSI)

Test System Configuration

  1. Install the Gigabit Ethernet NIC in the test system.
  2. Connect the Gigabit ethernet switch to power.

    Note Do not connect the switch to any other network.

  3. Connect the Gigabit Ethernet NIC in the test system to the switch by using a gigabit ethernet cable.
  4. Connect the disk storage system to the switch by using a gigabit ethernet cable.
  5. Install the appropriate Microsoft Windows operating system onto an NTFS partition that has at least 36 GB on the hard disk drive.
  6. If the test device supports MPIO, install any multipath drivers and create connections and multiple sessions with Enable Multi-Path I/O selected.
  7. Download and install Microsoft .NET Framework version 1.1.
  8. Configure the target device to use one-way (target authenticates initiator) Challenge Handshake Authentication Protocol (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 password that is between 12 and 16 characters long. If you are configuring the device to use both one-way CHAP and mutual CHAP, you must provide different passwords for the target and the initiator.

  9. Log on the target disk storage system with Persistent Login set.

    Important You must log on the iSCSI target device that is used for testing, or the tests will not work properly.

  10. Click Start, and then click Run.
  11. Enter diskmgmt.msc, and press ENTER.
  12. Make sure that the test disks are set as basic disks.
  13. Create three NTFS-formatted partitions that are greater than 2 GB each and less than 4 GB each.

    All of these partitions should be exposed with a single logon.

  14. Install the iSNS software on the test system and configure the target to use the iSNS server.
  15. If your device supports digest and you must configure it, configure the test device to support digest.
  16. Bind your volumes in the Favorite Targets (Windows Vista) or Bound Volumes (Windows Server 2003) tab of iSCSI Initiator Properties.
  17. Install DTM client.
  18. Configure the machine for testing in DTM Studio:
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureiSCSIHardwareBasedRaidSystem dimension.

Hardware Requirements

  • One computer with the following parts:
    • Dual-core or equivalent processor (Windows Vista / Windows XP)

      Note An equivalent processor is any processor that appears to Windows as if it contains the specified number of CPUs. You can achieve this status through one or more physical microprocessors.

    • Quad-core or equivalent processor (Windows Server 2008 / Windows Server 2003)

      Note An equivalent processor is any processor that appears to Windows as if it contains the specified number of CPUs. You can achieve this status through one or more physical microprocessors.

    • 2 GB of memory (Windows Vista / Windows XP)
    • 6 GB of memory (Windows Server 2008 / Windows Server 2003)
    • One logo-compliant ACPI BIOS, with ACPI enabled by default
  • One ISCSI RAID storage system (the test device)

    Note The RAID system must be a single cabinet that consists of an array controller that is enclosed in an external subsystem with hard disk drives, or it must be an external array controller that connects to a RAID JBOD. The RAID system cannot consist of only a PCI-based controller and one RAID JBOD.

  • One GB Ethernet NIC

    Important If the iSCSI RAID system supports Microsoft MPIO, you must have two Gigabit Ethernet NICS or one Gigabit Ethernet NIC and an iSCSI HBA.

  • One 1 GB Ethernet switch
  • One bootable ATA or SCSI hard disk drive with at least 36 GB capacity

Note

  • All hardware (except the test device, monitor, keyboard, mouse and the floppy disk drive) must be listed in the Windows Catalog.

  • To test a device and obtain a logo for Server Device qualification, the system that you are using to test the device must support four processors and at least 1 GB of RAM. These system capabilities are required for the Dynamic Partitioning (DP) Simulator and Test and the Multiple Processor Group test to run. You do not need a system that actually supports DP capabilities or has more than 64 processors to test your device.

    If you use a pool of systems to test devices, at least one system in the pool must contain four processors and at least 1 GB of RAM. Additionally, that system must contain the device and driver that you are testing. As long as the driver is the same on all systems in the pool, the schedule is created to run against all systems.

    For those tests that do not include a driver to test, such as testing a hard disk drive, the DTM scheduler constrains the DP test to run on the default system. You should manually configure this system to have multiple processor groups. The default system is the first system that is listed. In this case, you should ensure that this first system meets these minimum hardware requirements.

  • Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), you cannot test physical devices and their associated drivers that are being tested for Server Logo or Signature in virtual machines by using any form of virtualization. This requirement exists because not all virtualization products support the underlying functionality that is required to pass the tests that relate to Multiple Processor Groups, Device Power Management, and Device PCI functionality.

Software Requirements

  • Any drivers that are not available with the operating system
  • The current release of WLK
  • Windows Symbol files WHDC Symbols
  • The latest version of the Microsoft iSCSI software initiator

    Note To download the iSCSI software initiator, search for “iSCSI software initiator” at the Microsoft Download Center.

  • The latest version of the Microsoft iSNS server

    Note To download the Microsoft iSNS server, search for “iSNS” at the Microsoft Download Center.

  • The Microsoft .NET Framework Version 1.1

    Note To download the .NET Framework Version 1.1, go to the Microsoft Download Center.

  • One of the following operating systems:
    • Windows Vista
    • Windows XP Professional with Service Pack 2 (SP2)
    • Windows Server 2003 with Service Pack 1 (SP1), Enterprise Edition
    • Windows Server 2003 with Service Pack 1 (SP1), Datacenter Edition
    • Windows XP Professional x64 Edition
    • Windows Server 2003, Enterprise x64 Edition
    • Windows Server 2003, Datacenter x64 Edition
    • Windows Server 2003 with SP1, Enterprise Edition for Itanium-based Systems
    • Windows Server 2003 with SP1, Datacenter Edition for Itanium-based Systems
    • Windows Server 2008 R2

Tester Knowledge Requirements

As a tester, you must know how to perform 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 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 one-way and mutual CHAP (if it is supported).
  • Configure an iSCSI tape drive to use an iSNS server.
  • Log on an iSCSI target device.
  • Download and install Microsoft iSCSI software initiator, Microsoft iSNS server, and Microsoft .NET Framework Version 1.1ATA/ATAPI.


Running the Hardware-based RAID Systems Tests

After you prepare the test machine for hardware-based RAID system testing, you can run the logo tests from the DTM Studio.

  1. After you are prompted for a driver or device, select the scenario that applies to you:
    • If your hardware-based RAID system supports MPIO, follow these steps:

      1. If your hardware-based RAID system uses MSDSM.sys (the Microsoft standard device-specific module), select the I am not providing an INF or driver package check box, and then click Next.

        Screen shot of the Create New Submission dialog box with I am not providing an INF or drive package selected

      2. When you are prompted to select a device, select Microsoft Multi-Path Device Specific Module under the System Devices node, and then click Next.

        Screen shot of the Create New Submission dialog box with Microsoft Multi-Path Device Specific Module selected

        Note If your hardware-based RAID system supports MPIO and does not use Microsoft MPIO, you cannot submit by using this logo program.

    • If your hardware-based RAID system does not support MPIO, follow these steps:
      1. When you are prompted to select a driver, select the I am not providing an INF or Driver Package check box, and then click Next.

        You cannot load any driver. You cannot submit non-standard disk drivers and null-INF files by using this logo program.

      2. When you are prompted to select a device, select one of the disks that is displayed in Disk Drives that represents your RAID system. You do not need to select all of disks; DTM selects all matching disks automatically.
  2. Select the bus type for your hardware-based RAID system.

  3. If your device supports MPIO or VDS, select the appropriate check box when you are prompted in the Create New Submission wizard.

    Screen shot of the Create New Submission dialog box where you select whether the device implements MPIO or VDS
  4. Select the tests that you want to run, click Add Selected, and then click Schedule.

Important

For iSCSI hardware-based RAID systems, all of the iSCSI tests require a configuration file to set up the communication between the HBA (Initiator) and the iSCSI targets. This information includes the CHAP user name, target secret to log on the target, target name, target IP address, and HBA PNPID. When you select an iSCSI job, a yellow exclamation mark (!) appears; this mark is normal and indicates that more information is needed. You must enter this information in a user interface that appears when you schedule the job or by right-clicking the job and then clicking Add Information. This user interface generates a configuration file, which is copied to the client machine during each job. The following screen shot shows the extension user interface.

Screen shot of the Target Configuration tab

Note If you are running the MPIO test in an iSCSI environment, you might have to provide additional information about the iSCSI environment or provide the specific iSCSI configuration file. For more information, see Multi-Path I/O Test.


Troubleshooting Hardware-based RAID Systems Testing

For more information about how to troubleshoot hardware-based RAID systems tests, see Troubleshooting Storage Tests or the troubleshooting section of a specific test in Storage Tests.


Removable Storage Testing

The procedures in this section describe how to test your removable media device for correct functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and the Driver Test Manager (DTM). To ensure the full functionality of the device, 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.

Note You must use the latest version of the WLK to compile your driver for it to pass testing and obtain a logo.

Using the Test Procedure Help Topics

The test procedures in this section are divided into the following types of topics:

Preparing: The preparing topics describe how to configure the system or systems for Windows logo testing.
Running: The running topics describe how to run the tests for your device or system.
Troubleshooting: The troubleshooting section provides information to help you diagnose failures, warnings, or errors with the test.

Removable Media Device Tests

The tests that you must run depend on the capabilities of the device or system that you are testing. The following table contains all the tests that might be required for your test device.

 | PATA | IEEE 1394 | PC CARD | SAS | SATA | SCSI | USB
Media Lock Test | X | X | X | X | X | X | X
Anti-Virus/File System Filter Test Kit (IFS Test) | X | X | X | X | X | X | X
Disk Stress | X | X | X | X | X | X | X
Syscache Test | X | X | X | X | X | X | X
Device Fundamental Test | X | X | X | X | X | X | X
Run INFTest against a single INF | X | X | X | X | X | X | X
Media Status Notification Test * | X | X | X | X | X | X | X
SMART test utility | X |  |  |  |  |  |
SATA IO Sig Test |  |  |  |  | X |  |
1394 Configuration ROM Test |  | X |  |  |  |  |
CardBus Card Configuration Space Register test |  |  | X |  |  |  |
CardBus Card Common Silicon Guidelines test |  |  | X |  |  |  |
CardBus Bridge Power Management Register Test |  |  | X |  |  |  |
SCSI Compliance test |  |  |  |  |  | X |
SCSI Compliance Test 2.0 (LOGO) |  |  |  |  |  |  | X
USB Address Description Test |  |  |  |  |  |  | X
USB Descriptor Test |  |  |  |  |  |  | X
USB Device Control Requests Test |  |  |  |  |  |  | X
USB Device Framework (CV) Test |  |  |  |  |  |  | X
USB Enumeration Stress Test |  |  |  |  |  |  | X
USB Selective Suspend |  |  |  |  |  |  | X
USB Serial Number |  |  |  |  |  |  | X
USB Specification Compliance |  |  |  |  |  |  | X
USB Isochronous Alternate Interface Presence |  |  |  |  |  |  | X
USB HIDView (CV) (Manual) |  |  |  |  |  |  | X
USB System Suspend Resume Test |  |  |  |  |  |  | X
USB Enable Disable Test |  |  |  |  |  |  | X
USB Driver Level Re-Enumeration Test |  |  |  |  |  |  | X
USB-IF Test Certification ID Check |  |  |  |  |  |  | X
Flash Memory Assessment Test |  |  |  |  |  |  | X
Enhanced Storage Logo Test ** |  |  |  |  |  |  | X

* Run this test if the device supports Media Status Notification.

** Run this test if the device is an enhanced storage class device.

Run time

Approximately 24 hours.

Note Individual test descriptions are included in Storage Tests.

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. To determine if there are additional hardware requirements, see the test description for each bus-specific test.

  • One test system with the following parts:
    • The minimum requirements that are published for the test operating system
    • One logo-compliant ACPI BIOS, with ACPI enabled by default
    • One host controller with the appropriate bus interface for the test device
    • If the preceding host controller is not bootable, one bootable bus controller (for example, an SCSI controller). If the controller is bootable, you do not need an additional controller.
    • One monitor, one keyboard, and one mouse (or any pointing or drawing device)
  • One removable media device (that is, the test device)
  • One DVD or CD drive with at least 8x speed
  • One hard disk drive of the same bus type as the bootable controller for the test system, with at least 36 GB of space
  • 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

    Note If the test device has more than one port, you must have media for every port.

  • If the device is connected through USB, one USB 2.0 high-speed hub

Note

To test a device andobtain a logo for Server Device qualification, the system that you are using to test the device must support four processors and at least 1 GB of RAM. These system capabilities are required for the Dynamic Partitioning (DP) Simulator and Test and the Multiple Processor Group test to run. You do not need a system that actually supports DP capabilities or has more than 64 processors to test your device.

If you use a pool of systems to test devices, at least one system in the pool must contain four processors and at least 1 GB of RAM. Additionally, that system must contain the device and driver that you are testing. As long as the driver is the same on all systems in the pool, the schedule is created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard disk drive, the DTM scheduler constrains the DP test to run on the default system. You should manually configure this system to have multiple processor groups. The default system is the first system that is listed. In this case, you should make sure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), you cannot test physical devices and their associated drivers that are being tested for Server Logo or Signature in virtual machines by using any form of virtualization. This requirement exists because not all virtualization products support the underlying functionality that is required to pass the tests that relate to Multiple Processor Groups, Device Power Management, and Device PCI functionality.

Software Requirements

The following software is required to run the removable media device tests:

  • One of the following operating systems:
    • Windows Vista
    • Windows XP Professional with Service Pack 2 (SP2)
    • Windows Server 2003 with Service Pack 1 (SP1), Enterprise Edition
    • Windows Server 2003 with Service Pack 1 (SP1), Datacenter Edition
    • Windows XP Professional x64 Edition
    • Windows Server 2003, Enterprise x64 Edition
    • Windows Server 2003, Datacenter x64 Edition
    • Windows Server 2003 with SP1, Enterprise Edition for Itanium-based Systems
    • Windows Server 2003 with SP1, Datacenter Edition for Itanium-based Systems
    • Windows Server 2008 R2
  • Any drivers that are not available with the operating system
  • The current release of WLK

Tester Knowledge Requirements

To run the removable media device tests, testers must know how to perform the following actions:

  • Install the operating system from the product CD.
  • Install and operate the test device.
  • Install DTM client.
  • Start tests from the Device Console window of DTM Studio in Submission mode.


Preparing for Removable Storage Testing

Before running the removable media device 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 Removable Storage Testing.

Many of the tests in the Microsoft Windows Logo Kit (WLK) require that a test system restarts (often more than once) to complete a test run. To enable this restart, DTM configures the client to automatically log on by using the DTMLLUAdminUser user account. This configuration occurs when you first create your submission. DTM also turns off workstation locking and prevents the machine from automatically hibernating or sleeping. If you want to open a remote desktop connection to the client after you start a submission, use the DTMLLUAdminUser user account.

Test System Configuration

To configure the test system for removable media device testing, follow these steps:

  1. Install the appropriate Microsoft Windows operating system.

  2. Install the test device and any accessories.

    You do not need to install a device driver.

  3. If the test device is connected through USB, follow these steps:
    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.

  4. Place media in every port of the test device.

  5. Install DTM client and add the machine to a machine pool.


Running the Removable Storage Tests

To test removable media devices, follow these steps:

  1. Open DTM Studio.

  2. On the Explorers menu, click Device Console.

    (Later on, you can also switch to the Device Console window by clicking the Device Console tab in the lower-left corner of DTM Studio.)

  3. Create a new submission with the following information:
    1. After you select a submission category, select the Storage > Removable Media logo program.
    2. Because the test device should not require a driver, when you are asked about drivers in the wizard, select the I am not providing an INF or driver package check box.
    3. Select your test device under the Disk Drive node in the device list.

    4. In the following Create New Submission dialog box, do the following:

      • If the storage medium is manually ejected from the host, select Manual ejection only. The behavior also applies to "hot-pluggable" device, such as UFD where the medium is within the casing.
      • If the storage is manually injected (that is, it can be checked in conjunction with manual ejection behavior), select Manual injection only.
      • If the device is of reader type and it cannot be checked in conjunction with "flash memory" box, select Device accepts insertion_removal of media.
      • If the device is an Enhanced Storage (IEEE 1667) class device, select Device Supports 1667 protocol.
      Screen shot of the Create New Submission dialog box where you supply additional information about the storage you are testing

  4. Select the tests that you want to run, click Add Selected, and then click Schedule.


Troubleshooting Removable Storage Testing

For more information about how to troubleshoot removable media device testing, see Troubleshooting Storage Tests or the troubleshooting section of a specific test in Storage Tests.


Troubleshooting Storage Tests

The following list describes some common troubleshooting tips for storage tests:

  • Before you create a submission, make sure your client is in Ready Mode. If the client is not in Ready Mode, right-click the machine, point to 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 the Device Console window before you create a submission. If the device still does not appear, restart the client machine and check DTM Studio again.

  • If a job does not succeed verify the job's results and check if the job parameters are getting populated properly, do the following:

    • Verify the results by doing the following.

      1. In the Job Monitor window, select the failing job.
      2. Locate the failed entry in Task Execution Status.
      3. If the failed entry has the Run Job task type, right-click the entry, click Child Job Results. Repeat this step until you find a failed entry that does not have the Run Job task type.
      4. Right-click the failed entry, and click View Task Log to view the test's log.
      5. If the View Task Log option is not available, click View Errors. The errors are likely because of a failure in starting the test.

    • If the preceding step does not help, ensure that the test is receiving the proper parameters by doing the following.

      1. Right-click your device and click View Device XML.
      2. Look for a "StorageDevice or StorageHBA" section at the bottom of the XML code.
      3. If this section is missing, ensure that you completed the steps to configure the machine for testing.
      4. If the StorageDevice or StorageHBA section appears, do the following to check that the job is retrieving the correct parameters:
        • Right-click the job in the Job Execution Status pane of the Job Monitor window, and then click View Result Report.
        • Check the "Effective Parameters" section at the bottom of the report.
        • If the parameters are incorrect, you might have associated the wrong device with the submission, selected the wrong device/channel for launching the test, or misconfigured the hardware.

  • If jobs are appearing incorrectly, do the following to 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 by doing the following.

    1. Right-click your device and click View Device XML.
    2. Look for a "StorageDevice" or "StorageHBA" section at the bottom of the XML code.
    3. If this section is missing, ensure that you completed the steps to configure the machine for testing.
    4. If the information inside the StorageDevice section appears incorrect, ensure that you have selected the correct device and it has been configured. If a secondary window appears that is similar to the following Warning, then some of the parameters required to run the test are missing. Screen shot of the Job extension Warning notification window
    5. Check the machine to ensure that it is configured according to the Logo Program's setup documentation. Ensure that you have the latest device data by clicking the refresh button in Device Console. If this does not help, try restarting the test machine then clicking the refresh button in Device Console


Storage Tests

Boot Test

CardBus Bridge Power Management Register Test

CardBus Card Common Silicon Guidelines test

CardBus Card Configuration Space Register test

Crashdump Support Test

Disk Stress

Disk Verification

DMA Test

Enhanced Storage Logo Test

Flash Memory Assessment Test

HBA API Test

Hybrid Hard Disk Drive Logo Test

IFS Test

iSCSI Boot

iSCSI Boot Firmware Table Test

iSCSI Digest - Disk (HBA)

iSCSI Digest - Disk (Target)

iSCSI Digest - Tape (HBA)

iSCSI Digest - Tape (Target)

iSCSI HBA Mutual CHAP

iSCSI HBA Oneway CHAP

iSCSI iSNS Compliance Test

iSCSI Mutual CHAP (Target)

iSCSI Oneway CHAP (Target)

iSCSI Persistent Login Test

iSCSI Ping Test (HBA)

iSCSI Ping Test (Target)

iSCSI Redirection Test

iSCSI WMI Verification

Media Lock Test

Media Status Notification Test

MMC Test

Multi-Path I/O Test

Non-rotating Media Test

NTFS File Security Test

Optical Logo Test

Relative Open Test

SATA IO Sig Test

SCSI Compliance test

SCSI Initiator Client Server

Separated Cache Solution Evaluation test

SMART test utility

Storage Assessment Test

Storage Data Verification Filter Test

Storage Device Stress test (SDStress)

Storage Imports Test

Storage Query Property

Symlink Regressions

Trim Test

UDF Formatter Tests

VDS HCT

WLK Aggressive Optical Drive Test

WLK CSS Negotiation Region Check Test

WLK DVD Spindown Test

WLK Optical Drive Streaming Mode Test


2.2 TB Boot Scenario

Type: Automated test

Overview

Beginning in 2010, disk drive vendors can ship disks larger than 2.2 TB (>2.2 TB) into the market. Original equipment manufacturer (OEM) vendors are also preparing >2.2-TB boot solutions for their new system platforms. Both Unified Extensible Firmware Interface (UEFI) and shadow master boot record (MBR) solutions have been evaluated by Microsoft kernel and storage teams. To protect Microsoft partners’ investment and ensure a great user experience with >2.2-TB disk drive, the Windows Core OS team supports >2.2-TB boot scenario only in UEFI systems. The 2.2 TB Boot Scenario tests enforce the requirements on this issue.

Details

Run time: 20 minutes
System restart required: Yes
Supported operating systems for logo or signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

Processor

  • x64

  • IA64

Running the Test

Three tests make up the 2.2-TB boot scenario: 2.2 TB Boot Test (LOGO), Boot Test (SYSTEM), and Read Capacity 16 Unit Test – SCSI Compliance Test (LOGO). These tests provide coverage of the 2.2-TB boot requirements and work in conjunction to verify the 2.2-TB boot scenario.

2.2 TB Boot Test (LOGO)

The 2.2 TB Boot Test (LOGO) test checks the consistency of the preOS driver’s reported disk size when compared to the Windows environment. For more information, see 2.2 TB Boot Test.

Program: TwoTBBootTest.exe /device "[DiskBootDeviceObjLink]" and TwoTBBootTest.exe /createlogs
Test Assertions
PreOS and Windows Disk Last Block Consistency
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements

Read Capacity 16 Unit Test – SCSI Compliance Test (LOGO)

Title: ASSERTION: READ CAPACITY (16) Allocation length test
Description: The device must return GOOD (0x0) SCSI status and even though allocation lengthis set to 0 value
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.11 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status
Title: ASSERTION: READ CAPACITY (16) Basic Verification Test
Description: The device must return GOOD (0x0) SCSI status and 8 bytes of parameter data describing the capacity and medium format of the block device to the data-in buffer.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.11 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status
Title: ASSERTION: READ CAPACITY (16) PMI Test
Description: Send a READ CAPACITY command with the PMI (Partial Medium Indicator) set to 1. It indicates that the RETURNED LOGICAL BLOCK ADDRESS and BLOCK LENGTH IN BYTES are those of the last logical block address before a substantial delay in data transer mayb be encountered.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.11 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The returned LOGICAL BLOCK ADDRESS shall be greater than or equal to the logical block address specified by the RELADR and LOGICAL BLOCK ADDRESS fields in the command descriptor block.
Title: ASSERTION: READ CAPACITY (16) Negative Test
Description: Send a READ CAPACITY command with the PMI (Partial Medium Indicator) bit zero but the LOGICAL BLOCK ADDRESS non-zero
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.11 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device should return a CHECK CONDITION (2h) status and the sense key be set to ILLEGAL REQUEST with the additional sense code set to ILLEGAL FIELD IN CDB (24h)

Boot Test (SYSTEM)

The Boot Test (SYSTEM) test checks for adherence to the system requirements for supporting the 2.2-TB boot scenario. For more information on the general boot test, please see Boot Test.

Program: Boottest.exe /logotype system

Test Assertions

2.2 TB Boot Device must contain GPT partitions
Windows Logo Program: SYSFUND-0229 Systems with a boot device with greater than 2.2 terabyte capacity must comply with requirements
2.2 TB Boot Device must be on a 64-bit system
Windows Logo Program: SYSFUND-0229 Systems with a boot device with greater than 2.2 terabyte capacity must comply with requirements
2.2 TB Boot Device must be on a UEFI system
Windows Logo Program: SYSFUND-0229 Systems with a boot device with greater than 2.2 terabyte capacity must comply with requirements


2.2 TB Boot Test

Type: Automated test

Overview

The 2.2 TB Boot test checks the consistency of the reported disk size in a preOS and a Windows environment. These are required to support the 2.2 TB Boot Scenario.

Details

The drive size reported in the preOS environment should exactly match the drive size reported in Windows. Because the preOS device driver is different from the Windows device driver, the test must check for consistency of the reported drive capacity in order to ensure that disk accesses do not encounter problems caused by a variance in the reported sizes.

Run time: 10 minutes
Log file: TwoTBBootTest.wtl
System restart required: Yes
Supported operating systems for logo or signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Program: TwoTBBootTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

Processor

  • x64

  • IA64

Running the Test

Before starting the test, you must first ensure that the boot drive is attached to the test adapter. In Windows, the test configures the boot configuration to boot into a preOS environment during the next reboot to run the test cases. The computer reboots to the preOS environment to allow the preOS test cases to run. When the test cases are finished, the computer reboots back to the Windows environment to collect the logs and determine the test results.

Command Syntax

Command option | Description
TwoTBBootTest.exe | Without any options, prints the usage guide.
/nc | Do not clean up the folders and BCD objects created by the tool. This switch can be used for debugging purposes.
/ll | Set the logging level. The valid values are 0 to 5, with 0 being the maximum logging. The default value is 3.
/pll | Set the logging level for the preOS part of the test. The valid values are 0 to 5, with 0 being the maximum logging. The default value is 3.
/device | The boot device containing the boot drive to be run against.
/? | Prints the usage guide.

Code Tour

File Manifest

File | Location
TwoTBBootTestPreOS.efi | [WTT\TestBinRoot]\LoaderTest\TwoTBBootTest\
TwoTBBootTestPreOS.exe | [WTT\TestBinRoot]\LoaderTest\TwoTBBootTest\
TwoTBBootTest.exe | [WTT\TestBinRoot]\LoaderTest\TwoTBBootTest\
TwoTBBootTest.wim | [WTT\TestBinRoot]\LoaderTest\TwoTBBootTest\

Test Assertions

PreOS and Windows Disk Last Block Consistency
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements


ALUA MPIO Test (LOGO)

Type: Automated test

Overview

Asymmetric logical unit access (ALUA) occurs when the access characteristics of one port may differ from those of another port. Therefore, for storage devices with ALUA feature implemented, there may be at least two target port groups. This test verifies whether storage devices support the ALUA feature properly.

Note This test depends on the SCSI Compliance Test 2.0 binary. Please make sure that LUN0 is the largest non-boot LUN before running the test.

Details

The test checks whether the device declares support to ALUA by checking the INQUIRY TPGS field before additional testing. If the TGPS field is not 0, then the storage devices at least support REPORT TARGET PORT GROUPS, and the Report Target Port Groups test will be done. If TPGS is 2 or 3, then the storage devices support both REPORT TARGET PORT GROUPS and explicit SET TARGET PORT GROUPS. In this case, the test will perform the Report Target Port Groups test and Set Target Port Groups test.
Run time: 5 minutes
Log file: scsicompliance.wtl
System restart required: No
Supported operating systems for logo or signature testing:

  • Windows Server 2008 R2

  • Windows Server 2008

Program: scsicompliance.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Any drivers that are not shipped with the Windows operating system

  • The current release of the Windows Driver Kit

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard disk drive with a minimum of 20 GB available on partition C:

Processor

  • x86

  • x64

Running the Test

Run the test as a Driver Test Manager (DTM) job.

Command Syntax

Command option | Description
scsicompliance.exe | Should be followed by options.
/device [string] | Specifies the device to be tested.
/scenario [string] | Specifies the scenario test to be run. For example, unittest or discoverytest.
/cdb ReportTargetGroup,SetTargetGroup /Version 2 | Runs Report Target Port Groups and Set Target Port Groups CDBs of SPEC-3.

Code Tour

File Manifest

File | Location
scsicompliance.exe | [testbinroot]\nttest\driverstest\storage\wdk\

Test Assertions

For detailed information, please see the "Test Assertions" section in SCSI Compliance Test 2.0 (LOGO).


Boot Test

Type: Automated test

Overview

The Boot test determines whether the test client is booting from a particular device.

Details

The test accepts a device instance path, and it enumerates all of the device's children and finds disks that are equal to or below the device that is specified. The test then finds all of the volumes that span these disks. The test validates that the operating system is installed on one of these volumes and that the boot loader exists on one of the disks.
Run time: 5 minutes
Log file: BootTest.wtl
System restart required: No
Supported operating systems for logo or signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: BootTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Microsoft .NET Framework version 2.0 (installed automatically)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

  • x86

  • x64

  • Itanium

Running Boot Test

Before starting the test, you must ensure that the test adapter is the boot adapter in the system. This system does not need to be the only system in your machine pool. You can use a secondary system that does not meet the setup requirements for your logo program for this test, if necessary.

Command Syntax

Command option | Description
BootTest.exe | Without any options, prints the usage guide.
/device | The instance path of the device to test. This parameter is provided automatically when you run this test in the Device Console window of Driver Test Manager (DTM).
/logotype | Optional parameter that specifies which logo program to test. Possible values are “system” and “device.” The default value is “device.”

Code Tour

File Manifest

File | Location
BootTest.exe | tests\%ARCH%\nttest\driverstest\storage\wdk
StorageDevices.dll | tests\%ARCH%\nttest\driverstest\storage\wdk

Test Assertions

Adapter must support boot
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
Additional information: Option ROMs in host controllers and adapters for any interface type, including RAID controllers, that provide boot support must fully support extended Int13h functions (functions 4xh) as defined in BIOS Enhanced Disk Drive Services - 3 [T13-D1572], Revision 3 or later. Logical block addressing is the only addressing mechanism that is supported.Controllers should also support booting by using the Extensible Firmware Interface (EFI) and implement device paths as defined in EDD-3.

2.2 TB Boot Device must contain GPT partitions
Windows Logo Program: SYSFUND-0229 Systems with a boot device with greater than 2.2 terabyte capacity must comply with requirements
2.2 TB Boot Device must be on a 64-bit system
Windows Logo Program: SYSFUND-0229 Systems with a boot device with greater than 2.2 terabyte capacity must comply with requirements
Additional information: This assertion is only for the system logo program.
2.2 TB Boot Device must be on a UEFI system
Windows Logo Program: SYSFUND-0229 Systems with a boot device with greater than 2.2 terabyte capacity must comply with requirements
Additional information: This assertion is only for the system logo program.


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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • If testing a CardBus bridge/controller, One CardBus card that complies with the requirements of the "Designed for Microsoft Windows" Logo Program for Hardware.

Processor

  • x86

  • x64

  • Itanium

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

Test Assertions

14.9.1CardBus 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
14.9.2The 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.3The 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
14.9.4The 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
14.9.5The 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
14.9.6The 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
14.9.7The 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
14.9.8The 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
14.9.9The 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
14.9.10The 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.11The 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
14.9.12Each 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
14.9.13The 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
14.9.14For 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.15The 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
14.9.18The 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
14.9.19The 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.20The 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
14.9.21The 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.22The 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
14.9.23The 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
14.9.24The 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
14.9.25All 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.27The 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
14.9.28The 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
14.9.30If 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.31The 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
14.9.33The 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.37Writing 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
14.9.38If 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
14.9.40The 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
14.9.41The 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
14.9.42The 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
14.9.43The 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.44All 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.45The 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
14.9.46If 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.49Values 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.52The 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.53The 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.55The 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.57All 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 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • If testing a CardBus bridge/controller, One CardBus card that complies with the requirements of the "Designed for Microsoft Windows" Logo Program for Hardware.

Processor

  • x86

  • x64

  • Itanium

Command Syntax

Command option | Description
cbcomsig.exe |

Code Tour

File Manifest

File | Location
cbcomsig.exe | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pcidll.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pcclib.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pciwdm.sys | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk

Test Assertions

14.7.1CardBus 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
14.7.2CardBus 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
14.7.3CardBus 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
14.7.4CardBus 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
14.7.5CardBus 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
14.7.6CardBus 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
14.7.7CardBus 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
14.7.8CardBus 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


CardBus Card Configuration Space Register 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

Command Syntax

Command option | Description
cbcreg.exe |

Code Tour

File Manifest

File | Location
cbcreg.exe | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pcidll.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pcclib.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
pciwdm.sys | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk

Test Assertions

14.6.1All 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

14.6.2CardBus cards must have a separate configuration space for each implemented function.
Test Assertion GUID: 959be3ea-c341-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

14.6.3All 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

14.6.4CIS 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

14.6.5Each 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

14.6.6If 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

14.6.7If 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

14.6.8If 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

14.6.9If 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


Converged Traffic Test

Type: Automated test

Overview

The Converged Traffic test ensures that the test adapter supports concurrent network and disk input/output (I/O).

Details

The Converged Traffic test runs the Disk Stress test against the storage array attached to the Fibre Channel over Ethernet (FCoE) adapter while simultaneously running NTttcp to stress network traffic through the same FCoE adapter. For additional NTttcp details, consult the NTttcp whitepaper available from Windows Hardware Developer Central (WHDC). For Disk Stress details, please see Disk Stress.

Run time: 8 hours
Log file: DiskIO.wtl and Ntttcps.txt
System restart required: No
Test category: Storage Adapter or Controller
Supported operating systems for logo or signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

Program: Diskio.exe and Ntttcp.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Two FCoE adapters to be tested

  • Two computers that meet the minimum software requirements

  • Fibre Channel (FC) storage array with a minimum of 20 GB available

Processor

  • x86

  • x64

Running Boot Test

To schedule the Converged Traffic test in Driver Test Manager (DTM), you must first select a secondary machine to be the receiver of network I/O. You must then right-click the job and click Edit Parameters to configure the ReceiverIPAddress. The ReceiverIPAddress should correspond to an FCoE network port on the secondary machine. It should also be reachable from the primary test machine via a network port on the same FCoE adapter that has a storage array attached.

Code Tour

File Manifest

File | Location
DiskIO.exe | [testbinroot]\nttest\driverstest\storage\ WDK\
NTttcp.exe | [OSBinRoot]\netio\tcp\


Common Scenario Stress With DiskIO

Type: Automated test

Overview

The Common Scenario Stress with DiskIO test is a stress test that verifies the data integrity of disk input/output (I/O) through power state transitions.

Details

Common Scenario Stress with DiskIO will perform I/O to the test device, similar to how the Disk Stress test treats I/O. If there is a volume present on the test device (or a child device enumerated by the test device), then the I/O will be done through file Testfile.bin on the root of that volume. If no volumes are detected, then the I/O will be done to a raw disk. The DiskIO component of the test will complete each of the following I/O scenarios:

  • Alternating pattern with verification: write(0xAA), write(0x55), read, verify
  • Predefined worst case Serial Advanced Technology Attachment (SATA) pattern issued randomly with verification
  • Predefined worst case SATA pattern issued sequentially with verification
  • Random read
  • Random write
  • Random verify
  • Sequential read
  • Sequential write
  • Sequential verify

During these I/O scenarios, the computer cycles through supported power states, such as sleep and hibernation. The I/O scenarios are expected to complete without any errors during the power state interruptions. The test pauses all I/O before issuing a power state transition by allowing outstanding I/O to complete without issuing new I/O until the system resumes. This pausing behavior can be removed in a future iteration of the test.

Run time: 8 hours
Log file: Common_Scenario_Stress_With_DiskIO.wtl and DiskIO.wtl
System restart required: No, but the test hibernates and resumes the system
Test category: Storage Adapter or Controller
Supported operating systems for logo or signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows Server 2003

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Hard disk drive with a minimum of 20 GB available on partition C:

Processor

  • x86

  • x64

Command Syntax

Command option | Description
Common_Scenario_Stress_With_DiskIO.wsf | Without any options, the test runs with default settings.
/IODevices:"<IODevices>" | This is an optional parameter that specifies the devices to run I/O stress on. By default, it runs I/O on all disk drives and volumes. This should be in the format of any Simple Data Evaluation Language (SDEL) query. "AND," "OR," and parenthesis are supported. Example: "DeviceID='<someDeviceID>' OR Class='DiskDrive'".
/MinutesToRun:<MinutesToRun> | This is an optional parameter that specifies the minimum amount of time the script runs. The default value is 480 minutes. The script continues to run past this time if CyclesToRun has not yet been met.
/SleepPeriod:<SleepPeriod> | This is an optional parameter that specifies the amount of time (in seconds) of the real-time clock (RTC) wake timer each time the machine goes to sleep. The default value is 30.
/MinIOPeriod:<MinIOPeriod> | This is an optional parameter that specifies the minimum time (in milliseconds) I/O tests run per cycle. The default value is 5000.
/MaxIOPeriod:<MaxIOPeriod> | This is an optional parameter that specifies the maximum time (in milliseconds) that I/O tests run per cycle. The default value is 60000.
/ResumeDelay:<ResumeDelay> | This is an optional parameter that specifies the delay (in milliseconds) after the machine resumes from sleep and before the next I/O cycle starts. It allows devices to restore to their working state and renew the IP address for the network card, and so on. The default value is 10000.
/RandomSeed:<RandomSeed> | This is an optional parameter that specifies a previous RandomSeed to run and try to reproduce a specific run. The default value is 0, which indicates that a new seed will be chosen based on the system time.

Code Tour

File Manifest

File | Location
Common_Scenario_Stress_With_DiskIO.wsf | [testbinroot]\nttest\WDTF\SampleScripts\
DiskIOWDTFAction.dll | [testbinroot]\ntttest\WDTF\redist\Interfaces\Action
DiskIOCom.dll | [testbinroot]\nttest\driverstest\storage\wdk\diskio\
DiskIOLib.dll | [testbinroot]\nttest\driverstest\storage\wdk\diskio\


Crashdump Support Test

Type: Automated Test

Overview

Crashdump is the mechanism in which the OS calls the storage adapter driver to write the contents of the memory to a dump file after a system stop error. However, due to the nature of a system stop error, the OS cannot make any assumptions about the stability of the system, and thus very few system services are available to the storage drivers.

The Crashdump Support Test verifies that the storage adapter driver can still operate under these constrained environments and perform the I/O to write to the dump successfully.

Details

The Windows OS allows three different types of memory dump files to be generated:

  • Full

  • Kernel

  • 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.

The test will go through the following sequence of operations:

  1. Install Debugging Tools for windows to the %SystemDrive%\Debuggers directory and initialize the system.

  2. Install test driver to simulate crash.

  3. Test will simulate system stop errors (bluescreen) with bugcheck code 0x000000E2.

  4. System reboots, the test will re-launch automatically.

  5. Test will examine the previous crash by analyzing the memory dump file through the kernel debugger, and verify that the dump has been written correctly.

  6. Repeat steps 3 to 5 for each dump file type.

Run Time: 30 minutes
Log File:
System Restart Required: Yes
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

    Running Crashdump Support Test

    1. Set the page file size on the test machine to at least the of size of physical memory + 1 MB.

    2. Download and install Windows OS symbols using the detailed instructions below (symbols are needed to analyze the dump file; failure to install symbols is the most common test setup problem that would cause this test to fail, and you should not continue unless this issue is resolved). The version of the symbols must match the version of OS installed on the test machine, thus, it must be downloaded external to the kit.

    3. Run test as DTM job.

    Detailed Instruction on Installing Symbols:

    1. Install the Windows Debugging Tools to c:\debuggers Debugging Tools for Windows - Overview

    2. Open a command prompt (in Vista right-click and choose run as administrator).

    3. Assuming the system directory is c:\windows\system32. Type in the following command: c:\debuggers\symchk /r c:\windows\system32 /s SRV*c:\symbols\*http://msdl.microsoft.com/download/symbols

      This will download the symbols using the remote symbol store from Microsoft to the local directory c:\symbols, as the downstream store to cache the symbols. Please see this KB article for additional reference information: Use the Microsoft Symbol Server to obtain debug symbol files

    4. Make sure that symbols can be found for OS kernel. Type in the following command:

      c:\debuggers\symchk c:\windows\system32\ntoskrnl.exe /s c:\symbols\

      Or, for PAE systems, type the following command:

      c:\debuggers\symchk c:\windows\system32\ntkrnlpa.exe /s c:\symbols\

      You should see an output similar to the following to confirm a successful symbols installation:

      SYMCHK: FAILED files = 0

      SYMCHK: PASSED + IGNORED files = 1

    5. It is recommended that you uninstall Windows Debugging Tools before launching the test in DTM.

    Command Syntax

    Command option | Description
crashdumptest.exe -y <symbols_path> -dtm |

    Troubleshooting

    The following is a list of common test failures categories, reference information, and methods to troubleshoot:

    • The test logs error message "Paging file size is too small for full dump purposes":

      In the case of a crash, there is no certainty of what parts of the operating system will still be functional. The network or file system drivers may have caused the crash, for example, preventing access to file system structures to create a dump file, or network to store the file remotely. The OS handles this by using a file that it already knows exists (the pagefile) and writes directly to that file's logical block extents on disk. The dump process writes the contents of physical memory into the pagefile on the system disk (usually c:\pagefile.sys). The pagefile must be large enough to contain the dump. The largest dump is a complete dump which requires the size of physical memory (ex: 4096) plus one extra megabyte to contain the header information. The test requires that the user configure the page file to an appropriate size before execution (see Windows does not save memory dump file after a crash). If the page file size is insufficient, the test will log the following error during the initialization phase:

      • (i) Verifying paging file size.
      • (x) Paging file size is too small for full dump purposes.
      • (i) Paging file size: 330989568
      • (i) Physical memory size: 1073094656
      • (i) Please configure minimum paging file size to physical RAM size + 1MB.

    • I see the system stop error (blue screen), but the bugcheck code is not E2:

      After some basic settings validation the test will install a driver used to crash the system and reboot the system. After the reboot the test changes the crash control settings (for full memory dump), deletes any old dump files, and crashes the system. At the point of the crash the system will display a bugcheck screen (blue screen) with details of the nature of the crash. The type of bugcheck should be MANUALLY_INITIATED_CRASH (e2). If anything else appears here it means a second bugcheck occurred during the process of writing the dump file. This should be investigated by connecting a kernel debugger to the test client and debugging the storage adapter driver.

    • The test logs error message "Dump file is being used by another process. HRESULT: 0x80070020":

      After the dump file has been written the test machine should automatically reboot. Upon boot after a crash the operating system will detect the presence of dump information in the page file and begin the process of writing a dump. This process occurs asynchronously while the machine is booting and even after the user has logged in (see What to consider when you configure a new location for memory dump files in Windows Server 2003 for details). During this process you can view it's progress by checking the size of the dump file (C:\windows\memory.dmp) or viewing the process in task manager (werfault.exe). The test will often be running at the same time as this process, trying to access the same dump file. If this occurs the following messages will appear in the log:

      • (i) Connecting to DumpFile: C:\Windows\MEMORY.DMP
      • (i) Dump file is being used by another process. HRESULT: 0x80070020
      • (i) Usually memory.dmp is still being written due to large RAM, retry after 5 minutes.

      The test should then retry accessing the file. If the error message code is different, or if it changes (ex: 0x80070002 : ERROR_FILE_NOT_FOUND) then it means the file could not be written to disk. The first place to check for valuable debug information is the system event log. To view the event log click Start > Run > Compmgmt.msc. In the computer management window, select Computer Management\System Tools\Event Viewer\System. Browse through the list of events for an event with the source BugCheck. The most common cause for a missing dump file is insufficient free space on the disk. As noted in the KB article referenced above, the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\MachineCrash contains information about the last crash (before a reboot), including the partial dump file if one was created. This can be useful when trying to debug other missing dump issues.

    • The test logs error message "Failed to load the correct symbols":

      Upon reboot the test examines the dump file for correctness. The test does this, just as a developer would, using the kernel debugger kd ("Debugging Tools for Windows" package). In order to analyze a dump file the debugger needs access to symbols. I won't go into details on why these are needed (more information is available here), but think of these as a dictionary for the dump. They allow the debugger to analyze the contents of memory (or a crashdump file) into individual modules (executables, libraries, drivers, etc), functions within those modules, and data structures.

      For the test to work properly, it needs to provide the debugger with symbols. When it does not have proper symbols it will log warnings during the log failures during the first analysis phase of testing. The current mechanism for doing so is to have the user download public symbol packages (here) and install them on the test machine before running the test. When symbols are not installed or the symbols do not match the operating system under test, the following message may appear in the test log:

      • (x) Failed to load the correct symbols.
      • (i) Please refer to WDK documentation on how to install OS symbols.
      • (i) Your symbols might also be out of date, please update symbols via the symbol server: Use the Microsoft Symbol Server to obtain debug symbol files

      This won't actually cause the test to fail because in some cases the dump can still be analyzed with partially matching symbols. If the test continues and more test cases fail with messages like "Error retrieving addresses of ..." or "Unable to get..." it means that the debugger cannot analyze the dump due to the missing symbols. We understand the difficulties associated with downloading the public symbol packages and ensuring they are up to date with all of the latest hot-fixes on the system. One way we have found to work around a symbol is to supplement the locally installed symbol packaged with symbols cached from an internet symbol server. The test could use the symbol server directly, but it is not advised to have the test machines connected to the internet when under test. The steps for caching the symbols locally are as follows:

      1. Ensure that you have already created a crashdump. The easiest way to do this is to run the test once and let it fail.
      2. Ensure that you have the debugging tools installed. Again the easiest way to do this is to run the test once. It will install the tools to C:\Debuggers.
      3. Open a command prompt (in Vista right-click and choose run as administrator).

      4. Type in the following command, without the quotes:

        "c:\Debuggers\kd -z c:\Windows\MEMORY.DMP -y SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols"

      5. This will load the dump in the kernel debugger using the remote symbol store at Microsoft and the local directory C:\Symbols as the downstream store to cache the symbols.
      6. Make sure that symbols can be found for OS files like NTOSKRNL and NTDLL. These are necessary to analyze the dump. It is ok if errors appear loading symbols for other modules like 3rd party drivers.
      7. You should now have a prompt "0: kd>". At this prompt type the command ".reload /f" without the quotes. This command forces the debugger to load and cache all symbols for modules loaded in the dump.
      8. You can now exit the debugger with CONTROL+B then enter.

    Code Tour

    File Manifest

    File | Location
crashdumptest.exe | ...\tests\%ARCHITECTURE\nttest\driverstest\storage\wdk

    Test Assertions

    Loading Dump File Test (Full Dump)
    Test Assertion GUID: F57F156D-BEB3-44ac-907E-1E13F831270C
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    OS Version Test (Full Dump)
    Test Assertion GUID: 79F83EEE-FC95-4953-827D-6B57F63976AE
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Bugcheck Analysis Test (Full Dump)
    Test Assertion GUID: 3969F60C-097D-47df-AB9C-0BA0051A88DB
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Display Stack Test (Full Dump)
    Test Assertion GUID: 5D6E1C83-20D8-4627-9D8C-C3F87856F8B7
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Loaded Module Test (Full Dump)
    Test Assertion GUID: 71C70442-D907-48cd-AD99-B95C24B201A7
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Device Node Test (Full Dump)
    Test Assertion GUID: 9960DBE7-88E3-498d-8C3A-E6ACDE3830E2
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Virtual Memory Test (Full Dump)
    Test Assertion GUID: 2EB6383A-8AA7-4c49-9E06-49519F913B51
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Loading Dump File Test (Kernel Dump)
    Test Assertion GUID: E038983E-90A6-4bb0-926E-6D03604D265F
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    OS Version Test (Kernel Dump)
    Test Assertion GUID: 99C756CD-7549-40a1-89EB-7092199F4B97
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Bugcheck Analysis Test (Kernel Dump)
    Test Assertion GUID: 83E339DE-695B-41af-9227-E20B0F6B7A82
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Display Stack Test (Kernel Dump)
    Test Assertion GUID: EE7A6E78-D9E9-411c-8347-CC89B1CBF995
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Loaded Module Test (Kernel Dump)
    Test Assertion GUID: 791FCD39-154C-48e8-9A6B-24FCB209AC0D
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Device Node Test (Kernel Dump)
    Test Assertion GUID: 7B663C29-D16D-4017-98A4-27E3E73358B6
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Virtual Memory Test (Kernel Dump)
    Test Assertion GUID: A2191D89-AACE-46c4-82E3-3F6786B2BA43
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Loading Dump File Test (Mini Dump)
    Test Assertion GUID: FC1D8E20-23F7-4b53-A4D9-4274777E0EA9
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    OS Version Test (Mini Dump)
    Test Assertion GUID: 0A5E2DC8-AE5B-4293-B7E6-4379CCEC40DB
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Bugcheck Analysis Test (Mini Dump)
    Test Assertion GUID: 0E548A05-D66B-4d11-B4E6-045197F96445
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
    Display Stack Test (Mini Dump)
    Test Assertion GUID: 947549B3-9B1F-4042-888E-CC1BAC28BF40
    Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements


Disk Stress

Type: Automated Test

Overview

The Disk Stress test stresses disks on a computer by sending as much asynchronous I/O as the device can handle. The test should reach the bandwidth limit of the test device for the given test system configuration.

Details

The test is passed the instance path of the target test device. It finds all hard disks and optical drives that are equal to or connected to the test device. The test will then go through the following scenarios on all of the found devices:

  • Sequential read

  • Sequential write

  • Sequential verify (write followed by read and comparison)

  • Random read

  • Random write

  • Random verify

The test is given a fixed run time and runs each scenario for a fraction of that time. In the case of six scenarios and a run time of 90 minutes, each scenario is run for 15 minutes. The test displays dialog boxes with the progress of the current scenario. Any write scenarios (including verify) are skipped for optical devices. The size of the individual data transfers is determined by a command-line parameter; the default size for the logo test is 32 KB.

The test tries to do raw writes, bypassing any file system that is mounted on the hard disk if it can. The test attempts raw writes if one of the following occurs:

  • The test can find a raw, unpartitioned disk.

  • The test can find a raw, unformatted volume.

  • The test can find a volume that it can dismount.

If none of the preceding situations are available, the test performs I/O through the file system. This action is more CPU intensive and might not give accurate bandwidth and latency measurements for the device. In the third situation (the test finds a volume that it can dismount), which is the most common mode that the test is run in, the test allocates a test file to use and writes only to the extents of that file. This situation ensures that the test never corrupts the file system of the device that it is testing.

The amount of space that the test uses is determined by the free space that is available on the test device. To ensure best device performance, you should delete any unnecessary files from the test device and should cleanly format or defragment the device before running the test. The test warns you if the target's fragmentation might influence the test results.

Even though this test does measure device performance, there is currently no test case in the Logo version of this test that passes or fails based on these measurements.

Run Time: 90 minutes (Device LOGO) or 30 minutes (System LOGO)
Log File:DiskIO.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

    Hardware Requirements

    The test tool requires the following hardware:

      Processor

      The test tool runs on the following processor architectures:

        Running Disk Stress

        If you are testing any drive the requires media or testing in system-mode on a computer that contains drives that require media, you must insert media into the drives. The media that is used must be formatted and contain data that occupies at least 50% of the media's capacity.

        Code Tour

        File Manifest

        File | Location
DiskIo.exe | \tests\%ARCH%\nttest\driverstest\storage\wdk
StorageDevices.dll | \tests\%ARCH%\nttest\driverstest\storage\wdk


Disk Verification

Type: Automated Test

Overview

The Disk Verification test verifies a disk by doing random raw writes and reads and comparing the results.

Details

The test is passed the instance path of the target test device. The test then finds all hard disks that are equal to or connected to the test device. It will then choose the best target for the test in the following order:

  1. RAW unpartitioned disk

  2. RAW unformatted volume

  3. Volume that can be dismounted

  4. Volume that cannot be dismounted

The test will run a random verify scenario on this target.

The test is given a fixed run time of 72 hours. The test will display a dialog box with the current progress and bandwidth of the test. The size of the individual data transfers is determined by a command-line parameter; the default size for the logo test is 32 KB.

The test will try to do raw writes, bypassing any file system that is mounted on the hard disk if it can (as in cases 1, 2, and 3 in the preceding list).

The amount of space that the test uses is determined by the free space that is available on the test device. To ensure best device performance, you should delete unnecessary files off the test device and cleanly format or defragment the device before running the test. The test will warn you if the targets fragmentation might influence the test results.

Even though this test does measure device performance, there is currently no test case in the Logo version of this test that will pass or fail based on these measurements.

For more information about the DiskIO test application, see the "Disk Stress" topic.

Run Time: 72 hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

    Hardware Requirements

    The test tool requires the following hardware:

      Processor

      The test tool runs on the following processor architectures:

        Code Tour

        File Manifest

        File | Location
DiskIo.exe | \tests\%ARCH%\nttest\driverstest\storage\wdk
StorageDevices.dll | \tests\%ARCH%\nttest\driverstest\storage\wdk


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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

    Hardware Requirements

    The test tool requires the following hardware:

      Processor

      The test tool runs on the following processor architectures:

        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.

        Code Tour

        File Manifest

        File | Location
DMATest.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        DMATEST ATA Controller must support switching transfer modes during IO.
        Test Assertion GUID: 1e76d594-c379-11da-94f4-00123f3a6b60

        Windows Logo Program: STORAGE-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements

        Additional Information: Be sure to connect both the necessary Hard Disk(s) and optical device. Place non-blank media in the optical device.


Enhanced Storage Logo Test

Type: Automated test

Overview

The enhanced storage device is a storage device that supports 1667 protocol. With 1667 protocol the device supports data security on the storage media. The data on the storage device will not be exposed without proper credentials. The device may support different authentication mechanisms through different entities called silos. The different silos supported by the device will be enumerated as child devices of the 1667 storage drive. The drivers for the silos will be loaded into the system during enumeration.

Details

Run Time: 10 minutes
Log File: EnhancedStorageLogoTest.wtl
System Restart Required: No
Test Category: Storage
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program: EnhancedStorageLogoTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running Enhanced Storage Logo Test

The test takes a PNP device ID of one of the ACTs control device node as a command line argument. The test enumerates the siblings of the control device node. The siblings for this control device node will be:

  1. Control nodes for the other ACTs of the device

  2. Disk device nodes for each ACT

  3. Silos supported by each ACT

The test selects one of the ACT disk device nodes and verifies the SCSI command verification test cases.

The logo submission for these devices should be created with the following steps:

  1. Most of the 1667 supported devices are USB thumb drives. So these drives should be tested under removable storage logo category. The enhanced storage logo test is enabled only for Win7 removable storage logo submissions.

  2. From the device tree in the Create New Submission wizard, select the disk drive that corresponds to the test device under Disk drives. Screen shot of the Create New Submission dialog box listing devices to be tested

  3. In the Create New Submission wizard page the "Device supports 1667 protocol" check box should be selected.

Screen shot of the Create New Submission dialog box with lists and check boxes for supplying additional information about the storage you are testing

Note Current SID is set to "". If your enhanced storage device has a Security ID, then open the enhanced storage job, go to Parameters > Local > Security ID, and then enter the security ID for the device (for example, "ABCD").

Test Cases

Inquiry

Purpose: To validate if the Windows can recognize this device.

  1. Send the INQUIRY command with allocation length set to 0x08.

  2. If command failed, then fail the test case.

  3. Get the additional length from the response

  4. Check if the allocation length from step 3 + 0x05 is greater than or equal to 0x24 and it is 4-byte aligned.

  5. Send the INQUIRY command with allocation length set to additional length from step 3 + 5

  6. Check if the allocation length from step 5 + 0x5 is greater than or equal to 0x24 and it is 4-byte aligned.

  7. If the command fails, fail the test case

Result: The device should respond to the inquiry command properly.

Security Commands Support

Purpose: To validate if the device supports the SECURITY PROTOCOL IN, SECURITY PROTOCOL OUT SCSI commands with INC_512 bit set or cleared.

  1. Send the SECURITY PROTOCOL OUT command with the following values in the CDB:

    Security Protocol = 0

    Security Protocol Specific = 0

    INC_512 = 0

    Allocation Length = 0

  2. If the command fails, then fail the test case.

  3. Send the SECURITY PROTOCOL IN command with the following values in the CDB:

    Security Protocol = 0

    Security Protocol Specific = 0

    INC_512 = 0

    Allocation Length = 512

  4. If the command fails, then fail the test case.

  5. Send the SECURITY PROTOCOL OUT command with the following values in the CDB:

    Security Protocol = 0

    Security Protocol Specific = 0

    INC_512 = 1

    Allocation Length = 0

  6. If the command fails, then fail the test case.

  7. Send the SECURITY PROTOCOL IN command with the following values in the CDB:

    Security Protocol = 0

    Security Protocol Specific = 0

    INC_512 = 1

    Allocation Length = 1

  8. If the command fails, then fail the test case

Result: The device must support the SECURITY PROTOCOL IN and SECURITY PROTOCOL OUT SCSI commands as per the 1667 specification.

Protocol Support

Purpose: To validate if the device supports 1667 protocol

  1. Send the SECURITY PROTOCOL IN command with the following values in the CDB:

    Security Protocol = 0

    Security Protocol Specific = 0

    INC_512 = 1

    Allocation Length = 1

  2. If the command fails, then fail the test case.

  3. If the command succeeds, get the supported security protocol list length from the command response that is used in the next SECURITY PROTOCOL IN command data transfer length.

  4. Send the SECURITY PROTOCOL IN command with the following values in the CDB:

    Security Protocol = 0

    Security Protocol Specific = 0

    INC_512 = 1

    Allocation Length = 1

  5. If the command fails, then fail the test case.

  6. If the command succeeds, check the response if the device reports Supported Security Protocol - 0xEE in the supported security protocol list.

  7. If the supported security protocol, 0xEE, is not found in the command response, then fail the test case.

Result: The device should report security protocol 0xEE as a supported protocol.

Command Sequence

Purpose: Validate the ACT behavior for the pending commands sequence.

  1. Send the SECURITY PROTOCOL IN command with the following values in the CDB:

    Security Protocol = 0xEE

    Silo Index = 0 (Probe Silo Index)

    Function ID = 01

    INC_512 = 1

    Allocation Length = 1

  2. The ACT should fail this command because there will not be an outstanding SECURITY PROTOCOL OUT command pending.

  3. Send the SECURITY PROTOCOL OUT command with the following values in the CDB:

    Security Protocol = 0xEE

    Silo Index = 0 (Probe Silo Index)

    Function ID = 01

    INC_512 = 1

    Allocation Length = 0

  4. If the command fails, then fail the test case.

  5. Send the SECURITY PROTOCOL IN command with the following values in the CDB:

    Security Protocol = 0xEE

    Silo Index = (Probe Silo Index)

    Function ID = 01

    INC_512 = 1

    Allocation Length = 1

  6. If the command fails, then fail the test case.

Result: The probe silo should report SPIN/SPOUT sequence rejection error when the commands are sent out of sync.

Probe Command

Purpose: Validate if the device supports the 1667 probe command.

  1. Get the OS version information

  2. Send the PROBE command with following values in the SECURITY PROTOCOL OUT command CDB:

    Security Protocol = 0xEE

    Silo Index = 0x00

    Function ID = 0x01

    INC_512 = 1

    Allocation Length = 1

  3. If the command fails, then fail the test case.

  4. Send the SECURITY PROTOCOL IN command with the following values in the CDB:

    Security Protocol = 0xEE

    Silo Index = 0x00

    Function ID = 0x01

    INC_512 = 1

    Allocation Length = 1

  5. If the command fails, then fail the test case.

  6. Get the required probe response data size

  7. Fill in the probe command pay load with the host OS information.

  8. Send the SECURITY PROTOCOL OUT command with the following values in the CDB and with the payload created in step 7:

    Security Protocol = 0xEE

    Silo Index = 0x00

    Function ID = 0x00

    INC_512 = 1

    Allocation Length = Number of 512 blocks required for the data size from step 6.

  9. If the command fails, then fail the test case.

  10. Send the SECURITY PROTOCOL IN command with the following values in the CDB:

    Security Protocol = 0xEE

    Silo Index = 0x00

    Function ID = 0x01

    INC_512 = 1

    Allocation Length = 1

  11. If the command fails, then fail the test case.

Result: The device must properly respond to the PROBE command.

Silo Enumeration

Purpose: To enumerate all the Silos implemented by each ACT on the device.

  1. Get the list of ACTs reported by the device.

  2. Perform the following operations on each ACT:

    Authorize the ACT

    Get the authorization state

    Enumerate the silos implemented by the ACT

    The ACT must report one or more silos

  3. The device should report at least one ACT with one authentication silo. Verify if one of the following mandatory authentication silos are reported:

    Password silo

    Certificate silo

Result: The device should properly report all the silos implemented by each ACTs. At least one ACT should support one or more authentication silos.

Certificate Authentication Silo

Purpose: To validate the certificates in the certificate store

  1. Enumerate the ACTs supported by the device.

  2. Enumerate the silos for each ACT and validate the following
    • Silo GUID
      • Check if the
        • GUID is a 45 byte character sequence
        • GUID has '-'(dash) character after
          • 6 digits company ID,
          • 24 byte product ID string
          • 8 byte product instance ID string
        • Company ID, Product ID, Product Instance ID has the upper case hexadecimal characters
    • Certificate Store
      • Get the certificate store locations count.
      • Check if the certificate store locations count is greater than or equal to 6.
      • Get the certificate at each certificate store location and check if the
        • Validation policy has one of the following values
          • None (01h)
          • Basic (02h)
          • Extended (03h)
        • For Certificate at index zero check if the
          • certificate type is manufacturer certificate
          • certificate chain is in PKCS#7 format
          • ASCm certificate chain has a valid ASCm certificate as the last certificate in the chain
          • ASCm chain is at least two levels deep
    • Silo Capabilities
    • Check if the following capabilities are supported:
      • Hash Algorithms
      • Asymmetric Key Cryptography
      • Signing Algorithms
      • Certificate support
      • Optional features support

Result: The certificate authentication silo must be in compliance with the 1667 specification.

Password Silo Test Scenarios

Initial Check:

Check if the password silo supports at least SHA256 digest algorithms, and the maximum challenge size reported is acceptable on the host environment. If either of them is false, then skip all the test scenarios and fail this test.

Test Scenario 1

Purpose: Check if the password silo succeeds authentication with incorrect digest algorithm.

  1. Send Request Mutual Challenge command with unsupported digest algorithm and expect error.

  2. If Success, fail this test.

Result: Expect error code ERROR_UNSUPPORTED_DIGEST_ALGORITHM, 0x84.

Test Scenario 2

Purpose: Check if the password silo succeeds authentication with a user password when there is no user.

  1. Send Request Mutual Challenge command with valid and supported digest algorithm and get the device challenge.

  2. If command fails, fail the test.

  3. Send Mutual Authentication command with user password and expect error.

  4. If command fails, fail the test.

Result: Expect error code ERROR_USER_PASSWORD_DOES_NOT_EXIST, 0X8B.

Test Scenario 3

Purpose: Check if the password silo succeeds with privileged operation, having a default administrator password.

  1. Send Request Mutual challenge command and obtain device challenge.

  2. Send Mutual Authentication command with administrator password.

  3. Send a privileged command and expect error.

Result: Expect error code ERROR_DEFAULT_ADMIN_PASSWORD, 0X90.

Test Scenario 4

Purpose: Check if password silo changes password with invalid Security Identifier. This test is valid only for devices which support Security Identifier.

  1. Send Request Mutual challenge command and obtain device challenge.

  2. Send Mutual authentication command with valid password.

  3. Send Change password command for the corresponding entity with valid new password and invalid security identifier.

  4. If success, fail this test and skip rest of the tests.

Result: Expect error code ERROR_INVALID_SECURITY_IDENTIFIER, 0XA2.

Test Scenario 5

Purpose: Check if password silo has the correct state after changing admin password to empty password.

  1. Send Request Mutual Challenge command and obtain device challenge.

  2. Send Mutual Authentication command with administrator password.

  3. Send Change Password command to change admin password to valid non-empty string.

  4. Repeat steps 1 and 2 with corresponding password set in 3.

  5. Send Configure administrator command to configure administrator attributes.

  6. Repeat step 4

  7. Send Create User command to create user with valid attributes.

  8. Repeat step 4

  9. Send Change password command to change admin password to empty string.

  10. Query password silo and check the password silo information.

Fail the test, if any of the above commands fail.

Result: The state should be similar to the state after sending the Fire command of Initialize to Manufacturer state operation except rendering the contents of the ACT unusable.

Test Scenario 6

Purpose: Check if password silo allows creating more than one user.

  1. Send Request Mutual challenge command and obtain device challenge.

  2. Send Mutual authentication command with valid password.

  3. Send Change password command with valid non-empty admin password.

  4. Repeat steps 1 and 2

  5. Send Configure administrator command and configure admin attributes

  6. Repeat step 4

  7. Send Create User command

  8. Repeat steps 6 and 7 and expect error code

Result: Expect error code ERROR_USER_EXISTS, 0X9B.

Test Scenario 7

Purpose: Check if password silo allows administrator to manipulate user's attributes and user to manipulate admin's attributes.

  1. Send Request mutual challenge command to obtain device challenge.

  2. Send Mutual authentication with admin password.

  3. Send Unauthorize command for admin.

  4. Repeat steps 1 and 2.

  5. Send Authorize command for admin.

  6. Repeat step 4.

  7. Send Change password command for the user and expect error.

  8. If success, fail the test.

  9. Unauthorize admin and authorize user by repeating step 4 for each.

  10. Repeat step 4.

  11. Send privileged command and expect error.

  12. If success, fail the test.

Result: Expect error code ERROR_NOT_AUTHENTICATED 0X90 at step 7 and 11.

Test Scenario 8

Purpose: Check the behavior of password silo when user is blocked

  1. Send Request Mutual challenge command and obtain device challenge.

  2. Send Mutual authentication command.

  3. Send Unauthorize command for the user.

  4. Repeat steps 1 and 2.

  5. Send authorize command for the user with invalid password and block the user.

  6. Repeat step 4 for user and expect error, if success fail the test.

  7. Repeat step 4 for admin.

  8. Send Authorize command for admin and expect success.

  9. If error is received fail the test.

Result: When the user is blocked, authenticating as user should give error ERROR_SILO_BLOCKED 0X8C, but a non-blocked admin should be able to authenticate successfully.

Test Scenario 9

Purpose: Check the behavior of password silo on deleting user when there is none.

  1. Send Request Mutual challenge command and obtain device challenge.

  2. Send Mutual authentication command.

  3. Send Delete user command.

  4. If error is received, fail the test.

  5. Repeat steps 1, 2, 3 and expect error.

Result: Expect error code ERROR_USER_DOES_NOT_EXIST, 0x9A on deleting a user when there is none.

Test Scenario 10

Purpose: Check if the password silo allows the admin to change user password.

  1. Send Request Mutual challenge command and obtain device challenge.

  2. Send Mutual authentication command.

  3. Send Create user command.

  4. Repeat steps 1 and 2.

  5. Send Initialize user password command and expect success.

Result: Administrator should be able to change the user's password only using the Initialize user password command.

Test Scenario 11

Purpose: Check the behavior of password silo when admin is blocked

  1. Send Request Mutual challenge command and obtain device challenge.

  2. Send Mutual authentication command.

  3. Send Unauthorize command for the admin.

  4. Repeat steps 1 and 2.

  5. Send authorize command for admin with invalid password and block admin.

  6. Repeat step 4 for admin and expect error, if success fail the test.

  7. Repeat step 4 for user.

  8. Send Authorize command for user and expect success.

  9. If error is received fail the test.

Result: When admin is blocked, authenticating as admin should give error ERROR_SILO_BLOCKED 0X8C, but a non-blocked user should be able to authenticate successfully.

Test Scenario 12

Purpose: Check the behavior of password silo with invalid Security identifier for Initialize to manufacturer's state command. This test is valid only for those devices which support security identifier.

  1. Send ARM operation of Initialize to manufacturer's state command with invalid security identifier and expect error, else fail the test.

  2. Send ARM operation of Initialize to manufacturer's state command with valid security identifier and expect success.

  3. Send FIRE operation of Initialize to manufacturer's state command with invalid security identifier and expect error, else fail the test.

  4. Send ARM and FIRE operations of Initialize to manufacturer's state command with valid security identifier and expect success.

Result: With invalid security identifier in ARM and FIRE operations, expected error code is ERROR_INVALID_SECURIY_IDENTIFIER, 0XA2.


Flash Memory Assessment Test

Type: Automated Test

Overview

This tool verifies that a device meets the performance requirements for Flash Memory.

Details

The test interacts with the External Memory Devices (EMD) service to determine if the device passes the interface, minimum size, and file system requirements. The operating systems checks these same requirements when a removable storage device is first inserted to determine if the device should undergo the bandwidth tests to qualify for Windows ReadyBoost. The test then launches the WinSAT utility to measure the device's read and write throughput. The device must meet the throughput requirements for random reads and writes (as listed in the Windows Logo Program Requirements) across its entire capacity.

Run Time: 15 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Configure your removable storage device with a volume size of full capacity of your device or 4 GB, whichever is less. This can be done by using disk management. Afterwards, you can run the test.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Command Syntax

Command option | Description
FlashMemoryAT.exe [StorageDriveLetter] |

Code Tour

File Manifest

File | Location
FlashMemoryAT.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk


HBA API Test

Type: Automated Test

Overview

The HBA API Compliance test verifies the Microsoft 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 Windows logo, Fibre Channel and SAS Storport miniport drivers and SCSI miniport drivers must support the HBA API.

The HBA API test requires a Fibre Channel switch between the HBA and the storage devices that you are testing. The Fibre Channel switch must support the GIEL and GANXT specifications. Most switches that have been made in the past 10 years support these specifications.

The topology can any kind of fabric configuration, as long as a switch is present. For example, the simplest configuration is the following: [TestMachine]<-->[FibreChannelSwitch]<-->[FibreChannelStorageArray]

Details

The test uses a Microsoft Visual Basic script to query the HBAs WMI interfaces. For specific test cases, see the Test Assertions section. You can view the source of the test by opening the script file 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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

    Hardware Requirements

    The test tool requires the following hardware:

      Running HBA API Test

      The test first installs the schema for the HBA API on the computer and then starts the script.

      Code Tour

      File Manifest

      File | Location
hbaapi.vbs | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
hbaapi.bmf | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

      Test Assertions

      0 HBA miniport must support HBA API WMI interfaces.
      Test Assertion GUID: c0bcadba-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      4 The provider must provide one instance of MSFC_HBAAdapterMethods per adapter.
      Test Assertion GUID: c0bcadbe-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      4.2.1 The method RefreshInformation must be implemented.
      Test Assertion GUID: c0bcadc3-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      4.2.2 The methods GetDiscoveredPortAttributes and GetPortAttributesByWWN must be implemented.
      Test Assertion GUID: c0bcadc4-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      Additional Information: A call to GetDiscoveredPortAttributes with port and discovered index zero should return success. The returned NodeWWN, PortWWN, and PortFcId port attribute fields must be valid. The NumberOfDiscoveredPorts field must be zero. A call to GetPortAttributesByWWN with the preceding port should match the attributes that are returned in the preceding situation.
      4.2.3 The method SendCTPassThru must be implemented.
      Test Assertion GUID: c0bcadc5-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      4.2.4 The method ScsiReadCapacity must be implemented.
      Test Assertion GUID: c0bcadc6-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      4.2.8 The methods Get/SetFC3MgmtInfo must be implemented.
      Test Assertion GUID: c0bcadca-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      4.2.9 The method GetEventBuffer must be implemented.
      Test Assertion GUID: c0bcadcb-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      4.3.4 Calling GetBindingCapability should return a success or not supported.
      Test Assertion GUID: c0bcadcf-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      4.3.6 Calling SetBindingSupport should return a success or not supported.
      Test Assertion GUID: c0bcadd1-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      4.3.7 Calling GetFcpPersistentBinding should return success or more data.
      Test Assertion GUID: c0bcadd2-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      4.3.8 Calling GetFcpPersistentBinding2 should return success or more data.
      Test Assertion GUID: c0bcadd3-c401-11da-94f4-00123f3a6b60
      Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
      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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements


Hybrid Hard Disk Drive Logo Test

Type: Automated Test

Overview

The Hybrid Hard Disk Drive Logo test validates and verifies if a hybrid disk drive complies with the standards and achieves the performance and power management requirements. This test should run on a secondary drive and when the test is running there should not be any other I/O happening to the drive.

Warning To verify the performance and throughput of the drive, the test reads and writes to the disk directly. So, the data in the disk will be lost if you run this test. Please make sure you back up the data before running the test. The test will skip testing with a failure if you try to run it on a system or boot drive.

Details

A hybrid hard disk (H-HDD) is a hard disk drive with nonvolatile Flash memory that acts as a cache that holds written and pinned LBAs within the drive. The main purpose of a H-HDD is to provide a nonvolatile cache (NV Cache) mechanism by using the Flash memory that is accessible at all times for writes and low-latency reads including when the magnetic media spindle is stopped.

During power savings periods, the disk is spun down most of the time and reads and writes happen from the NV Cache. The Disk will spin up if the data has to be flushed to the disk from the cache or the read request could not be resolved from data in the cache. The power consumption for the disk can be minimized because the disk is spun down most of the time. The power savings are targeted at portable computer systems powered by a battery. The ATA command set has been extended to support the NV Cache and power management functionalities of the H-HDD.

A hard disk drive that is implemented as a Hybrid Hard Disk responds to an ATA command set extension - Non Volatile Cache Command Proposal for ATA8-ACS, Feb. 4th, 2006, Revision 6.

The Microsoft Windows operating system must be able to perform the following tasks when a Hybrid Disk Drive is installed on a system:

  • Detect the hybrid hard disk.

  • Enable NV-Cache mode when on battery power.

  • Pin boot or resume LBAs as required to enhance boot and resume performance.

  • Pin as many LBAs as the Identify Device reports as the size of the NV Cache.

  • Use the current ATA command set as released to T13 (which is referenced earlier).

The device must be configured to allow these command sets to function properly and control the resource in an appropriate fashion (spinning down the drive to save power when in NV Cache mode).

Systems that implement a hybrid hard disk must meet the requirements that are outlined in this topic.

The Hybrid Disk Logo test verifies the following requirements of the hybrid disk drive:

  • Basic logo requirements:
    • The hybrid disk is detectable.
    • The disk satisfies the minimum NV cache size requirement.

  • The disk supports the ATA command set extension.

  • Performance requirements.

LOGO TEST REQUIREMENTS

Basic Requirements tests:

  • Detect the hybrid hard disk when installed.

  • NV cache size is at least 50 MB.

NV Cache ATA command support:

  • Should be in compliance with the ATA7 command set along with the ATA8-ACS command set extensions for NV Cache proposed to T13:
    • Identify command.
    • Power Management commands.
    • Cache Management commands.

Note The command set proposal is available from the Technical Committee T13 Web site.

NV cache Management tests:

  • Pin Lba(s) into NV cache.

  • Unpin LBA(s) from NV cache.

  • Validate the behavior of the disk in the NV cache power save mode for read and write requests.

  • Validate the behavior of the disk for the NV Cache commands in non-power save mode.

  • Latency requirements in power mode:
    • In Boot/resume scenarios the read, write latencies for a 512 bytes block should be less than 3 seconds.
    • In normal operation, the read/write latencies for 4 K block should be less than 3 milliseconds and for 4.5 K block it should be less than 4 milliseconds.

Performance test:

  • Verifies the read/write latency is less than:
    • 3 ms for a 4 K random block.
    • 4 ms for a 4.5 K random block.

Note 10% of the IOs can exceed the latency requirements. But none of the IOs should take more than 5 ms for 4 K random/sequential block scenario and 10 ms for 4.5 K random/same block scenario.

Throughput test:

  • Verifies the following throughput values:

Scenario | Throughput
4 KB Random Read | 4 MB/sec
4 KB Random Write | 4 MB/sec
64 KB Sequential Read | 16 MB/sec
64 KB Sequential Write | 8 MB/sec
1 MB Random Read | 16 MB/sec
1 MB Random Write | 10 MB/sec

Logo Test Assumptions:

The test should be run on a secondary disk. The test reads and writes to the disk directly. The test verifies IOs on the entire disk, so it expects the disk to be formatted, empty, and have only one partition. The disk must not be active, and the test will not run if the disk is active. To verify that your disk is not active, or to remove the active property if it is active, follow these steps:

  1. Open Disk Management (type diskmgmt.msc in the Run dialog or Start menu search box.

  2. Your system/boot disk and hybrid drive will appear.

  3. The hybrid drive must not have the word Active in its description. If the drive is marked Active (for example, if it says Healthy (Active, Primary Partition), then it must be made inactive before the test is run. To do this using the Disk Management Method, follow these steps:

    a. Right-click the secondary drive in Disk Management, and select Delete Volume. You will receive the following warning if the drive has an active partition:

    This is the active partition on this disk....

    Click Yes to continue.

    b. The drive will now be unallocated. Right-click the disk again and select New Simple Volume using the default values. You can select Quick Format if you don't want to wait for a full format.
    c. The disk in Disk Manager will now say Healthy (Primary Partition) without the word "Active".

TEST OVERVIEW

  1. Check if the drive supports NV cache.
    • Send the IDENTIFY command.
    • Check if bit 0 and bit 4 are set in the word 214 in the response. Skip the test if those bits are not set.
    • Skip the test if the test drive is a boot drive or a system drive.
  2. Check if the drive supports write cache.
    • If the drive supports this feature, check if the write cache is disabled. If the write cache is not disabled, disable the write cache.

  3. Run the test cases.

  4. Enable the write cache, if the test disabled it.

TEST CASES

  1. IDENTIFY TEST

    Description: This test verifies if the device correctly identifies itself as a hybrid hard disk drive.

    1.1 Send identify device command

    ATA Command: Identify Device - ECh

    1.2 Check for the following data in the response.

    1.3 NV cache mode support flag is 1

    Bit 0 in word 214

    1.4 NV cache mode commands support flag is 1

    Bit 4 in word 214

    1.5 Device estimated time to spin up in seconds is not 0

    Bits 0-7 in word 219

    1.6 NV cache size is at least 50MB

    Bits 0-15 in word 215 for MSW of cache size in LBAs

    Bits 0-15 in word 216 for LSW of cache size in LBAs

    Result: The drive should properly set the NV Cache parameters in response for the IDENTIFY command.

  2. NV CACHE POWER MODE TEST

    Description: This test ensures that the drive responds appropriately to the NV Cache Power mode command.

    Windows Vista uses this command to manage drive spin down and improve battery life.

    2.1 Set NV cache power mode with 5 seconds minimum high power time

    ATA Command: Set NV Cache Power Mode - B6/00h

    2.2 Check the power mode of the disk after 15 seconds

    ATA Command: Check Power Mode - E5h

    2.3 If the disk is not in the power save mode, the test fails

    2.4 Disable NV cache power mode

    ATA Command: Return from NV Cache Power Mode - B6/01h

    2.5 Check the power mode state of the drive

    ATA Command: Check Power Mode - E5h

    2.6 If the disk is still in power save mode, the test fails

    Result: The drive should respond correctly for the enable/disable power mode commands.

  3. NV CACHE MAX PIN AREA TEST

    Description: This test ensures that the drive correctly reports the number of LBAs that are available to Windows Vista for pinning data. Windows Vista uses this number to determine how much data it can place into the NV cache.

    3.1 Set NV cache power mode with 5 seconds minimum high power time

    ATA Command: Set NV Cache Power Mode - B6/00h

    3.2 Unpin all LBAs in the NV Cache

    ATA Command: Remove LBA(s) From NV Cache Pinned Set - B6/11h with unpin all flag set

    3.3 Wait for Unpin all LBAs operation to complete

    3.4 Flush the NV cache

    ATA Command: Flush NV Cache - B6/14h

    3.5 Wait for Flush operation to complete

    3.6 Send Add LBA command to pin 0 LBAs. The drive should respond with number of unpinned LBAs equal to

    NV Cache size.

    ATA Command: Add LBA(s) to NV Cache Pinned Set - B6/10h

    3.7 Check for NV Cache number of remaining unpinned LBAs in the response data

    3.8 If the number of unpinned LBAs is not equal to NV Cache, the test case fails.

    3.9 Disable NV cache power mode.

    ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: When the NV Cache is empty, the drive should report that the number of the unpinned LBAs is equal to the NV Cache size.

  4. POWER MODE SPIN UP TIME TEST

    Description: This test measures whether Windows Vista can put a H-HDD into a given power mode and that the drive appropriately obeys the spin up hold time. This feature enables Windows Vista to aggressively conserve power by spinning down the drive.

    4.1 Enable Power Mode with 5 seconds minimum high power time

    ATA Command: Set NV Cache Power Mode - B6/00h

    4.2 Check for the drive spindle state for 5 seconds.

    ATA Command: Check Power Mode - E5h

    4.3 Disk spindle should be up for at least 5 seconds; otherwise, the test case fails.

    4.4 Disable NV cache power mode.

    ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: When the power mode is enabled with some minimum high power time, the drive should be in spin up state at least for the high power time before going to spun down state.

  5. POWER MODE STATE TEST

    Description: These tests ensure that the drive correctly sets power mode states so that Windows Vista can improve battery life.

    5.1 Set NV cache power mode with 5 seconds minimum high power time.

    ATA Command: Set NV Cache Power Mode - B6/00h

    5.2 Set the disk power state to D3.

    Send IOCTL IOCTL_PT_SET_DEVICE_POWER_STATE to the powertst.sys to set the power state of the

    hybrid hard disk to D3

    5.3 Sleep for 5 seconds to make sure the disk spindle will be in idle state .

    5.4 Set the disk power state to D0.

    Send IOCTL IOCTL_PT_SET_DEVICE_POWER_STATE to the powertst.sys to set the power state of the

    hybrid hard disk to D0

    5.5 Check the power mode of the disk.

    ATA Command: Check Power Mode - E5h

    5.6 If the disk is not in the power save mode, the test fails.

    5.7 Disable NV cache power mode.

    ATA Command: Return from NV Cache Power Mode - B6/01h

    5.8 Set the disk power state to D3.

    Send IOCTL IOCTL_PT_SET_DEVICE_POWER_STATE to the powertst.sys to set the power state of the

    hybrid hard disk to D3

    5.9 Sleep for 5 seconds to make sure the disk spindle will be in idle state.

    5.10 Set the disk power state to D0.

    Send IOCTL IOCTL_PT_SET_DEVICE_POWER_STATE to the powertst.sys to set the power state of

    the hybrid hard disk to D0

    5.11 Check the power mode of the disk.

    ATA Command: Check Power Mode - E5h

    5.12 If the disk is in power save mode, the test fails.

    5.13 Disable NV cache power mode.

    ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: The drive should retain its power mode state even when its device power state is changed.

  6. PIN LBA TEST

    Description: This test ensures that Windows Vista can correctly pin data into the NVCache. Pinning forms the foundation for many of the performance and spin-down improvements.

    6.1 This scenario is verified in both power save mode and without power save mode. If this scenario is being

    verified in power save mode, perform steps 6.2 to 6.9. Otherwise, perform only steps 6.7 to 6.8.

    6.2 Set NV cache power mode with 5 seconds minimum high power time.

    ATA Command: Set NV Cache Power Mode - B6/00h

    6.3 Unpin all LBAs in the NV Cache.

    ATA Command: Remove LBA(s) From NV Cache Pinned Set - B6/11h with unpin all flag set

    6.4 Wait for Unpin all LBAs operation to complete

    6.5 Flush the NV cache.

    ATA Command: Flush NV Cache - B6/14h

    6.6 Wait for Flush operation to complete

    6.7 Pin one random LBA with populate immediately flag.

    ATA Command: Add LBA(s) to NV Cache Pinned Set - B6/10h

    6.8 Query for NV cache pinned LBAs set and check for the NV cache LBA range that we just pinned. If that range

    entry is not found, the test fails.

    ATA Command: Query NV Cache Pinned Set - B6/12h

    6.9 Disable NV cache power mode.

    ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: The drive should respond to the Pin LBA command properly.

  7. UNPIN LBA TEST

    Description: This ensures that Windows Vista can remove data from the NV cache to manage the cache.

    7.1 This scenario is verified in both power save mode and without power save mode. If this scenario is being

    verified in power save mode, perform steps 7.2 to 7.10. Otherwise, perform only steps 7.7 to 7.9.

    7.2 Set NV cache power mode with 5 seconds minimum high power time.

    ATA Command: Set NV Cache Power Mode - B6/00h

    7.3 Unpin all LBAs in the NV Cache.

    ATA Command: Remove LBA(s) From NV Cache Pinned Set - B6/11h with unpin all flag set

    7.4 Wait for Unpin all LBAs operation to complete

    7.5 Flush the NV cache.

    ATA Command: Flush NV Cache - B6/14h

    7.6 Wait for Flush operation to complete

    7.7 Pin one random LBA with populate immediately flag.

    ATA Command: Add LBA(s) to NV Cache Pinned Set - B6/10h

    7.8 Remove (unpin) the LBA that we just pinned.

    ATA Command: Remove LBA(s) From NV Cache Pinned Set - B6/11h

    7.9 Query for NV Cache pinned LBAs set and check for the NVCache LBA range that we just unpinned; if that

    range entry is found, the test fails.

    ATA Command: Query NV Cache Pinned Set - B6/12h

    7.10 Disable NV cache power mode.

    ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: The drive should respond to the Remove LBA command properly.

  8. PIN MAXIMUM (64) LBA ENTRIES TEST

    Description: This command ensures that the drive appropriately pins large blocks of data by pinning the maximum allowable number of LBAs. Pinning large amounts of data enables Windows Vista to efficiently populate the drive.

    8.1 This scenario is verified in both power save mode and without power save mode. If this scenario is being

    verified in power save mode, perform steps 8.2 to 8.10. Otherwise, perform only steps 8.7 to 8.9.

    8.2 Set NV cache power mode with 5 seconds minimum high power time.

    ATA Command: Set NV Cache Power Mode - B6/00h

    8.3 Unpin all LBAs in the NV Cache.

    ATA Command: Remove LBA(s) From NV Cache Pinned Set - B6/11h with unpin all flag set

    8.4 Wait for Unpin all LBAs operation to complete

    8.5 Flush the NV cache.

    ATA Command: Flush NV Cache - B6/14h

    8.6 Wait for Flush operation to complete

    8.7 Create a list of 64 Random LBAs entries list, of chunk size 1 LBA (512 bytes).

    8.8 Pin all the LBAs in the entry list with populate immediately flag.

    ATA Command: Add LBA(s) to NV Cache Pinned Set - B6/10h

    8.9 Query for NV Cache pinned LBAs set and check for the all the NVCache LBA range entries that we just pinned;

    if any of those ranges are not found, the test fails.

    ATA Command: Query NV Cache Pinned Set - B6/12h

    8.10 Disable NV cache power mode.

    ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: The drive should respond to the Pin LBA and Query NV Cache Pinned set commands properly.

  9. PIN LBAS UPTO NV CACHE SIZE

    Description: This test ensures that Windows Vista can use all the LBAs in the NV Cache. If the entire NV Cache is not available to Windows Vista, it cannot optimally manage the cache.

    9.1 This scenario is verified in both power save mode and without power save mode. If this scenario is being verified in power save mode, perform steps 9.2 to 9.9. Otherwise, perform only steps 9.7 to 9.8.

    9.2 Set NV cache power mode with 5 seconds minimum high power time.

    ATA Command: Set NV Cache Power Mode - B6/00h

    9.3 Unpin all LBAs in the NV Cache

    ATA Command: Remove LBA(s) From NV Cache Pinned Set - B6/11h with unpin all flag set

    9.4 Wait for Unpin all LBAs operation to complete

    9.5 Flush the NV cache

    ATA Command: Flush NV Cache - B6/14h

    9.6 Wait for Flush operation to complete

    9.7 Pin the number of LBAs of 64K chunks up to the size of the NV cache with populate immediately flag

    ATA Command: Add LBA(s) to NV Cache Pinned Set - B6/10h

    9.8 If the pinning is unsuccessful, the logo test fails.

    9.9 Disable NV cache power mode

    ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: The drive should allow us to pin the LBAs upto NVCache size.

  10. PIN LBAS MORE THAN NVCACHE SIZE

    Description: This verifies that the drive correctly handles a request to pin more data than the drive can physically accommodate.

    10.1 This scenario is verified in both power save mode and without power save mode. If this scenario is being verified in power save mode, perform steps 10.2 to 10.10. Otherwise, perform only steps 10.7 to 10.9.

    10.2 Set NV cache power mode with 5 seconds minimum high power time.

    ATA Command: Set NV Cache Power Mode - B6/00h

    10.3 Unpin all LBAs in the NV Cache

    ATA Command: Remove LBA(s) From NV Cache Pinned Set - B6/11h with unpin all flag set

    10.4 Wait for Unpin all LBAs operation to complete

    10.5 Flush the NV cache

    ATA Command: Flush NV Cache - B6/14h

    10.6 Wait for Flush operation to complete

    10.7 Pin the number of LBAs of 128K chunks up to one LBA more than the size of the NV cache with populate immediately flag

    ATA Command: Add LBA(s) to NV Cache Pinned Set - B6/10h

    10.8 If the pinning is successful then the logo test fails

    10.9 If the pinning is unsuccessful, validate the response; the error code should reflect that there is no enough NV cache space to complete the request; otherwise, the test fails.

    10.10 Disable NV cache power mode

    ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: The drive should not allow us to pin the LBAs more than NVCache size.

  11. NV CACHE MISS TEST

    Description: This test verifies that the drive correctly reports NV Cache misses. Windows Vista uses this information to optimize the set of data that it places in the cache.

    11.1 This scenario is verified in both power save mode and without power save mode. If this scenario is being verified in power save mode, perform steps 11.2 to 11.9. Otherwise, perform only steps 11.7 to 11.8.

    11.2 Set NV cache power mode with 5 seconds minimum high power time.

    ATA Command: Set NV Cache Power Mode - B6/00h

    11.3 Unpin all LBAs in the NV Cache

    ATA Command: Remove LBA(s) From NV Cache Pinned Set - B6/11h with unpin all flag set

    11.4 Wait for Unpin all LBAs operation to complete

    11.5 Flush the NV cache

    ATA Command: Flush NV Cache - B6/14h

    11.6 Wait for Flush operation to complete

    11.7 Query NV cache misses

    ATA Command: Query NV Cache Misses - B6/13h

    11.8 Check the response for the query NV cache misses command

    11.9 Disable NV cache power mode

    ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: The drive should respond to Query NV Cache Misses command properly.

  12. READ LBA TEST

    Description: This tests determines whether Windows Vista can read LBAs from the NV Cache and verifies the integrity of the data read.

    12.1 This scenario is verified in both power save mode and without power save mode. If this scenario is being verified in power save mode, perform steps 12.2 to 12.22. Otherwise, perform only steps 12.7 to 12.21.

    12.2 Set NV cache power mode with 5 seconds minimum high power time.

    ATA Command: Set NV Cache Power Mode - B6/00h

    12.3 Unpin all LBAs in the NV Cache

    ATA Command: Remove LBA(s) From NV Cache Pinned Set - B6/11h with unpin all flag set

    12.4 Wait for Unpin all LBAs operation to complete

    12.5 Flush the NV cache

    ATA Command: Flush NV Cache - B6/14h

    12.6 Wait for Flush operation to complete

    12.7 Select a random LBA between 0 - 1024

    12.8 Write data to the selected LBA

    ATA Command: WRITE DMA EXT - 35h, DMA

    12.9 Unpin all LBAs in the NV Cache

    ATA Command: Remove LBA(s) from NV Cache Pinned Set - B6/11h with unpin all flag set

    12.10 Wait for Unpin all LBAs operation to complete

    12.11 Flush the NV cache

    ATA Command: Flush NV Cache - B6/14h

    12.12 Wait for Flush operation to complete

    12.13 Pin the selected LBA to NV cache with populate Immediately flag

    ATA Command: Add LBA(s) to NV Cache Pinned Set - B6/10h

    12.14 Set the disk power state to D3

    Send IOCTL IOCTL_PT_SET_DEVICE_POWER_STATE to the powertst.sys to set the power state of

    the hybrid hard disk to D3

    12.15 Sleep for 5 seconds to make sure the disk spindle will be in idle state

    12.16 Set the disk power state to D0

    Send IOCTL IOCTL_PT_SET_DEVICE_POWER_STATE to the powertst.sys to set the power state of

    the hybrid hard disk to D0

    12.17 Calculate the time stamp T1

    12.18 Send the read request for the pinned LBA

    ATA Command: Read DMA EXT - 25h, DMA

    12.19 Calculate the time stamp T2

    12.20 Calculate the time (T2-T1) it took to access the LBA in the NV cache and compare it with the threshold time (3 seconds). If the access time is exceeding the threshold time, the test fails.

    12.21 Validate the data of the LBA by comparing with the data that we initially wrote. The test fails if the validation fails.

    12.22 Disable NV cache power mode

    ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: The test writes to an LBA and pins that LBA. Then, it checks if the read latency is less than three seconds when the drive is still trying to startup. This check is to verify pinning the LBA with populate immediately flag would make the drive to copy the LBA from the disk to the NVCache.

  13. WRITE LBA TEST

    Description: This test measures the drive's ability to write an LBA into NVRAM when in power saving mode without spinning up the drive. Writing to the NVRAM without spinning up the drive is critical to extend the battery life.

    13.1 This scenario is verified in both power save mode and without power save mode. If this scenario is being verified in power save mode, perform steps 13.2 to 13.18. Otherwise, perform only steps 13.7 to 13.17.

    13.2 Set NV cache power mode with 5 seconds minimum high power time

    ATA Command: Set NV Cache Power Mode - B6/00h

    13.3 Unpin all LBAs in the NV Cache

    ATA Command: Remove LBA(s) from NV Cache Pinned Set - B6/11h with unpin all flag set

    13.4 Wait for Unpin all LBAs operation to complete

    13.5 Flush the NV cache

    ATA Command: Flush NV Cache - B6/14h

    13.6 Wait for Flush operation to complete

    13.7 Select one Random LBA

    13.8 Pin the selected LBA to NV cache with populate immediately flag

    ATA Command: Add LBA(s) to NV Cache Pinned Set - B6/10h

    13.9 Write some date to the selected LBA

    ATA Command: WRITE DMA EXT - 35h, DMA

    13.10 Set the disk power state to D3

    Send IOCTL IOCTL_PT_SET_DEVICE_POWER_STATE to the powertst.sys to set the power state of

    the hybrid hard disk to D3

    13.11 Sleep for 5 seconds to make sure the disk spindle will be in idle state

    13.12 Set the disk power state to D0

    Send IOCTL IOCTL_PT_SET_DEVICE_POWER_STATE to the powertst.sys to set the power state of

    the hybrid hard disk to D0

    13.13 Calculate the time stamp T1

    13.14 Send the read request for the pinned LBA

    ATA Command: Read DMA EXT - 25h, DMA

    13.15 Calculate the time stamp T2

    13.16 Calculate the time (T2-T1) it took to access the LBA in the NV cache and compare it with the threshold time (3 seconds). If the access time is exceeding the threshold time, the test fails.

    13.17 Validate the data of the LBA by comparing with the data that we initially wrote. The test fails if the validation fails.

    13.18 Disable NV cache power mode

    ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: The test pins an LBA and write to that LBA. Then, it checks if the read latency is less than three seconds when the drive is still trying to startup. This check is to verify whether the writes go to the NV Cache when that LBA is already in the pinned set.

  14. PERFORMANCE TEST

    Description: This test verifies that the drive meets the minimum criteria for random and sequential reads and writes. Setting a minimum performance bar ensures that the user will have an acceptable experience when using a H-HDD.

    14.1 Set NV cache power mode with 5 seconds minimum high power time

    14.2 Unpin all LBAs in the NV Cache

    ATA Command: Remove LBA(s) from NV Cache Pinned Set - B6/11h with unpin all flag set

    14.3 Wait for Unpin all LBAs operation to complete

    14.4 Flush the NV cache

    ATA Command: Flush NV Cache - B6/14h

    14.5 Wait for Flush operation to complete

    a) 1024 RANDOM 4K BLOCK READ WRITES

    1. Generate list of 1024 different random 4KB blocks which are 512b aligned to the disk offsets (but no overlapping ranges).
    2. Generate a random 32-bit number and fill that number in the 4K write buffer.
    3. Write to the 4K random block.
      • Measure the IO latency; it should be less than 3 ms.
      • If the IO latency exceeds 3 ms but less than 5 ms, print a warning message. 10% of IOs are allowed to exceed the latency requirements. But if the number of IOs that fail the performance requirements is more than 10%, fail the test.
      • If the IO latency is more than 5 ms, fail the test.
    4. Sleep for 50 ms.
    5. Read from the 4K random block.
      • Measure the latency; it should take less than 3 ms.
      • If the IO latency exceeds 3 ms but less than 5 ms, print a warning message. 10% of IOs are allowed to exceed the latency requirements. But if the number of IOs that fail the performance requirements is more than 10%, fail the test.
      • If the IO latency is more than 5 ms, fail the test.
      • Validate the read data. The read data should match with the data written to that location before.
    6. Repeat steps 2 to 5 on 1024 random 4K blocks.

    7. Unpin all LBAs in the NV Cache

      ATA Command: Remove LBA(s) from NV Cache Pinned Set - B6/11h with unpin all flag set

    8. Wait for Unpin all LBAs operation to complete.

    9. Flush the NV cache

      ATA Command: Flush NV Cache - B6/14h

    10. Wait for Flush operation to complete.

    (b) 1024 RANDOM 4.5K BLOCK READ WRITES

    1. Generate list of 1024 different random 4.5KB blocks which are 512b aligned to the disk offsets (but no overlapping ranges).
    2. Generate a random 32-bit number and fill that number in the 4.5K write buffer.
    3. Write to the 4.5K random block.
      • Measure the IO latency; it should take less than 4 ms.
      • If the IO latency exceeds 4 ms but less than 10 ms, print a warning message. 10% of the IOs are allowed to exceed the latency requirements. But if the number of IOs that fail the performance requirements is more than 10%, fail the test.
      • If the IO latency is more than 10 ms, fail the test.
    4. Sleep for 50 ms.
    5. Read from the 4.5K random block.
      • Measure the IO latency; it should take less than 4 ms.
      • If the IO latency exceeds 4 ms but less than 10 ms, print a warning message. 10% of the IOs are allowed to exceed the latency requirements. But if the number of IOs that fail the performance requirements is more than 10%, fail the test.
      • If the IO latency is more than 10 ms, fail the test.
      • Validate the read data. The read data should match with the data that was written to that location before.
    6. Repeat steps 2 to 5 on 1024 random 4.5K blocks.

    7. Unpin all LBAs in the NV Cache

      ATA Command: Remove LBA(s) from NV Cache Pinned Set - B6/11h with unpin all flag set

    8. Wait for Unpin all LBAs operation to complete

    9. Flush the NV cache

      ATA Command: Flush NV Cache - B6/14h

    10. Wait for Flush operation to complete

    (c) SAME 4.5K BLOCK READ WRITES

    1. Generate a random 32-bit number and fill that number in the 4.5K write buffer.
    2. Select a 4.5 K random lock that is the last block on a 64-KB boundary and pin that block.
    3. Write to the 4.5 K random Block.
      • Measure the IO latency; it should take less than 4 ms.
      • If the IO latency exceeds 4 ms but less than 10 ms, print a warning message. 10% of the IOs are allowed to exceed the latency requirements. But if the number of IOs that fail the performance requirements is more than 10%, fail the test.
      • If the IO latency is more than 10 ms, fail the test.
    4. Sleep for 50ms.
    5. Read from the 4.5K random block.
      • Measure the IO latency; it should take less than 4 ms.
      • If the IO latency exceeds 4 ms but less than 10 ms, print a warning message. 10% of the IOs are allowed to exceed the latency requirements. But if the number of IOs that fail the performance requirements is more than 10%, fail the test.
      • If the IO latency is more than 10 ms, fail the test.
      • Validate the read data. The read data should match with the data that was written to that location before.
    6. Repeat steps 1 to 4 on the same random block 1024 times.

    7. Unpin all LBAs in the NV Cache

      ATA Command: Remove LBA(s) from NV Cache Pinned Set - B6/11h with unpin all flag set

    8. Wait for Unpin all LBAs operation to complete.

    9. Flush the NV cache

      ATA Command: Flush NV Cache - B6/14h

    10. Wait for Flush operation to complete.

    (d) 1024 SEQUENTIALLY INCREASING 4K BLOCK READ WRITES

    1. Generate list of 1024 sequential (increasing order) 4KB blocks which are 512-b aligned to the disk offsets

      (but no overlapping ranges).

    2. Generate a random 32-bit number and fill that number in the 4K write buffer.
    3. Write to the 4K block.
      • Measure the IO latency; it should take less than 3 ms.
      • If the IO latency exceeds 3 ms but less than 5 ms, print a warning message. 10% of the IOs are allowed to exceed the latency requirements. But if the number of IOs that fail the performance requirements is more than 10%, fail the test.
      • If the IO latency is more than 5 ms, fail the test.
    4. Sleep for 50 ms.
    5. Read from the 4K block.
      • Measure the IO latency; it should take less than 3 ms.
      • If the IO latency exceeds 3 ms but less than 5 ms, print a warning message. 10% of the IOs are allowed to exceed the latency requirements. But if the number of IOs that fail the performance requirements is more than 10%, fail the test.
      • If the IO latency is more than 5 ms, fail the test.
      • Validate the read data. The read data should match with the data that was written to that location before.
    6. Repeat steps 2 to 5 on 1024 sequentially incrementing 4K blocks.

    7. Unpin all LBAs in the NV Cache

      ATA Command: Remove LBA(s) from NV Cache Pinned Set - B6/11h with unpin all flag set

    8. Wait for Unpin all LBAs operation to complete.

    9. Flush the NV cache

      ATA Command: Flush NV Cache - B6/14h

    10. Wait for Flush operation to complete.

    (e) 1024 SEQUENTIALLY DECREASING 4K BLOCK READ WRITES:

    1. Generate list of 1024 sequential (decreasing order) 4KB blocks which are 512b aligned to the disk offsets (but no overlapping ranges).
    2. Generate a random 32-bit number and fill that number in the 4K write buffer.
    3. Write to the 4K block.
      • Measure the IO latency; it should take less than 3 ms.
      • If the IO latency exceeds 3 ms but less than 5 ms, print a warning message. 10% of the IOs are allowed to exceed the latency requirements. But if the number of IOs that fail the performance requirements is more than 10%, fail the test.
      • If the IO latency is more than 5 ms, fail the test.
    4. Sleep for 50 ms.
    5. Read from the 4 K block.
      • Measure the IO latency; it should take less than 3 ms.
      • If the IO latency exceeds 3 ms but less than 5 ms, print a warning message. 10% of the IOs are allowed to exceed the latency requirements. But if the number of IOs that fail the performance requirements is more than 10%, fail the test.
      • If the IO latency is more than 5 ms, fail the test.
      • Validate the read data. The read data should match with the data that was written to that location before.
    6. Repeat steps 2 to 5 on 1024 sequentially decrementing 4K blocks.

    7. Unpin all LBAs in the NV Cache

      ATA Command: Remove LBA(s) from NV Cache Pinned Set - B6/11h with unpin all flag set

    8. Wait for Unpin all LBAs operation to complete.

    9. Flush the NV cache

      ATA Command: Flush NV Cache - B6/14h

    10. Wait for Flush operation to complete.
    11. Make sure the device is set back to non NV cache by the end of the test case.

    12. Disable NV cache power mode

      ATA Command: Return from NV Cache Power Mode - B6/01h

    Result: Read/Write latencies should be less than:

    • 1 ms for a 4 K random/sequential block.
    • 1.2 ms for a 4.5 K random/sequential block.

  15. THROUGHPUT TEST

    Description: This test is to measure performance of the drive; it focuses on total throughput rather than responsiveness for individual operations.

    This test case is sub divided into three test cases. Each test case verifies the Read Write throughput on 32 MB.

    • 4 KB Random blocks (8192 IOs)
    • 64 KB Sequential blocks (512 IOs)
    • 1 MB Random blocks (32 IOs)

    The throughput is calculated based on the read write latencies to these blocks.

    Perform steps 1 to 11 on 4 KB random blocks, 64 KB sequential blocks, and 1 MB random blocks.

    1. Set NV cache power mode with 5 seconds minimum high power time.

      ATA Command: Set NV Cache Power Mode - B6/00h

    2. Unpin all LBAs in the NV Cache

      ATA Command: Remove LBA(s) from NV Cache Pinned Set - B6/11h with unpin all flag set

    3. Wait for Unpin all LBAs operation to complete

    4. Flush the NV cache

      ATA Command: Flush NV Cache - B6/14h

    5. Wait for Flush operation to complete
    6. Generate a list of test blocks for 32 MB data that are not overlapping. These blocks will be 512 bytes aligned to the disk offsets if the scenario that is being tested is the 4 KB random or 64 KB Sequential scenario. The blocks will be 1 MB aligned for the 1 MB random clock scenario. Pin all the test data blocks.
    7. Generate random 32-bit value for each location. These random 32-bit random values are used to fill the data blocks.
    8. Write to the tests data blocks. Measure the time it took to write.
    9. Generate random IO blocks of the same block size and send write IOs to those blocks. This step is to make sure that the data in the DRAM cache is overwritten with this data.
    10. Read from the test data blocks. Measure the time it took to read. Validate the read data; it should be filled with the value we wrote to that location before.
    11. Calculate the throughput for these reads and writes.

    12. The drive should meet the following requirements.
      Scenario Throughput

      4 KB Random Read

      4 MB/sec

      4 KB Random Write

      4 MB/sec

      64 KB Sequential Read

      16 MB/sec

      64 KB Sequential Write

      8 MB/sec

      1 MB Random Read

      16 MB/sec

      1 MB Random Write

      10 MB/sec

    13. Disable NV cache power mode

      ATA Command: Return from NV Cache Power Mode - B6/01h

FUNCTION TO WAIT FOR UNPIN ALL OPERATION TO COMPLETE

  1. Send the unpin all command.

  2. Poll the device to find the "Number unpinned LBAs remaining" (N).

  3. If 'N' is equal to NV cache size, then unpin all operation is complete, so exit the loop with success.

  4. If the previous value of 'N' is less than its current value then the unpin all operation is considered as progressing, So time out counter will be reset to zero.

  5. If the previous value of 'N' is >= to its current value then the test would consider the unpin all operation is not progression, so the time out counter is incremented.

  6. If the time out counter is >= 60, then the test will generate an error saying "ERR: TIMEOUT - NV cache Unpin all operation is not progressing for the last one minute." and exits the test case.

  7. Sleep for 1 second.

  8. Go to step2.

FUNCTION TO WAIT FOR FLUSH OPERATION TO COMPLETE

  1. Send the Flush command and check the response for "Number of LBAs still to be removed" (N).

  2. If 'N' is equal to zero, then the flush operation is complete, so exit the loop with success.

  3. If the current value of 'N' is less than its previous value then the flush operation is considered as progressing, so time out counter will be reset to zero.

  4. If the current value of 'N' is >= to its previous value then the test would consider flush operation is not progression, so the time out counter is incremented.

  5. If the time out counter is >= 60, then the test will generate an error saying "ERR: TIMEOUT - NV Cache Flush operation is not progressing for the last one minute." and exits the test case.

  6. Sleep for 1 second.

  7. Go to step 1.

Run Time: 60 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2008

  • Windows 7

  • Windows Server 2008 R2

Program:

Requirements

Software Requirements

The test tool requires the following software:

    Hardware Requirements

    The test tool requires the following hardware:

      Processor

      The test tool runs on the following processor architectures:

        Running Hybrid Hard Disk Drive Logo Test

        To run this test, you must have the following three binary files:

        • PitonLogoTestsetup.exe is a setup application to install the powertst.sys driver.

        • PitonLogotest.exe is the logo test.

        • Powertst.sys is a driver to change the power state of the drive.

        To run the test manually, do the following:

        1. Copy the following test binaries to a folder:
          • PitonLogoTestsetup.exe
          • PitonLogotest.exe
          • Powertst.sys
          • wttlog.dll

        2. Start a command prompt with administrator privileges and use that command window for steps 3 and 4.

        3. Install the powertst.sys driver by running the setup application with the PitonLogoTestSetup.exe -install command.

        4. Run the logo test by using the PitonLogoTest.exe -deviceid <deviceid> command.

        For more information about command-line options, type PitonLogoTest.exe /?.

        Note The powertst.sys driver does automatically start when the computer is restarted. You must manually start the driver before you run the logo test by using PitonLogoTestSetup.exe -install or net start powertst.

        To uninstall the powertst.sys driver, run PitonLogoTestSetup.exe -uninstall.

        Command Syntax

        Command option | Description
pitonlogotest.exe -device <deviceid> | Run the test on the disk drive with that deviceid

        Cautions

        The driver verifier would interfere with the logo test IOs. If the driver verifier is enabled on the system, please disable it before running the test.
        Please make sure there are no Ready Boost configured devices on the system. The Ready Boost features in the operating system might interfere with logo test IOs.

        Code Tour

        File Manifest

        File | Location
pitonlogotest.exe | storage\wdk\piton
pitonlogotestsetup.exe | storage\wdk\piton
powertst.sys | storage\wdk\piton

        Test Assertions

        TEST: IDENTIFY Device Command
        Test Assertion GUID: aaecc364-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Enable Disable NV Cache Power Mode
        Test Assertion GUID: aaecc365-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Max NV Cache Pin Area
        Test Assertion GUID: aaecc366-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Power Mode Spinup Time
        Test Assertion GUID: aaecc367-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Power Mode State Test
        Test Assertion GUID: aaecc368-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Pin Data
        Test Assertion GUID: aaecc369-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Unpin Data
        Test Assertion GUID: aaecc36a-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Pin Max LBAs
        Test Assertion GUID: aaecc36b-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Pin LBAs More than NV cache size
        Test Assertion GUID: aaecc36c-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Query Cache Misses
        Test Assertion GUID: aaecc36d-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Read LBAs
        Test Assertion GUID: aaecc36e-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Write LBAs
        Test Assertion GUID: aaecc36f-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Pin Maximum Random LBA Entries
        Test Assertion GUID: aaecc370-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements
        TEST: Power Mode Performance Test
        Test Assertion GUID: aaecc371-c420-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0005 Hybrid Disk Drives support industry standards and Windows requirements


IFS Test

Overview

The Installable File System (IFS) test is designed to test that installable file systems comply with the Microsoft Windows operating systems. Its intended audience includes file system developers who want to verify that their drivers comply with a standard set of expected functionality.

You can run the IFS test from the command line and specify several options. Each test returns a test status block if the test has passed or failed. You can also view the test results in NTlog.

The IFS test was written with the following design goals:

  • Subsystem independence. The tests take place in the NT Native Call API (the user-mode Ntdll.dll), which provides subsystem independence. The Microsoft Win32 API is a 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, you can reasonably assume that other subsystems are working properly.

  • Synthetic operation distinction. Several Win32 file system operations rely on a sequence of NT native call APIs being run. These APIs are identified to be the first type of synthetic file system operations. The testing approach 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 that is satisfied by 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 to not include synthetic operation testing directly in the Compliance test. First, you would be testing a lot of the Win32 user-mode code, kernel-mode I/O manager code, or object manager code. These items are key system paths that are well tested and that you do not need to retest. Second, if a synthetic operation fails because of a file system problem, there is no easy description of the failure without also a description of Win32 or NT internal calls. In addition, if unexpected results do occur in the core operating system components, you 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 code sample. You can use the IFS test to test portions of your driver before the entire file system driver (FSD) is complete. You can test portions of a driver under development by separating the IFS test into groups, which include the relevant set of individual tests. This independence permits you to test specific portions of the new FSD without the interaction from other untested or unimplemented functions.

  • Asynchronous and synchronous testingMost of the I/O operations can be performed both asynchronously and synchronously. The calling user-mode thread might block in kernel mode when it is waiting for a synchronous operation to finish. The same user-mode thread might be able to continue running while an asynchronous operation is completed by a system or worker thread in kernel mode. You must 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 enables you to test different aspects of a file system and determine which operation causes a failure. You 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 that indicates 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 type of testing 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 directly call into the FSD through these two interfaces. The level of control in the native calls enables you to test for specific operations on the file system, enabling fault identification. The native calls also make the test extensible because new calls can replace outdated calls, and you can add additional calls 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 you must address all IRPs and fast I/O paths for complete coverage. Note that all native calls that use the file system interface were considered.

  • Extensible. You can add to the IFS test when new capabilities are added to the file system model. The grouping of tests lends itself to this capability. You can add and remove individual tests from the groups without affecting surrounding tests. You can also check backward compatibility 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. You can use the tests as your 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. You can use the IFS test to verify the transparency and coexistence properties of filters and determine if a filter is negatively affecting a Windows NT system.

Details

The following list contains all of the file system test groups in the IFS test:

  • OpenCreateGeneral

  • OpenCreateParameters

  • CloseCleanupDelete

  • VolumeInformation

  • FileInformation

  • EaInformation

  • DirectoryInformation

  • FileLocking

  • OpLocks

  • ChangeNotification

  • DeviceControl

  • FileSystemControlVolume

  • FileSystemControlGeneral

  • ReadWrite

  • SectionsCaching

  • Security

  • ObjectID

  • MountPoints

  • ReparsePoints

  • SparseFiles

  • ExtendedSecurity

  • ForcedDismount

  • Encryption

  • Quotas File

  • LinkTracking

  • ChangeJournal

  • StreamEnhancements

  • DefragEnhancements

The following sections describe each group in more 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 call 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 that is obtained from 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, the create file function should return an error (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 that is 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 that is 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. You can obtain the Unicode on disk volume attribute flag 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 by 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. You can obtain the case sensitive search volume attribute flag 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 differentiation 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. You can obtain the case preserved names volume attribute flag 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 preservation 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 name 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. You can create the 8.3 representation when extended characters are used in the file name. You can use this short name representation 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. You can specify the share access of a handle 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. You can open or create the alternate streams 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 setting 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 Microsoft 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 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 call should fail.

    The directory is then created with a call to the create file function by 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 by 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. You can access files by going through the handle of an open directory. This type of access 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 preceding 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. You can open or create directories relative to an open directory. This type of access 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 preceding 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. You can query the unique and persistent identifier for a file. This identifier can be used to open the file on supported file systems. A test file is created in the TESTVOL\TESTROOT path. The query information file function is called to obtain the unique index value. The 8 bytes are passed into a call to the create file function in place of the 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. You can specify the nondirectory file option flag 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 operation 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 operation 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 support allows for opening the "\DosDevices\?: volume device; where ?: is the name of the drive letter that is mapped to the volume that is 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. Because 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 that are 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 you use the file create function 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 you use the file create function 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 that are specified in the call to the file create function must match the attributes that are 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 that are specified in the call to the file create function must match the attributes that are 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. You can set the attributes of a file when the file is created. If the read-only attribute is set on a file, you can open the file 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. You can set 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 that are specified in the call to the file create function must match the attributes that are currently set on the existing file. New attributes are combined with a bitwise OR 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 that is 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 that is 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 that is 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 test 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, and 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 file system should set the attribute 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 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 that is 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 might differ from the information that is read through the open directory handle. The information is updated when the last open handle to the file object is closed. This action sends out 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 the updated (but not committed) information is changed by using 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 that is 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 might 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 through 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 closure sends out IRP_MJ_CLEANUP.

    This test first creates a number of subdirectories, verifies the file information through 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 IRP corresponds to the 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 a Microsoft MS-DOS or Microsoft 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 problem. The cache is process-specific and directory-specific. When a file is deleted and created again by 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 or 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 might 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, the test attempts 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 attempt 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 of 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 of 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. This size 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 of 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 file. A query is then performed to obtain the allocation size, which is expected to be a multiple of 512. If this query passes, 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 query 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 query returns information about the compression that is 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. This test checks the original size of the file when it was created, 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 of 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 can 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 rename 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, 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 by 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 of the open handles are 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 of 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 are obtained at creation time. If all values are correct, 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 that is 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 end-of-file pointer 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 (this type of file open might 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 size is the size of the extended attribute information that is 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 name 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 that is used for this test has three extended attributes, each with 4 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 that are 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 that is used for this test has three EAs, each with 4 bytes of data. This file is opened with access privilege that permits its EA data to be read. A query list with a label to just the second entry is created and a query is performed on just the second EA entry. The data that is 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 that is 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 that is used for this test has three Extended Attributes (EA), each with 4 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 that are 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 that is used for this test has one EA with 4 bytes of data associated with it. This file is opened with access privilege that permits its EA data to be read. The file is then queried for its EA data. If the query is successful, 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, because this file has no EA data the EA size is expected to be zero. Next, there are two EAs, 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 EA 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 EA with 4 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 4 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 that is used for this test has three EAs, each with 4bytes 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 that are 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, 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

The tests in this group include:

  • LockSharedExTest. This test 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 attempt 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 that A holds 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 immediately if a lock is currently held on the region of the file. This failure 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 time out, 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 a Level 1I oplock is always backed by a real user handle, a batch oplock can 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.
    • C opens a test file for reading.
    • C requests a batch oplock on the file by using the FSCTL_REQUEST_BATCH_OPLOCK file control.
    • C should succeed at reading the file.
    • D opens the test file for reading and writing, but this action should be blocked because a break is pending.
    • 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.
    • 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.
    • C opens a test file for reading and writing.
    • C requests a Level I oplock on the file using the FSCTL_REQUEST_OPLOCK_LEVEL_I file control.
    • The file should be written to and read from by C, this should succeed
    • 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.
    • The IRP from step 2 should complete.
    • The FSCTL_OPLOCK_BREAK_NOTIFY control should be sent. This IRP should be queued since there is a break in progress.
    • C issues the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE control. This will acknowledge the break to a level II lock.
    • The IRP from step 6 should now complete indicating that there is now no break in progress.
    • C and D close the file.

  • FilterOplockTest. There is currently no description for this test.

  • CompleteImmediatelyTest. Normally an open to a file that has an oplock 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 option 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 1 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 test should be called the OplockWriteBreakIItoNone test. The only major IRP type that will cause a break is IRP_MJ_WRITE. 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 test tests that Level 1 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 1 oplock on the file with the FSCTL_REQUEST_OPLOCK_LEVEL_I file control. This request should fail with STATUS_OPLOCK_NOT_GRANTED because 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 break occurs because when this request is issued by a client, there are changes to critical information that logically invalidate the oplock. These include the following types of Set Information:

    1. FileEndOfFileInformation
    2. FileAllocationInformation
    3. FileRenameInformation
    4. FileLinkInformation

    The first two classes in the preceding list will break any oplock to none, while the latter two will break only batch oplocks 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 that are 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 (the 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, which indicates that the oplock has been granted.
    2. The file should read from by C; this read should succeed.
    3. Process D attempts to lock a range of the file by using the NtLockFile routine. This thread (of Process D) should block.
    4. The IRP that is 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 because 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 can 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 request 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, which indicates 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 operation should succeed. The oplock should not break.
    6. D opens the test file for reading and writing; this operation should block. This iblock occurs because the client that is 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 control will acknowledge the break to a Level II lock. This FSCTL returns STATUS_PENDING.
    9. The blocked that is 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 break can occur only 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 because subsequent opens with the write ability will cause the oplock to break on open. This test simply tests 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 operation should succeed.
    4. D opens the test file for reading only; this operation should block because the client that is holding a Level I oplock must be notified of the 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 to 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 reads will not be cached reads because 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 attempt 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 operation 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 operation should not block because 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 operation should succeed.
    9. D closes the file.
    10. The IRP from step 7 should complete to indicate that 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 ability enables 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 by using the FSCTL_REQUEST_OPLOCK_LEVEL_II control operation.
    3. The file should be read from by C; this operation should succeed.
    4. D opens a test file for reading and writing.
    5. D requests a Level II oplock on the file by 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; and if the write does not occur, a time-out 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 that the original DACL is reset to allow the test file to be deleted during cleanup. All notification events should complete.

  • NotificationCleanupFileSizeTest. This tests that 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 time-out 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 time-out 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 on, 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. These changes include 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 does not 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 once 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 does not happen, an error has occurred. This test is repeated but this time a file handle is supplied to the notification function; this operation 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 on for 4 seconds, ;if the notification does not 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 Group

The tests in this group include:

  • 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 that is 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 by 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 dismount 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, the volume will attach to the NTFS driver. The test for dismounting involves being able to see a mount request to the volume. That visibility is necessary because the first reference to the volume after it is dismounted will typically mount the volume back up. The mounting can be observed by the File System Control. Note that the volume can be dismounted ionly 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 operation should fail with an access-denied error, but this open attempt will remount the volume. So a dismount is issued again to the test volume and this dismount 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 be locked only if there are no other open handles on the volume. This test will have to be performed on a non-system containing volume. Second, a volume is locked then unlocked by 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 operation should fail because there is an open file handle. If this operation 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 tested is the flushing of the cache before the volume is locked. This flushing is done by getting the volume statistics (specifically the read/write counters). Then, the test opens up a couple of files on the test volume and performs 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 lock 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 ControlLockVolumeTest.

  • VolumeMountedTest. The File System Control checks to see if a volume is mounted. This check 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 checks if the volume is mounted is issued. For NTFS, this check should come back with a success; but on FAT volumes, this check will return the wrong volume error.

  • MountedDirtyTest. This File System Control marks a volume as permanently dirty. This operation is done when there has been a corruption detected in the metadata. 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 restart is performed and the Chkdsk program gets initiated.

  • InvalidateVolumesTest. The File System control that invalidates volumes will search for all of the volumes that are mounted on the same real device and mark them all bad. This marking prevents their further use in the system, because the only operations that can be done on such handles are 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 invalid handle error. 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 that are modified with new file sizes. A success will be returned when the handles to the opened files are used to access untouched files. The invalid file error will be returned when the handles to the files, which had modified file sizes, are used to access the files.

  • ControlLockVolumeFlushTest. This test 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 test is used only 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 by 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 control should uncompress the file. The file size is checked to make sure that it is the same as it was before 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 and 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 is incremented by known increments.

  • PathNameValidTest. This test is supported only on Fat Compatible Volumes. This File System Control checks a path for valid characters, leading backslashes, and for wildcards. It passes the string to the file system to check. This check entirely depends on the syntax of the file system path. A volume handle is opened and two test path are checked. The first path is a valid path and the second path checked is an invalid path.

  • 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 MB) is written to the file. The bitmap is again obtained. The allocated clusters count should increase by the amount that is necessary for the new file.

  • MoveFileTest. The File System Control move file information class will move the logical clusters that a file uses to new logical clusters on the volume. A file is created and written with a known data pattern. The initial retrieval pointers are queried by using FSCTL_GET_RETRIEVAL_POINTERS. Next, the file's clusters are moved by 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 or write beyond the end of the volume. A test volume is opened and a read is performed starting at the very end of the volume. This read is expected to return 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, reading at the very end of the volume; this read should return with success.

ReadWrite File System Test Group

The tests in this group include:

  • ReadWriteTest. This test will test the reading from and writing to files that the file system manages. First, a synchronous file handle is opened to the test file and a buffer that is 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 that is 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 write operation 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. Finally, 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 that is 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 by using the non-caching handle; this data is read back and checked by using the caching handle. Second, some data is written out to the file by using the caching handle; this data is read back and checked by using the non-caching handle. The data that is 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 statistics 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 statistics 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 test appends 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 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 action as a seek before the read. To test this equivalence, 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 I/O operation is specified with a zero-byte length, the file offset should not be updated. In addition, zero length extending or beyond the end of the file (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 zero-byte length. The new current file offset is recorded and checked to ensure that it did not 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 I/O 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 that are 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 that are read is verified. This test is repeated for the write operation. When the test writes with an offset near the end-of-file and specifies 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 I/O. If an operation cannot proceed immediately, the calls can 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 on for completion.

  • APCSynchRWTest. The read and write functions can perform asynchronous I/O by using asynchronous procedure calls (APCs). 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 I/O completes. A test file is opened with an asynchronous file handle. A write operation is performed on the test file, with an APC routine specified for the write. The APC routine will set the event when the write completes. This completion is waited on 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 Windows NT set function or by writing beyond the end of the file, the contents of the file are cleared for security purposes.

    First, a test file is opened with caching enabled. The Windows NT set function is used to set the end-of-file pointer to a value that is 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 bthat is eyond 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 zeros.
    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 that is larger than the current end-of-file. The Set Information File call should succeed.
    5. Another view is created on the extended region.
    6. The file contents are read. The extended region's view should contain all zeros. The original region should have valid data.

  • FlushBuffersTest. This tests involves IRP_MJ_FLUSH_BUFFERS 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, and the last write time should be updated from the flush.

  • FlushBuffersRootTest. This test involves IRP_MJ_FLUSH_BUFFERS 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, and the last write time should be updated on all files, from the flush.

  • FlushBuffersVolumeTest. This test involves IRP_MJ_FLUSH_BUFFERS 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 or 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 zero-share access (nothing is shared).
    6. Some data is written to the opened test file.
    7. The written data is verified to exist 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 that contains 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 file is opened for reading.
    2. A new file is created with write access (and with a file name of "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 Microsoft 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. The open should fail with STATUS_USER_MAPPED_FILE.
    4. The test file is again opened with a call to NtCreateFile(). The FILE_SUPERSEDE disposition is specified. 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 that is smaller than the current end-of-file.
    5. The Set Information File call should return the STATUS_USER_MAPPED_FILE error.
    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 that is being tested is NTFS and that a test user is created with Users rights. This test user is specified at the command line when the test is running with the /u option. The password for this user must be the same as the user name (that is, if the username is HollyHolt, the password must be HollyHolt). 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 that is used in this test and ownership will belong to the test user. Next, the test file is opened by the current user (the user that is 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 allow only 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 that is 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 SID is compared to the Group SID that it was set to.

  • SetSaclSecurityTest. This test requires the file system that is being tested is NTFS. First, the Security Privilege is enabled to access the SACL. A SACL list allows you to audit operations that are performed on a file. The test file is opened and the SACL list is set to audit all Read operations that are performed on the test file. Next, the file is opened again and queried for its SACL information. This information 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 that is being tested is NTFS. First, the Security Privilege is enabled 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 on close. After 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 that is being tested is NTFS. First, the Security Privilege is enabled 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 the event is in the log, the test is passed and the original DACL information is reset.

  • AuditOwnerSecurityTest. This test requires that the file system that is 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 (that is, if the username is HollyHolt, the password must be HollyHolt). 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 that is used in this test and ownership will belong to the test user. Next, the Security Privilege is enabled 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 change in ownership should set an event in the Event Log. The Event Log is searched for this event, and if present, the test is passed.

  • DirectoryTraverseTest. The default installation of Microsoft Windows enables Bypass Traverse Checking for all users on the system. This feature 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 that is being tested is NTFS and that a test user is created with Users rights. There are three directories in this test (the second directory is a subdirectory of the first and the third directory is a subdirectory of the second). The first directory is opened and the DACL is changed so that only administrators can perform operation on it; the same is done with the second directory. Next, a second thread is initiated that will log on the test user and try to create a file in the first directory; this attempt should fail. The same is repeated with the second directory. This attempt is repeated on the third 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 identifiers (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 can be opened by its Object ID and its path name.

The following tests are part of this group:

  • GetObjectIDVolumeTest. The NtQueryVolumeInformationFile function with the 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 function with the FileNameInformation class can be used to retrieve the full path of a file or directory through Object IDs. This ability 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 function with FILE_OPEN_BY_FILE_ID can be used to open a file or directory by Object ID. Similar to the semi-unique 64-bit 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 by using the NtNotifyChangeDirectoryFile function. 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. FSCTL_SET_OBJECT_ID_EXTENDED is used to set the extended information portion of a file or directory's Object ID. This ability is verified by using 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 that the user that is attempting the operation has BACKUP/RESTORE privileges on the system. The 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 situation 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 function 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 that was just deleted, the renamed file will have an object ID. In this situation, 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 by 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 uniqueness 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 uniqueness 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 by 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 control code can be used to return the existing Object ID or generate a new Object ID for the file or directory. This situation 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 by 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 by using FSCTL_DELETE_OBJECT_ID, provided the handle is opened with RESTORE intent and WRITE access. This situation 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 or WRITE access. The operation should fail with STATUS_ACCESS_DENIED. Then, the operation is repeated with a handle that is 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 by 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 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. FSCTL_GET_OBJECT_ID and FILE_OBJECTID_BUFFER can be used to retrieve a file or directory's Object ID. This situation 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 Microsoft Win32 CreateDirectoryEx call. The target directory contains a subdirectory and a file. The test verifies access to these items through the copied reparse point.

  • CreateDirectoryExVolumeTest. The purpose of this test is to create a volume mount point and then copy the directory that contains the point. A special Win32 CreateDirectoryEx call 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. The test verifies access to these items through the reparse point.

  • 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 by 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 and greater, this situation 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 and greater, this situation 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 the NtQueryDirectoryFile function 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 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 that is 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 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 that 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 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 function. This operation is expected to fail with STATUS_INVALID_USER_BUFFER on NTFS5-compatible file systems.

  • GetPointInvalidParamTest. This test validates the behavior of 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 function. The operation is expected to fail with STATUS_INVALID_PARAMETER n NTFS5-compatible file systems.

  • SetPointInvalidBufferSizeTest. This test validates the behavior of 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 function. The operation is expected to fail with STATUS_INVALID_BUFFER_SIZE on NTFS5-compatible file systems.

  • SetPointInvalidParamTest. This test validates the behavior of 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 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 that is less than REPARSE_DATA_BUFFER_HEADER_SIZE, an input buffer length argument that is greater than MAX_REPARSE_DATA_BUFFER_SIZE, an input buffer length argument that is different than the reparse data buffer length, or a GUID that is 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 by using NtQueryFullAttributesFile function, 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 function is used with the FileAttributeTagInformation class. This operation is expected to succeed on NTFS5-compatible file systems.

  • SetPointIoReparseTagInvalidTest. This test validates the behavior of 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 that is 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 the NtDeleteFile function. 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 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 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_REPARSE_ATTRIBUTE_CONFLICT status code.

  • DelPointInvalidBufferSizeTest. This test validates the behavior of 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 function. The operation is expected to fail with STATUS_INVALID_BUFFER_SIZE on NTFS5-compatible file systems.

  • DelPointIoReparseDataInvalidTest. This test validates the behavior of 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 that is greater than REPARSE_DATA_BUFFER_HEADER_SIZE, an input buffer data length argument that is different than zero, or a buffer size argument that is 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 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 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 that is 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 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 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 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 FSCTL_MOVE_FILE call 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 because the area takes no allocation. The attempt is then made over a sparse and nonsparse range. This operation 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 ability. 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 change 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 change 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 by 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 Group

  • 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 that a specified SID owns. The FIND_BY_SID_DATA structure is used as input buffer to specify the SID. An output buffer that is aligned on a FILE_NAME_INFORMATION structure boundary is used to return the found files.

ForcedDismount File System Test Group

  • ForceDismountTest. The purpose of this test is to verify that, in Microsoft Windows 2000 and greater, 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 can mark a directory or file as encrypted. A file so marked is encrypted by NTFS by using the current encryption driver. If the file is later marked as not encrypted, it is decrypted and left in a plain text (not encrypted, but still protected by the Windows 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 that indicates 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 function 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 by using OpenEncryptedFileRaw, ReadEncryptedFileRaw, WriteEncryptedFileRaw, and CloseEncryptedFileRaw. These function are used in off-line recovery. The operations are tested by encrypting a file and 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 retrieval 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 retrieval 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 retrieval 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 or 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 and greater, 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 and greater, 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 scenario 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 action 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 function with the FILE_ATTRIBUTE_ENCRYPTED flag specified. A new file cthat is reated 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 function with the FILE_ATTRIBUTE_ENCRYPTED flag specified. A new directory that is 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 function 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 share 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 two 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 enforcement uses the FILE_VC_QUOTA_ENFORCE flag with NtSetVolumeInformation and 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 situation 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 to enable disk quota tracking, where quota usage changes are tracked but no quota enforcement is done. This situation 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 situation is applied with NtSetVolumeInformation and 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 situation is applied with NtSetVolumeInformation and 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 situation is applied with NtSetVolumeInformation and 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 situation is applied with NtSetVolumeInformation and 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 situation is tested by creating files and directories with and without Object IDs. The files and 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 by 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 by 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 that 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 that it is 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 control code 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, and 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 by using NtQueryInformationFile with the FileStreamInformation class.

  • StreamRenameTest. Streams can now be opened and renamed with 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 FILE_NOTIFY_CHANGE_STREAM_NAME and FILE_ACTION_ADDED_STREAM pair is observed when streams are added to a file. The FILE_NOTIFY_CHANGE_STREAM_NAME and FILE_ACTION_REMOVED_STREAM pair are added when a file that contains 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

The tests in this group are:

  • MoveDirTest. Directories can now be de-fragmented by using FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_MOVE_FILE. This test creates many files in a directory. Then, the retrieval pointers are obtained by using a directory handle. The clusters are then moved by using the directory handle, the retrieval pointers, and a volume handle.

  • MoveViewTest. System view (security, quota, reparse, and object ID) directories can now be de-fragmented by 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 by using the directory handle, the retrieval pointers, and a volume handle.

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

    Hardware Requirements

    The test tool requires the following hardware:

    • 1 NTFS formatted volume of at least 2 Gigabytes in size
    • 1 NTFS formatted volume with compression enabled of at least 2 Gigabytes in size
    • 1 FAT16 formatted volume of 2000 Megabytes in size
    • 1 FAT32 formatted volume of at least 2 Gigabytes in size

    Processor

    The test tool runs on the following processor architectures:

      Running IFS Test

      You must create formatted volumes as follows:

      • 1 NTFS formatted volume of at least 2 GB in size

      • 1 NTFS formatted volume with compression enabled of at least 2 GB in size

      • 1 FAT16 formatted volume of 2,000 MB in size

      • 1 FAT32 formatted volume of at least 2 GB in size

      You can create these volumes by using the disk management user interface.

      You must also add the machine to a WORKGROUP and have the Administrator autologon set up. (The test will automatically set up the correct registry keys, users and groups, and privileges but will require a restart; so you must set up autologon before starting the test.)

      To run the test, select the "Installable File System Filter Tests" job in Driver Test Manager (DTM) Studio and schedule it. Modify the parameters to include the appropriate drive letters for each file system type. If you specify NONE for a drive letter, the test will not run for that particular drive type.

      Code Tour

      File Manifest

      File | Location
* | [testbinroot]\nttest\basetest\core_file_services\ifstestkit

      Test Assertions

      Anti Virus filter driver does not alter file system behavior.

      Test Assertion GUID: A72C4D26-977B-19CB-2E11-D6F93917D718


iSCSI Boot

Type: Automated Test

Overview

The iSCSI Boot 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 performs the following algorithm:

  1. Determine the current system boot drive.

  2. Retrieve the currently active iSCSI sessions on the system by using the ISCSI_SessionStaticInfo Microsoft Windows Management Instrumentation (WMI) class.

  3. For every active iSCSI session that is found, do the following:
    • Check the Type field of the session class to determine if it is a boot session.
    • If the iSCSI session is a boot session, determine the drive letter that is associated with that session.
    • If the associated drive letter matches the system boot drive letter, start up from the iSCSI device.

System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

    Hardware Requirements

    The test tool requires the following hardware:

      Processor

      The test tool runs on the following processor architectures:

        Running iSCSI Boot

        1. Install the operating system on a target disk device.

        2. Run the test as a DTM job from the Device Console window.

        3. Enter the required data in the configuration dialog box that appears when this job is scheduled.

        Command Syntax

        Command option | Description
iscsi_boot_test |

        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)

        Code Tour

        File Manifest

        File | Location
iscsi_boot_test.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

        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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
        Additional Information: The iSCSI Boot test validates that at least one active iSCSI session has been established on the system. The test expects 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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
        Additional Information: The iSCSI Boot test validates that only one active iSCSI session has the boot flag set. The test expects only one active iSCSI session has the boot flag set The iSCSI Boot test validates that the system was started up through the volume that is associated with the iSCSI session that is marked as bootable. The test expects the system was booted through the volume that is associated with the iSCSI session that is marked as bootable
        The HBA is not required to support boot.
        Test Assertion GUID: e78bca89-977c-47bd-981a-4aa2303344f4
        Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements


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 (ibftestwrap.exe) and a kernel-mode binary (ibftest.sys). Both binaries are required for the test to run successfully.

  1. ibftestwrap.exe loads ibftest.sys into kernel mode.

  2. ibftest.sys checks if iBFT exists in memory.

  3. If iBFT exists in memory, ibftest.sys will get a copy of the table.

  4. ibftest.sys validates the table and returns results to ibftestwrap.exe.

  5. ibftestwrap.exe in turn provides a friendly log.

  6. 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.

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Server 2003

Program:

Requirements

Software Requirements

The test tool requires the following software:

    Hardware Requirements

    The test tool requires the following hardware:

      Processor

      The test tool runs on the following processor architectures:

        Running iSCSI Boot Firmware Table Test

        1. Copy iBFTest binaries: (Or make sure iBFTest is available within DTM)
          1. Copy ibftestwrap.exe to test working directory.
          2. Copy ibftest.sys to test working directory.

        2. Run ibftestwrap.exe

        Command Syntax

        Command option | Description
ibftestwrap.exe |

        Code Tour

        File Manifest

        File | Location
ibftestwrap.exe | [WTT\TestBinRoot]\nttest\DriversTest\storage\wdk\ibftest
ibftest.sys | [WTT\TestBinRoot]\nttest\DriversTest\storage\wdk\ibftest

        Test Assertions

        LoadDriver System must load iSCSI Boot Firmware table driver.
        Test Assertion GUID: 1d22e647-c438-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0007 Device storage special features meet industry standards and Windows requirements
        UnLoadDriver System must unload iSCSI Boot Firmware table driver.
        Test Assertion GUID: 1d22e648-c438-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0007 Device storage special features meet industry standards and Windows requirements
        GetIBFInfo System must implement a iSCSI Boot Firmware table.
        Test Assertion GUID: 1d22e649-c438-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0007 Device storage special features meet industry standards and Windows requirements
        System must expose iSCSI Boot Firmware Table.
        Test Assertion GUID: 1d22e64a-c438-11da-94f4-00123f3a6b60
        Windows Logo Program: STORAGE-0007 Device storage special features meet industry standards and Windows requirements


iSCSI Digest - Disk (HBA)

Type: Automated Test

Overview

The iSCSI Digest - Disk (HBA) test verifies that the host-bus adapter (HBA) supports header and data digests as negotiated during the log on phase.

Details

The iSCSI Digest - Disk (HBA) test performs the following algorithm:

  1. Prepare the system for iSCSI operations:
    1. If the target that is used for testing is already logged on, the session information is saved so the session can be restored later.
    2. The target disk device is added as a static iSCSI target.
  2. Perform iSCSI operations:
    1. If the target that is used for testing is already logged on, the current session to the target is logged out.
    2. The target is logged on by using the HBA that you are testing with header digests enabled.
    3. After logging on to the target, the test waits for all disk devices to be enumerated on the test system.
    4. The test will perform I/O read and write operations with the current target session.
    5. The test repeats the preceding steps with data digests only enabled and header and data digests enabled.
    6. The HBA under test must properly log on by using all three digest combinations with no I/O failures detected during I/O operations.

  3. Restore any previous iSCSI target sessions.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On Windows XP and Windows Server 2003, the latest version of the Microsoft iSCSI software initiator is needed.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • iSCSI disk storage system or iSCSI bridge with disk storage system attached

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running iSCSI Digest - Disk (HBA)

  1. Log on to the disk target and format the drive. The disk target should have a drive letter before you run the test.

  2. Run the test as DTM job from the Device Console window.

  3. Enter the required data in the configuration dialog box that appears when this job is scheduled.

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 box when the job is scheduled from Device Console.

Code Tour

File Manifest

File | Location
iscsi_digest.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Test Assertions

1.1 Setting up test, and saving open sessions.
Test Assertion GUID: 0df19e9d-c42e-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
Additional Information: The setup stage must get the current sessions to the target and then persist 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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
3.1 The HBA must successfully logout from target.
Test Assertion GUID: 7f102026-c42e-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
4.1 Cleaning up test, restoring sessions.
Test Assertion GUID: 7f102028-c42e-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
Additional Information: The cleanup stage must restore the sessions that were persisted during the setup stage.


iSCSI Digest - Disk (Target)

Type: Automated Test

Overview

The iSCSI Digest - Disk (Target) 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 performs the following algorithm:

  1. Prepare the system for iSCSI operations:
    1. If the target that you are testing is already logged on, the session information is saved so the session can be restored later.
    2. The target disk device is added as a static iSCSI target.
  2. Perform iSCSI operations:
    1. If the target that you are testing is already logged on, the current session to the target is logged out.
    2. The target is logged on with header digests enabled.
    3. After logging on to the target, the test waits for all disk devices to be enumerated on the test system.
    4. The test will perform I/O read and write operations with the current target session.
    5. The test repeats the preceding steps with data digest only enabled and header and data digests enabled.
    6. The target that you are testing must permit logon by using all three digest combinations and no I/O failures can be detected during I/O operations.

  3. Restore any previous iSCSI target sessions.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On Windows XP and Windows Server 2003, the latest version of the Microsoft iSCSI software initiator is needed.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running iSCSI Digest - Disk (Target)

  1. Log on to the disk target and format the drive. The disk target should have a drive letter before you run the test.

  2. Run the test as DTM job from the Device Console window.

  3. Enter the required data in the configuration dialog box that appears when this job is scheduled.

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 box when the job is scheduled from Device Console.

Code Tour

File Manifest

File | Location
iscsi_digest.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Test Assertions

1.1 Setting up test, and saving open sessions.
Test Assertion GUID: 0df19e9d-c42e-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Additional Information: The setup stage must get the current sessions to the target and then persist 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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
4.1 Cleaning up test, restoring sessions.
Test Assertion GUID: 7f102028-c42e-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Additional Information: The cleanup stage must restore the sessions that were persisted during the setup stage.


iSCSI Digest - Tape (HBA)

Type: Automated Test

Overview

The iSCSI Digest - Tape (HBA) 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 completes the following steps:

  1. Prepare the system for iSCSI operations:
    • If the target that is 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. Perform iSCSI operations:
    • If the target that is used for testing is already logged on, the current session to the target is logged out.
    • The target is logged on by 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 b using the current target session.
    • The test repeats the preceding steps with data digests-only enabled and header and data digests enabled.
    • The HBA under test must properly log on by using all three digest combinations with no I/O failures detected during I/O operations.

  3. Restore any previous iSCSI target sessions.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On Windows XP and Windows Server 2003, you need the latest version of the Microsoft iSCSI software initiator.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Combination iSCSI tape and media changer device or iSCSI bridge with combination tape and media changer device attached

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running iSCSI Digest - Tape (HBA)

To run this test, do the following:

  1. Log on to the tape target and format the target.

  2. Run the test as a Driver Test Manager (DTM) job.

  3. Enter the required data in the configuration dialog box that appears when this job is scheduled.

Troubleshooting

  1. Look at the job results log file for test failures.

  2. Verify that the iSCSI configuration information is entered correctly in the configuration dialog box when the job is scheduled from the Device Console window.

Code Tour

File Manifest

File | Location
iscsi_digest.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Test Assertions

1.1 Setting up test, and saving open sessions.
Test Assertion GUID: 0df19e9d-c42e-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
Additional Information: The setup stage must get the current sessions to the target and then persist 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-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
3.1 The HBA must successfully logout from target.
Test Assertion GUID: 7f102026-c42e-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
4.1 Cleaning up test, restoring sessions.
Test Assertion GUID: 7f102028-c42e-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
Additional Information: The cleanup stage must restore the sessions that were persisted during the setup stage.


iSCSI Digest - Tape (Target)

Type: Automated Test

Overview

The iSCSI Digest - Tape (Target) 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 performs the following algorithm:

  1. Prepare the system for iSCSI operations:
    1. If the target that you are testing is already logged on, the session information is saved so the session can be restored later.
    2. The target tape device is added as a static iSCSI target.
  2. Perform iSCSI operations:
    1. If target that you are testing is already logged on, the current session to the target is logged out.
    2. The target is logged on by using the Microsoft iSCSI Initiator with header digests enabled.
    3. After logging on to the target, the test waits for the tape device to be enumerated by the test system.
    4. The test will perform tape I/O operations by using the current target session.
    5. The test repeats the preceding steps with data digests only enabled and header and data digests enabled.
    6. The target under test must permit logon by using all three digest combinations and no I/O failures can be detected during I/O operations.

  3. Restore any previous iSCSI target sessions.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On Windows XP and Windows Server 2003, you need the latest version of the Microsoft iSCSI software initiator.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running iSCSI Digest - Tape (Target)

  1. Log on to the tape target and format the target.

  2. Run the test as a DTM job.

  3. Enter the required data in the configuration dialog box that appears when this job is scheduled.

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 box when the job is scheduled from Device Console.

Code Tour

File Manifest

File | Location
iscsi_digest.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Test Assertions

1.1 Setting up test, and saving open sessions.
Test Assertion GUID: 0df19e9d-c42e-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Additional Information: The setup stage must get the current sessions to the target and then persist 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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
4.1 Cleaning up test, restoring sessions.
Test Assertion GUID: 7f102028-c42e-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Additional Information: The cleanup stage must restore the sessions that were persisted during the setup stage.


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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On Windows XP and Windows Server 2003, you need the latest version of the Microsoft iSCSI software initiator.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • 1 GB network adapter

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

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 |

Troubleshooting

  1. Look at the job results log file for test failures.

  2. Verify that the iSCSI configuration information is entered correctly in the configuration dialog (A popup dialog box that appears when the job is scheduled from the device console)

Code Tour

File Manifest

File | Location
iscsi_initchap.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Test Assertions

1 Received PDU is a valid login request PDU.
Test Assertion GUID: ef76110a-c4c5-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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 operation code 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 negotiation stage as the current stage.
Test Assertion GUID: ef76110d-c4c5-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 because the 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 can 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 contain one and only CHAP_I key.
Test Assertion GUID: 03515b5c-c4c9-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 contain one and only CHAP_C key.
Test Assertion GUID: 03515b60-c4c9-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 can 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-0002 Storage host controllers and adapters comply with 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 non-encoded 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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.
The HBA is not required to support Mutual CHAP.
Test Assertion GUID: 0d3996be-65df-4063-a818-1258f8b4b3f1
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements


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 a 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 a one-way CHAP. The target verifies that the initiator follows the CHAP specifics that are 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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On Windows XP and Windows Server 2003, you need the latest version of the Microsoft iSCSI software initiator.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • 1-GB network adapter.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

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 |

Troubleshooting

  1. Look at the job results log file for test failures.

  2. Verify that the iSCSI configuration information is entered correctly in the configuration dialog box (a popup dialog box that appears when the job is scheduled from the device console).

Code Tour

File Manifest

File | Location
iscsi_initchap.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Test Assertions

1 Received PDU is a valid login request PDU.
Test Assertion GUID: ef76110a-c4c5-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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 operation code 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 negotiation stage as the current stage.
Test Assertion GUID: ef76110d-c4c5-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 because required key = value pairs for the initial logon request are present.
102 The initial login request must contain only one TargetName key.
Test Assertion GUID: ef76111c-c4c5-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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 target name 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-0002 Storage host controllers and adapters comply with 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 only one InitiatorName key.
Test Assertion GUID: ef76111e-c4c5-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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 should specify only one SessionType key, if any, when performing a full login.
Test Assertion GUID: ef76111f-c4c5-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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 non-discovery 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-0002 Storage host controllers and adapters comply with 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 only one AuthMethod key.
Test Assertion GUID: ef761121-c4c5-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 can include only 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-0002 Storage host controllers and adapters comply with 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 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-0002 Storage host controllers and adapters comply with 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 only one CHAP_A key.
Test Assertion GUID: 03515b59-c4c9-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 only one value that specifies MD5.
Test Assertion GUID: 03515b5b-c4c9-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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, 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 routine. 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-0002 Storage host controllers and adapters comply with 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 only one CHAP_N key.
Test Assertion GUID: 03515b64-c4c9-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 only one CHAP_R key.
Test Assertion GUID: 03515b66-c4c9-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 can contain only 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-0002 Storage host controllers and adapters comply with 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 can be a binary value, for MD5, the required length exceeds the 8-byte limit for decimal encoded responses. Therefore, the encoding can 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 hexadecimal constant or as a base 64 constant.
308 The CHAP_R value must be 16 bytes in length (not encoded).
Test Assertion GUID: 03515b69-c4c9-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 contain only one CHAP_I key.
Test Assertion GUID: 03515b5c-c4c9-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 can be encoded as a decimal or a 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-0002 Storage host controllers and adapters comply with 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 contain only one CHAP_C key.
Test Assertion GUID: 03515b60-c4c9-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 HBA must maintain a connection to the test target during login.
Test Assertion GUID: ef761108-c4c5-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 terminates the logon process. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Upon completion of CHAP validation, the test target 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-0002 Storage host controllers and adapters comply with 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 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 iSCSI iSNS Compliance test verifies that the Microsoft initiator can log on to the device that you are testing by using the information that the target registers with the iSNS server. The test first clears all existing discovery information on the initiator and adds the iSNS server as the only discovery mechanism. The test then verifies that the device under test is found by 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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • For operating systems before Windows Vista, the latest version of the Microsoft iSCSI software initiator

  • For operating systems before Windows Vista, the latest version of the Microsoft iSNS server

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running iSCSI iSNS Compliance Test

  1. Before you run this test, you must register the device under test with the iSNS server.

  2. Run the test as a Driver Test Manager (DTM) job.

  3. Enter the required data in the configuration dialog box that appears 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

Test Assertions

Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements


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 logon similar to the user logging on through iSCSI Initiator Control Panel Applet. The rest of the variations perform logon outside of the Microsoft initiator by using the iSCSI protocol. Each variation challenges the target by using different challenge sizes with different encodings. The target is expected to calculate the proper response.

There are four different variations:

  • 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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On operating systems before Windows Vista, the latest version of the Microsoft iSCSI software initiator

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running iSCSI Mutual CHAP (Target)

To run this test, do the following:

  1. Set up up the initiator and the target with CHAP secrets.

  2. Run the test as a Driver Test Manager (DTM) job.

  3. Enter the required data in the configuration dialog box that appears when this job is scheduled.

Command Syntax

Command option | Description
iscsi_targetchap -mutual -hct |

Troubleshooting

  1. Look at the job results log file for test failures.

  2. Verify the data entered in the configuration dialog box when the job is scheduled from the Device Console window.

Code Tour

File Manifest

File | Location
iscsi_targetchap.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Test Assertions

0 Login using CHAP must succeed.
Test Assertion GUID: 5cfdfc45-c4fe-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
Additional Information: Test: The target can use only 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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.
The target is not required to support Mutual CHAP.
Test Assertion GUID: 98ec2ac5-28ff-441e-bce9-8ea5eeb660e5
Windows Logo Program: STORAGE-0001 Storage devices meet 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 logon similar to the user logging in through iSCSI Initiator Control Panel Applet. The rest of the variations perform logon outside of the Microsoft initiator by 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 logon or return the appropriate status code, depending on the response received.

There are four different variations:

  • 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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On operating systems before Windows Vista, the latest version of the Microsoft iSCSI software initiator

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running iSCSI Oneway CHAP (Target)

To run this test, do the following:

  1. Run the test as a Driver Test Manager (DTM) job.

  2. Enter the required data in the configuration dialog box that appears when this job is scheduled.

Command Syntax

Command option | Description
iscsi_targetchap -oneway -hct |

Troubleshooting

  1. Look at the job results log file for test failures.

  2. Verify the data entered in the configuration dialog box when the job is scheduled from the Device Cconsole window.

Code Tour

File Manifest

File | Location
iscsi_targetchap.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Test Assertions

0 Login using CHAP must succeed.
Test Assertion GUID: 5cfdfc45-c4fe-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
Additional Information: Test: The target can use only 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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.


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 that you are testing. 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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On operating systems before Windows Vista, the latest version of the Microsoft iSCSI software initiator

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running iSCSI Persistent Login Test

To run this test, do the following:

  1. Log on to the disk target and format the drive. The disk target should have a drive letter before you run the test.

  2. Run the test as a Driver Test Manager (DTM) job.

  3. Enter the required data in the configuration dialog box that appears when this job is scheduled.

Command Syntax

Command option | Description
iscsi_plogin -phase 1 -hct |

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 box when the job is scheduled from the Device Console window.

Code Tour

File Manifest

File | Location
iscsi_plogin.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Test Assertions

1.1 The Microsoft ISCSI Initiator service must be installed.
Test Assertion GUID: 77ac12a0-c4d9-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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.


iSCSI Ping Test (HBA)

Type: Manual 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 by 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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On operating systems before Windows Vista, the latest version of the Microsoft iSCSI software initiator

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running iSCSI Ping Test (HBA)

To run this test, do the following:

  1. Run the test as a Driver Test Manager (DTM) job.

  2. Enter the required data in the configuration dialog box that appears when this job is scheduled.

Command Syntax

Command option | Description
iscsi_pingtest -initiator -hct |

Troubleshooting

  1. Look at the job results log file for test failures.

  2. Verify the data entered in the configuration dialog box when the job is scheduled from the Device Console window.

Code Tour

File Manifest

File | Location
iscsi_pingtest.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 Ping Test (Target)

Type: Manual 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 by 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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On operating systems before Windows Vista, the latest version of the Microsoft iSCSI software initiator

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running iSCSI Ping Test (Target)

To run this test, do the following:

  1. Run the test as a Driver Test Manager (DTM) job.

  2. Enter the required data in the configuration dialog box that appears when this job is scheduled.

Command Syntax

Command option | Description
iscsi_pingtest -target -hct |

Troubleshooting

  1. Look at the job results log file for test failures.

  2. Verify the data entered in the configuration dialog box when the job is scheduled from the Device Console window.

Code Tour

File Manifest

File | Location
iscsi_pingtest.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

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-0001 Storage devices meet 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-0001 Storage devices meet 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 or port.

Details

This test implements a simple iSCSI target. The test performs a logon to this target by using the HBA under test. The target, when it receives the first logon packet, will redirect the HBA to connect to the target by using a different location.

The test has three different variations that use different redirection mechanisms:

  • 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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On operating systems before Windows Vista, the latest version of the Microsoft iSCSI software initiator

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running iSCSI Redirection Test

  1. Run the test as a Driver Test Manager (DTM) job.

  2. Enter the required data in the configuration dialog box that appears when this job is scheduled.

Command Syntax

Command option | Description
iscsi_redirect -hct |

Troubleshooting

  1. Look at the job results log file for test failures.

  2. Verify the data entered in the configuration dialog box when the job is scheduled from the Device Console window.

Code Tour

File Manifest

File | Location
iscsi_redirect.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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-0002 Storage host controllers and adapters comply with 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 WMI Verification

Type: Automated Test

Overview

The iSCSI WMI Verification test verifies that an iSCSI host-bus adapter (HBA) driver implements the required Microsoft Windows Management Instrumentation (WMI) interfaces. To qualify for the Windows logo, iSCSI HBA drivers must support the WMI classes that are documented in the iSCSI Driver Development Kit (DDK) version 1.0.

Details

The test enumerates all WMI classes that the HBA driver that you are testing exposes. 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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • On operating systems before Windows Vista, the latest version of the Microsoft iSCSI software initiator

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Running iSCSI WMI Verification

  1. Run the test as a Driver Test Manager (DTM) job.

  2. Enter the required data in the configuration dialog box that appears when this job is scheduled.

Command Syntax

Command option | Description
iscsiwmi.cmd |

Troubleshooting

  1. Look at the job results log file for test failures.

  2. Verify the data entered in the configuration dialog box when the job is scheduled from the Device Console window.

Code Tour

File Manifest

File | Location
iscsiwmi.cmd | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Test Assertions

iScsi WMI provider test
Test Assertion GUID: b17357d0-5f26-4071-8ced-56a135d46a92
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with 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.


Media Lock Test

Type: Manual Test

Overview

The Media Lock Test is a user-mode application that tests the functionality of locking mechanisms on SCSI-removable devices of type CD-ROM and direct access (for example, a Iomega Jaz or Zip drive). This test issues SCSI passthrough Prevent/Allow medium removal commands.

Details

This test verifies if the device supports the media lock command properly. The test locks the media by using the Prevent/Allow medium removal command and then verifies if the media is locked. This test is a manual test and needs manual intervention.

Run Time: 20 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • SCSI-removable devices

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running Media Lock Test

  • Run this test as a Driver Test Manager (DTM) job.

You will need to manually intervene for this test.

Command Syntax

Command option | Description
mlocktst.exe <drive> |

Code Tour

File Manifest

File | Location
mlocktst.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements

Device must report "Medium not present" when no media is loaded."
Test Assertion GUID: 8902c4c4-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements

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-0001 Storage devices meet industry standards and Windows requirements
Device must report disk geometry when issued IOCTL_DISK_GET_DRIVE_GEOMETRY"
Test Assertion GUID: 8902c4c6-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
Device must support a button\mechanism for ejecting media."
Test Assertion GUID: 8902c4c8-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device must transition to ready state within 45s after media is inserted."
Test Assertion GUID: 8902c4c9-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device must mount media after media is inserted."
Test Assertion GUID: 8902c4ca-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
Device must dismount media after media is ejected."
Test Assertion GUID: 8902c4cc-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device must properly implement front panel button."
Test Assertion GUID: 8902c4cd-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device must support the 'Prevent' command to lock the media."
Test Assertion GUID: 8902c4ce-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device must support the 'Prevent' command to unlock the media."
Test Assertion GUID: 8902c4cf-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device must support the 'Start stop unit' command to eject the media."
Test Assertion GUID: 8902c4d0-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
Media should remail accessible after a failed eject command."
Test Assertion GUID: 8902c4d4-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device must properly support Prevent/Allow and Start/Stop SCSI commands."
Test Assertion GUID: 8902c4d5-c50d-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements


Media Status Notification Test

Type: Manual Test

Overview

The Media Status Notification (MSN) specification v1.03 test contains two scenarios: one to test the ejectability of a device, and one to test the media status bits.

Details

If a device also supports the Removable Media Feature set, the test will check that Lock, Unlock, and Eject behave correctly with MSN enabled.

The test checks the media status bits. The test also 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 Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Removable drive with eject option

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running Media Status Notification Test

To run this test manually, you must insert and remove media in your device.

Command Syntax

Command option | Description
MEDIASN.EXE <drive> |

Code Tour

File Manifest

File | Location
mediasn.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
Media must remain available after user presses eject button.
Test Assertion GUID: 0ad01f16-c51a-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device must suppourt Get Media Status command.
Test Assertion GUID: 0ad01f17-c51a-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
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-0001 Storage devices meet industry standards and Windows requirements
Media Change Request bit should be asserted when eject button is pressed.
Test Assertion GUID: 0ad01f19-c51a-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
No media bit should be asserted when media is not present.
Test Assertion GUID: 0ad01f1a-c51a-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Write protect bit should be asserted when write-protected media present.
Test Assertion GUID: 0ad01f1b-c51a-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Media Change bit should be asserted when media is inserted.
Test Assertion GUID: 0ad01f1c-c51a-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Media Change bit should be cleared when Get Media Status is called.
Test Assertion GUID: 0ad01f1d-c51a-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device must properly implement Media Status Notification.
Test Assertion GUID: 0ad01f1e-c51a-11da-94f4-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements


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: 60 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Running MMC Test

Run the test as a DTM job.

Manual interaction is required for this test.

Command Syntax

Command option | Description
mmctest.exe |

Code Tour

File Manifest

File | Location
mmctest.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Test Assertions

Command Get Configuration
Test Assertion GUID: 5bd99e15-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Inquiry
Test Assertion GUID: 5bd99e16-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Test Unit Ready
Test Assertion GUID: 5bd99e17-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Mode Sense (10)
Test Assertion GUID: 5bd99e18-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Request Sense
Test Assertion GUID: 5bd99e19-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Get Event Status Notification
Test Assertion GUID: 5bd99e1a-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Mode Select
Test Assertion GUID: 5bd99e1b-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Prevent Allow Medium Removable
Test Assertion GUID: 5bd99e1c-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Mechanism Status
Test Assertion GUID: 5bd99e1d-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Start Stop Unit
Test Assertion GUID: 5bd99e1e-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read Capacity
Test Assertion GUID: 5bd99e1f-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read 10
Test Assertion GUID: 5bd99e20-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read CD
Test Assertion GUID: 5bd99e21-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read CD MSF
Test Assertion GUID: 5bd99e22-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read TOC/PMA/ATIP
Test Assertion GUID: 5bd99e23-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read Disc Information
Test Assertion GUID: 5bd99e24-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Synchronize Cache
Test Assertion GUID: 5bd99e25-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Reserve Track
Test Assertion GUID: 5bd99e26-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read 12
Test Assertion GUID: 5bd99e27-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Set Streaming
Test Assertion GUID: 5bd99e28-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Set Read Ahead
Test Assertion GUID: 5bd99e29-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Send OPC Information
Test Assertion GUID: 5bd99e2a-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read Format Capacities
Test Assertion GUID: 5bd99e2b-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Verify 10
Test Assertion GUID: 5bd99e2c-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Blank
Test Assertion GUID: 5bd99e2d-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Write 12
Test Assertion GUID: 5bd99e2e-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Write 10
Test Assertion GUID: 5bd99e2f-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Format Unit
Test Assertion GUID: 5bd99e30-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read DVD Structure
Test Assertion GUID: 5bd99e31-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read Buffer Capacity
Test Assertion GUID: 5bd99e32-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Close Track Session
Test Assertion GUID: 5bd99e33-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Get Performance
Test Assertion GUID: 5bd99e34-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read Track Information
Test Assertion GUID: 5bd99e35-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Set CD Speed
Test Assertion GUID: 5bd99e36-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Pause/Resume
Test Assertion GUID: 5bd99e37-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Stop Play/Scan
Test Assertion GUID: 5bd99e38-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Scan
Test Assertion GUID: 5bd99e39-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Report Key
Test Assertion GUID: 5bd99e3a-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Write And Verify 10
Test Assertion GUID: 5bd99e3b-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Play Audio 10
Test Assertion GUID: 5bd99e3c-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Play Audio 12
Test Assertion GUID: 5bd99e3d-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Play Audio MSF
Test Assertion GUID: 5bd99e3e-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Send DVD Structure
Test Assertion GUID: 5bd99e3f-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Load Unload Medium
Test Assertion GUID: 5bd99e40-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Seek 10
Test Assertion GUID: 5bd99e41-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Send Key
Test Assertion GUID: 5bd99e42-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Erase 10
Test Assertion GUID: 5bd99e43-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Command Read Sub Channel
Test Assertion GUID: 5bd99e44-c685-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Profile List
Test Assertion GUID: a8aa5515-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Core
Test Assertion GUID: a8aa5516-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Morphing
Test Assertion GUID: a8aa5517-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Removable Medium
Test Assertion GUID: a8aa5518-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Random Readable
Test Assertion GUID: a8aa5519-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Write Protect
Test Assertion GUID: a8aa551a-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Multi Read
Test Assertion GUID: a8aa551b-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature CD Read
Test Assertion GUID: a8aa551c-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature DVD Read
Test Assertion GUID: a8aa551d-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Random Writable
Test Assertion GUID: a8aa551e-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Incremental Streaming Writable
Test Assertion GUID: a8aa551f-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Sector Erasable
Test Assertion GUID: a8aa5520-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Formattable
Test Assertion GUID: a8aa5521-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Hardware Defect Management
Test Assertion GUID: a8aa5522-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Write Once
Test Assertion GUID: a8aa5523-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Restricted overwrite
Test Assertion GUID: a8aa5524-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature CD-RW CAV WRITE
Test Assertion GUID: a8aa5525-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature MRW
Test Assertion GUID: a8aa5526-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Enhanced Defect Reporting
Test Assertion GUID: a8aa5527-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature DVD+RW
Test Assertion GUID: a8aa5528-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature DVD+R
Test Assertion GUID: a8aa5529-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Rigid Restricted Overwrite
Test Assertion GUID: a8aa552a-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature CD Track At Once
Test Assertion GUID: a8aa552b-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature DVD-R/-RW WRITE
Test Assertion GUID: a8aa552c-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature CD Mastering
Test Assertion GUID: a8aa552d-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Double Density CD Read
Test Assertion GUID: a8aa552e-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Double Density CD-R Write
Test Assertion GUID: a8aa552f-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Double Density CD-RW Write
Test Assertion GUID: a8aa5530-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature CD-RW Media Write Support
Test Assertion GUID: a8aa5531-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Power Management
Test Assertion GUID: a8aa5532-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature S.M.A.R.T
Test Assertion GUID: a8aa5533-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Embedded Changer
Test Assertion GUID: a8aa5534-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature CD Audio Analog Play
Test Assertion GUID: a8aa5535-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Microcode Upgrade
Test Assertion GUID: a8aa5536-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Timeout
Test Assertion GUID: a8aa5537-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature DVD_CSS
Test Assertion GUID: a8aa5538-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Real Time Streaming
Test Assertion GUID: a8aa5539-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Logical Unit serial number
Test Assertion GUID: a8aa553a-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Disc Control Blocks
Test Assertion GUID: a8aa553b-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature DVD_CPRM
Test Assertion GUID: a8aa553c-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Feature Reserved
Test Assertion GUID: a8aa553d-c686-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile CD-RW
Test Assertion GUID: ebfd2e8f-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile CD-R
Test Assertion GUID: ebfd2e90-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile No Current
Test Assertion GUID: ebfd2e91-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile Non Removable Disk
Test Assertion GUID: ebfd2e92-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile Removable Disk
Test Assertion GUID: ebfd2e93-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile Magneto-Optical Erasable
Test Assertion GUID: ebfd2e94-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile Optical Write Once
Test Assertion GUID: ebfd2e95-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile AS MO
Test Assertion GUID: ebfd2e96-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile CD ROM
Test Assertion GUID: ebfd2e97-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile DVD-ROM
Test Assertion GUID: ebfd2e98-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile DVD-R Sequential Recording
Test Assertion GUID: ebfd2e99-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile DVD-RAM
Test Assertion GUID: ebfd2e9a-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile DVD-RW Restricted Overwrite
Test Assertion GUID: ebfd2e9b-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile DVD-RW Sequential Recording
Test Assertion GUID: ebfd2e9c-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile DVD+RW
Test Assertion GUID: ebfd2e9d-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile DVD+R
Test Assertion GUID: ebfd2e9e-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile DDCD-ROM
Test Assertion GUID: ebfd2e9f-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile DDCD-R
Test Assertion GUID: ebfd2ea0-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile DDCD-RW
Test Assertion GUID: ebfd2ea1-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile Logical Unit Not Confirming To Standard
Test Assertion GUID: ebfd2ea2-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Profile Reserved
Test Assertion GUID: ebfd2ea3-c687-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements


Multi-Path I/O Test

Type: Automated test

Overview

Customers of an enterprise storage solution rely heavily on the high availability of its components. In storage, high availability is often implemented by redundancy. Multi-path I/O (MPIO) is one such implementation for the fabric layer of an enterprise storage solution. Microsoft supports multi-path I/O with a multi-path driver (mpio.sys) and a Device Specific Module (msdsm.sys) that ship with Windows Advanced Server operating system in the Windows Vista timeframe.

The test provides multi-path I/O testing for the compatibility of a vendor's storage solution with Microsoft driver solutions. It focuses on the following areas:

  1. Path failover and recovery should not affect data transfer quality. One purpose of setting up an MPIO environment is to increase the reliability of data transferring. This test simulates several simple scenarios that would happen in the real world to break a path, and then checks whether the environment can transfer data normally.

  2. Data transfer efficiency should be improved, or at least not degraded, in an MPIO environment.

  3. Storage devices should work normally under all policies they declare to support.

Note For a Device Specific Module (DSM) that supports vendor policy, please make the vendor's policy the current policy before running this test.

Details

The test includes the following basic test assertions, which are combined into four test cases:

  1. Failover: Data transfer is not broken when some paths are broken but not all.

  2. Failback: Data transfer works normally when some paths are restored from failover.

  3. Link bounce: For an MPIO environment, all paths except for one path are broken. If that path is broken and recovers within 15 seconds, the data transfer is able to continue without error.

  4. Simultaneous failover and failback, or "simultaneous bouncing": Data transfer is not broken when some paths fail over and other paths fail back simultaneously.
  5. Load balance policy: Different policy can be set and data transfer can work correctly with it. For Round Robin Load Policy and Round Robin Load Policy with subset, the test checks whether efficiency is degraded.

The test components include a stand-alone test application, a fault injection filter driver, a test case configuration file, an iSCSI configuration file (if the path is created over an iSCSI session), and the Device Test Manager (DTM).

Follow these steps to operate the test:

  1. DTM starts the stand-alone test application, which retrieves the test cases to run.
  2. DTM retrieves the MPIO test environment information for further testing.
  3. If a path is not over iSCSI, the test loads the filter driver for a related HBA instance for further testing.
  4. If the path is over iSCSI, provide the iSCSI configuration information using one of the following ways:
    • Input the configuration data into the window pop-up on the test client, which creates the Iscsihctconfig.ini file under [WLK PATH]\JobsWorkingDir\Tasks\[WTTJOBNAME]\.

    • Before testing, create the Iscsihctconfig.ini file, which contains the configuration data. Use the following format:

      [Targets]
      DiskTarget=Target
      [Target]
      TargetName=iqn.2001-05.com.equallogic:0-8a0906-7e2dd0401-fd1d03f67f74b96b-10-2411a0920-0
      PortalPort=3260
      PortalIPAddress=10.10.20.80
      CHAPType=None
  5. Set the load balance policy, which declares support, simulates failover and failback scenarios, and performs testing. For a non-iSCSI test environment, simulate the link bouncing and simultaneous bouncing scenarios.
  6. Set the Round Robin policy for non-ALUA storage and ALUA storage to enable performance checking.
  7. The test tool logs to WTTLogger.

Run time: Approximately 1 to 3 hours, depending on the test environment configuration
Log file: mpiotest.log
System restart required: Yes
Supported operating systems for logo or signature testing:

  • Windows Server 2008

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Hardware storage RAID array that uses either the Microsoft DSM or a third-party DSM that interfaces to the Microsoft MPIO core architecture

  • Software components included with the DSM or hardware storage RAID array being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard disk drive with a minimum of 20 GB available on partition C:

  • Multi-Path I/O Setup

Processor

The test tool runs on the x64 processor architectures.

Command Syntax

mpiotest.exe –d “[WDKDeviceID]”-s mpiotest_script_fvt.txt –logo

Code Tour

File Manifest

File | Location
mpiotest.exe | ...\Tests\%PROCESSOR_ARCHITECTURE%\nttest\DriversTest\storage\wdk\
mpfifltr.sys | ...\Tests\%PROCESSOR_ARCHITECTURE%\nttest\DriversTest\storage\wdk\
iscsihctconfig.ini | ...\Tests\%PROCESSOR_ARCHITECTURE%\nttest\DriversTest\storage\wdk\
mpiotest_script_fvt.txt | ...\Tests\%PROCESSOR_ARCHITECTURE%\nttest\DriversTest\storage\wdk\

Test Assertions

3rd Party DSM must support the vendor’s specific load balance policy.
Test Assertion GUID: 7682274a-c6a1-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0007 Device storage special features meet industry standards and Windows requirements
Details: This test requires you to configure MPIO to comply with the vendor’s specific policy before the MPIO test. As the first test case for the MPIO test, it would do failover, failback, link bouncing, and simultaneous bouncing testing to make sure that the MPIO test environment can work normally with the third-party DSM. If there is no vendor-specific policy, skip the testing. If there is, configure the current policy to be the vendor’s specific one. Otherwise, the test will fail, and you must configure the correct setting before running the MPIO test. This test is performed for each MPIO pseudo-LUN.

DSM must support required WMI functions.
Test Assertion GUID: 7682274a-c6a1-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0007 Device storage special features meet industry standards and Windows requirements
Details: Get the MPIO path information through WMI, and print the information related to the specific DSM.

DSM must support failover and failback functionality and various load balance policies.
Test Assertion GUID: 7682274c-c6a1-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0007 Device storage special features meet industry standards and Windows requirements
Details: Classify the MPIO pseudo-LUN based on adapter information, storage information, and MPIO path information into different groups. For each MPIO pseudo-LUN group, choose one pseudo-LUN to run the testing:
  1. Set load balance policy on the pseudo-LUN.
  2. Perform failover, failback, link bouncing, and simultaneous bouncing testing to make sure the MPIO test environment can work normally on this specific policy.
  3. For each load balance policy other than the vendor's, repeat steps 1 and 2.

Note For iSCSI MPIO, the test does not do link bouncing and simultaneous bouncing testing.

DSM must support round-robin data access.
Test Assertion GUID: 7682274d-c6a1-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0007 Device storage special features meet industry standards and Windows requirements
Details: Check whether test storage supports Round Robin Policy or Round Robin with Subset Policy or not. If it does, set the policy to be the supported one. For non-ALUA storage, set it to be Round Robin Policy, and for ALUA storage, set it to be Round Robin with Subset Policy. If it does not support either of these policies, skip this testing. Perform failover on all adapter ports or iSCSI sessions except one, then run I/O operations to collect the throughput data. Recover all adapter ports or iSCSI sessions, and then perform I/O operations to check the throughput. This throughput data should not be worse than the one with only one port or iSCSI session available. Otherwise, there will be warning messages.


Non-rotating Media Test

Type: Automated Test

Overview

The Non-rotating Media Test verifies that an ATA device (including SATA) properly reports its nominal media rotation rate as described in the ATA/ATAPI Command Set-2 (ACS-2) or later. To obtain this specification, see the T13 Technical Committee Web site at T13 Technical Committee. Compliance with this standard ensures that the operating system can differentiate between non-rotating media and standard rotating disk devices.

Details

The Non-rotating Media Test uses ATA pass-through requests (IOCTL_ATA_PASS_THROUGH) to construct and send the IDENTIFY DEVICE (0xec) command to the device. The test then evaluates the Nominal Media Rotation Rate (word 217) to verify compliance with the specification.

Run Time: 2 minutes
Log File: nrmtest.log.xml
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: nonrotatingmedia.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

    One or more ATA or SATA disks attached to the test system

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

Command Syntax

Command option | Description
nonrotatingmedia.exe | Without any options, shows usage information.
-d [DiskDeviceObjLink] | Starts the application and runs the test cases that are specified in the .profile file.
-nrm [0|1] | Specifies that the device in test is non-rotating media (1) or a rotating disk device (0).

Troubleshooting

The test writes the results to the log files nrmtest.log.xml and nrmtest.log.txt. Use the log files to determine the cause of any failures.

Code Tour

File Manifest

File | Location
nonrotatingmedia.exe | [testbinroot]\nttest\driverstest\storage\wdk\

Test Assertions

Logo Requirement: Storage-0017

Assertion Description:

Non-rotational Media Test: Verifies that an ATA device (including SATA) identifies itself as it was identified during the device submission wizard: as non-rotating media or otherwise. The following table describes the relationship between the test result and the Nominal Media Rotation Rate reported by the IDENTIFY DEVICE command. This table does not exhaustively list all possible test results. It is also possible that a device would fail this test, for instance, if the ATA pass-through failed. Review the test results in the log file for specific details about failures.

Reported Rotation Rate | Description | Result for Rotating Disks* | Result for Non-rotating Media*
0x0000 | Rate not reported | Warn | Warn
0x0001 | Non-rotating media | Warn | Pass
0x0002-0x0400 | Reserved | Warn | Warn
0x0401-0xfffe | Nominal media rotation rate in rotations per minute | Pass | Warn
0xffff | Reserved | Warn | Warn

*The device type is determined by information provided to the device submission wizard.


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.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • 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.

Code Tour

File Manifest

File | Location
fileSec.exe | nttest\BASETEST\core_file_Services\NTFS\security\fileSec.exe


Optical Logo Test

The Optical logo test validates if the device is in compliance with the latest MMC/Mt. Fuji, specifications and meets the Microsoft quality standards.

Overview

  1. Verify if the device is in compliance with the latest MMC/Mt. Fuji specification for all the commands used by Windows

  2. Validate if the device works well with Windows, in terms of performance and reliability.

Details

The drive shall support the following commands:

  1. Get Configuration (with no media)

  2. Get Event Status Notification

  3. Inquiry

  4. Mechanism Status

  5. Mode Sense

  6. Prevent Allow Medium Removal

  7. Request Sense

  8. Start Stop Unit

  9. Test Unit Ready

The drive shall support the following commands if they are mandatory for the features and profiles it supports.

  1. Get Configuration (with media)

  2. Get Performance

  3. Read Buffer Capacity

  4. Read Capacity

  5. Read Disc Information

  6. Read Format Capacities

  7. Read Toc Pma Atip

  8. Send Opc Information

  9. Set CD Speed

  10. Read10

The drive shall support the following scenarios if the commands associated with these scenarios are mandatory for the features and profiles it supports.

  1. Event Status Notification

  2. Write
    • Sequential mode
    • Packet mode
    • Restricted Overwrite
    • Multi Session support

  3. Audio Media (Write Audio Tracks)

  4. Blank

  5. Unique drive serial number

  6. Real-time streaming

  7. Audio Media Gapless Raw Recording

Test Cases

The test cases validate the quality of the device by testing the commands and scenarios that are important to have better a user experience with optical devices.

Device Test Cases

The following commands verification test cases that are applicable for the device

  1. GET CONFIGURATION (WITH NO MEDIA)

  2. GET EVENT STATUS NOTIFICATION

  3. INQUIRY

  4. MECHANISM STATUS

  5. MODE SENSE

  6. PREVENT ALLOW MEDIUM REMOVAL

  7. REQUEST SENSE

  8. START STOP UNIT

  9. TEST UNIT READY

Profile Test Cases

The following commands verification test cases will be tested on all applicable profiles

  1. GET CONFIGURATION

  2. GET PERFORMANCE

  3. READ CAPACITY

  4. READ BUFFER CAPACITY

  5. READ DISC INFORMATION

  6. READ FORMAT CAPACITIES

  7. READ TOC PMA ATIP

  8. SEND OPC INFORMATION

  9. SET CD SPEED

  10. READ10

Scenario Test Cases

The test following scenarios are test using the IMAPI burn engine interfaces.

  1. EVENT STATUS NOTIFICATION

  2. BLANK

  3. WRITE/MULTISESSION

  4. AUDIO MEDIA

  5. WRITE DUAL LAYER MEDIA

  6. DRIVE SERIAL NUMBER

  7. READ ONLY DRIVE

  8. REAL-TIME STREAMING

  9. AUDIO MEDIA GAPLESS RAW RECORDING

Testable Media Types

The following media types are testable:

  • CD-ROM

  • CD-R

  • CD-RW

  • DVD-ROM

  • DVD+R

  • DVD-R

  • DVD+RW

  • DVD-RW Restricted Overwrite

  • DVD-RAM

  • DVD+R Dual Layer

  • DVD-R Dual Layer

  • BD-ROM

  • BD-R Sequential

  • BD-RE

Known Issues

The following are known issues with regards to testing:

  • Bus reset test scenario disabled by default

    The test will not by default validate the proper device behavior upon bus reset.

    If bus reset happens, the drive is expected to reset itself properly, come back online and should work as normal. But some defective drives do not reset themselves properly and they won't work after the bus reset. This is not a proper implementation. When this specific test scenario is enabled, the command verification test cases (both device and profile test cases) will send the commands with incorrect SRB data direction flag. This will typically stall the bus and eventually cause the port driver to reset the bus after a given timeout period.

    But most of the storage controllers do not support this test scenario properly. The incorrectly implemented storage controllers will not recover after the bus reset. So that the test case might fail due to the storage controller even for properly implemented devices. The logo test is not able to distinguish device failures from storage controller failures. So, testing this specific scenario is disabled by default for the device logo. To enable testing this specific scenario the test executable should be launched with the "RunDataDirectionFlagScenario" command line option.

Hardware Requirements

  1. The test expects two identical test devices connected to the test system

  2. If the drive is read only drive, then the test system should be connected with two identical test read only drives and a writer drive.

Setup Instructions

The test shows the following configuration dialog box to get the primary and secondary drive tray configuration:

Screen shot of the Primary and Secondary drive tray configuration dialog box

The user has to select the identical secondary drive from the drives list in the Writer Drive dialog box and should select the drive tray capabilities, whether it supports auto ejecting and auto loading the tray.

Screen shot of the Writer Drive dialog box

This configuration dialog will show up if the test drive is a read only drive. The user has to select the writer drive from the writer drives list and should select the drive tray capabilities, whether it supports auto ejecting and auto loading the tray.

Note: The I/O intensive applications running on the test machine might interfere with the optical logo test performance measurement scenarios. Please make sure there are no other applications running on the test machine when the logo test is running.

Test Cases Description

Device Test Cases

GET CONFIGURATION COMMAND (WITH NO MEDIA)

Description: This test is to make sure the drive responds to the GET CONFIGURATION command properly when there is not media in the tray.

Applicable Media: Any media supported by the device.

Test Case Steps:

  1. Eject the tray by sending the START STOP UNIT command.

  2. Wait until the tray is open.

  3. Send the GET CONFIGURATION command with response data length of 4 bytes to get the feature header data length. If the command fails, print the sense key and fail the test case. Purpose: allow software to probe support of command.

  4. Check if the drive reports no current profile in the feature header. If the drive doesn't repro current profile as "no current profile" then fail the test case.

  5. Send the GET CONFIGURATION command again with RT=00b and with the correct data length returned by the device in step 3. Purpose: allow software to retrieve the entire list of features supported by the drive.

  6. Check if the drive reports no current profile in the feature header. If the drive doesn't repro current profile as "no current profile" then fail the test case.

  7. Get the profile list feature descriptor in the response for the current profile bit set and Fail the test case if any of the profile descriptor has the current profile bit set to 1.

  8. Send the GET CONFIGURATION command with response data length of 20 bytes, RT=01b, Starting Feature Number=0010h (Random Readable Feature). If the command fails or if the Random Readable Feature descriptor is not returned, print the sense key as appropriate and fail the test case. Purpose: allow software to probe specific feature currency (not current).

  9. [Optional] Send the GET CONFIGURATION command with data direction flag set to "to the device" and with response data length of 4 bytes to get the feature header data length. If the command fails, print the sense key and fail the test case. Purpose: To make sure the device handles command with incorrect data direction.

  10. Inject the tray.

  11. Wait until the device comes to ready state.

  12. Send the GET CONFIGURATION command with response data length of 16 bytes, RT=01b, Starting Feature Number=0003h (Removable Medium Feature). If the command fails print the sense key as appropriate and fail the test case. If the command succeeds
    • Check if the "Eject" bit is set if the drive supports auto eject mechanism.
    • Check if the "Load" bit is set if the drive supports auto inject mechanism.

Result: The drive should respond to the GET CONFIGURATION command properly.

GET EVENT STATUS NOTIFICATION COMMAND

Description: To validate if the drive supports the GET EVENT STATUS NOTIFICATION command.

Applicable Media: Any media supported by the device.

Test Case Steps:

  1. Send Get Event Status Notification Command with the following values in the CDB.
    • Notification Class Request = 0x7E (Operational Change, Power Management, External Request, Media, Multi-Host, Device Busy),
    • Polled = 1
    • Allocation Length equal to the size of the response header (4 bytes)

  2. If the command fails, fail the test case

  3. In the response check which events are supported

  4. [Optional] Send Get Event Status Notification Command with the data direction flag set to "to the device" and the following values in the CDB.
    • Notification Class Request = 0x7E (Operational Change, Power Management, External Request, Media, Multi-Host, Device Busy),
    • Polled = 1
    • Allocation Length equal to the size of the response header (4 bytes)

  5. If the command fails, fail the test case

  6. In the response check that Event Data Length is 0x6, NEA bit is cleared, Notification Class is non-zero and Supported Event Classes are identical to step 3. Otherwise fail the test case

  7. Send Get Event Status Notification Command with the following values in the CDB.
    • Notification Class Request = 0x7E (Operational Change, Power Management, External Request, Media, Multi-Host, Device Busy)
    • Polled = 1
    • Allocation Length equal to the size of the response header (4 bytes)

  8. If the command fails, fail the test case

Result: The drive should respond to the GET EVENT STATUS NOTIFICATION command properly.

INQUIRY COMMAND

Description: To validate if the drive supports the INQUIRY command.

Applicable Media: Any media supported by the device.

Test Case Steps:

  1. Send the INQUIRY command with allocation length equal 08h. Purpose: allow software to probe the required response buffer size.

  2. If the command succeeds, check the response for the additional length in the header. The additional length must be 32d or larger [MMC5r04 6.9.2].

  3. Send the INQUIRY command again with allocation length set to 5 bytes more than the additional length from step 2.

  4. If the command succeeds, ensure that response data fields match values specified in MMC5r04 table 320.

  5. Check that Vendor Identification, Product Identification and Product Revision Level are not null.
    • Purpose: Basic identification by software.
  6. Check if the following values match:
    • Device Type = 5
    • Device Type Qualifier = 0
    • Removable Media = 1
    • Response Data Format = 2
    • Hierarchy Support = 0
    • Normal ACA = 0
    • Protect = 0
    • Third Party Copy = 0
    • Target Port Group Support = 0
    • Access Controls Coordinator = 0
    • SCC Supported = 0
    • Addr16 = 0
    • Medium Changer = 0
    • Multi Port = 0
    • VS1 = 0
    • Enclosure Services = 0
    • BQue = 0
    • VS2 = 0
    • Command Queue = 0
    • Linked Commands = 0
    • Synchronous = 0
    • Wide16 = 0
  7. Send the INQUIRY command with the following values in the CDB
    • EVPD = 0
    • Allocation Length = 240
  8. Send the INQUIRY command with the following values in the CDB
    • EVPD = 1
    • Allocation Length = 240

  9. If the command succeeds then compare the response from step 7 and step 8, if both are equal then fail the test case.

  10. Send the INQUIRY command for a random number of times between 10 and 25 with random allocation lengths. If the command fails then fail the test case.

  11. [Optional] Send the INQUIRY command with the data direction flag set to" to the device" and with the following values in the CDB
    • EVPD = 0
    • Allocation Length = 240

Result: The drive should respond to the INQUIRY command properly.

MECHANISM STATUS COMMAND

Description: To validate if the drive supports the MECHANISM STATUS command.

Applicable Media: Any media supported by the device.

Test Case Steps:

  1. Send the MECHANISM STATUS command with allocation length 0 bytes (data sense unspecified). If the command fails, print the sense key and fail the test case.
    • Purpose: allow software to probe support of command.

  2. Eject the Tray.

  3. Wait until the device return the sense data (Sense Key : 0x2, ASC: 0x3A, ASCQ: 0x02)

  4. Send the MECHANISM STATUS command with allocation length 8 bytes.

  5. Check that Door Open bit is 1b.

    • Purpose: Allow software to detect if door is open or closed (open).

  6. Inject the tray

  7. Wait Until the device is ready

  8. Send the MECHANISM STATUS command with allocation length 8 bytes.

  9. Check that Door Open bit is 0b.

    • Purpose: Allow software to detect if door is open or closed (closed).

  10. Create a 8 byte buffer and fill it with random data

  11. [Optional] Send the MECHANISM STATUS command with data direction flag set to "to the device" and with allocation length of 8 bytes. Pass the buffer from step 11 to the device.

Result: The drive should respond to the MECHANISM STATUS command properly.

MODE SENSE COMMAND

Description: To validate if the drive supports the MODE SENSE command.

Applicable Media: Any media supported by the device.

Test Case Steps:

  1. Send the MODE SENSE command with the following values in the CDB to get all the supported Mode Pages
    • Page Control = 0
    • Disable Block Descriptors = 1
    • Page Code = 0x3F
    • Allocation Length = 0x8000
  2. Check the following values in the response
    • Block Descriptor Length in the mode parameters header is zero.
    • Page length for each mode page data is equal to the value documented in MMC5.

  3. Validate the Mode page data for each reported page

  4. Send the Mode Sense command for each reported page with the following values in the CDB
    • Page Control = 0
    • Disable Block Descriptors = 1
    • Allocation Length = Page Length reported by the drive in step 2.
  5. Check the following values in the response
    • Block Descriptor Length in the mode parameters header is zero
    • Page code in the mode page header matches with the requested page code
    • Page length in the mode page header is equal to the value document in MMC5.

  6. Send the Mode Sense command with allocation length 0xFFF0

  7. Check the following values in the response
    • Block Descriptor Length in the mode parameters header is zero
    • Page code in the mode page header matches with the requested page code

  8. Send the Mode Sense command with allocation length 0x0A

  9. Check if the response matches byte by byte up to the response size (0x0A) with the response for allocation length equal to 0xFFF0.

  10. Send the Mode Sense command for a random number of times between 10 and 25 with random allocation lengths between 0x0A and 0xFFF0.

  11. Check if the response matches byte by byte up to the response size (random value between 0x0A and 0xFFF0) with the response for allocation length equal to 0xFFF0.

  12. [Optional] Send the MODE SENSE command with the data direction flag set to "to the device" and with the following values in the CDB to get all the supported Mode Pages
    • Page Control = 0
    • Disable Block Descriptors = 1
    • Page Code = 0x3F
    • Allocation Length = 0x8000

Result: The drive should respond to the MODE SENSE command properly.

PREVENT ALLOW MEDIUM REMOVAL COMMAND

Description: To validate if the drive supports the PREVENT ALLOW MEDIUM REMOVAL command.

Applicable Media: Any media supported by the device.

Test Case Steps:

  1. Send the PREVENT ALLOW MEDIUM REMOVAL command with prevent bit set to 1 and Persistent bit set to 0. This would lock the drive. If the command fails print the sense key and fail the test case.

  2. Send the start stop unit command with LocEj bit set to 1 and Immediate bit set to 0 and Start bit set to zero. This will try to eject the disc. If the drive doesn't reject the command with sense data 0x05 0x53, 0x02 then it is a failure.

  3. Send the Test Unit ready command and ensure it succeeds.

  4. Ask the user to press the eject button to eject the media

  5. Send the Test Unit ready command and ensure it still succeeds (door should not open).

  6. Send the Prevent Allow Medium Removal command with prevent bit set to 0 and Persistent bit set to 0. This would unlock the drive. If the command fails print the sense key and fail the test case.

  7. Ask the user to press the eject button to eject the media

  8. Wait for the device to open the door - Send the Test Unit ready command, if the command succeeds then wait for 1 second and retry until it fails with (02/3A/02). Timeout after 30 seconds.

  9. If the drive supports auto loading mechanism then inject the tray back into the drive otherwise ask the user to insert the tray back into the drive.

  10. Wait for the device to be ready

  11. [Optional] Send the PREVENT ALLOW MEDIUM REMOVAL command with the data direction flag set to the "to the device" and pass the random data in a random size buffer.

Result: The drive should respond to the PREVENT ALLOW MEDIUM REMOVAL command properly.

REQUEST SENSE COMMAND

Description: To validate if the drive supports the REQUEST SENSE command.

Applicable Media: Any media supported by the device.

Test Case Steps:

  1. Send the REQUEST SENSE command, with the descriptor bit set to zero and Allocation Length set to 252. The drive shall respond with the fixed format sense data

  2. If the command fails print the sense key and fail the test case

  3. If the response code is 0x70 or 0x71 the test passes otherwise the test fails

  4. [Optional] Send the REQUEST SENSE command, with the data direction flag set to "to the device" and with the descriptor bit set to zero and Allocation Length set to 252. The drive shall respond with the fixed format sense data

Result: The drive should respond to the REQUEST SENSE command properly.

START STOP UNIT COMMANDS, EJECT & LOAD PERFORMANCE

Description: To validate if the drive supports the START STOP UNIT command.

Applicable Media: Any media supported by the device.

Test Case Steps:

  1. Send the START STOP UNIT command with the following values in the CDB
    • Immediate = 0, LoadEject = 0, Start = 0, PowerConditions = 0
    • Immediate = 0, LoadEject = 0, Start = 1, PowerConditions = 0
    • Immediate = 1, LoadEject = 0, Start = 0, PowerConditions = 0
    • Immediate = 1, LoadEject = 0, Start = 1, PowerConditions = 0

  2. The command shall succeed for each of this combination.

  3. If the drive supports ejecting the tray, then send the START STOP UNIT command with the following values in the CDB, to eject the tray
    • Immediate = 1, LoadEject = 1, Start = 0, PowerConditions = 0

  4. Wait for the device to open the door - Send the TEST UNIT READY command, if the command succeeds then wait for 5 seconds and retry until it fails with (02/3A/02). Timeout after 10 seconds.

  5. If the drive supports loading the tray (auto inject), then send the START STOP UNIT command with the following values in the CDB, to inject the tray
    • Immediate = 1, LoadEject = 1, Start = 1, PowerConditions = 0

  6. If the drive doesn't support loading the tray then ask the user to insert the tray back into the drive.

  7. Wait for the device to be ready - Send the TEST UNIT READY command, if the command fails with a sense key then wait for 1 second and retry until it succeeds. Timeout after 30 seconds. PREMIUM LOGO: Time out: 20 seconds.

  8. Send the START STOP UNIT command with the following values in the CDB, to eject the tray
    • Immediate = 0, LoadEject = 1, Start = 0, PowerConditions = 0

  9. Wait for the device to open the door - Send the TEST UNIT READY command, if the command succeeds then wait for 1 second and retry until it fails with (02/3A/02). Timeout after 30 seconds.

  10. Ask user to remove the media

  11. If the drive supports loading the tray (auto inject), then send the START STOP UNIT command with the following values in the CDB, to inject the tray
    • Immediate = 0, LoadEject = 1, Start = 1, PowerConditions = 0

  12. Ensure the command fails with Not Ready / Medium not present / Tray closed (02/3A/01)

  13. If the drive supports ejecting the tray, then send the START STOP UNIT command with the following values in the CDB, to eject the tray
    • Immediate = 0, LoadEject = 1, Start = 0, PowerConditions = 0

  14. Ask the user to place the media in the tray.

  15. If the drive doesn't support loading the tray then ask the user to insert the tray back into the drive and wait until the device is ready. If the drive supports loading the tray (auto inject), then send the START STOP UNIT command with the following values in the CDB, to inject the tray and wait until the device is ready.
    • Immediate = 0, LoadEject = 1, Start = 1, PowerConditions = 0
  16. [Optional] Send the START STOP UNIT command with data direction flag set to "to the device". Send random size buffer with random data and with the following values in the CDB.
    • Immediate = 0, LoadEject = 0, Start = 0, PowerConditions = 0

Result: The drive should respond to the START STOP UNIT command properly.

TEST UNIT READY COMMAND

Description: To validate if the drive supports the TEST UNIT READY command.

Applicable Media: Any media supported by the device.

Test Case Steps:

  1. Send the TEST UNIT READY command.

  2. If the command fails print the sense key and fail the test case

  3. [Optional] Send the TEST UNIT READY command with data direction flag set to "to the device" and with random size buffer filled with random data.

Result: The drive should respond to the TEST UNIT READY command properly.

Profile Test Cases

GET CONFIGURATION COMMAND

Description: To validate if the drive supports the GET CONFIGURATION command for the reported profile.

Applicable Media: All media types supported by the device.

Test Case Steps:

  1. Send the GET CONFIGURATION command with response data length of 0 bytes (data sense unspecified). If the command fails, print the sense key and fail the test case.
    • Purpose: allow software to probe support of command.
  2. Send the GET CONFIGURATION command with response data length of 4 bytes to get the feature header data length. If the command fails, print the sense key and fail the test case.
    • Purpose: allow software to probe support of command.
  3. Send the GET CONFIGURATION command with response data length of 8 bytes (to get the header), RT=00b, Starting Feature Number=0000h. If the command fails or if the Current Profile equals 00h, print the sense key as appropriate and fail the test case.
    • Purposes:
      • allow software to probe the required response buffer size.
      • allow software to probe current profile (a profile is current).
  4. If the command succeeds check the following in the response
    • Data length in the header is non zero and it is four byte aligned
    • Current profile number matches with media type loaded in the drive
  5. Send the GET CONFIGURATION command with response data length read at step 3, RT=00b, Starting Feature Number=0000h. Read the Current Profile, and then look for this profile code in the list of supported profiles. Ensure the current profile matches with the profile type of the inserted media. If the command fails or if the current profile is not reported current in the list of supported profiles, print the sense key as appropriate and fail the test case.
    • Purpose: Ensure consistency of the information reported by the drive.
  6. Send the GET CONFIGURATION command again with RT=00b and with the correct data length returned by the device in step3 if length fits 2 bytes. If length exceeds 2 bytes, send the command with maximum data length for 2 bytes.
    • Purpose: allow software to retrieve the entire list of features supported by the drive.

  7. If length exceeded 2 bytes, read the feature number for the last complete feature descriptor returned and issue additional GET CONFIGURATION command with RT=10b and with starting feature number equal to this feature number plus 1. Repeat operation until the data length returned in the feature header is equal or smaller to the allocated length. Concatenate the resulting feature descriptors for verification in step 10.

  8. For all commands succeeding at steps 3-6, check if the data length in the header of the response is multiple of 4 (4 byte aligned). Fail if it is not 4 byte aligned. Purpose: 4 bytes alignment is assumed by software.

  9. Additionally if the command(s) succeeded, check that each reported feature Version and Additional Length fields are equal or bigger than the respective values for the given feature in MMC-5 document. E.g.: Core Feature's version must be 0010b or higher and its additional length must be 8 or larger. Purpose: Ensure consistency of the information reported by the drive. If the removable medium feature is reported, the version number of it should be 1 as specified in GET CONFIGURATION command.

  10. Additionally if the command(s) succeeded, check that each mandatory feature for reported supported profile is reported.
    • Purpose: Ensure consistency of the meta-information reported by the drive.

  11. Send the GET CONFIGURATION command with response data length of 20 bytes, RT=01b, Starting Feature Number=0010h (Random Readable Feature). If the command fails or if the Random Readable Feature descriptor is not returned, print the sense key as appropriate and fail the test case. Purpose: allow software to probe specific feature currency (current).

  12. [Optional] Send the GET CONFIGURATION command with data direction flag set to "to the device" and with random size buffer filled with random data. The following values are set in the CDB:
    • Allocation Length = Size of the buffer, Starting Feature Number=0000h, RT=00b

Result: The drive should properly implement the GET CONFIGURATION command for the applicable media types.

GET PERFORMANCE

Description: To validate if the drive supports the GET PERFORMANCE command for the reported profile.

Applicable Media:

  • DVD+R

  • DVD+RW

  • DVD-RW Restricted Overwrite

  • DVD-RAM

  • DVD-R

  • DVD-ROM

  • CD-R

  • CD-RW

Test Case Steps:

  1. Send the GET CONFIGURATION command to the get the REAL TIME STREAMING feature. Check the response, if the Write Speed Performance Descriptor bit is set. If this is not set then the drive doesn't support Write speed descriptors. Skip steps 6 to 11 which validate the write speed descriptors.

  2. Send the GET PERFORMANCE command with the following values in the CDB to get zero nominal read performance descriptors.
    • Type = 0
    • Starting LBA = 1
    • Max Descriptors = 0
    • Data Type = 0x10

  3. If the command fails print the sense key and fail the test case

  4. Send the GET PERFORMANCE command with the following values in the CDB to get one nominal read performance descriptor.
    • Type = 0
    • Starting LBA = 1
    • Max Descriptors = 1
    • Data Type = 0x10

  5. If the command fails print the sense key and fail the test case

  6. Send the GET PERFORMANCE command with the following values in the CDB to get one nominal write performance descriptor.
    • Type = 0
    • Starting LBA = 1
    • Max Descriptors = 1
    • Data Type = 0x14

  7. If the command fails print the sense key and fail the test case

  8. Send the GET PERFORMANCE command with the following values in the CDB to get data length for the list of write speed descriptors
    • Type = 3
    • Starting LBA = 1
    • Max Descriptors = 0
    • Data Type = 0x14

  9. If the command fails print the sense key and fail the test case

  10. Send the GET PERFORMANCE command with the following values in the CDB to get the list of write speed descriptors
    • Type = 3
    • Starting LBA = 1
    • Max Descriptors = 10
    • Data Type = 0x14

  11. If the command fails print the sense key and fail the test case

  12. [Optional] Send the GET PERFORMANCE command with data direction flag set to "to the device" and with random size buffer filled with random data. Set with the following values in the CDB to get zero nominal read performance descriptors.
    • Type = 0
    • Starting LBA = 1
    • Max Descriptors = 0
    • Data Type = 0x10

  13. If the command fails print the sense key and fail the test case

Result: The drive should properly implement the GET PERFORMANCE command for the applicable media types.

READ CAPACITY COMMAND

Description: To validate if the drive supports the READ CAPACITY command for the reported profile.

Applicable Media: All media types reported by the device.

Test Case Steps:

  1. Send the READ CAPACITY command.

  2. If the command fails print the sense key and fail the test case.

  3. If the Block length in bytes is not 2048 then fail the test case.

  4. [Optional] Send the READ CAPACITY command with data direction flag set to "to the device" and with random size buffer filled with random data.

  5. If the command fails print the sense key and fail the test case.

Result: The drive should properly implement the READ CAPACITY command for the applicable media types.

READ BUFFER CAPACITY COMMAND

Description: To validate if the drive supports the READ BUFFER CAPACITY command for the reported profile.

Applicable Media:

  • DVD+R

  • DVD+RW

  • DVD-RW Restricted Overwrite

  • DVD-RAM

  • DVD-R

  • DVD-ROM

  • CD-R

  • CD-RW

Test Case Steps:

  1. Send the GET CONFIGURATION command to the get the REAL TIME STREAMING feature. Check the response, if the Read Buffer Capacity Block (RBCB) bit is set. If this is not set then the drive doesn't support Read Buffer Capacity command. Skip the test case.

  2. Send the READ BUFFER CAPACITY command with block bit set to 0, and Allocation Length equal to the size of the Buffer Capacity Structure

  3. If the command fails print the sense key and fail the test case

  4. Repeat step 2 with Block bit set to 1

  5. If the command fails print the sense key and fail the command

  6. [Optional] Send the READ BUFFER CAPACITY command with data direction flag set to "to the device" and with random size buffer filled with random data and block bit set to zero.

  7. If the command fails print the sense key and fail the test case.

Result: The drive should properly implement the READ BUFFER CAPACITY command for the applicable media types.

READ DISC INFORMATION COMMAND

Description: To validate if the drive supports the READ DISC INFORMATION command for the reported profile.

Applicable Media:

  • DVD+R

  • DVD+RW

  • DVD-R

  • CD-R

  • CD-RW

Test Case Steps:

  1. Send the READ DISC INFORMATION command, with the allocation length of 2 to get the standard disc information size

  2. If the command fails print the sense key and fail the test case

  3. Get the disc information length from the response. If the length is less than the Standard Disc Information Block Size (34), then fail the test case.

  4. Send the READ DISC INFORMATION command, with the allocation length equal to the data length from step 3 plus 2.

  5. If the command fails print the sense key and fail the test case

  6. [Optional] Send the READ DISC INFORMATION command with data direction flag set to "to the device" and with random size buffer filled with random data and Allocation length set to the size of the buffer.

Result: The drive should properly implement the READ DISC INFORMATION command for the applicable media types.

READ FORMAT CAPACITIES COMMAND

Description: To validate if the drive supports the READ FORMAT CAPACITIES command for the reported profile.

Applicable Media:

  • DVD+RW

  • DVD-RW Restricted Overwrite

  • DVD-RAM

  • CD-RW

Test Case Steps:

  1. Send the READ FORMAT CAPACITIES command with Allocation Length equal to 4 (Capacity List Header).

  2. If the command fails print the sense key and fail the test case.

  3. Get the Capacity List Length from the response

  4. Send the READ FORMAT CAPACITIES command with Allocation Length equal to Capacity List Length + 4 (size of the Capacity List Header).

  5. If the command fails print the sense key and fail the test case.

  6. Check the response if the capacity list length is multiple of 8.

  7. [Optional] Send the READ FORMAT CAPACITIES command with data direction flag set to "to the device" and with random size buffer filled with random data and Allocation length set to the size of the buffer.

Result: The drive should properly implement the READ FORMAT CAPACITIES command for the applicable media types.

READ TOC/PMA/ATIP COMMAND

Description: To validate if the drive supports the READ TOC/PMA/ATIP command for the reported profile.

Applicable Media:

  • DVD-ROM

  • CD-ROM

Test Case Steps:

  1. Send the READ TOC/PMA/ATIP command with the following values in the CDB.
    • Format = 0, MSF = 0, Track Session Number = 1, Allocation Length = 4

  2. If the command fails print the sense key and fail the test case.

  3. [Optional] Send the READ TOC/PMA/ATIP command with data direction flag set to "to the device" and with buffer filled with random data and Allocation length set to the size of the buffer. Set the CDB with the following values:
    • Format = 0, MSF = 0, Track Session Number = 1, Allocation Length = 4

Result: The drive should properly implement the READ TOC/PMA/ATIP command for the applicable media types.

SEND OPC INFORMATION COMMAND

Description: To validate if the drive supports the SEND OPC INFORMATION command for the reported profile.

Applicable Media:

  • DVD-RW Restricted Overwrite

  • DVD-R

  • CD-RW

  • CD-R

Test Case Steps:

  1. Send the SEND OPC INFORMATION command with DoOpc set to 1.

  2. If the command fails print the sense key and fail the test case.

  3. [Optional] Send the SEND OPC INFORMATION command with DoOpc set to 1, data direction flag set to "to the device" and with random size buffer filled with random data. The Allocation length is set to the size of the buffer.

Result: The drive should properly implement the SEND OPC INFORMATION command for the applicable media types.

SET CD SPEED COMMAND

Description: To validate if the drive supports the SET CD SPEED command for the reported profile.

Applicable Media: All media types supported by the device.

Test Case Steps:

  1. Send the GET CONFIGURATION command to the get the REAL TIME STREAMING feature. Check the response, if the Set CD Speed (SCS) bit is set. If this is not set then the drive doesn't support SET CD SPEED command. Skip the test case.

  2. Send the SET CD SPEED command, with the following values in the CDB.
    • RotationalControl = 0, ReadSpeed = 0xFFFF, WriteSpeed = (((4* 75 * 2352) + 500) / 1000) If the command fails print the sense key and fail the test case.
  3. [Optional] Send SET CD SPEED command with data direction flag set to "to the device" and with random size buffer filled with random data. Set the following values in the CDB.
    • RotationalControl = 0, ReadSpeed = 0xFFFF, WriteSpeed = (((4* 75 * 2352) + 500) / 1000)

Result: The drive should properly implement the SET CD SPEED command for the applicable media types.

READ10 COMMAND

Description: To validate if the drive supports the READ10 command for the reported profile.

Applicable Media:

  • DVD-ROM

  • CD-ROM

Test Case Steps:

  1. Send READ TOC/PMA/ATIP command with Allocation Length equal the size of the READ TOC response header ( 4 bytes)

  2. Send READ TOC/PMA/ATIP command with Allocation Length equal the size of the READ TOC response header ( 4 bytes) + the Data Length from the Response Header from step 1.

  3. Check all the formatted Read TOC descriptors, if any of its control is set to 0x04

  4. If not found then fail the test case

  5. Otherwise get the track starting address from the formatted Toc track descriptor.

  6. Send the Read Capacity command with LBA field set to zero, to get the Block size.

  7. Send the Read Command with the Transfer Length set to zero and Starting LBA set to the LBA from step 5.

  8. Calculate the number of blocks to read

  9. If the LBA in the Read capacity response is less than the LBA from the step 5 then the number of blocks to read is set to 0

  10. If the LBA in the Read capacity response is greater than the LBA from the step 5 then

    Set the number of blocks to read equal to difference between the LBA from the read capacity response and the LBA from step 5. If that value is greater than 50, set the number of blocks to read to 50.

  11. Set the Starting LBA in the read 10 CDB to the LBA from step 5

  12. Send the read10 command with transfer length set to 1

  13. Sleep for 10 milliseconds

  14. Increment the starting LBA in the read 10 CDB

  15. Repeat steps 12 to 14 until we read all the number of blocks.

  16. [Optional] Send the READ10 command with data direction flag set to "to the device" and with random size buffer filled with random data. Set the following values in the CDB.
    • TransferLength = 1, Starting LBA = Random LBA value in the LBA range of Number of LBAs from step 8 with starting LBA from the step 5.

Result: The drive should properly implement the READ10 command for the applicable media types.

Scenario Test Cases

EVENT NOTIFICATION

Description: To validate if the device event notification are properly reported to the windows PNP.

Applicable Media: Any media supported by the device.

Test Case Steps:

  1. If BusType field of the drive's STORAGE_ADAPTER_DESCRIPTOR structure is set to BusTypeSata then send IOCTL_ATA_PASS_THROUGH with request for Identify Packet Device Information data. In the response check that bit 5 of word 78 (Asynchronous Notification feature is supported) and bit 5 of word 79 (Asynchronous Notification feature is enabled) are both set. Otherwise fail the test

  2. Register for Operational Change event.

  3. Check if the media is present.

  4. If the media is present, eject media.

  5. Wait for the MEDIA REMOVAL event. If the event is not generated within 60 seconds timeout then fail the test case.

  6. Inject the media to the drive.

  7. Wait for the MEDIA ARRIVAL event. If the event is not generated within 60 seconds timeout then fail the test case.

Result: The drive should properly implement the event notifications.

WRITE TESTS

Description: Validates the write capabilities of the drive for the data content in the context of IMAPI. The device is tested with various write speeds reported by the drive. The test also validates the multisession capabilities of the device is applicable for the inserted media.

Applicable Media:

  • Sequential writing:

    CD-R

    CD-RW

    DVD+R

    DVD-R

    DVD-RAM

    BD-R

    BD-RE

  • Restricted overwrite:

    DVD-RW

  • Packet mode:

    DVD+RW

  • Multisession:

    CD-R

    CD-RW

    DVD-R

    DVD+R

    BD-R

Test Case Steps:

  1. Ask the user to insert blank media.

  2. Call the API IDiscFormat2Data::get_CurrentMediaStatus to check if the media is blank.

  3. If the media is not blank and if it is one of the following rewriteable media type, then erase the media by sending the blank command with a minimal blank option.
    • CD-RW
    • DVD-RW Sequential Recording
    • DVD-RW Restricted Overwrite
    • DVD+RW
    • DVD-RAM
    • BD-RE

  4. If the media is not a rewritable media then ask the user to insert the blank media. Retry this for 3 times, otherwise fail the test case.

  5. Get the list of Write Speed Descriptors by calling the API IDiscFormat2Data::get_SupportedWriteSpeedDescriptors.

  6. Randomize the order of the reported write speeds

  7. Set the Write Speed by calling the API IDiscFormat2Data::SetWriteSpeed with one of the write speeds from step 6.

  8. Create a random data size with the range of 10% of the available space on the media. Fill the buffer with random data.

  9. Get the number of free blocks on the disc using the API IDiscFormat2Data::get_FreeSectorsOnMedia.

  10. Get the next writable address using the API IDiscFormat2Data::get_NextWritableAddress.

  11. Write the data buffer from step 8 using IDiscFormat2Data::Write.

  12. If the drive supports Auto eject-inject mechanism then eject and inject the media into the tray.

  13. If the media is not DVD-RW, DVD+RW, DVD-RAM, BD-RE then
    • Get the number of free blocks on the disc using the API IDiscFormat2Data::get_FreeSectorsOnMedia.
    • Check if the number of free sectors is less than the value from step 9 by the size of write data in step 8.
    • Get the next writable address using the API IDiscFormat2Data::get_NextWritableAddress.
    • Check next writable address is greater than the next writable address from step 10 by the size of the write data in step 8.
    • Read data from the disc and compare if it matches with the data written to the media in step 11.

  14. Get the last Track Information

  15. If the media is not DVD-RW then check if the Logical Track Size if greater than or equal to size of the data we wrote.

  16. Check if the Logical track number is correct

  17. Get the Write parameters mode page

  18. Check if the Track information reported by the drive is not Packet/Incremental if the Write parameters mode page reports as Fixed packet

  19. Read disc information and check if the number of session matches.

  20. If the media is not DVD-RW, DVD+RW and DVD-RAM then repeat steps 7 to 19 for each write speed. If the drive returned only one write speed then repeat steps 7 to 19 one more time to add one more session to the disc for validating the multisession capabilities.

Result: The drive should be capable of burning the data in the context of IMAPI.

AUDIO MEDIA (WRITE AUDIO TRACKS)

Description: Validate the write capabilities of the drive for the audio content in the context of IMAPI.

Applicable Media:

  • CD-R

  • CD-RW

Test Case Steps:

  1. If the media is not blank and if it is CD-RW media type, then erase the media by sending the blank command with a minimal blank option.

  2. If the media is not a rewritable media then ask the user to insert the blank media. Retry this for 3 times, otherwise fail the test case.

  3. Lock the Media for Exclusive Access by calling DiscFormat2TrackAtOnce::PrepareMedia.

  4. Get the list of Write Speed Descriptors by calling the API IDiscFormat2TrackAtOnce::get_SupportedWriteSpeeds.

  5. Choose random number of audio tracks between 3 and 10.

  6. Randomize the order of the reported write speeds.

  7. Set the Write Speed by calling the API IDiscFormat2TrackAtOnce::SetWriteSpeed from step 1.

  8. Get the number of free blocks on the disc using the API IDiscFormat2Data::get_FreeSectorsOnMedia.

  9. Create audio data of random size from 1 minute audio data to 10 minute audio data. The size of the data should be a multiple of 2352.

  10. Add the audio data stream to the IDiscFormat2TrackAtOnce::AddAudioTrack.

  11. Get the last track Information

  12. Check if the Logical track size if greater than or equal to size of the audio track we wrote.

  13. Check if the Logical track number is correct

  14. Get the number of free sectors on the media by calling IDiscFormat2TrackAtOnce::FreeSectorsOnMedia.

  15. Check if the number of free sectors from step 14 is less than value from step 8 by the size of the audio track written to the media.

  16. Repeat steps 5 to 15 for the number audio tracks from step 5

  17. Get the Write parameters mode page

  18. Check if the Track information reported by the drive is not Packet/Incremental if the Write parameters mode page reports as Fixed packet

  19. Repeat steps 1 to 18 for each Write Speed.

  20. If the drive supports Auto eject-inject mechanism then eject and inject the media into the tray.

Result: The drive should be capable of burning the audio media in the context of IMAPI.

BLANK

Description: Validate the format/blank capabilities of the drive in the context of IMAPI.

Applicable Media:

  • CD-RW

  • DVD+RW

  • DVD-RW Restricted Overwrite

  • BD-RE

Test Case Steps:

  1. Check if the media is one of the following read write media type by calling the API IDiscFormat2Data::CurrentPhysicalMediaType
    • CD-RW
    • DVD-RW
    • DVD+RW

  2. If the media is not one of the read write media type then skip the test case.

  3. Check if the media is a blank media by calling the API IDiscFormat2Erase::MediaPhysicallyBlank

  4. If the media is non blank then go to step 7.

  5. Create 25MB random data stream.

  6. Write the data stream to the disc using the API IDiscFormat2Data::Write

  7. Check if the drive reports the media as non-blank media by calling the IDiscFormat2Data::get_CurrentMediaStatus API.

  8. If the drive still reports media as blank then fail the test case

  9. Implement Erase Event Handler DDiscFormat2EraseEvents::Update

  10. Call the API IDiscFormat2Erase::put_FullErase and set the erase option to false, so that it will do a minimal blank.

  11. Send the blank command using the IDiscFormat2Erase::EraseMedia API

  12. Wait on the events until the elapsed time is zero.

  13. Call the API IDiscFormat2Data::get_CurrentMediaStatus to check if the media is blank.

  14. Read disc information and check if the
    • Number of sessions reported is 1.
    • The first track in the last session is 1.
    • The last track in the last session is 1.

  15. Call the API IDiscFormat2Erase::put_FullErase and set the erase option to full blank. Repeat steps 9 to 14.

Result: The drive should be capable of formatting the media in the context of IMAPI.

WRITE DUAL LAYER MEDIA

Description: Validates the write capabilities of the for the dual layer media in the context of IMAPI. The device is tested with various write speeds reported by the drive.

Applicable Media:

  • DVD+R DL

  • DVD-R DL

Test Case Steps:

  1. Ask the user to insert blank media.

  2. Call the API IDiscFormat2Data::get_CurrentMediaStatus to check if the media is blank.

  3. If the media is not a rewritable media then ask the user to insert the blank media. Retry this for 3 times, otherwise fail the test case.

  4. Get the list of Write Speed Descriptors by calling the API IDiscFormat2Data :: get_SupportedWriteSpeedDescriptors.

  5. Randomize the order of the reported write speeds

  6. Set the Write Speed by calling the API IDiscFormat2Data::SetWriteSpeed with one of the write speeds from step 5.

  7. Create a random data stream of random size up to 50% of the available space on the media. Fill the buffer with random data.

  8. Write the data buffer from step 7 using IDiscFormat2Data :: Write.

  9. If the drive supports auto eject-inject mechanism then eject and inject the media into the tray.

  10. Read data from the disc and compare if it matches with the data written to the media in step 9.

  11. Get the last Track Information

  12. Check if the Logical Track Size if greater than or equal to size of the data we wrote.

  13. Check if the Logical track number is correct

  14. Get the Write parameters mode page

  15. Check if the Track information reported by the drive is not Packet/Incremental if the Write parameters mode page reports as Fixed packet

  16. Read disc information and check if the number of session matches.

  17. Repeat steps 8 to 16 with random data stream of random size up to 100% of the available space on the media.
    • Purpose: To test if the drive is able to write the data on dual layer properly.

Result: The drive should be capable of burning the data to both layers of the Dual Layer media in the context of IMAPI.

READ ONLY DRIVE

Description: Test the read capability of a read only drive on a open (append able) and closed (finalized) disc.

Applicable Media:

  • BD-ROM

  • DVD-ROM

  • CD-ROM

Setup: This test case requires a secondary writer drive for creating the test data disc for the corresponding test profile.

Test Case Steps:

  1. Eject the writer drive tray.

  2. If the test profile is
    • BD-ROM ask the user to insert BD-R/ BD-RE in the writer drive.
    • DVD-ROM ask the user to insert DVD+R/DVD-R/DVD+RW/DVD-RAM in the writer drive.
    • CD-ROM ask the user to insert CD-R/CD-RW in the writer drive.

  3. Inject the writer drive tray.

  4. Get the list of Write Speed Descriptors by calling the API IDiscFormat2Data :: get_SupportedWriteSpeedDescriptors.

  5. Create a random data stream of random size up to 10% of the available space on the media. Fill the buffer with random data.

  6. Set the Write Speed by calling the API IDiscFormat2Data::SetWriteSpeed with the first write speed descriptor value from step 4.

  7. Write the data buffer from step 5 using IDiscFormat2Data::Write to the media in the writer drive.

  8. Eject the writer drive tray if it supports auto eject mechanism. Otherwise ask the user to press the eject button.

  9. Eject the test drive tray if it supports auto eject mechanism eject the tray otherwise ask the user to press the eject button.

  10. Ask the use to remove the media from the writer drive and place it in the test drive.

  11. Inject the writer drive tray if it supports auto inject (loading the tray) mechanism. Otherwise ask the user to insert the tray into the drive.

  12. Inject the test drive tray if it supports auto inject (loading the tray) mechanism. Otherwise ask the user to insert the tray into the drive.

  13. Read data from the test drive disc and compare if it matches with the data written to the media in step 7.

  14. Set the IDiscFormat2Data::ForceMediaToBeClosed to true and Repeat steps 1 to 13 to validate the test drive on a finalized disc.

Result: The drive should be capable of reading both the closed and open media.

DRIVE SERIAL NUMBER

Description: Validate the drive serial number returned by the test drive is in compliance with the MMC/Mt. Fuji specification standards.

Applicable Media: Any media supported by the device.

Setup: This test case requires two identical drives to validate if both drives return unique serial numbers. One primary test device and the other one is a secondary test drive.

Test Case Steps:

  1. Send the INQUIRY command to the primary test device with the allocation length equal 05h.

  2. If the command succeeds, get the additional length value from the response header.

  3. Send the INQUIRY command again to the primary device with allocation length set to 5 bytes more than the additional length from step 2.

  4. If the command succeeds get the Vendor Identification, Product Identification and Product Revision Level.

  5. Repeat the step 1 to 4 for the secondary drive and get the Vendor Identification, Product Identification and Product Revision Level.

  6. Compare the Vendor Identification, Product Identification and Product Revision Level values from step 4 and step 5. If they do not match then fail the test case.
    • Purpose: This is to make sure both the test drives are identical.

  7. Send the GET CONFIGURATION command to the primary test drive to get the LOGICAL UNIT SERIAL NUMBER feature with allocation length equal to the size of the LOGICAL UNIT SERIAL NUMBER feature descriptor.

  8. Check the response if the feature code matches with the LOGICAL UNIT SERIAL NUMBER feature code. Get the additional length.

  9. Send the GET CONFIGURATION command to the primary test drive to get the LOGICAL UNIT SERIAL NUMBER feature with allocation length equal to the size of the LOGICAL UNIT SERIAL NUMBER feature descriptor plus the required additional length reported in step 8.

  10. Check the following in the response
    • The feature code matches with the LOGICAL UNIT SERIAL NUMBER feature code.
    • The reported serial number data is in ASCII.
    • Data is padded.
    • No data after padding.

  11. Repeat 7 to 9 for the secondary test device and get the drive serial number.

  12. Compare the drive serial numbers from step 10 and step 11. The drives are expected to return unique serial numbers. If both the serial numbers are equal then fail the test case.

Result: The drive should return a unique serial number and that number should be in compliance with the MMC/Mt. Fuji standards.

REAL TIME STREAMING

Description: Validate the real-time streaming capabilities of the drive for the data content in the context of cdrom.sys driver. The device is tested with various read and write speeds reported by the drive.

Applicable Media: Any media supported by the device.

Test Case Steps:

  1. Ask the user to insert media.

  2. If media is not writable or rewritable proceed to reading test at step 13.

  3. Call the API IDiscFormat2Data::get_CurrentMediaStatus to check if the media is blank.

  4. If the media is not blank and if it is one of the following rewritable media type, then erase the media by sending the blank command with a minimal blank option.
    1. CD-RW
    2. DVD-RW Sequential Recording
    3. DVD-RW Restricted Overwrite
    4. DVD+RW
    5. DVD-RAM
    6. BD-RE

  5. If the media is not a rewritable media then ask the user to insert the blank media. Retry this for 3 times, otherwise fail the test case.

  6. Send GET CONFIGURATION command with request for REAL TIME STREAMING feature. If it is not successful or Current bit is not set fail the test.

  7. If either Stream Writing (SW) bit or Write Speed Performance Descriptor (WSPD) bit of REAL TIME STREAMING feature response is not set then fail the test.

  8. Send GET PERFORMANCE command with request for Write Speed Descriptors and build and array of supported write speeds. If the command is not successful fail the test.

  9. Shuffle the write speed array.

  10. IF free media size is over 10% of its full capacity call DeviceIoControl with IOCTL_CDROM_SET_SPEED and CDROM_SET_STREAMING structure supplied for the next write speed. Write random data up to 10% of full capacity and measure the speed (refer to the corresponding section in this document for measuring procedure description).

  11. Repeat step 10 as long as possible. If all write speeds are probed shuffle the speed array and set next write speed to the beginning.

  12. Send CLOSE TRACK SESSION commands to finalize the media.

  13. If Write Speed Performance Descriptor (WSPD) bit of REAL TIME STREAMING feature response is set then send GET PERFORMANCE command with request for Write Speed Descriptors and build an array of supported read speeds otherwise send GET PERFORMANCE command with request for Performance data with Tolerance bits set to 10b (nominal) and for the read speeds select the lowest value of Start Performance and End Performance fields in the response. If either of the commands I not successful fail the test.

  14. Shuffle the read speed array.

  15. Set the read length to size of the first track on media.

  16. For each read speed call DeviceIoControl with IOCTL_CDROM_SET_SPEED and CDROM_SET_STREAMING structure supplied for the next read speed. Read the whole data recorded on media in chunks of 10% of media capacity (or at least 5 MB if media has less than 50 MB of data) and measure the speed of each chunk. If the actual speed of any chunk is below the requested speed for any of the chunks mark the test failed.

Result: The drive should be capable of operating in real-time streaming mode.

Additional Test Details

WRITE SPEED MEASUREMENT

The test queries the device and gets the supported write speeds for the test media. Then it will try to validate the write scenario for all the reported write speeds. The test expects the calculated write speeds for each write scenario is close to the write speed set to the drive. The test allows 10% tolerance for the measured write speed. The test validates the write speed as below:

The test writes data to the media and monitors the amount of data being written. It excludes the timing for the initial 10% written data the final 10% written data. It measures the timing only for the middle 80% data and calculates the speed for that data and adds 10% tolerance to that value. So, if 'x' is the calculated the speed for the middle 80% data then the final calculated speed is 1.1x. The test expects this value to be greater than or equal to the speed set to the drive before beginning the write, as shown in the following chart.

Chart of the results of a written data test

The test excludes the initial 10% of data written timing to allow the drive to prepare for writing. The final 10% data timing is excluded to allow the drive to do the proper cleanup for the data written to the media.

AUDIO MEDIA GAPLESS RAW RECORDING

Description: Validates the write capabilities of the drive for the gapless raw audio content in the context of IMAPI.

Applicable Media:

  • CD-R

  • CD-RW

Test Case Steps:

  1. Check if the drive with media inserted supports gapless raw recording or not. If it's not supported, testing will fail.

  2. Check the sector types supported by test drive.

  3. For each sector type supported by test drive, complete steps 4 through 9

  4. Create the raw image.

  5. Set correct sector type and create the result stream for the raw image.

  6. Determine whether the raw image is gapless or not.

  7. Randomly choose a write speed and set it to be the burning speed. Set the requested sector type to be the one that has been set for the raw image. Write the stream of the raw image to the media and watch the progress. Calculate the speed of burning and print the throughput.

  8. Determine whether the writing is successful by checking each logical track information. Check if the track is audio track, if the track size is correct, and if the size of the last logical track number plus its start address is equal to the start address of the lead out of the disc. If any of the conditions returns false, testing will fail. Otherwise, it will pass.

  9. Do a raw reading for the media. For each track, check if the track is audio. If it's not, fail the testing, because the recording already ensured that the tracks are audio tracks. Calculate the start offset and end offset of the track. Do the reading for the track starting from the start offset and ending at the end offset of the track. If an error occurs during the reading process, fail the testing;

Result: The drive should be able to burn the gapless raw audio image in the context of IMAPI.


Relative Open Test

Overview

The Relative Open Test uses NtCreateFile to open handles to a volume, directory, stream, and reparse point. It then uses relative open to create files and alternate data streams on these handles. The test is intended for file system driver developers who want to verify that their drivers comply with a standard set of expected file system functionality.

Details

Same as the preceding description.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running Relative Open Test

Volumes must be created as described in the Manual Test Steps. To run the test, select the "Relative Open Test" job and schedule it. Modify the parameters to include the appropriate drive letters for each file system type.


SATA IO Sig Test

Type: Automated Test

Overview

The SATA IO Sig 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. You must provide this key, and the test will review it for validity.
Run Time: 1 minute
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running SATA IO Sig Test

Provide your SATA IO certification key.

Command Syntax

Command option | Description
cscript satasig.vbs [deviceID] |

Code Tour

File Manifest

File | Location
satasig.vbs | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk


SCSI Compliance test

Type: Automated Test

Overview

The SCSI Compliance test verifies that a block storage device (RAID adapter or disk target) that is supported by the operating system fully complies with the SCSI standards described in the SCSI-3 Primary Commands-2 (SPC-2) or later, and SCSI Block Commands (SBC) or later specifications. To obtain these specifications, see the T10 Technical Committee Web site at T10 Technical Committee. Ensuring that the block device and the operating system maintain compliance with these standards makes for a more robust and reliable system. Although some block devices might not be using a SCSI transport, the operating system communicates with them using SCSI commands (the exception is individual ATA disk drives that are not part of a RAID set).

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.

Note If you are running this test as a part of Storage RAID Hardware-based RAID (Storage Array) submission, and your storage array supports Multi-Path I/O (MPIO), you must configure your MPIO to use Fail-Over Only policy, and set the target storage disk to use the same active path for all MPIO'ed disks.

Note If you are running this test as a part of a Storage RAID Hardware-based RAID (Storage Array) submission, please make sure that LUN0 is configured as the largest size non-boot LUN.

Details

The SCSI Compliance test consists of several phases: setup, device enumeration, execution, and results reporting. The test operates in two modes:

  • A non-destructive test run against one or more devices.

  • A destructive (allows WRITE commands) 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. For debugging purposes, the level of output verbosity can be increased when the test is run interactively. It is designed to provide complete information for the submitter so that they can address command issues.

Functionality Testing

The test sends the following commands to the device. The test runs a variety of tests for each command descriptor block (CDB) to ensure full and complete compliance. Commands that are indicated as optional must still perform correctly if a vendor chooses to implement the command. Each command may have many subtests.

INQUIRY

REQUEST SENSE

MODE SENSE (6)

MODE SENSE (10) [Optional, except if MODE SENSE (6) can return > 255 bytes of information]

MODE SELECT (6) [Optional]

MODE SELECT (10) [Optional]

RESERVE (6) [prior to Vista only]

RELEASE (6) [prior to Vista only]

READ CAPACITY

LONGLBA Support [Optional]

READ (6) [Optional]

READ (10)

READ (16) [Optional]

WRITE (6) [Optional]

WRITE (10)

WRITE (10) with FUA bit

WRITE (16) [Optional]

WRITE (16) with FUA bit [Optional]

REPORT LUNS [required except for PCI RAID adapters]

PERSISTENT RESERVE IN / OUT

Robustness and Reliability Testing

To validate robustness and reliability, the test completes the following tasks:

  • 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: 5 minutes*
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Microsoft Windows XP Professional with Service Pack 2 (SP2); Microsoft Windows Server 2003, Enterprise Edition; or Microsoft Windows Server 2003, Datacenter Edition

  • Any drivers that are not shipped with the Microsoft Windows operating system

  • The current release of the Microsoft Windows Driver Kit

  • The latest version of the Microsoft iSCSI software initiator. To download the iSCSI software initiator, search for "iSCSI software initiator" at the Microsoft Download Center. The latest version of the Microsoft iSNS server.To download the Microsoft iSNS server, search for "iSNS" at the Microsoft Download Center.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • The system requires one or more SCSI, iSCSI, or Fibre Channel disks attached to the test system.

  • Microsoft Windows XP Professional with Service Pack 2 (SP2); Microsoft Windows Server 2003, Enterprise Edition; or Microsoft Windows Server 2003, Datacenter Edition. Any drivers that are not shipped with the Microsoft Windows operating system. The current release of the Microsoft Windows Driver Kit. The latest version of the Microsoft iSCSI software initiator. To download the iSCSI software initiator, search for "iSCSI software initiator" at the Microsoft Download Center. The latest version of the Microsoft iSNS server. To download the Microsoft iSNS server, search for "iSNS" at the Microsoft Download Center.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running SCSI Compliance test

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.

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 with the SCSI specification.

  • The optional SCSI commands that are 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 the 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 20SPC-3 (SCSI Primary Commands - 3)SCSI Block Commands - 2 (SBC-2)SCSI Architecture Model - 3 (SAM-3)

Code Tour

File Manifest

File | Location
scsicompliancetest.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Test Assertions

1.1 INQUIRY Basic Verification Test
Test Assertion GUID: 6bfd171e-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol requirements
2.14 MODE SENSE (6) Checking Power Condition Mode Page.
Test Assertion GUID: 6bfd1742-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
2.15 MODE SENSE (6) Checking Caching Mode Page.
Test Assertion GUID: 6bfd1743-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: [Deleted]
4.10 MODE SELECT (6) Changing WCE.
Test Assertion GUID: 6bfd1757-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol requirements
Additional Information:
4.16 MODE SELECT (6) Attempting to restore original values.
Test Assertion GUID: 6bfd175d-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol requirements
5.10 MODE SELECT (10) Changing WCE.
Test Assertion GUID: 6bfd1768-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol requirements
5.16 MODE SELECT (10) Attempting to restore original values.
Test Assertion GUID: 6bfd176e-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol requirements
9.3 READ CAPACITY (10) Negative Test
Test Assertion GUID: 6bfd177f-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
10.1 REQUEST SENSE (6) Support Test
Test Assertion GUID: 6bfd1780-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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 command 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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 except INQUIRY should return RESERVATION CONFLICT.
15.8 Multi-Initiator.
Test Assertion GUID: 6bfd179d-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol 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-0003 SCSI based devices meet SCSI protocol requirements
Additional Information:
18.1 REPORT LUNS Basic Verification Test.
Test Assertion GUID: 6bfd17a1-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Finds the device object associated with LUN 0 (either a disk or the adapter) and sends a REPORT LUNS command for 16 bytes (required minimum).
18.2 REPORT LUNS Basic Verification Test.
Test Assertion GUID: 6bfd17a2-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Validates the data size based on the size of the data returned.
18.3 REPORT LUNS Test for correct format.
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Validates that each LUN reported is correctly formatted.
19.1 PERSISTENT RESERVE OUT : REGISTER AND IGNORE EXISTING KEY Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies support for PERSISTENT RESERVE OUT command with service action REGISTER AND IGNORE EXISTING KEY. Apply: Establishes a new registration on the device. Expect: The command should return with GOOD status.
19.2 PERSISTENT RESERVE IN : READ KEYS Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies support for PERSISTENT RESERVE IN command with service action READ KEYS. Apply: Queries device for list of registered initiators. Expect: The command should return data with at least 16 bytes, in increments of 8 bytes, and GOOD status.
19.3 PERSISTENT RESERVE IN : READ KEYS Functional Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies functionality of PERSISTENT RESERVE IN command with service action READ KEYS by checking the list of registered initiators for a previously known key (from assertion 19.1). Apply: Queries device for a list of registered initiators. Expect: The device should return data of same size as before, with GOOD status, and the previously registered key should be in the list.
19.4 PERSISTENT RESERVE OUT : RESERVE Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
19.5 PERSISTENT RESERVE IN : READ RESERVATION Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Validates command PERSISTENT RESERVE IN with service action READ RESERVATION based on expected results and size of data. Apply: Queries device for information about current reservations. Expect: Command should return data with at least 16 bytes, in multiples of 8 bytes, and GOOD status.
19.6 PERSISTENT RESERVE IN : READ RESERVATION Functional Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies functionality of command PERSISTENT RESERVE IN with service action READ RESERVATION by checking the list of current reservations against the previously known reserved key (from assertion 19.4). Apply: Queries device for list of current reservations. Test: Data should be same length as before, the previously registered key should be in the list, and the command should return GOOD status.
19.7 PERSISTENT RESERVE OUT : RELEASE Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies command PERSISTENT RESERVE OUT with service action RELEASE by releasing previous reserve (from assertion 19.4). Apply: Instructs device to release the previous reserve on LUN 0, element 1, with type write exclusive (registrants only). Test: The command should return GOOD status.
19.8 PERSISTENT RESERVE IN : READ RESERVATION
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies command PERSISTENT RESERVE IN with service action READ RESERVATION by checking that the key has been removed from list of reservations (in assertion 19.7). Apply: Queries device for list of current reservations. Expect: Command should return list not containing previous key, with GOOD status.
19.9 PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Checks to see if command PERSISTENT RESERVE IN with service action READ KEYS returns list with previously registered key (assertion 19.1). Apply: Requests a list of keys for registered initiators from device. Expect: The command should return list containing previously registered key.
19.10 PERSISTENT RESERVE OUT : REGISTER Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Checks to see if command PERSISTENT RESERVE OUT with service action REGISTER accepts registration of key with value 0x0. Apply: Registers an initiator with key 0. Expect: The command should return with GOOD status.
19.11 PERSISTENT RESERVE IN : READ KEYS Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies command PERSISTENT RESERVE IN with service action READ KEYS by checking list of keys for invalid entries resulting from assertion 19.10. Apply: Queries device for list of registered initiators. Expect: The command should return a list of keys without either the null key 0x0 or previous known key.
19.12 PERSISTENT RESERVE OUT : REGISTER AND IGNORE EXISTING KEY Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies support for PERSISTENT RESERVE OUT command with service action REGISTER AND IGNORE EXISTING KEY, and with APTPL bit set to 1. Apply: Establishes a new registration on the device, with activate persist through power loss option turned on. Expect: The command should either return GOOD status, or CHECK CONDITION with ILLEGAL REQUEST if unsupported.
19.13 PERSISTENT RESERVE IN : READ KEYS Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies functionality of PERSISTENT RESERVE IN command with service action READ KEYS by checking the list of registered initiators for a previously known key (from assertion 19.12). Apply: Queries device for a list of registered initiators. Expect: The device should return data of same size as before, with GOOD status, and the previously registered key should be in the list.
19.14 PERSISTENT RESERVE OUT : RESERVE Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies support for command PERSISTENT RESERVE OUT with service action RESERVE, using key from assertion 19.12. Apply: Request a reserve for previously known key on LUN 0, element 1, with type write exclusive (registrants only). Expect: The command should return GOOD status.
19.15 PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies correct return value for PERSISTENT RESERVE IN command with READ RESERVATION service action. Apply: Queries device for information about current reservations. Expect: List should contain the key reserved in 19.14 and the command should return GOOD status.
19.16 PERSISTENT RESERVE OUT : CLEAR Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies support for PERSISTENT RESERVE OUT command with CLEAR service action. Apply: Instructs device to clear all reserves for LUN 0. Expect: Command should return GOOD status.
19.17 PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies PERSISTENT RESERVE IN command with READ RESERVATION service action for correct return value. Apply: Queries device for list of reserves. Expect: The list should not contain the key which was cleared in assertion 19.16 and the command should return with GOOD status.
19.18 PERSISTENT RESERVE IN : READ KEYS Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies PERSISTENT RESERVE IN command with READ KEYS service action for correct return value. Apply: Queries device for list of registered initiators. Expect: The list should not contain the key which was cleared in assertion 19.16 and the command should return with GOOD status.
19.19 PERSISTENT RESERVE OUT : REGISTER AND IGNORE EXISTING KEY Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies support for PERSISTENT RESERVE OUT command with service action REGISTER AND IGNORE EXISTING KEY. Apply: Establishes a new registration on the device. Expect: The command should return with GOOD status.
19.20 PERSISTENT RESERVE IN : READ KEYS Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies functionality of PERSISTENT RESERVE IN command with service action READ KEYS by checking the list of registered initiators for a previously known key (from assertion 19.19). Apply: Queries device for a list of registered initiators. Expect: The list should contain the previously registered key, and the command should return with GOOD status.
19.21 PERSISTENT RESERVE OUT : RESERVE Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies support for PERSISTENT RESERVE OUT command with service action RESERVE. Apply: Request a reserve for key registered in assertion 19.19, on LUN 0, element 1, with type write exclusive (registrants only). Expect: The command should return GOOD status.
19.22 PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies functionality of command PERSISTENT RESERVE IN with service action READ RESERVATION by checking the list of current reservations against the previously known reserved key. Apply: Queries device for list of current reservations. Test: The list should contain the key which was reserved in assertion 19.21, and the command should return GOOD status.
19.23 PERSISTENT RESERVE OUT : PREEMPT Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies support for command PERSISTENT RESERVE OUT with service action PREEMPT. Apply: Instructs device to preempt previously created peristent reservation on Lun 0, with type write exclusive (registrants only). Expect: The command should return with GOOD status.
19.24 PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies command PERSISTENT RESERVE IN with service action READ RESERVATION by checking that the key has been removed from list of reservations. Apply: Queries device for list of current reservations. Expect: The list should not contain the key reserved in assertion 19.21, and the command should return with GOOD status.
19.25 PERSISTENT RESERVE IN : READ KEYS Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Checks to see if command PERSISTENT RESERVE IN with service action READ KEYS returns list with previously registered key. Apply: Requests a list of registered initiators from device. Expect: The list should contain the key registered in assertion 19.21, and the command should return with GOOD status.
19.26 PERSISTENT RESERVE OUT : PREEMPT AND ABORT Support Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies support for PERSISTENT RESERVE OUT command with service action PREEMPT AND ABORT. Apply: Sends command to device for LUN 0, type write exclusive (reigstrants only). Expect: Command should return GOOD status.
19.27 PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies correct results for PERSISTENT RESERVE IN command with service action READ RESERVATION. Apply: Queries device for list of current reservation keys. Expect: List should contain key reserved in assertion 19.21.
19.28 PERSISTENT RESERVE IN : READ KEYS Verification Test
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601
Windows Logo Program: STORAGE-0003 SCSI based devices meet SCSI protocol requirements
Additional Information: Test: Verifies correct result for PERSISTENT RESERVE IN command with service action READ KEYS. Apply: Queries device for list of registered initiators. Expect: The list should contain the key previously registered in assertion 19.19, and the command should return with GOOD status.


SCSI Compliance Test 2.0 (LOGO)

Type: Automated test

Overview

The SCSI Compliance test verifies that a block storage device (RAID adapter or disk target) that is supported by the operating system fully complies with the Small Computer System Interface (SCSI) standards described in the SCSI-3 Primary Commands-3 (SPC-3) or later, and SCSI Block Commands-2 (SBC-2) or later specifications. To obtain these specifications, see the T10 Technical Committee website at T10 Technical Committee (t10.org). Ensuring that the block device and the operating system maintain compliance with these standards results in a more robust and reliable system. Although some block devices might not be using a SCSI transport, the operating system communicates with them using SCSI commands (except for individual ATA disk drives that are not part of a RAID set).

The test uses SCSI pass-through requests (IOCTL_SCSI_PASS_THROUGH) to construct and send SCSI command descriptor blocks (CDBs) to the device. The test evaluates the results of the commands to verify compliance.

Note If you are running this test as a part of a Storage RAID Hardware-based RAID (Storage Array) submission, and your storage array supports Multipath I/O (MPIO), you must configure your MPIO to use Fail-Over Only policy, and set the target storage disk to use the same active path for all MPIO-capable disks.

Note If you are running this test as a part of a Storage RAID Hardware-based RAID (Storage Array) submission, please make sure that LUN0 is configured as the largest size non-boot LUN.

Details

The SCSI Compliance test consists of several phases: setup, device enumeration, execution, and results reporting. The test operates in the following modes:

  • A non-destructive test run against one or more devices.
  • A destructive (allows WRITE commands) test that targets one or more specified disks.

Multiple 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. For debugging purposes, the length of output can be increased when the test is run interactively. It is designed to provide complete information for the submitter, so that they can address command issues.

Functionality Testing

The test sends the following commands to the device. The test runs a variety of tests for each command descriptor block (CDB) to ensure full and complete compliance. Commands that are indicated as optional must still perform correctly if you choose to implement the command. Each command can have many subtests.

TEST UNIT READY
REQUEST SENSE
FORMAT UNIT
READ (6)
WRITE (6)
INQUIRY
MODE SELECT
MODE SENSE
START STOP UNIT
PREVENT ALLOW MEDIUM REMOVAL
READ CAPACITY
READ (10)
WRITE (10)
MODE SELECT (10)
MODE SENSE (10)
PERSISTENT RESERVE IN/OUT
READ (16)
WRITE (16)
READ CAPACTIY (16)
REPORT LUNS
SECURITY PROTOCOL IN/OUT
REPORT TARGET PORT GROUPS
SET TARGET PORT GROUPS
REPORT SUPPORTED OPCODE CLEAR
Run time: 10 minutes
Log file: Scsicompliance.wtl
System restart required: No
Supported operating systems for logo or signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: Scsicompliance.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Any drivers that are not shipped with the Windows operating system
  • The current release of the Windows Driver Kit
  • The latest version of the Microsoft iSCSI software initiator. To download the iSCSI software initiator, search for “iSCSI software initiator” at the Microsoft Download Center.
  • The latest version of the Microsoft iSNS server. To download the Microsoft iSNS server, search for “iSNS” at the Microsoft Download Center.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard disk drive with a minimum of 20 GB available on partition C:
  • The system requires one or more SCSI, iSCSI, or Fibre Channel disks attached to the test system.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Run the test as a Driver Test Manager (DTM) job.

Command Syntax

Command option | Description
scsicompliance.exe | Should be followed by options.
/device [string] | Specifies the device to be tested.
/logoprogram [string] | Specifies the type of logo program of the device to certify.
/scenario [string] | Specifies the scenario test to be run. For example, unittest or discoverytest.
[options] | Other options, which can be accessed by /? option.

Code Tour

File Manifest

File | Location
scsicompliance.exe | [testbinroot]\nttest\driverstest\storage\wdk\

Test Assertions

Title: ASSERTION: TEST UNIT READY Basic Verification Test
Description: The TEST UNIT READY command provides a means to check whether the logical unit is ready. This is not a request for a self-test. If the logical unit is able to accept an appropriate medium-access command without returning CHECK CONDITION status, this command shall return a GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.33 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: REQUEST SENSE (6) Support Test
Description: Checking to see whether Request Sense Command is supported and returns GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.27 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: REQUEST SENSE (6) RESPONSE CODE Test
Description: Verify that RESPONSE CODE is either 0x70 or 0x71 or 0x72 or 0x73.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.27 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: RESPONSE CODE == 0x70 or RESPONSE CODE == 0x71 or RESPONSE CODE == 0x72 or RESPONSE CODE == 0x73
Title: ASSERTION: REQUEST SENSE (6) Sense Data Length Test
Description: Verify that length of SENSE data is correct (data transferred matches data length reported by the command response).
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.27 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Additional Sense Length = Sense data size - 8
Title: ASSERTION: FORMAT UNIT test with Type 1 Protection
Description: Format Unit with longlist=0, fmtdata=0, cmplist=0, defect list format=0 and type 1 protection
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.2 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: FORMAT UNIT test with Type 2 Protection
Description: Sending Format Unit with longlist=0, fmtdata=0, cmplist=0, defect list format=0 and type 2 protection
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.2 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: FORMAT UNIT test with Type 3 Protection
Description: Sending Format Unit with longlist=0, fmtdata=0, cmplist=0, defect list format=0 and type 3 protection
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.2 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: FORMAT UNIT test with Type 0 Protection
Description: Sending Format Unit with longlist=0, fmtdata=0, cmplist=0, defect list format=0 and type 0 protection
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.2 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: READ (6) Basic Verification Test
Description: The device must return GOOD (0x0) SCSI status and the first two blocks of data correctly. This test sends two READ commands reading two different but overlapped blocks of data. Then it compares the overlapped data. It returns true if the overlapped data is the same between the read operations (implying that the two commands read the same data correctly).
Reference: SCSI-3 Block Commands (SBC) specification Revision 8c Section 6.1.4. http://www.t10.org/ftp/t10/drafts/sbc/sbc-r08c.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: READ (6) Sequential Read Test
Description: The device must read 1000 sequential blocks of data correctly. This test sends the command 1000 times, reading 1024 bytes of data sequentially starting at a random block address.
Reference: SCSI-3 Block Commands (SBC) specification Revision 8c Section 6.1.4. http://www.t10.org/ftp/t10/drafts/sbc/sbc-r08c.pdf
Expectation: All READ (6) commands succeed.
Title: ASSERTION: READ (6) Random Read Test
Description: The device must read 1000 random blocks of data correctly. This test sends the command 1000 times, reading data at random logical block address.
Reference: SCSI-3 Block Commands (SBC) specification Revision 8c Section 6.1.4. http://www.t10.org/ftp/t10/drafts/sbc/sbc-r08c.pdf
Expectation: All READ (6) commands succeed.
Title: ASSERTION: READ (6) Read-With-Disk-Cache-Cleared Test
Description: The device must return data correctly after clearing 12-MB disk cache. This test first reads 12 MB sequential data for later verification. Then, it clears the disk cache by reading 12 MB random data. Finally, it reads the same 12 MB sequential data to see whether the data is same as in first read.
Reference: SCSI-3 Block Commands (SBC) specification Revision 8c Section 6.1.4. http://www.t10.org/ftp/t10/drafts/sbc/sbc-r08c.pdf
Expectation: The 12 MB data read after cache cleared is correct.
Title: ASSERTION: WRITE (6) Basic Functionality Test
Description: The command writes one block of data to device correctly. This test compares the data we want to write and the data returned by the READ after the write operation. If the data is the same, this implies that the WRITE command writes the data to disk correctly.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.30.
Expectation: ScsiStatus == 0x0
Title: ASSERTION: WRITE (6) Sequential Write Test
Description: The command writes 1000 sequential blocks of data correctly.This test sends the command 1000 times, writing data sequentially starting at a random logical block addresses.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.30.
Expectation: All WRITE (6) commands succeed.
Title: ASSERTION: WRITE (6) Random Write Test
Description: The command writes 1000 random blocks of data correctly.This test sends the WRITE command 1000 times, writing data at random logical block addresses.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.30.
Expectation: All WRITE (6) commands succeed.
Title: ASSERTION: WRITE (6) Write-With-Disk-Cache-Enabled Test
Description: The command writes 12 MB of data correctly with cache enabled.This test writes 12 MB of data to disk. Then it sends a SYNCHRONIZE CACHE (10) command to synchronize the logical block address in cache with the ones in disk. Finally, it will read the same 12 MB data that has just been written to verify that the data we just wrote are correct.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.30.
Expectation: The 12 MB data are written correctly.
Title: ASSERTION: WRITE (6) Write-With-Disk-Cache-Disabled Test
Description: The command writes 12 MB of data correctly with cache disabled.This test writes 12 MB of data to disk. Then it reads the same 12 MB data that has just been written to verify that the data we just wrote are correct.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.30.
Expectation: The 12 MB data are written correctly.
Title: ASSERTION: INQUIRY Basic Verification Test
Description: The device must return GOOD (0x0) SCSI status and data of size smaller than or equal to 255 bytes in response to the INQUIRY command with ALLOCATION LENGTH field set to 255 (0xFF) bytes. The ALLOCATION LENGTH field specifies the maximum number of bytes that an application client has allocated for returned data.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status and data of size smaller than or equal to 255 bytes.
Title: ASSERTION: INQUIRY Test for error when PAGE CODE field is nonzero and EVPD=0
Description: Checking that an error is returned when PAGE CODE field is nonzero and EVPD=0.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x2, CHECK CONDITION
Title: ASSERTION: INQUIRY Retrieving standard inquiry data
Description: Checking whether we can retrieve standard inquiry data.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, GOOD
Title: ASSERTION: INQUIRY Checking size of standard inquiry data
Description: Standard INQUIRY data shall contain at least 36 bytes.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Data Transfer Length >= 36 bytes
Title: ASSERTION: INQUIRY Testing device type field
Description: Checking device type field to ensure it is a direct-access device.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Device Type == 0x0, Direct-access device
Title: ASSERTION: INQUIRY Testing peripheral qualifier field
Description: Checking Peripheral Qualifier field.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Peripheral qualifier field == 0
Title: ASSERTION: INQUIRY VERSION Field Test
Description: The device must return a valid VERSION field of 0x4, 0x5 or 0x6.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: VERSION is 0x4 (SPC-2) or later for non-SCSI bus type and VERSION is 0x3 (SPC)or later for SCSI bus type.
Title: ASSERTION: INQUIRY Checking RESPONSE DATA FORMAT
Description: Checking that RESPONSE DATA FORMAT == 2.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: RESPONSE DATA FORMAT == 2
Title: ASSERTION: INQUIRY Checking additional length
Description: Checking additional length field is correct.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Additional Length field == Total Data size - 5
Title: ASSERTION: INQUIRY Checking VENDOR IDENTIFICATION field
Description: Checking that VENDOR IDENTIFICATION field contains valid ASCII.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: VENDOR IDENTIFICATION field contains valid ASCII.
Title: ASSERTION: INQUIRY Checking PRODUCT IDENTIFICATION field
Description: Checking that PRODUCT IDENTIFICATION field contains valid ASCII.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: PRODUCT IDENTIFICATION field contains valid ASCII.
Title: ASSERTION: INQUIRY Checking PRODUCT REVISION LEVEL field
Description: Checking that PRODUCT REVISION LEVEL field contains valid ASCII.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: PRODUCT REVISION LEVEL field contains valid ASCII.
Title: ASSERTION: INQUIRY Command Support Data Tes.
Description: The device must set the HiSup bit in the Standard Inquiry Data.
Reference: SCSI Architecture Model - 3 (SAM-3) Revision 14 (or later) specification Section 4.9.2 http://www.t10.org/ftp/t10/drafts/sam3/sam3r14.pdf
Expectation: HiSup bit is set in Standard Inquiry Data.
Title: ASSERTION: INQUIRY Checking for Supported Vital Product Pages
Description: Checking to see whether Vital Product Pages are supported.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.4. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: List of Supported Vital Product Data Pages is returned.
Title: ASSERTION: INQUIRY Testing access to each supported Vital Product Data Page
Description: Attempting to access each supported Vital Product Data Page.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.4. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Each supported page is accessible (up to 255 bytes).
Title: ASSERTION: INQUIRY Attempting Unit Serial Number Page 0x80
Description: Checking whether Unit Serial Number Page 0x80 is supported and is valid ASCII.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 7.6.10. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0 and result is valid ASCII.
Title: ASSERTION: INQUIRY Attempting Device identification Page 0x83
Description: Checking whether Device identification Page 0x83 is supported.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 7.6.3. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: INQUIRY Checking Identification Descriptors in VPD page 0x83
Description: Checking that Identification Descriptors contain meaningful data.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 7.6.3. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: All descriptors are compliant and contain meaningful data.
Title: ASSERTION: INQUIRY Checking Version Descriptors
Description: Checking that Version Descriptors are compliant.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Version descriptors exist.
Title: ASSERTION: INQUIRY Checking RMB bit
Description: For devices into which we can't insert/remove media, example: UFD, RMB bit should be set to 0. For devices into which we can insert/remove media, example: USB card reader, RMB bit should be set to 1. This test is run only on removable storage devices.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Correct value for RMB bit depending on the device.
Title: ASSERTION: MODE SELECT (6) Basic Test
Description: Checking to see whether a simple MODE SELECT command, with PF and SP == 0, passes.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 6: MODE SENSE (6) Attempting to get Caching mode page
Description: Checking to see whether a simple MODE SENSE command on Page 0x08 will return GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 6: MODE SENSE (6) Checking Parameters Savable (PS bit).
Description: Checking to see whether Parameters Savable bit for the Caching Mode Page is 1.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: PS == 1
Title: MODE SELECT 6: MODE SENSE (6) Checking Mode Parameter Header
Description: Verify that MediumType == 0 and BlockDescriptorLength == 0.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: MediumType == 0x0 and BlockDescriptorLength == 0x0
Title: MODE SELECT 6: MODE SENSE (6) Checking Caching Mode Page Length
Description: Checking that the Caching Mode Page is 20 bytes.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: cachePageLength == 20 bytes
Title: MODE SELECT 6: MODE SENSE (6) Getting Changeable values
Description: Saving away Changeable Values for Caching Mode Page.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 6: MODE SENSE (6) Getting default values
Description: Saving away Default Values for Caching Mode Page.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT (6) Changing WCE.
Description: Applying MODE SELECT to WCE=0 for the device.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 6: MODE SENSE (6) Checking that WCE has been cleared
Description: Checking that the previous MODE SELECT command actually changed the current mode parameters.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: WCE is clear.
Title: MODE SELECT 6: MODE SENSE (6) Checking that Saved Values have changed
Description: Checking that the previous MODE SELECT command actually changed the saved mode parameters.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Saved values have changed.
Title: MODE SELECT (6) setting WCE
Description: Applying MODE SELECT to set WCE.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 6: MODE SENSE (6) Checking that WCE has been set.
Description: Checking that the previous MODE SELECT command actually set WCE.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Current values have been set.
Title: MODE SELECT (6) Attempting to restore original values.
Description: Testing whether MODE SELECT can return the Caching Mode Page values to their original values.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 6: MODE SENSE (6) Verifying values were restored.
Description: Checking that the values were restored in the Caching Mode Page.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.7 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Current values equal default values.
Title: ASSERTION: RESERVE (6) Support Test
Description: Checking that the Reserve Command is supported and returns GOOD status.
Reference: Refer to SPC-2 (SCSI Primary Commands - 2) specification Section 7.22.
Expectation: Scsi Status is 0x0.
Title: ASSERTION: RELEASE (6) Support Test
Description: Checking that the Release Command is supported and returns GOOD status.
Reference: Refer to SPC-2 (SCSI Primary Commands - 2) specification Section 7.17.
Expectation: Scsi Status is 0x0.
Title: ASSERTION: MODE SENSE (6) Basic Test
Description: Checking that a simple MODE SENSE command on Page 0x3f will return GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: MODE SENSE (6) Checking size of returned data
Description: Checking that we receive a minimum amount of data (that is, at least the MODE PARAMETER HEADER).
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Data Transfer Length >= 4 bytes
Title: ASSERTION: MODE SENSE (6) Checking MODE PARAMETER HEADER
Description: Checking that the MODE PARAMETER HEADER length information is valid.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ModeDataLength = Data Transfer Length - 1 = -1 bytes
Title: MODE SENSE (6) Test DBD (disable block descriptors) bit
Description: Testing to make sure that, when DBD bit is set, no block descriptors are returned.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Block Descriptor Length = 0
Title: MODE SENSE (6) Testing new data length when DBD bit is set
Description: Testing that new data length should equal old data length minus block descriptor length.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: New Data Length = Old Data Length
Title: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set
Description: Testing that page data is the same before and after DBD bit is set.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Page data will match.
Title: MODE SENSE (6) Testing Page Control Field
Description: Testing different values of the Page control field, and enforcing the size of the data returned.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Data length for each value of PC is correct.
Title: MODE SENSE (6) Scanning All Mode Pages
Description: Checking Mode Page 0x3f data to examine supported mode pages.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: To find supported mode pages: Information Exception control mode page and Caching mode page.
Title: MODE SENSE (6) Ensuring mandatory mode pages are supported
Description: Checking that required mode pages are present in MODE PAGE 0x3f.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Caching and Informational Exception pages are supported, at a minimum.
Title: MODE SENSE (6) Checking Individual Mode Pages
Description: Testing to ensure we can access each individual mode page, and that the paremeters are correct
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Pages should be returned and the headers should be compliant.
Title: MODE SENSE (6) Checking Informational Exception Mode Page
Description: Ensuring Informational Exception mode page is compliant.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Power Condition mode page is supported.
Title: MODE SENSE (6) Checking Power Condition Mode Page
Description: Ensuring Power Condition mode page is compliant.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Informational Exception mode page is supported.
Title: MODE SENSE (6) Checking Caching Mode Page.
Description: Ensuring Caching mode page is compliant.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Caching mode page is supported.
Title: MODE SENSE (6) Checking Device Specific Parameters
Description: Tests whether the Device specific parameters are supported.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.9 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Nothing.
Title: ASSERTION: START STOP UNIT Basic Test 1
Description: Sending StartStopUnit with IMMED=0, LOEJ=0, START=0, expect no action
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.17 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: START STOP UNIT Basic Test 2
Description: Sending StartStopUnit with IMMED=0, LOEJ=0, START=1, expect no action.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.17 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: START STOP UNIT Basic Test 3
Description: Sending StartStopUnit with IMMED=1, LOEJ=0, START=0, expect no action.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.17 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: START STOP UNIT Basic Test 4
Description: Sending StartStopUnit with IMMED=1, LOEJ=0, START=1, expect no action.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.17 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: START STOP UNIT unload test with IMMED bit clear
Description: Sending StartStopUnit with IMMED=0, LOEJ=1, START=0, medium should be unloaded.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.17 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: SCSI status is 0x2 (CHECK).
Title: ASSERTION: START STOP UNIT load test with IMMED bit clear
Description: Sending StartStopUnit with IMMED=0, LOEJ=1, START=1, medium should be loaded.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.17 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: START STOP UNIT unload test with IMMED bit set
Description: Sending StartStopUnit with IMMED=1 LOEJ=1, START=0, medium should be unloaded.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.17 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: START STOP UNIT load test with IMMED bit set
Description: Sending StartStopUnit with IMMED=1 LOEJ=1, START=0, medium should be loaded.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.17 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: RECEIVE DIAGNOSTIC RESULTS Page Code Valid Test
Description: On receiving this command without a prior Send Diagnostic results command, device should not go into bad state.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.18 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: RECEIVE DIAGNOSTIC RESULTS Page Code Test
Description: Device should return the diagnostic pages specified in the PAGE CODE field, which are the control mode page and informational exception control mode page .
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.18 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return diagnostic page for the page asked.
Title: ASSERTION: SEND DIAGNOSTIC RESULTS Page Basic Verification Test
Description: Logical units that support this command shall implement, at a minimum, the default self-test feature.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.28 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: SEND DIAGNOSTIC RESULTS Background Short self-test
Description: The device shall start its short self-test in the background mode followed by a response to receive diagnostic results command. Device shall ignore DEVOFFL bit and UNITOFFL bit.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.28 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: SEND DIAGNOSTIC RESULTS Background Extended self-test
Description: The device shall start its Extended self-test in the background mode followed by a response to receive diagnostic results command.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.28 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: SEND DIAGNOSTIC RESULTS Abort Background self-test
Description: The device shall abort the current self-test running in background mode.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.28 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: SEND DIAGNOSTIC RESULTS Foreground Short self-test
Description: The device shall start its short self-test in the foreground mode followed by a response to receive diagnostic results command.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.28 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: SEND DIAGNOSTIC RESULTS Foreground Extended self-test
Description: The device shall start its Extended self-test in the foreground mode followed by a response to receive diagnostic results command.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.28 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: PREVENT ALLOW MEDIUM REMOVAL prevent bit set test
Description: Sending Prevent Allow Medium Removal with prevent bit set to 01.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.13 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status if it supports CDB, else return CHECH CONDITION andset sense key/ASC/ASCQ to 5/20/0 accordingly.
Title: ASSERTION: PREVENT ALLOW MEDIUM REMOVAL prevent bit clear test
Description: Sending Prevent Allow Medium Removal with prevent bit set to 00.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.13 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: READ CAPACITY (10) Basic Verification Test
Description: The device must return GOOD (0x0) SCSI status and 8 bytes of parameter data describing the capacity and medium format of the block device to the data-in buffer.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.10 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: READ CAPACITY (10) PMI Test
Description: Send a READ CAPACITY command with the Partial Medium Indicator (PMI) set to 1. It indicates that the RETURNED LOGICAL BLOCK ADDRESS and BLOCK LENGTH IN BYTES are those of the last logical block address before a substantial delay in data transer may be encountered.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.10 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The returned LOGICAL BLOCK ADDRESS shall be greater than or equal to the logical block address specified by the RELADR and LOGICAL BLOCK ADDRESS fields in the command descriptor block.
Title: ASSERTION: READ CAPACITY (10) Negative Test
Description: Send a READ CAPACITY command with the Partial Medium Indicator (PMI) bit zero but the LOGICAL BLOCK ADDRESS non-zero.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.10 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device should return a CHECK CONDITION (2h) status and the sense key be set to ILLEGAL REQUEST with the additional sense code set to ILLEGAL FIELD IN CDB (24h).
Title: ASSERTION: READ (10) Basic Functionality Test
Description: The command reads the first two blocks of data correctly.This test sends two READ commands reading two different but overlapped blocks of data. Then it compares the overlapped data. It returns true if the overlapped data is the same between the read operations (implying that the two commands read the same data correctly).
Reference: SCSI-3 Block Commands (SBC) specification Revision 8c Section 6.1.5. http://www.t10.org/ftp/t10/drafts/sbc/sbc-r08c.pdf
Expectation: Scsi Status == 0x0
Title: ASSERTION: READ (10) Sequential Read Test
Description: The command reads 1000 sequential blocks of data correctly.This test sends the command 1000 times, reading data sequentially starting at a random logical block addresses.
Reference: SCSI-3 Block Commands (SBC) specification Revision 8c Section 6.1.5. http://www.t10.org/ftp/t10/drafts/sbc/sbc-r08c.pdf
Expectation: All READ (10) commands succeed.
Title: ASSERTION: READ (10) Random Read Test
Description: The command reads 1000 random blocks of data correctly.This test sends the command 1000 times, reading data at random logical block addresses.
Reference: SCSI-3 Block Commands (SBC) specification Revision 8c Section 6.1.5. http://www.t10.org/ftp/t10/drafts/sbc/sbc-r08c.pdf
Expectation: All READ (10) commands succeed.
Title: ASSERTION: READ (10) Read-With-Disk-Cache-Cleared Test
Description: The command reads 12 MB of data correctly with disk cache cleared.This test first reads 12 MB sequential data for later verification. Then, it clears the disk cache by reading 12 MB random data. Finally, it reads the same 12 MB sequential data to see whether the data is same as the one in first read.
Reference: SCSI-3 Block Commands (SBC) specification Revision 8c Section 6.1.5. http://www.t10.org/ftp/t10/drafts/sbc/sbc-r08c.pdf
Expectation: The 12 MB data read after cache cleared is correct.
Title: ASSERTION: WRITE (10) Basic Functionality Test
Description: The command writes one block of data to device correctly.This test compares the data we want to write and the data returned by the READ after the write operation. If the data is the same, this implies that the WRITE command writes the data to disk correctly.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.31.
Expectation: ScsiStatus == 0x0
Title: ASSERTION: WRITE (10) Sequential Write Test
Description: The command writes 1000 sequential blocks of data correctly.This test sends the command 1000 times, writing data sequentially starting at a random logical block addresses.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.31.
Expectation: All WRITE (10) commands succeed.
Title: ASSERTION: WRITE (10) Random Write Test
Description: The command writes 1000 random blocks of data correctly.This test sends the WRITE command 1000 times, writing data at random logical block addresses.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.31.
Expectation: All WRITE (10) commands succeed.
Title: ASSERTION: WRITE (10) Write-With-Disk-Cache-Enabled Test
Description: The command writes 12 MB of data correctly with cache enabled.This test writes 12 MB of data to disk. Then it sends a SYNCHRONIZE CACHE (10) command to synchronize the logical block address in cache with the ones in disk. Finally, it will read the same 12 MB data that has just been written to verify that the data we just wrote are correct.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.31.
Expectation: The 12 MB data are written correctly.
Title: ASSERTION: WRITE (10) Write-With-Disk-Cache-Disabled Test
Description: The command writes 12 MB of data correctly with cache disabled.This test writes 12 MB of data to disk. Then it reads the same 12 MB data that has just been written to verify that the data we just wrote are correct.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.31.
Expectation: The 12 MB data are written correctly.
Title: ASSERTION: WRITE (10) FUA Test
Description: The command writes data to disk correctly with cache and Force Unit Access (FUA) on.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.31.
Expectation: Data is written correctly to disk with FUA on. Checksums of all WRITE (10) are correct.
Title: ASSERTION: MODE SELECT (10) Basic Test
Description: Checking that a simple MODE SELECT command, with PF and SP == 0, passes.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 10: MODE SENSE (10) Attempting to get Caching mode page
Description: Checking that a simple MODE SENSE command on Page 0x08 will return GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 10: MODE SENSE (10) Checking Parameters Savable (PS bit).
Description: Checking that Parameters Savable bit for the Caching Mode Page is 1.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: PS == 1
Title: MODE SELECT 10: MODE SENSE (10) Checking Mode Parameter Header
Description: Verify that MediumType == 0 and BlockDescriptorLength == 0.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: MediumType == 0x0 and BlockDescriptorLength == 0x0.
Title: MODE SELECT 10: MODE SENSE (10) Checking Caching Mode Page Length
Description: Checking that the Caching mode page is 20 bytes.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: cachePageLength == 20 bytes
Title: MODE SELECT 10: MODE SENSE (10) Getting Changeable values
Description: Saving away Changeable Values for Caching mode page.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 10: MODE SENSE (10) Getting default values
Description: Saving away Default Values for Caching mode page.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT (10) Changing WC.
Description: Applying MODE SELECT to WCE=0 for the device.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 10: MODE SENSE (10) Checking that WCE has been cleared
Description: Checking that the previous MODE SELECT command actually changed the current mode parameters.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: WCE is clear.
Title: MODE SELECT 10: MODE SENSE (10) Checking that Saved Values have changed
Description: Checking that the previous MODE SELECT command actually changed the saved mode parameters.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Saved values have changed.
Title: MODE SELECT (10) setting WCE
Description: Applying MODE SELECT to set WCE.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 10: MODE SENSE (10) Checking that WCE has been set
Description: Checking that the previous MODE SELECT command actually set WCE.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Current values have been set.
Title: MODE SELECT (10) Attempting to restore original values
Description: Testing MODE SELECT can return the Caching mode page values to their original values.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: MODE SELECT 10: MODE SENSE (10) Verifying values were restored
Description: Checking that the values were restored in the Caching mode page.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.8 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Current values equal default values.
Title: ASSERTION: RESERVE (10) Support Test
Description: Checking that the Reserve (10) Command is supported and returns GOOD status.
Reference: Refer to SPC-2 (SCSI Primary Commands - 2) specification Section 7.21.
Expectation: Scsi Status is 0x0.
Title: ASSERTION: RELEASE (10) Support Test
Description: Checking that the Release (10) Command is supported and returns GOOD status.
Reference: Refer to SPC-2 (SCSI Primary Commands - 2) specification Section 7.16.
Expectation: Scsi Status is 0x0.
Title: ASSERTION: MODE SENSE (10) Basic Test
Description: Checking that a simple MODE SENSE10 command on Page 0x3f will return GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.10 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: MODE SENSE (10) Checking size of returned data
Description: Checking that we receive a minimum amount of data (that is, at least the MODE PARAMETER HEADER).
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.10 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Data Transfer Length >= 8 bytes
Title: ASSERTION: MODE SENSE (10) Checking MODE PARAMETER HEADER
Description: Checking that the MODE PARAMETER HEADER length information is valid.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.10 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ModeDataLength = Data Transfer Length - 2 = -2 bytes
Title: MODE SENSE (10) Test DBD (disable block descriptors) bit
Description: Testing that, when DBD bit is set, no block descriptors are returned.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.10 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Block Descriptor Length = 0
Title: MODE SENSE (10) Comparing MODE PAGE data before and after DBD bit is set
Description: Testing that page data is the same before and after DBD bit is set.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.10 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Page data will match.
Title: MODE SENSE (10) Testing Page Control Field
Description: Testing different values of the Page control field, and enforcing the size of the data returned.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.10 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Data length for each value of PC is correct and PC=0 and PC=2 return good status.
Title: ASSERTION: PERSISTENT RESERVE OUT : REGISTER AND IGNORE EXISTING KEY Support Test
Description: Checking that the PERSISTENT RESERVE OUT with service action REGISTER AND IGNORE EXISTING KEY is supported and returns GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.12 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: PERSISTENT RESERVE IN : READ KEYS Support Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ KEYS with minimum ALLOCATION LENGTH is supported, returns GOOD status, and appropriate ADDITIONAL LENGTH.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, DataTransferLength == ALLOCATION LENGTH, ADDITIONAL LENGTH != 0, and ADDITIONAL LENGTH == 0.
Title: ASSERTION: PERSISTENT RESERVE IN : READ KEYS Functional Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ KEYS with full ALLOCATION LENGTH returns the known key previously registered.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, ADDITIONAL LENGTH == previous ADDITIONAL LENGTH, list contains known key.
Title: ASSERTION: PERSISTENT RESERVE OUT : RESERVE Support Test
Description: Checking that the PERSISTENT RESERVE OUT with service action RESERVE, LU_SCOPE, Write Exclusive - Registrants Only, and previously registered key returns GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.12 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: PERSISTENT RESERVE IN : READ RESERVATION Support Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ RESERVATION with minimum ALLOCATION LENGTH is supported, returns GOOD status, and appropriate ADDITIONAL LENGTH.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, DataTransferLength == ALLOCATION LENGTH, ADDITIONAL LENGTH != 0, and ADDITIONAL LENGTH is mulitple of 8.
Title: ASSERTION: PERSISTENT RESERVE IN : READ RESERVATION Functional Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ RESERVATION with full ALLOCATION LENGTH returns the known key previously reserved.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, ADDITIONAL LENGTH == previous ADDITIONAL LENGTH, list contains known key.
Title: ASSERTION: PERSISTENT RESERVE OUT : RELEASE Support Test
Description: Checking that the PERSISTENT RESERVE OUT with service action RELEASE, LU_SCOPE, Write Exclusive - Registrants Only, and previously registered key returns GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.12 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ RESERVATION returns list without previously released key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list does not contain known key.
Title: ASSERTION: PERSISTENT RESERVE IN : READ KEYS Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ KEYS returns list with previously registered key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list still contains known key.
Title: ASSERTION: PERSISTENT RESERVE OUT : REGISTER Support Test
Description: Checking that the PERSISTENT RESERVE OUT with service action REGISTER is supported and returns GOOD status when SERVICE ACTION RESERVATION KEY = 0.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.12 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: PERSISTENT RESERVE IN : READ KEYS Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ KEYS returns list without previously unregistered key or null key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list does not contain known key, list does not contain the null key.
Title: ASSERTION: PERSISTENT RESERVE OUT : REGISTER AND IGNORE EXISTING KEY Support Test
Description: Checking that the PERSISTENT RESERVE OUT with service action REGISTER AND IGNORE EXISTING KEY with APTPL = 1 returns GOOD status or CHECK CONDITION with ILLEGAL REQUEST.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.12 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: PERSISTENT RESERVE IN : READ KEYS Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ KEYS returns list with registered key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list contains known key.
Title: ASSERTION: PERSISTENT RESERVE OUT : RESERVE Support Test
Description: Checking that the PERSISTENT RESERVE OUT with service action RESERVE, LU_SCOPE, Write Exclusive - Registrants Only, and previously registered key returns GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.12 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ RESERVATION returns list with previously reserved key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list contains known key.
Title: ASSERTION: PERSISTENT RESERVE OUT : CLEAR Support Test
Description: Checking that the PERSISTENT RESERVE OUT with service action CLEAR, LU_SCOPE, Write Exclusive - Registrants Only, and previously registered key returns GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.12 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Description: Checking to see if the PERSISTENT RESERVE IN with service action READ RESERVATION returns list without previously cleared key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list does not contain known key.
Title: ASSERTION: PERSISTENT RESERVE IN : READ KEYS Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ KEYS returns list without previously cleared key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list does not contain known key.
Title: ASSERTION: PERSISTENT RESERVE OUT : REGISTER AND IGNORE EXISTING KEY Support Test
Description: Checking that the PERSISTENT RESERVE OUT with service action REGISTER AND IGNORE EXISTING KEY is supported and returns GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.12 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: PERSISTENT RESERVE IN : READ KEYS Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ KEYS returns list with registered key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list contains known key.
Title: ASSERTION: PERSISTENT RESERVE OUT : RESERVE Support Test
Description: Checking that the PERSISTENT RESERVE OUT with service action RESERVE, LU_SCOPE, Write Exclusive - Registrants Only, and previously registered key returns GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.12 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ RESERVATION returns list with previously reserved reservation with current initiator's key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list contains known key.
Title: ASSERTION: PERSISTENT RESERVE OUT : PREEMPT Support Test
Description: Checking that the PERSISTENT RESERVE OUT with service action PREEMPT, LU_SCOPE, Write Exclusive - Registrants Only, and previously registered key returns GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.12 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ RESERVATION returns list without previously preempted key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list does not contain known key.
Title: ASSERTION: PERSISTENT RESERVE IN : READ KEYS Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ KEYS returns list with known key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list contains known key.
Title: ASSERTION: PERSISTENT RESERVE OUT : PREEMPT AND ABORT Support Test
Description: Checking that the PERSISTENT RESERVE OUT with service action PREEMPT AND ABORT, LU_SCOPE, Write Exclusive - Registrants Only, and previously registered key returns GOOD status.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.12 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: PERSISTENT RESERVE IN : READ RESERVATION Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ RESERVATION returns list with known key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list contains known key.
Title: ASSERTION: PERSISTENT RESERVE IN : READ KEYS Verification Test
Description: Checking that the PERSISTENT RESERVE IN with service action READ KEYS returns list with known key.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0, list contains known key.
Title: ASSERTION: PERSISTENT RESERVE OUT : REGISTER AND IGNORE EXISTING KEY Support Test
Description: Clean up test environment for latter test.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.11 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: ScsiStatus == 0x0
Title: ASSERTION: READ (16) Support Test
Description: Verify that the device supports the READ (16) command.This test issues a simple READ (16) command and checks whether the return code is 0x2 (meaning not supported).
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.10.
Expectation: Scsi Status is 0x0.
Title: ASSERTION: READ (16) Basic Functionality Test
Description: The command reads the first two blocks of data correctly. This test sends two READ commands reading two different but overlapped blocks of data. Then it compares the overlapped data. It returns true if the overlapped data is the same between the read operations (implying that the two commands read the same data correctly).
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.10.
Expectation: Scsi Status is 0x0.
Title: ASSERTION: READ (16) Sequential Read Test
Description: The device must read 1000 sequential blocks of data correctly. This test sends the command 1000 times, reading data sequentially starting at a random logical block address.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.10.
Expectation: All READ (16) commands succeed.
Title: ASSERTION: READ (16) Random Read Test
Description: The command reads 1000 random blocks of data correctly.This test sends READ (16) command 1000 times, reading data at random logical block addresses.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.10.
Expectation: All READ (16) commands succeed.
Title: ASSERTION: READ (16) Read-With-Disk-Cache-Cleared Test
Description: The command reads 12 MB of data correctly with disk cache cleared.This test first reads 12 MB sequential data for later verification. Then, it clears the disk cache by reading 12 MB random data. Finally, it reads the same 12 MB sequential data to see if the data is same as the data in the first read.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.10.
Expectation: The 12 MB data read after cache cleared is correct.
Title: ASSERTION: WRITE (16) Support Test
Description: Verify that the device supports the command. This test issues a simple WRITE (16) command and checks whether the return code is 0x2 (Check Condition).
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.33.
Expectation: ScsiStatus == 0x0
Title: ASSERTION: WRITE (16) Basic Functionality Test
Description: The command writes one block of data to device correctly.This test compares the data we want to write and the data returned by the READ after the write operation. If the data are the same, this implies that the WRITE command writes the data to disk correctly.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.33.
Expectation: ScsiStatus == 0x0
Title: ASSERTION: WRITE (16) Sequential Write Test
Description: The command writes 1000 sequential blocks of data correctly.This test sends the command 1000 times, writing data sequentially starting at a random logical block address.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.33.
Expectation: All WRITE (16) commands succeed.
Title: ASSERTION: WRITE (16) Random Write Test
Description: The command writes 1000 random blocks of data correctly.This test sends the WRITE command 1000 times, writing data at random logical block addresses.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.33.
Expectation: All WRITE (16) commands succeed.
Title: ASSERTION: WRITE (16) Write-With-Disk-Cache-Enabled Test
Description: The command writes 12 MB of data correctly with cache enabled.This test writes 12 MB of data to disk. Then it sends a SYNCHRONIZE CACHE (10) command to synchronize the logical block addresses in cache with the ones in disk. Finally, it will read the same 12 MB data that has just been written to verify that the data we just wrote are correct.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.33.
Expectation: The 12 MB data returned by the WRITEs is correct.
Title: ASSERTION: WRITE (16) Write-With-Disk-Cache-Disabled Test
Description: The command writes 12 MB of data correctly with cache disabled.This test writes 12 MB of data to disk. Then, it reads the same 12 MB data that has just been written to verify that the data we just wrote are correct.
Reference: Refer to SBC-2 (SCSI Block Commands) specification revision 8 Section 5.2.33.
Expectation: The 12 MB data are written correctly.
Title: ASSERTION: READ CAPACITY (16) Allocation length test
Description: The device must return GOOD (0x0) SCSI status and even though allocation length is set to 0 value.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.11 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI statu.s
Title: ASSERTION: READ CAPACITY (16) Basic Verification Test
Description: The device must return GOOD (0x0) SCSI status and 8 bytes of parameter data describing the capacity and medium format of the block device to the data-in buffer.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.11 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device must return GOOD (0x0) SCSI status.
Title: ASSERTION: READ CAPACITY (16) PMI Test
Description: Send a READ CAPACITY command with the Partial Medium Indicator (PMI) set to 1. It indicates that the RETURNED LOGICAL BLOCK ADDRESS and BLOCK LENGTH IN BYTES are those of the last logical block address before a substantial delay in data transer may be encountered.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.11 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The returned LOGICAL BLOCK ADDRESS shall be greater than or equal to the logical block address specified by the RELADR and LOGICAL BLOCK ADDRESS fields in the command descriptor block.
Title: ASSERTION: READ CAPACITY (16) Negative Test
Description: Send a READ CAPACITY command with the Partial Medium Indicator (PMI) bit zero but the LOGICAL BLOCK ADDRESS non-zero.
Reference: SCSI Block Commands - 2 (SBC-2) Revision 16 (or published) specification Section 5.11 http://www.t10.org/ftp/t10/drafts/sbc2/sbc2r16.pdf
Expectation: The device should return a CHECK CONDITION (2h) status and the sense key be set to ILLEGAL REQUEST with the additional sense code set to ILLEGAL FIELD IN CDB (24h).
Title: ASSERTION: REPORT LUNS Basic Verification Test
Description: Attempts to find the LUN 0 corresponding to D.U.T. and execute the REPORT LUNS command. This test will only send REPORT LUNS to LUN 0 at the current target address per SAM-3. This test will only issue a request with SELECT REPORT set to zero per SPC-3.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.21 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status and data of size smaller than or equal to 255 bytes.
Title: ASSERTION: REPORT LUNS LUN0 Test
Description: This test will only send REPORT LUNS to LUN 0 at the current target address per SAM-3. This test will only issue a request with SELECT REPORT set to zero per SPC-3.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.21 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status and data of size smaller than or equal to 255 bytes.
Title: ASSERTION: REPORT LUNS Data valid Test
Description: This test will only send REPORT LUNS to LUN 0 at the current target address per SAM-3. This test will only issue a request with SELECT REPORT set to zero per SPC-3.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.21 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Each reported LUN uses single level numbers restricted to less than or equal to 255.
Title: ASSERTION: SECURITY PROTOCOL OUT Basic Test
Description: This test sends SPOUT command to device unit before sending SPIN next.
Reference: SCSI Primary Commands - 4 (SPC-4) Revision 17 (or published) specification Section 6.31 http://www.t10.org/ftp/t10/drafts/spc4/spc4r17.pdf
Expectation: Devices that understand IEEE 1667 silo commands must return GOOD (0x0) SCSI status and devices that don't can return check condition.
Title: ASSERTION: SECURITY PROTOCOL IN Basic Test
Description: This test sends SPIN command followed by test unit ready to check whether device is in bad state to accept further commands.
Reference: SCSI Primary Commands - 4 (SPC-4) Revision 17 (or published) specification Section 6.30 http://www.t10.org/ftp/t10/drafts/spc4/spc4r17.pdf
Expectation: Devices that understand IEEE 1667 silo commands must return GOOD (0x0) SCSI status and devices that don't can return check condition and then respond to TUR with GOOD SCSI status.
Title: ASSERTION: REPORT TARGET PORT GROUPS Basic Verification Test
Description: Check whether test can get target port groups information with this command.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.25. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Scsi status == 0
Title: ASSERTION: REPORT TARGET PORT GROUPS Response Data Format Test
Description: Check whether test can get target port groups information in valid format with this command.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.25. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Response Data Format is correct.
Title: ASSERTION: SET TARGET PORT GROUPS Check Information can be Set
Description: Check whether test can set target port groups information with this command. Get target port groups information; then set target port groups; read target port groups information to do comparison.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.31. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: Group Information is set. SCSI status should be 0 or sense code should be 2A/06 for Report Target Port Group CDB after setting.
Title: ASSERTION: REPORT SUPPORTED OP CODES with RTCD clear
Description: This test requests information on commands the addressed logical unit supports; command timeouts descriptor shall not be included in any parameter data returned.This test is run only on USB devices.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status along with all supported op codes in requested format.
Title: ASSERTION: REPORT SUPPORTED OP CODES with RTCD set
Description: This test requests information on commands the addressed logical unit supports; command timeouts descriptor shall be included in each command descriptor that is returned in parameter data. This test is run only on USB devices.
Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
Expectation: The device must return GOOD (0x0) SCSI status along with all supported op codes in requested format.


SCSI Initiator Client Server

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 an instance of the server on every machine and the client the machine chosen before.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • N-1 other machines that meet the above requirements.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

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

Code Tour

File Manifest

File | Location
nnodesim.exe | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
countlms.vbs | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk

Test Assertions

Server must be able to read MBR of storage device.
Test Assertion GUID: 1b088e43-c8d3-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0006 Storage devices used in clusters comply with industry standards and Windows failover cluster 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-0006 Storage devices used in clusters comply with industry standards and Windows failover cluster requirements.
Server must be able to perform a sequential read / write on the storage device.
Test Assertion GUID: 1b088e45-c8d3-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0006 Storage devices used in clusters comply with industry standards and Windows failover cluster requirements.
Server must be able to write MBR of storage device.
Test Assertion GUID: 1b088e46-c8d3-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0006 Storage devices used in clusters comply with industry standards and Windows failover cluster requirements.
Server must be able to reserve the storage device.
Test Assertion GUID: 1b088e47-c8d3-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0006 Storage devices used in clusters comply with industry standards and Windows failover cluster requirements.
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-0006 Storage devices used in clusters comply with industry standards and Windows failover cluster requirements.
A server may only realease a reservation that it currently holds.
Test Assertion GUID: 1b088e49-c8d3-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0006 Storage devices used in clusters comply with industry standards and Windows failover cluster requirements.


Separated Cache Solution Evaluation test

Type: Manual Test

Overview

Separated NVRAM storage solutions provide a number of challenges that are not present in integrated NVRAM storage solutions such as a hybrid hard disk. The purpose of these tests is to verify that, in spite of these additional challenges, both solutions provide the same level of protection and a comparable performance for data that is written to the hard disk.

Details

This test tool consists of two parts:

  • SCS Evaluation Results Checker: A job that runs in DTM, collects the results from the user, and verifies that all the test cases were run by the developer on the same hardware and driver that is being submitted for logo.

    The SCS evaluation results checker job is required for storage adapters that implement a non-volatile cache that is separate from HDDs attached. This is indicated by checking "Implements Non-Volatile cache" when you create a submission in DTM. The job prompts the user for a file when the job is scheduled from Device Console. The user should provide the Results.xml file that is produced from the SCS evaluation test. This job must be scheduled against the storage adapter and driver that were used when running the SCS evaluation test. The Results.xml file must contain passing results for all required tests (see test assertions section).

  • SCS Evaluation Test : An MSI file that is provided in the Windows Logo Kit (WLK) that is meant to be installed on a developer's machine and used to run the tests and collect results. This does not run as part of DTM. An in depth specification of the SCS evaluation test follows.

Functional Specification

Separated Cache Solution Evaluation test

1 Overview

This document provides the description and motivation for a set of tests that are designed to make sure of the correct functionality of a separated NVRAM storage solution with a focus on data consistency on the hard disk. Separated NVRAM solutions provide a number of challenges that are not present in integrated NVRAM storage solutions such as a hybrid hard disk. The purpose of these tests is to verify that, in spite of these additional challenges, both solutions provide the same level of protection for data that is written to the hard disk.

The document is broken down into sections that contain assumptions, specifications of the test tools and hardware, and detailed descriptions of the tests themselves. We assume that you are familiar with Windows ReadyDrive technology as it is present in Windows Vista, the Non-Volatile Cache Command Proposal for ATA8-ACS e05106r7 specification submitted and accepted by the T13 committee, as well the basic functionality of both Hybrid Hard Disks and separated NVRAM solutions. The Non-Volatile Cache Command Proposal is accessible on the T13 website at T13 Technical Committee.

2 High Level Goals

2.1 Data Loss / Reliability

A primary goal of these tests is to make sure that in a separated NVRAM solution the contents of the disk are always consistent within the operating system. In these scenarios, ensuring consistency primarily relies on the correct ordering of writes and the obeying of flushes issued by the operating system (for example, the FlushFileBuffers API). Detailed descriptions of these two aspects of ensuring data consistency are given later. Note, that these tests would be verified on systems that do not have any NVRAM solution to make sure that there is no hardware or software logic that inherently does not conform to the expected behavior.

A key concern surrounding the use of separated NVRAM solutions is the "recovery process" that occurs in the event of a system crash or power loss. This process is believed to be designed to ensure that in the event of a crash or power loss the data on the disk is at a minimum consistent from the perspective of the operating system. It is acceptable for some rollback to occur provided that rollback does not violate write ordering and flush requirements. While the design and implementation of such a recovery process is not known, it is required that the process be performed correctly. Because this recovery process may rely on data on the disk being in a specific state when the crash or power loss occurred, it is considered invalid to remove the disk and boot it in another system to verify that the contents of the disk are consistent. The recovery process also requires that the disk be allowed to boot up past the BIOS stage prior to a scenario being marked complete. This allows the BIOS bootstrapping code to do its work to attempt to repair or synchronize the disk's contents.

2.2 Performance

It is important that any separated NV cache solution does not adversely impact the performance of the system in key scenarios. These scenarios include steady state performance as well as power transitions such as standby and hibernate. Ensuring a predictable and sufficient level of performance not only improves the quality of the user's experience with Windows Vista but also plays a key part in some reliability scenarios.

The ability to quickly spin the drive down when the system is put into standby or hibernate is critical to ensuring the user's data is not compromised. A common user scenario is to close the lid of a notebook (thus putting it in standby, hibernate, or shutdown) and then picking it up to leave a meeting. If the disk continues to be utilized to write out data during this process it's quite possible the disk arm could be jarred and crashed into the spindle and likely corrupting data.

3 Assumptions

3.1 Hybrid Disk WDK Tests

It is assumed that any device that should be considered for equivalence testing has already passed all of the Hybrid Hard Disk tests in the WDK.

3.2 Baseline System

The "baseline" system for the Separated Cache Solution Evaluation Tests is considered to be a "clean install" for Windows Vista Ultimate on a system with a standard hard disk and the non-volatile cache mode disabled. So, essentially we are compare the same system under two different configurations - non-volatile cache enabled and non-volatile cache disabled. The system is alike in all other aspects.

3.3 Disk Consistency

The consistency of the disk will be ensured by monitoring the IOs issued to the disk using a bus analyzer. The data from the bus analyzer can be compared to the IOs issued by the test in an automated fashion to ensure that the contents of the disk are in a consistent state. As such in this document "consistent on the disk" refers to test detecting that the required IOs have passed across the bus such that they were observed by the bus analyzer. Additional details about the bus analyzer are given in the "Test Tools" section of this document.

3.4 Write Ordering and OS Flush Operations

3.4.1 General Requirements

It is assumed that correct ordering of writes will be maintained at all times. That is given the following series of IOs:

  • W1, W2, F1, W3, W4, F2, W5, W6, F3

Where WN are writes issued in the order specified and FN are OS flushes issued in the order specified that only the correct ordering of IOs will be pushed across the bus to the disk. The definition of correct ordering is determined by the configuration of the IO system (write buffering on vs. off, etc). This ordering will be verified using a bus analyzer as described later in this document.

A general rule that applies to the proper ordering of the above IOs requires that after successful completion of any OS flush, FN, all writes issued prior to it are present on the disk. For example, after F2 completes the IOs represented by W3 and W4 must have been observed by the bus analyzer after F1. Additional constraints and requirements are detailed below in configuration specific sub-sections.

3.4.2 Disk Write Buffering Disabled

When the write buffering in the disk's track buffer is disabled proper ordering also requires that prior to the issuing of any given OS flush that the ordering of writes prior to the flush is maintained. In essence with disk write buffering disabled each write must be committed to physical disk spinning media, in order, before the IO is completed to the OS. Given a flush command it is required that data be committed to physical disk spinning media prior to the completion of the flush command.

When configured to have write-buffering in the track buffer disabled the storage sub-system is effectively configured for maximum protection against data loss and inconsistency between the disk and the non-volatile cache. In this configuration the disk's track buffer should be disabled, it is not valid to mask that and leave it enabled. Flushes, FUA, etc. should all be honored according to their defined behavior. While this configuration is not a very common configuration for client systems it is a valid configuration.

3.4.2.1 Disk Write Buffering Disabled - Example

It is assumed that correct ordering of writes will be maintained at all times. That is given the following series of IOs:

  • W1, W2, F1, W3, W4, F2, W5, W6, F3

The correct ordering of IOs is as follows:

  • W1, W2, F1, W3, W4, F2, W5, W6, F3

It is also valid that in the event of an unexpected system shutdown any partial sequence of the above to be observed provided the ordering is the same.

3.4.3 Disk Write Buffering Enabled

When the write buffering in the disk's track buffer is enabled it is valid for writes to be re-ordered and collapsed provided that ordering around flushes is still maintained. This is typically done to improve performance by optimizing the seek pattern on the disk. As such proper ordering does not require that prior to the issuing of any given OS flush that the ordering of writes prior to that flush operation be maintained.

In the event of a power fail, crash, or other unexpected / dirty shutdown it is valid for the IO sequences to get truncated at any point in time. Once the system has been booted and the recovery operation has been performed the valid sequences as defined earlier must be observed in full on the bus.

This is the common configuration for client systems and as such is given the most attention from both documentation and testing perspectives.

3.4.3.1 Disk Write Buffering Enabled - Reordering Example

It is assumed that flush ordering will be maintained at all times. That is given the following series of IOs:

  • W-1.1, W-1.2, F1, W-2.1, W-2.2, F2, W-3.1, W-3.2, F3

It is required that no write W-i.j may be observed on the bus before a write W-(i-1).* has been observed on the bus. That yields the following valid sequences of IOs:

  • W1, W2, F1, W3, W4, F2, W5, W6, F3

  • W2, W1, F1, W4, W3, F2, W6, W5, F3

  • W2, W1, F1, W3, W4, F2, W6, W5, F3

  • W2, W1, F1, W4, W3, F2, W5, W6, F3

  • W1, W2, F1, W4, W3, F2, W6, W5, F3

Note that not all valid sequences have been given and that given a sequence of observed IOs it must hold to the general rule in order to be valid.

3.4.3.2 Disk Write Buffering Enabled - Collapsing Example

As stated earlier writes can be not only reordered but collapsed when disk writes occur to the same sector in between two flush operations.

That is given the following set of IOs where (a, b) notation indicates writes to the same sector on the disk:

  • W-1.1a, W-1.2, W-1.3b, F1, W-2.1, W-2.2, F2, W-3.1, W-3.2, F3

Yields the following valid sequences of IOs:

  • W2, W1b, F1, W3, W4, F2, W5, W6, F3

  • W1b, W2, F1, W3, W4, F2, W5, W6, F3

  • W1a, W1b, W2, F1, W3, W4, F2, W5, W6, F3

  • W2, W1a, W1b, F1, W3, W4, F2, W5, W6, F3

Note that not all valid sequences have been given and that given a sequence of observed IOs it must hold to the general rule in order to be valid.

3.4.3.3 Disk Write Buffering Enabled - Unexpected Shutdown Example

In the event of a power fail, crash, or other unexpected / dirty shutdown it is valid for the IO sequences to get truncated at any point in time. Once the system has been booted and the recovery operation has been performed the valid sequences as defined earlier must be observed in full on the bus.

Given the following sequence of IOs:

  • W-1.1, W-1.2, F1, W-2.1, W-2.2, F2, W-3.1, W-3.2, F3

It is valid to observe any of the following once the unexpected shutdown has occurred and prior to the recovery having taken place:

  • W-1.1

  • W-1.2, W-1.2, F1

  • W-1.1, W-1.2, F1, W-2.2

Note that not all valid sequences have been given and that given a sequence of observed IOs it must hold to the general rule in order to be valid.

Once the recovery process completes the valid sequences of IOs are the same as in the general case when disk write caching is enabled.

3.4.4 Forced Unit Access (FUA)

Forced Unit Access implies that write through semantics are enforced from the disk write cache's perspective for a given write IO. While a FUA write does not imply a flush of the disk's write cache it is valid for the disk to flush some or part of its disk cache when a FUA write is received.

Given the following sequence of IOs:

  • W1, W2_FUA, W3, F1

It is valid to observe any of the following on the bus:

  • W1, W2_FUA, W3, F1

  • W2_FUA, W1, W3, F1

  • W2_FUA, W3, W1, F1

  • W2_FUA, W1, W3, F1

Note that "W3, W2_FUA, W1, F1" is not a valid pattern. FUA implies that a write has been completed to non-volatile media before any writes after it has been issued. This applies not only to a non-volatile flash solution but also to a hard disk. If these writes are re-ordered in this way and power is lost between the time W3 has completed and W2_FUA has been issued the disk may be in an inconsistent state if removed from the system.

NOTE: FUA Test Cases are NOT part of the LOGO requirements. The test cases included are intended for IHV's who wish to implement FUA in the future.

3.4.5 Write Pattern Optimization

By write pattern optimization we refer to the merging of two or more sector writes into a single write to the disk. Note, that this write may include writing out sectors which are clean. For example, for the case of three contiguous sectors 1,2 and 3 in the NvCache of which sectors 1 and 3 have been modified one can have a single write which comprises these three sectors even though sector 2 is clean.

A caveat for this optimization is that sectors should be evicted from the NvCache only after they have been committed to disk successfully. This is because a power failure when the write is in progress might leave the disk in an inconsistent state and possibly even corrupt data which was considered up-to-date on the disk (sector 2 in the example above).

Note that such an optimization may not be valid if the writes are a mix of FUA writes and non-FUA writes. Any ordering constraints must be obeyed ahead of any optimizations such as this. The concern also applies to the case when write-buffering is disabled and any merging optimizations can be applied only while adhering to the ordering constraints.

3.4.6 Other Write / Flush Optimizations

3.4.6.1 Bonus Flushes

It is valid for the IO subsystem to issue additional flushes to the disk provided the write ordering rules and tests outlined in this document are not violated.

It is important to ensure the performance requirements and tests in this document are also not violated.

3.4.6.2 Write Buffer Optimizations in the Track Buffer

There are some concerns which suggest disabling the write-buffer by default may not be desirable. Write-buffering is typically enabled by default on hard disks. Moreover, an end-user can toggle this feature i.e., disable or enable write-buffering as desired. In some sense, this default then indicates the user's choice. Changing this default then reflects a departure from the conviction that user settings are being adhered to. If one argues that, with write-buffering turned off, flushes are still sent to the non-volatile cache instead of disk media, is indeed in the user's best interest as it delivers improved performance, then extreme care needs to be taken in the instrumentation. In particular, the actual user setting should be remembered and appropriately reset as and when the system transitions to non-volatile cache disabled from non-volatile cache enabled[1]. If the user had write-buffering enabled originally and the user-setting is not reset the user will see a significant performance impact as all writes will be write-through (one of the primary reasons why write-buffering is enabled by default).

Finally, note that for the case when write-buffering is disabled on the disk then all flush commands as well as write-through flags are removed by the Windows operating system before any request is sent out over the wire. So, no additional logic needs to be implemented to strip the flushes. Please see the following document for details.

Disk Subsystem Performance Analysis for Windows

3.5 Performance

As described earlier performance of a separated cache solution is a concern and ensuring that it provides a level of performance that is consistent and performant is critical.

3.5.1 Hybrid Disk Throughput / Latency Requirements

Hybrid Hard Disks are required to provide the following level of performance in order to be used by the system as an NV cache enabled solution:

  • 16 MB/s sustained throughput for 64 KB sequential reads when the platter is spun down to a file pinned in the NV cache.

  • 8 MB/s sustained throughput for 64 KB sequential writes when the platter is spun down.

  • 4 MB/s sustained throughput for 4 KB random reads and writes when the platter is spun down to a file pinned in the NV cache.

  • Less than 1 ms latency for a given 4 KB random read when the platter is spun down to a file pinned in the NV cache. The minimum IO time observed during an assessment is used for this requirement.

This test is done as part of the WDK tests for validating a hybrid disk but it should also be noted that the test is done by Windows Vista when it boots up and detects a hybrid disk or, in this case, a separated NV cache solution. Devices that do not pass the test will not be used by Windows Vista as NV cache enabled.

In its current form the runtime assessment only requires that disk IOs be aligned to 512 bytes within the file. Given the offset of the volume on the disk and the random nature of the offsets used in the assessment there may be inconsistencies between the alignment of the IOs issued as part of the assessment and the IOs that are issued as part of a realistic user workload. In future versions of the assessment we will look at the algorithm in detail and determine if changes need to be made.

3.5.2 Testing Methodology

Performance testing will primarily use Event Tracing for Windows (ETW) to collect data. ETW leverages existing instrumentation in Windows Vista to gather detailed information about disk IO, process / thread activity, etc. The equivalence testing tools will provide the functionality to collect and analyze the ETW traces such that an automated determination can be made regarding pass or fail of a test. ETW also provides events around power transitions such as standby, hibernate, and shutdown. These events will be used to determine the timing of the operation. Note, that the timing instrumentation is attuned to what would be the user-perceived experience.

Detailed descriptions of each test are given later in the document. The remainder of this section provides a high level overview of each type of test as well as details about the timing goals for each type of test. We first outline the methodology for running these tests. Note that while a percentage based performance goal is ideal as it is oblivious of the absolute performance of the system being tested, a raw time based performance metric is used in conjunction where necessary as Windows imposes timeouts around certain power-transitions.

Finally, note that these tests will be run for both the case write-buffering is enabled on the system and when it is disabled.

3.5.2.1 Methodology

For these tests the goal is to ensure that the user sees acceptable behavior for the operations listed. For each test we execute the operation 5-10 times and compute the average of the times of interest over these runs. The operation itself is run for two cases--when the non volatile cache feature is enabled and when it is disabled. The non-volatile cache feature should be toggled using the Group Policy Object Editor or gpedit.msc.

The following steps disable the non-volatile cache feature:

  1. Launch an elevated command prompt

  2. In the command prompt: type: gpedit.msc

  3. In the popup dialog box with the title Group Policy Object Editor: Click: Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> Disk NV Cache

  4. Double-click "Turn Off Non Volatile Cache Feature"

  5. Click: enabled

  6. Click: Apply

  7. Click: OK

  8. Issue an unpin all command to the cache

  9. Restart the NV Cache service

The default, or "not configured" setting corresponds to non-volatile cache feature enabled. Note, that another option would be to define the default to be the same system with a typical hard-disk and no separated-cache solution. This is not desirable for two reasons: i) this makes the process of running these tests extremely cumbersome, and ii) we aim to test the performance of the same system when the non-volatile cache feature is disabled to when the feature is enabled, thus comparing the end-user experience in the two cases.

The following steps enable the non-volatile cache feature:

  1. Launch an elevated command prompt

  2. In the command prompt: type: gpedit.msc

  3. In the popup dialog box with the title Group Policy Object Editor: Click: Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> Disk NV Cache

  4. Double-click "Turn Off Non Volatile Cache Feature"

  5. Click: unconfigured

  6. Click: Apply

  7. Click: OK

  8. Restart the NV Cache service

3.5.2.2 Standby and Hibernate

The goals of the standby and hibernate tests are to ensure not only data consistency during the transitions but also good performance and reliability. The transition into and out of standby and hibernate should be a fast transition not only to give the user a good experience but also to ensure the user's data is protected and that the disk has spun down and the head has been parked shortly after the transition has been initiated. In the event the system is a laptop this allows the user to carry the machine around without the risk of crashing the disk head into the spindle.

From a user's perspective both the timing of going into standby (hibernate) and resuming from standby (hibernate) are of interest. For standby we require that the time to go into standby as well as resume from standby for the non-volatile cache enabled case is no worse than 20% as compared to the non-volatile cache disabled case.

In general, one would expect that the time to resume from hibernate is faster in the non-volatile cache enabled as compared to the non-volatile cache disabled. For this test since our goal is to ensure that the performance is acceptable, we require that the time to resume from hibernate for the former be no worse than 5% as compared to the latter.

3.5.2.3 Shutdown

The goals for the shutdown test are similar to that for the standby/hibernate tests and both the time it takes to shutdown the system as well as the time it takes to boot the system are of interest.

We require that the time it takes to shutdown the system for the non-volatile cache enabled case be no worse than 15s worse as compared to the non-volatile cache disabled case. For boot, in general we would expect the non-volatile cache enabled case to yield smaller boot times. For the purposes of this test since our only goal is to ensure that the performance is acceptable, we require that the boot times for the non-volatile cache enabled case be no worse than 5% as compared to the non-volatile cache disabled case.

4 Tools

4.1 Disk IO Playback Test Tool

Almost all test related activity on the test system will be controlled via this tool. Below is an enumeration and detailed description of all major functionality, command line options, etc. Note the tool and the document will evolve over time so ensure that update to data versions of both are always used.

4.1.1 Overview

In order to provide repeatable and configurable workloads a tool will be provided that allows for the playback of a specific set of IOs as part of a scenario. The input to the tool will be a CSV file that describes the IOs to issue; this is referred to as an "IO Pattern" in this document. The format of the IO pattern file is detailed later in this document.

An IO pattern can be written by hand using a text editor or it can be generated from an ETW trace. ETW traces collect information about disk IO from the partition manager and as such a conversion must be applied to convert the ETW trace to an IO pattern consumable by the tool. The tool will provide options for not only collecting the ETW traces but also for converting them to IO patterns.

Once an IO pattern has been obtained it can be played back with configurable parameters as described below. IO patterns also provide a key extensibility point by which the pattern can be tweaked by hand (to insert sleeps for example) and operations can be inserted manually (such as to initiate a hibernate).

4.1.2 Disk Usage

Since issuing IO patterns that contain writes could be destructive to existing data on the disk the tool will create a large 4 GB file on the system volume and use it for doing the IO in the test.

As part of the test the tool will ensure that the file is contiguous, as such it's recommended for the system volume to have a large amount of free space. This ensures that writes can be issued without corrupting the disk or requiring the disk to be a secondary disk. As such the offsets contained in the IO patterns will be byte offsets relative to the start of the file.

In order to ensure no buffering or caching is done by the OS all IO will be issued as un-buffered.

4.1.3 ETW Tracing Options

The tool will support the collection of ETW traces such that the IO being played back can easily be traced and analyzed. The tracing will be controlled via a command line option and will be off by default.

The tool will also be able to convert an existing ETW trace into an IO pattern. Due to the restrictions on an IO pattern (must use byte offsets and work within a well defined area on the disk) some filtering and munging of the raw ETW data must be performed.

4.1.3.1 Performance Analysis

In addition to collecting traces the tool will provide support for analyzing the ETW traces collected as part of the performance tests.

4.1.4 Command Line Options

This section will evolve as the tool evolves, the most up to date help will always be the command line help provided with the tool.

4.1.4.1 Command Line Help

The tool will support command line help using the "-?" / "/?" option.

4.1.5 IO Pattern Dumps & Options

The tool will support the dumping of ETW traces to IO pattern files as well as the read back of those files into the tool for subsequent testing. The I/O Pattern file should have a csv or comma-separated format. The first line in the file is the command FileSize; there should be no subsequent FileSize commands in the I/O Pattern file. It is assumed that any read/write commands respect the file size specified in the first line else the run is aborted. Also, the tool which issues the command is expected to verify that the file size specified in not greater than the file size on disk. Additionally tags such as "sleep", "hibernate", etc will be supported such that state transitions can be initiated by the tool.

4.1.5.1 IO Pattern File Format

The first string in each line in the I/O pattern file identifies the command and so also the number of subsequent entries in that line. The possible commands are as follows; the strings in italics below correspond to a numerical or ascii value:

  • FileSize, FileSizeInBytes

  • FUAFileSize, FileSizeInBytes

  • WriteCache, BoolEnable

  • PerformanceTest, NumberOfParallelWriters, NumberOfRuns

  • Write/FUAWrite, BoolSync, ByteOffset, ByteCount, AsciiChar

  • Read/FUARead, BoolSync, ByteOffset, ByteCount

  • Flush

  • Hibernate, TimeToResumeInSeconds, CrashValue

  • Standby, TimeToResumeInSeconds, CrashValue

  • Shutdown, CrashValue

  • Crash

Except the FileSize/FUAFileSize/WriteCache commands, any number of the above commands could be interspersed arbitrarily. A FUAFileSize command should be present only if it is desired that an additional file be created which is accessed in the write-through mode. FUARead/FUAWrite commands then correspond to IOs to the file opened in the write-through mode.

The WriteCache command specifies a toggling of the disk's write caching in the track buffer. BoolEnable is 1 if it should be enabled or 0 if it should be disabled. This tag in the pattern file translates into a call to the disk with IOCTL_DISK_SET_CACHE_INFORMATION and the WriteCacheEnabled member of the input structure set appropriately.

The PerformanceTest command specifies that the test be a performance test for a power transition. NumberOfParallelWriters specifies the size of the workload on the system before the power transition. Each parallel writer issues write commands to the disk. Each parallel writer writes to its own file so that writes do not go to the same LBA on the disk. A test may have up to a maximum of 15 parallel writers. NumberOfRuns specifies the number of times a system undergoes the power transition for the baseline performance measurements and the actual scenario measurement with the NV Cache feature, respectively. For example, if NumberOfRuns is set to 5, the test would perform a total of 10 power transitions: 5 with the non volatile cache turned off and 5 with the feature turned on.

For the Write command ByteCount number of ASCII character AsciiChar are written to location ByteOffset in the file. The file is assumed to be filled with ASCII '0' to begin with and so also AsciiChar is chosen to be something different from '0'. BoolSync is 1 to indicate synchronous I/O, and 0 for asynchronous I/O. AsciiChar is restricted to the set of values, upper case A-Z.

Sleep corresponds to a call to the "Sleep" API and not to a power transition.

The Hibernate, Standby, Shutdown commands indicate that the system should programmatically be put into a power transition. If the CrashValue tag is 1 then the system will configure the crashing driver to crash when the power transition IRP is received by the crashing driver on the way down into the power transition. If the CrashValue tag is 2 then the system will configure the crashing driver to crash when the power transition IRP is received by the crashing driver on the way up from the power transition. If CrashValue tag is 0 then the system will be configured to automatically resume once the timeout specified by TimeToResumeInMilliseconds has elapsed and the crashing driver will not be used.

The Crash command corresponds to invoking an IOCTL to the crashing driver that crashes the system.

4.1.5.2 IO Pattern Execution

The I/O pattern "executor" creates the I/O Test File filled with character '0' and for the specified FileSizeInBytes for the FileSize command. The executor then simply executes the commands in the I/O Pattern File sequentially. The executor also retrieves the mapping of the file sectors to disk and saves this information in a separate file so that one can identify accesses to the file in the bus-trace.

4.2 Bus Analyzer

In order to accurately test separated NVRAM solutions a bus analyzer is required. This requirement stems from the fact that there is no reliable way to ensure the integrity of the user's data without directly monitoring the contents moving across the bus. Separated NVRAM solutions are designed to be resilient to crashing and when such a situation is detected they attempt to recover and ensure the consistency of the data on the disk. As such in order to properly test these kinds of solutions the consistency of the data on the disk cannot be checked by removing the disk and putting it in another system.

A bus analyzer will be used to ensure the order of IOs that go across the bus is consistent with what has been issued and completed by the test tool.

4.2.1 Bus Analyzer Output / Validation

The output of the bus analyzer will be used to verify that the contents of the disk are consistent and correct for a given test. The Disk IO Playback Tool outlined earlier will have an option to take a parsed and filtered bus trace as input and validate it against the specified test.

The Finisar Bus Doctor RX (RX-108P-BUFF) will be used for the creation and validation of the evaluation tests.

Since all bus analyzers will produce different output the format of the bus trace input to the tool will have to be defined. This will ensure that external parties can produce a tool to convert the output of their bus analyzer to a format that can be consumed by the tool for comparison.

The testing tools will use two methods will be employed to ensure the IOs are being serviced in the correct order that are detailed below.

4.2.1.1 Correlating Bus Trace IOs to issued IOs Using the Offsets

During the execution phase of a given test the test tool gathers information about the location of the file used for the test on the disk. This information combined with knowledge of the IOs issued by the test allows the bus trace IOs to match to their corresponding IOs issued by the test using the offset.

While any bus-analyzer could be used to trace the IO bus activity, the bus-trace needs to be processed and should have a certain format in order for it to be consumed by the tool used for verifying the IOs. For verification purposes only the Read, Write and Flush commands seen in the trace are of interest. The desired format for these three commands of interest is as follows; the strings in italics below correspond to a numerical value:

  • READ, LbaOffset, LbaCount

  • WRITE, LbaOffset, LbaCount

  • FLUSH

In the above, LbaOffset corresponds to the LBA offset to which the IO (read or write) was issued and LbaCount indicates the numbers if LBAs requested. READ and WRITE indicate whether the IO was a read or a write. The FLUSH command corresponds to a flush command observed in the bus-trace.

4.3 Faulty Driver

The faulty driver is a kernel mode driver that is able to bug check the system at a specified time. This driver will read a time value from the registry that corresponds to the time delay in milliseconds from driver load until the driver should bug check. The driver will maintain a count via the registry of the number of times it has been loaded and ensure that it does not bug check more than the number of times specified (also a registry key). This allows a system with the driver present to be (somewhat) easily recovered.

Additional modes will be required to signal that the driver should crash at well defined transitions, such as during the resume from standby. These will all be able to be toggled using the command line test tool.

Additionally an IOCTL will be exposed from the driver that will allow the system to be bug checked on demand.

Options will be provided with the test tool to install and uninstall the crashing driver.

4.4 Power Loss

Testing of scenarios that involve power loss will be a manual process in the first iteration of these tests. Power loss is defined as removing power from a system that contains no other power source that can be used for powering the system for general use, such as a laptop battery. Once power has been removed from the system it is imperative that the disk is not removed from the system and in general that the hardware is not tampered with in any way.

Power loss scenarios can be automated in the future using programmable power strings to ensure repeatability as well as reduce the amount of manual activity required to run the tests.

5 Test Details

5.1 Overview

5.1.1 System Preparation

To ensure that background system activity does not influence the test results we suggest disabling some components - the details on how this can be achieved are included in the README which is distributed with the test suite.

5.1.2 Test Initialization

In order to ensure the start of a test can be easily recognized in the output of the bus analyzer the test will issue a well defined pattern of IOs. This pattern will consist of 100 512 byte IOs issued to the 512 byte aligned middle-offset of the file. Note, that this is step is necessary only for the tests which require correlating the issued IOs to that seen in a bus trace.

5.1.3 IO Patterns

The IO patterns of interest for these test cases revolve around write activity. As such the initial set of test cases will contain a straightforward mixture of writes and flushes designed to provide an easily reproducible and verifiable IO pattern. The writes and flushes will be intermixed with power transitions and power loss events.

Each test will outline the pattern of IO issued by the test application as well as the required results as observed from the bus analyzer.

5.1.4 Power Transitions and Crashes

The power transitions that will be used in this version of the tests include the following:

  • Suspend to Standby (S3)

  • Suspend to Hibernate (S4)

  • Shutdown (S5)

  • Kernel Mode Crash / Bugcheck

  • Unexpected power loss

Most of the above will be issued programmatically and will not require any manual actions. As stated earlier the power loss transitions will require manual intervention both to remove and restore power.

5.2 Synthetic Data Consistency / Reliability Test Cases

5.2.1 Overview

In general the tests consist of a well defined set of IO followed by some action. The IO issued by each test and the expected result is given below for each test in detail. There is often significant overlap between tests of a similar category but rather than generalize and potentially introduce inaccuracies or assumptions each test is always described in detail.

The goal of these tests is to focus narrowly on a specific set of difficult problems and ensure they are handled correctly. This automatic NVCache flush command, however, is not necessary and so will not be issued when running the performance tests (described later).

Finally, note that the sequence of commands listed for each test case below is merely representative, The actual number of writes issued between two flushes, the IO sizes, the number of non-crashing power transitions etc. can vary a little

In the following, for saving space we have shown a sample workload with 4 writes and two flushes. The IOPattern file used in the test suite has 100 writes, 10 flushes.

In every IOPattern file, there will be no more than one type of power transition, e.g. an IOPattern file would not contain both standby and shutdown. For a test case containing shutdown, there is one shutdown command in the entire IOPattern file, and the shutdown command is always the last command in the file. For hibernate and standby tests, there are two power transition commands in each test case. An exception for the standby and hibernate tests is the power loss tests; in this case the IOPattern file contains only one standby or hibernate command. The last power transition in the IOPattern file may contain crash (with the crash flag set), depending on the particular test case.

5.2.2 Basic Write / Flush Test

The goal of the Basic Write / Flush test is to ensure that in the absence of a proper power transition that the correct ordering of writes is maintained and that flushes are obeyed correctly.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. A call to FlushFileBuffers

5.2.2.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 completes that the data for Steps 4 and 5 has been observed in the trace in order.

The test case files for this section is 5.2.2.1.io.txt.

5.2.2.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 completes that the data for Steps 4 and 5 has been observed in the trace in any order.

The test case files for this section are 5.2.2.2.io.txt and 5.2.2.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.2.3 Basic Write / Flush Test with Crash

This permutation of the test inserts a call to the crashing driver to crash the system. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. A call to the crashing driver to crash the system.

  7. The system will be rebooted and allowed to boot completely into the OS which could trigger a NVRAM cache recovery operation if needed.

5.2.2.3.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 7 the data for Steps 4 and 5 has been observed in the trace in order.

The test case files for this section are 5.2.2.3.1.io.txt and 5.2.2.3.1.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.2.3.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 7 the data for Step 4 and Step 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.2.3.2.io.txt and 5.2.2.3.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.2.4 Basic Write / Flush Test with Power Loss

This permutation of the test inserts a sudden power loss into the test. The goal of this test is to ensure that the proper ordering is maintained in lieu of a sudden power loss and a recovery operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. Power will be removed from the system.

  7. The system will be rebooted and allowed to boot completely into the OS which could trigger a NVRAM cache recovery operation if needed.

5.2.2.4.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 7 the data for Steps 4 and 5 has been observed in the trace in order.

The test case files for this section are 5.2.2.4.1.io.txt and 5.2.2.4.1.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.2.4.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 7 the data for Step 4 and Step 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.2.4.2.io.txt and 5.2.2.4.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.2.5 Basic Write / Flush Test with Power Loss 2

This permutation of the test inserts a sudden power loss into the test as well as a power loss during the potential recovery step. The goal of this test is to ensure that the proper ordering is maintained in lieu of a sudden power loss and a power loss during a recovery operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. Power will be removed from the system.

  7. The system will be booted.

  8. Prior the system booting into the OS power will be removed from the system.
    • Note this step is a bit undefined right now as there is no known reliable way to detect if this recovery is going on. There may be activity on the bus trace that can signify it is happening; it is an area that will need to be investigated.

  9. The system will be booted and allowed to boot completely into the OS.

5.2.2.5.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 9 the data for Steps 4 and 5 has been observed in the trace in order.

The test case files for this section are 5.2.2.5.1.io.txt and 5.2.2.5.1.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.2.5.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 9 the data for Step 4 and Step 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.2.5.2.io.txt and 5.2.2.5.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.3 Standby / Resume Test

The goal of the Standby / Resume test is to ensure that in the presence of a proper power transition that the correct ordering of writes is maintained and that flushes are obeyed correctly.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will suspend into standby.

  7. The system will be resumed.

  8. A call to FlushFileBuffers

5.2.3.1.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order. This same requirement holds true for Step 7.

  • After Step 8 the data for Steps 4 and 5 has been observed in the trace in order.

The test case file for this section is 5.2.3.1.1.io.txt.

5.2.3.1.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order. This same requirement holds true for Step 7.

  • After Step 8 completes that the data for Steps 4 and 5 has been observed in the trace in any order.

The test case file for this section is 5.2.3.1.2.io.txt.

5.2.3.2 Standby / Resume Test with Crash

This permutation of the test inserts a call to the crashing driver to crash the system during the resume operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation. The crashing driver will be set up to crash one time immediately after being notified of the resume operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will suspend into standby

  7. The system will be resumed and the driver will crash the system during the resume.

  8. The system will be booted completely into the OS and the driver will not crash it this time.

5.2.3.2.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order. This same requirement holds true for Step 7.

  • After Step 8 the data for Steps 4 and 5 has been observed in the trace in order.

The test case files for this section are 5.2.3.2.1.io.txt and 5.2.3.2.1.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.3.2.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order. This same requirement holds true for Step 7.

  • After Step 8 completes that the data for Steps 4 and 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.3.2.2.io.txt and 5.2.3.2.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.3.3 Standby / Resume Test with Crash 2

This permutation of the test inserts a call to the crashing driver to crash the system during the standby operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will suspend into standby and the crashing driver will crash the system before the transition is complete.

  7. . The system will be booted completely into the OS and the driver will not crash it this time.

5.2.3.3.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order.

  • After Step 7 the data for Steps 4 and 5 has been observed in the trace in order.

The test case file for this section is 5.2.3.3.1.io.txt.

5.2.3.3.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order.

  • After Step 7 completes the data for Steps 4 and 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.3.3.2.io.txt and 5.2.3.3.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.3.4 Standby / Resume Test with Power Loss

This permutation of the test inserts an unexpected power loss during the resume operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a recovery operation.

The test will issue the following set of IO

  1. . 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will suspend into standby

  7. The system will be resumed and the power will be removed during the resume.

  8. Power will be restored and the system will be booted completely into the OS.

5.2.3.4.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order. This same requirement holds true for Step 7.

  • After Step 8 the data for Steps 4 and 5 has been observed in the trace in order.

The test case files for this section are 5.2.3.4.1.io.txt and 5.2.3.4.1.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.3.4.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order. This same requirement holds true for Step 7.

  • After Step 8 completes that the data for Steps 4 and 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.3.4.2.io.txt and 5.2.3.4.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.3.5 Standby / Resume Test with Power Loss 2

This permutation of the test inserts an unexpected power loss during the resume operation as well as a power loss during the recovery operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a power loss during a recovery operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will suspend into standby

  7. The system will be resumed and the power will be removed during the resume.

  8. Power will be restored and the system will be booted. Prior the system booting into the OS power will be removed from the system.

  9. Power will be restored and the system will be booted completely into the OS.

5.2.3.5.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order. This same requirement holds true for Step 7 and Step 8.

  • After Step 9 the data for Steps 4 and 5 has been observed in the trace in order.

The test case file for this section is 5.2.3.5.1.io.txt.

5.2.3.5.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order. This same requirement holds true for Step 7 and Step 8.

  • After Step 9 completes that the data for Steps 4 and 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.3.5.2.io.txt and 5.2.3.5.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.4 Hibernate / Resume Test

The goal of the Hibernate / Resume test is to ensure that in the presence of a proper power transition that the correct ordering of writes is maintained and that flushes are obeyed correctly.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will be put into hibernate.

  7. The system will be resumed.

  8. A call to FlushFileBuffers

5.2.4.1.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order. This same requirement holds true for Step 7.

  • After Step 8 the data for Steps 4 and 5 has been observed in the trace in order.

The test case file for this section is 5.2.4.1.1.io.txt.

5.2.4.1.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order. This same requirement holds true for Step 7.

  • After Step 8 completes that the data for Steps 4 and 5 has been observed in the trace in any order.

The test case file for this section is 5.2.4.1.2.io.txt.

5.2.4.2 Hibernate / Resume Test with Crash

This permutation of the test inserts a call to the crashing driver to crash the system during the resume operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation. The crashing driver will be set up to crash one time immediately after being notified of the resume operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will be put into hibernate.

  7. The system will be resumed and the driver will crash the system during the resume.

  8. The system will be booted completely into the OS and the driver will not crash it this time.

5.2.4.2.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order. This same requirement holds true for Step 7.

  • After Step 8 the data for Steps 4 and 5 has been observed in the trace in order.

The test case file for this section is 5.2.4.2.1.io.txt.

5.2.4.2.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order. This same requirement holds true for Step 7.

  • After Step 8 completes that the data for Steps 4 and 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.4.2.2.io.txt and 5.2.4.2.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.4.3 Hibernate / Resume Test with Crash 2

This permutation of the test inserts a call to the crashing driver to crash the system during the hibernate operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will be put into hibernate and the crashing driver will crash the system before the hibernate operation completes.

  7. The system will be booted completely into the OS and the driver will not crash it this time.

5.2.4.3.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order.

  • After Step 7 the data for Steps 4 and 5 has been observed in the trace in order.

The test case file for this section is 5.2.4.3.1.io.txt.

5.2.4.3.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order.

  • After Step 7 completes that the data for Steps 4 and 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.4.3.2.io.txt and 5.2.4.3.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.4.4 Hibernate / Resume Test with Power Loss

This permutation of the test inserts an unexpected power loss during the resume operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a recovery operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will be put into hibernate

  7. The system will be resumed and the power will be removed during the resume.

  8. Power will be restored and the system will be booted completely into the OS.

5.2.4.4.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order. This same requirement holds true for Step 7.

  • After Step 8 the data for Steps 4 and 5 has been observed in the trace in order.

The test case file for this section is 5.2.4.4.1.io.txt.

5.2.4.4.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order. This same requirement holds true for Step 7.

  • After Step 8 completes that the data for Steps 4 and 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.4.4.2.io.txt and 5.2.4.4.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.4.5 Hibernate / Resume Test with Power Loss 2

This permutation of the test inserts an unexpected power loss during the resume operation as well as a power loss during the recovery operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a power loss during a recovery operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will be put into hibernate

  7. The system will be resumed and the power will be removed during the resume.

  8. Power will be restored and the system will be booted. Prior the system booting into the OS power will be removed from the system.

  9. Power will be restored and the system will be booted completely into the OS.

5.2.4.5.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order. This same requirement holds true for Step 7 and Step 8.

  • After Step 9 the data for Steps 4 and 5 has been observed in the trace in order.

The test case file for this section is 5.2.4.5.1.io.txt.

5.2.4.5.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order. This same requirement holds true for Step 7 and Step 8.

  • After Step 9 completes that the data for Steps 4 and 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.4.5.2.io.txt and 5.2.4.5.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.5 Shutdown / Restart Test

The goal of the Shutdown / Restart test is to ensure that in the presence of a proper shutdown and reboot that the correct ordering of writes is maintained and that flushes are obeyed correctly.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will be shutdown cleanly.

5.2.5.1.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 6 completes that the data for Steps 4 and 5 has been observed in the trace in order.

The test case file for this section is 5.2.5.1.1.io.txt.

5.2.5.1.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 completes that the data for Steps 4 and 5 has been observed in the trace in any order.

The test case file for this section is 5.2.5.1.2.io.txt.

5.2.5.2 Shutdown / Restart Test with Crash

This permutation of the test inserts a call to the crashing driver to crash the system during the shutdown operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation. The crashing driver will be set up to crash one time during the shutdown process.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will be shutdown.

  7. During the shutdown the crashing driver will crash the system.

  8. The system will be booted completely into the OS.

5.2.5.2.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 7 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order.

  • After Step 8 the data for Steps 4 and 5 has been observed in the trace in order.

The test case files for this section are 5.2.5.2.1.io.txt

5.2.5.2.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 6 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order. This same requirement holds true for Step 7.

  • After Step 8 completes that the data for Steps 4 and 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.5.2.2.io.txt and 5.2.5.2.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.5.3 Shutdown / Restart Test with Power Loss

This permutation of the test inserts an unexpected power loss during the shutdown operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a recovery operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will be shutdown

  7. Power will be removed from the system before the shutdown is complete.

  8. Power will be restored and the system will be booted completely into the OS.

5.2.5.3.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 7 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order.

  • After Step 8 the data for Steps 4 and 5 has been observed in the trace in order.

The test case files for this section are 5.2.5.3.1.io.txt.

5.2.5.3.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 7 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order.

  • After Step 8 completes that the data for Steps 4 and 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.5.3.2.io.txt and 5.2.5.3.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.5.4 Shutdown / Restart Test with Power Loss 2

This permutation of the test inserts an unexpected power loss during the shutdown operation as well as a power loss during the recovery operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a power loss during a recovery operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will be shutdown

  7. Power will be removed from the system before the shutdown is complete.

  8. Power will be restored and the system will be booted. Prior the system booting into the OS power will be removed from the system.

  9. Power will be restored and the system will be booted completely into the OS.

5.2.5.4.1 Valid Results with Write Buffering Disabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in order.

  • After Step 7 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in order. This requirement also holds true for Step 8.

  • After Step 9 the data for Steps 4 and 5 has been observed in the trace in order.

The test case files for this section are 5.2.5.4.1.io.txt

5.2.5.4.2 Valid Results with Write Buffering Enabled

  • After Step 3 completes that the data for Steps 1 and 2 has been observed in the trace in any order.

  • After Step 7 the data for Step 4 or Step 4 and Step 5 may have been observed in the trace in any order. This requirement also holds true for Step 8.

  • After Step 9 completes that the data for Steps 4 and 5 may have been observed in the trace in any order. It is valid for the data in Steps 4 and 5 to never be observed in the trace for this test.

The test case files for this section are 5.2.5.4.2.io.txt and 5.2.5.4.2.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.6 FUA Test Cases

In this section, we outline tests for the case the application issues interspersed IOs to two files one of which is accessed in the write-through mode and the other in the write-back mode[2]. These tests need to be run only for the case the write buffering is enabled on the system. For the case write buffering is disabled the test cases in the previous sections suffice.

There is a FUA test case corresponding to each of tests listed in Sections 5.2.2 through 5.2.4 above. The ordering of IOs for these test cases essentially follows from the discussion in Section 3.4.4. Rather then repeat each of the test scenarios listed above we elaborate only a sample test case. The ordering requirements for the remaining test cases can be inferred from this example.

In the following, write and FUAwrite respectively, correspond to writes being issued o two different files opened in the write-through and write-back mode, respectively,

NOTE: FUA Test Cases are NOT part of the LOGO requirements. The Separated Cache Solution is not required to run or pass any FUA Tests.

5.2.6.1 Basic Write / Flush Test

The goal of the Basic Write / Flush test is to ensure that in the absence of a proper power transition that the correct ordering of writes is maintained and that flushes are obeyed correctly.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case files for this section are 5.2.6.1.fua.io.txt and 5.2.6.1.fua.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.6.2 Basic Write / Flush Test with Crash

This permutation of the test inserts a call to the crashing driver to crash the system. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. A call to the crashing driver to crash the system.

  10. The system will be rebooted and allowed to boot completely into the OS which could trigger a NVRAM cache recovery operation if needed.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case files for this section are 5.2.6.2.fua.io.txt and 5.2.6.2.fua.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.6.3 Basic Write / Flush Test with Power Loss

This permutation of the test inserts a sudden power loss into the test. The goal of this test is to ensure that the proper ordering is maintained in lieu of a sudden power loss and a recovery operation.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB FUAwrite of all "S"s to offset L.

  10. 4 KB write of all "C"s to offset W.

  11. 4 KB write of all "D"s to offset Z.

  12. Power will be removed from the system.

  13. The system will be rebooted and allowed to boot completely into the OS which could trigger a NVRAM cache recovery operation if needed.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case files for this section are 5.2.6.3.fua.io.txt and 5.2.6.3.fua.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.6.4 Standby / Resume Test

The goal of the Standby / Resume test is to ensure that in the presence of a proper power transition that the correct ordering of writes is maintained and that flushes are obeyed correctly.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will suspend into standby.

  12. The system will be resumed.

  13. A call to FlushFileBuffers

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case file for this section is 5.2.6.4.fua.io.txt.

5.2.6.5 Standby / Resume Test with Crash

This permutation of the test inserts a call to the crashing driver to crash the system during the resume operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation. The crashing driver will be set up to crash one time immediately after being notified of the resume operation.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will suspend into standby

  12. The system will be resumed and the driver will crash the system during the resume.

  13. The system will be booted completely into the OS and the driver will not crash it this time.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case file for this section is 5.2.6.5.fua.io.txt.

5.2.6.6 Standby / Resume Test with Crash 2

This permutation of the test inserts a call to the crashing driver to crash the system during the standby operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will suspend into standby and the crashing driver will crash the system before the transition is complete.

  12. The system will be booted completely into the OS and the driver will not crash it this time.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case files for this section are 5.2.6.6.fua.io.txt and 5.2.6.6.fua.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.6.7 Standby / Resume Test with Power Loss

This permutation of the test inserts an unexpected power loss during the resume operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a recovery operation.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will suspend into standby

  12. The system will be resumed and the power will be removed during the resume.

  13. Power will be restored and the system will be booted completely into the OS.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case file for this section is 5.2.6.7.fua.io.txt.

5.2.6.8 Standby / Resume Test with Power Loss 2

This permutation of the test inserts an unexpected power loss during the resume operation as well as a power loss during the recovery operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a power loss during a recovery operation.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will suspend into standby

  12. The system will be resumed and the power will be removed during the resume.

  13. Power will be restored and the system will be booted. Prior the system booting into the OS power will be removed from the system.

  14. Power will be restored and the system will be booted completely into the OS.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case files for this section are 5.2.6.8.fua.io.txt and 5.2.6.8.fua.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.6.9 Hibernate / Resume Test

The goal of the Hibernate / Resume test is to ensure that in the presence of a proper power transition that the correct ordering of writes is maintained and that flushes are obeyed correctly.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will be put into hibernate.

  12. The system will be resumed.

  13. A call to FlushFileBuffers

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case files for this section are 5.2.6.9.fua.io.txt.

5.2.6.10 Hibernate / Resume Test with Crash

This permutation of the test inserts a call to the crashing driver to crash the system during the resume operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation. The crashing driver will be set up to crash one time immediately after being notified of the resume operation.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will be put into hibernate.

  12. The system will be resumed and the driver will crash the system during the resume.

  13. The system will be booted completely into the OS and the driver will not crash it this time.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case files for this section are 5.2.6.10.fua.io.txt and 5.2.6.10.fua.ff.io.txt. The former file has a flush frequency of 10 writes and the latter file has a flush frequency of 2 writes.

5.2.6.11 Hibernate / Resume Test with Crash 2

This permutation of the test inserts a call to the crashing driver to crash the system during the hibernate operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation.

The test will issue the following set of IO

  1. 4 KB write of all "A"s to offset X.

  2. 4 KB write of all "B"s to offset Y.

  3. A call to FlushFileBuffers

  4. 4 KB write of all "C"s to offset W.

  5. 4 KB write of all "D"s to offset Z.

  6. The system will be put into hibernate and the crashing driver will crash the system before the hibernate operation completes.

  7. The system will be booted completely into the OS and the driver will not crash it this time.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case file for this section is 5.2.6.11.fua.io.txt.

5.2.6.12 Hibernate / Resume Test with Power Loss

This permutation of the test inserts an unexpected power loss during the resume operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a recovery operation.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will be put into hibernate.

  12. The system will be resumed and the driver will crash the system during the resume.

  13. Power will be restored and the system will be booted completely into the OS.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case files for this section are 5.2.6.12.fua.io.txt.

5.2.6.13 Hibernate / Resume Test with Power Loss 2

This permutation of the test inserts an unexpected power loss during the resume operation as well as a power loss during the recovery operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a power loss during a recovery operation.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will be put into hibernate.

  12. The system will be resumed and the driver will crash the system during the resume.

  13. Power will be restored and the system will be booted. Prior the system booting into the OS power will be removed from the system.

  14. Power will be restored and the system will be booted completely into the OS.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case file for this section is 5.2.6.13.fua.io.txt.

5.2.6.14 Shutdown / Restart Test

The goal of the Shutdown / Restart test is to ensure that in the presence of a proper shutdown and reboot that the correct ordering of writes is maintained and that flushes are obeyed correctly.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will be shutdown cleanly.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case file for this section is 5.2.6.14.fua.io.txt.

5.2.6.15 Shutdown / Restart Test with Crash

This permutation of the test inserts a call to the crashing driver to crash the system during the shutdown operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a crash and a recovery operation. The crashing driver will be set up to crash one time during the shutdown process.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will be shutdown.

  12. During the shutdown the crashing driver will crash the system.

  13. The system will be booted completely into the OS.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case file for this section is 5.2.6.15.fua.io.txt. The frequent flush test case is 5.2.6.15.fua.ff.io.txt.

5.2.6.16 Shutdown / Restart Test with Power Loss

This permutation of the test inserts an unexpected power loss during the shutdown operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a recovery operation.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will be shutdown.

  12. Power will be removed from the system before the shutdown is complete.

  13. Power will be restored and the system will be booted completely into the OS.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case files for this section are 5.2.6.16.fua.io.txt.

5.2.6.17 Shutdown / Restart Test with Power Loss 2

This permutation of the test inserts an unexpected power loss during the shutdown operation as well as a power loss during the recovery operation. The goal of this test is to ensure that the proper ordering is maintained in lieu of a power loss and a power loss during a recovery operation.

The test will issue the following set of IO

  1. 4 KB FUAwrite of all "P"s to offset I.

  2. 4 KB write of all "A"s to offset X.

  3. 4 KB write of all "B"s to offset Y.

  4. 4 KB FUAwrite of all "Q"s to offset J.

  5. 4 KB write of all "C"s to offset W.

  6. 4 KB write of all "D"s to offset Z.

  7. 4 KB FUAwrite of all "R"s to offset K.

  8. A call to FlushFileBuffers

  9. 4 KB write of all "C"s to offset W.

  10. 4 KB write of all "D"s to offset Z.

  11. The system will be shutdown.

  12. Power will be removed from the system before the shutdown is complete.

  13. Power will be restored and the system will be booted. Prior the system booting into the OS power will be removed from the system.

  14. Power will be restored and the system will be booted completely into the OS.

Valid results:

  • None of the data for steps 2 through 7 are observed before the data for step 1 has been observed in the trace.

  • When the IO corresponding to step 4 is observed in the trace none of data for step 5 through 7 has been observed in the trace. The data for steps 2 and 3 may or may not have been observed in the trace.

  • When the data for step 7 is observed in the trace the data for step 1 and step 4 has been observed in the trace, the data for steps 2, 3, 5 and 6 may or may not have been observed in the trace.

  • When step 8 completes all the data for steps 1 through 7 has been observed in the trace.

The test case files for this section are 5.2.6.17.fua.io.txt.

5.3 Synthetic Performance Test Cases

As with the previous tests each test case below is given in detail so as to ensure there is no confusion or ambiguity about the structure of the test or the expected results.

All performance testing is done with write caching in the disk's track buffer enabled. The methodology for these tests is similar to that outlined in Section 3.5.2.1. Also, similarly we compare the average timing for the operations listed below for the hybrid case to the default case over 5-10 runs for each case.

While it would be desirable to provide some representative performance numbers for these tests the unavailability of prototypes in the market prevents us from doing so. These goals have been designed to ensure an acceptable user experience and moreover, the fact that the goals are relative in nature makes providing representative performance numbers unnecessary. Here, by relative we refer to the fact that the performance goals are not absolute and compare the performance of the same system when the non-volatile cache feature is enabled to when it is disabled.

Finally, note that these tests will be run for both the case with write-buffering enabled on the system and the case with write-buffering disabled.

5.3.1 Standby

The concerns around standby revolve around there being a sufficient amount of dirty data in NV cache such that when the power transition is initiated a significant amount of time is required to flush out the dirty data. This would not only greatly reduce the quality of that experience for the user but also puts their data at risk if the disk is required to continue spinning much longer after the transition is initiated (i.e. the lid closed).

For standby we require that the time to go into standby as well as resume from standby for the non-volatile cache enabled case is no worse than 20% as compared to the non-volatile cache disabled case.

5.3.1.1 Suspend with Heavy Write Activity 1

The goal of this test is to accumulate a significant amount of unique dirty data shortly before transitioning to standby. A flush happens for every ten writes in this test. The test script file for this test case with write caching disabled is 5.3.1.1.WC0.io.txt. The test script file for this test case with write caching enabled is 5.3.1.1.WC1.io.txt. The passing criteria for both the write cache enabled and disabled cases are the same. Passing the tests requires that the system completely enter standby within a specified period of time.

The test is comprised of the following steps:

Steps 1 to 6 measure standby and resume time with non-volatile cache disabled

  1. Disable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  2. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

  3. Initiate a standby power transition and start a timer which wakes up the system after 1 minute (i.e. the system would stay in the standby state for 1 minute).

  4. Delay for 2 minutes after the systems resumes from standby

  5. Extract standby and resume time from the system's Performance Diagnostics event log

  6. Repeat steps 2. to 5. five times

    Steps 7 to 12 measure standby and resume time with non-volatile cache enabled

  7. Enable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  8. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

    NOTE: These will be the same IO which were issued in Step 1.

  9. Initiate a standby power transition and start a timer which wakes up the system after 1 minute. (i.e. the system would stay in the standby state for 1 minute).

  10. Delay for 2 minutes after the systems resumes from standby.

  11. Extract standby and resume time from the system's Performance Diagnostics event log.

  12. Repeat steps 8-11 five times.

  13. Calculate the average for standby and resume duration measurements with the non-volatile cache turned on and turned off respectively.

5.3.1.1.1 Passing this test requires that going into standby and resuming (i.e. displaying of the desktop) completes within a set amount of time. The test fails if any of the following conditions is true:

  • The average time for the system to go into standby for the non-volatile cache enabled case is 20% above the non-volatile cache disabled case

  • The average time for the system to resume from standby for the non-volatile cache enabled case is 20% above the non-volatile cache disabled case

5.3.1.2 Suspend with Heavy Write Activity 2

The goal of this test is to accumulate a significant amount of unique dirty data shortly before issuing an explicit flush prior to transitioning to standby. A flush happens for every two writes in this test--the difference between this test case and 5.3.1.1. The test script file for this test case with write caching disabled is 5.3.1.2.WC0.io.txt. The test script file for this test case with write caching enabled is 5.3.1.2.WC1.io.txt. The passing criteria for both the write cache enabled and disabled cases are the same. Passing the test requires that the system completely enter standby within a specified period of time.

The test is comprised of the following steps:

Steps 1 to 7 measure standby and resume time with non-volatile cache disabled

  1. Disable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  2. Issue a FlushFileBuffers call.

  3. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

  4. Initiate a standby power transition and start a timer which wakes up the system after 1 minute (i.e. the system would stay in the standby state for 1 minute).

  5. Delay for 2 minutes after the systems resumes from standby.

  6. Extract standby and resume time from the system's Performance Diagnostics event log.

  7. Repeat steps 2-6 five times.

    Steps 8 to 14 measure standby and resume time with non-volatile cache enabled.

  8. Enable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  9. Issue a FlushFileBuffers call.

  10. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

    NOTE: These will be the same IO which were issued in Step 1.

  11. Initiate a standby power transition and start a timer which wakes up the system after 1 minute. (For example, the system would stay in the standby state for 1 minute.)

  12. Delay for 2 minutes after the systems resumes from standby.

  13. Extract standby and resume time from the system's Performance Diagnostics event log.

  14. Repeat steps 9-13 five times

  15. Calculate the average for standby and resume duration measurements with the non-volatile cache turned on and turned off respectively.

5.3.1.2.1 Passing this test requires that the going into standby and resuming (i.e. displaying of the desktop) completes within a set amount of time. The test fails if any of the following conditions is true:

  • The average time for the system to go into standby for the non-volatile cache enabled case is 20% above the non-volatile cache disabled case

  • The average time for the system to resume from standby for the non-volatile cache enabled case is 20% above the non-volatile cache disabled case

5.3.2 Hibernate

The concerns around hibernate revolve around there being a sufficient amount of dirty data in NV cache such that when the power transition is initiated a significant amount of time is required to flush out the dirty data. This would not only greatly reduce the quality of that experience for the user but also puts their data at risk if the disk is required to continue spinning much longer after the transition is initiated (i.e. the lid closed).

In general, one would expect that the time to resume from hibernate is faster in the non-volatile cache enabled case as compared to the non-volatile cache disabled case. For this test, we require that the time to resume from hibernate for the former be no worse than 5% as compared to the latter.

5.3.2.1 Hibernate with Heavy Write Activity 1

The goal of this test is to accumulate a significant amount of unique dirty data shortly before transitioning to hibernate. A flush happens for every ten writes in this test. The test script file for this test case with write caching disabled is 5.3.2.1.WC0.io.txt. The test script file for this test case with write caching enabled is 5.3.2.1.WC1.io.txt. The passing criteria for both the write cache enabled and disabled cases are the same. Passing the test requires that the system completely hibernate within a specified period of time.

The test is comprised of the following steps:

Steps 1 to 6 measure hibernate resume time with non-volatile cache disabled

  1. Disable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  2. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

  3. Initiate a hibernate power transition and start a timer which wakes up the system after 1 minute (for example, the system would stay in the hibernate state for 1 minute).

  4. Delay for 2 minutes after the systems resumes from hibernate.

  5. Extract hibernate resume time from the system's Performance Diagnostics event log.

  6. Repeat steps 2-5 five times.

    Steps 7 to 12 measure hibernate resume time with non-volatile cache enabled.

  7. Enable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  8. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

    NOTE: These will be the same IO which were issued in Step 1.

  9. Initiate a hibernate power transition and start a timer which wakes up the system after 1 minute (for example, the system would stay in the hibernate state for 1 minute).

  10. Delay for 2 minutes after the systems resumes from hibernate.

  11. Extract hibernate resume time from the system's Performance Diagnostics event log.

  12. Repeat steps 8-11 five times.

  13. Calculate the average for hibernate resume duration measurements with the non-volatile cache turned on and turned off respectively.

5.3.2.1.1 Passing this test requires that hibernate resume (i.e. displaying of the desktop) completes within a set amount of time. The test fails if both the following conditions are true:

  • The average time for the system to resume from hibernate for the non-volatile cache enabled case is 5% above the non-volatile cache disabled case.

  • The average time for the system to resume from hibernate for the non-volatile cache enabled case exceeds the non-volatile cache disabled case by over 2 seconds.

5.3.2.2 Hibernate with Heavy Write Activity 2

The goal of this test is to accumulate a significant amount of unique dirty data shortly before issuing an explicit flush prior to transitioning to hibernate. A flush happens for every two writes in this test--the difference between this test case and 5.3.2.1. The test script file for this test case with write caching disabled is 5.3.2.2.WC0.io.txt. The test script file for this test case with write caching enabled is 5.3.2.2.WC1.io.txt. The passing criteria for both the write cache enabled and disabled cases are the same. Passing the test requires that the system completely hibernate within a specified period of time.

The test is comprised of the following steps:

Steps 1 to 6 measure hibernate resume time with non-volatile cache disabled

  1. Disable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  2. Issue a FlushFileBuffers call.

  3. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

  4. Initiate a hibernate power transition and start a timer which wakes up the system after 1 minute (for example, the system would stay in the hibernate state for 1 minute).

  5. Delay for 2 minutes after the systems resumes from hibernate.

  6. Extract hibernate resume time from the system's Performance Diagnostics event log.

  7. Repeat steps 2-6 five times.

    Steps 8 to 14 measure hibernate resume time with non-volatile cache enabled.

  8. Enable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  9. Issue a FlushFileBuffers call.

  10. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

    NOTE: These will be the same IO which were issued in Step 1.

  11. Initiate a hibernate power transition and start a timer which wakes up the system after 1 minute (for example the system would stay in the hibernate state for 1 minute).

  12. Delay for 2 minutes after the systems resumes from hibernate.

  13. Extract hibernate resume time from the system's Performance Diagnostics event log.

  14. Repeat steps 9-13. five times.

  15. Calculate the average for hibernate resume duration measurements with the non-volatile cache turned on and turned off respectively.

5.3.2.2.1 Passing this test requires that hibernate resume (i.e. displaying of the desktop) completes within a set amount of time. The test fails if both the following conditions are true:

  • The average time for the system to resume from hibernate for the non-volatile cache enabled case is 5% above the non-volatile cache disabled case.

  • The average time for the system to resume from hibernate for the non-volatile cache enabled case exceeds the non-volatile cache disabled case by over 2 seconds.

5.3.3 Shutdown

The concerns around shutdown revolve around there being a sufficient amount of dirty data in NV cache such that when the power transition is initiated a significant amount of time is required to flush out the dirty data. This would not only greatly reduce the quality of that experience for the user but also puts their data at risk if the disk is required to continue spinning much longer after the transition is initiated (i.e. the lid closed).

We require that the time it takes to shutdown the system for the non-volatile cache enabled case be no worse than 15s worse as compared to the non-volatile cache disabled case. For boot, in general we would expect the non-volatile cache enabled case to yield smaller boot times. For the purposes of this test, we require that the boot times for the non-volatile cache enabled case be no worse than 5% as compared to the non-volatile cache disabled case.

5.3.3.1 Shutdown with Heavy Write Activity 1

The goal of this test is to accumulate a significant amount of unique dirty data shortly before shutting down the system. A flush happens for every ten writes in this test. The test script file for this test case with write caching disabled is 5.3.3.1.WC0.io.txt. The test script file for this test case with write caching enabled is 5.3.3.1.WC1.io.txt. The passing criteria for both the write cache enabled and disabled cases are the same. Passing the test requires that the system shutdown within a specified period of time.

The test is comprised of the following steps:

Steps 1 to 6 measure shutdown and boot time with non-volatile cache disabled

  1. Disable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  2. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

  3. Initiate a shutdown power transition

  4. Delay for 2 minutes after the systems boots

  5. Extract shutdown and boot time from the system's Performance Diagnostics event log

  6. Repeat steps 2. to 5. five times

    Steps 7 to measure shutdown and boot time with non-volatile cache enabled

  7. Enable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  8. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

    NOTE: These will be the same IO which were issued in Step 1

  9. Initiate a shutdown power transition.

  10. Delay for 2 minutes after the systems reboots.

  11. Extract shutdown and boot times from the system's Performance Diagnostics event log.

  12. Repeat steps 8-11 five times.

  13. Calculate the average for shutdown and boot duration measurements with the non-volatile cache turned on and turned off respectively.

5.3.3.1.1 Passing this test requires that shutdown and boot (i.e. displaying of the desktop) completes within a set amount of time. The test fails if any of the following conditions is true:

  • The average time for the system to shutdown for the non-volatile cache enabled case is 15 seconds longer than the non-volatile cache disabled case

  • The average time for the system to boot for the non-volatile cache enabled case is 5% above the non-volatile cache disabled case

5.3.3.2 Shutdown with Heavy Write Activity 2

The goal of this test is to accumulate a significant amount of unique dirty data shortly before issuing an explicit call to flush the track buffer followed by a shutdown. A flush happens for every two writes in this test--the difference between this test case and 5.3.3.2. The test script file for this test case with write caching disabled is 5.3.3.2.WC0.io.txt. The test script file for this test case with write caching enabled is 5.3.3.2.WC1.io.txt. The passing criteria for both the write cache enabled and disabled cases are the same. Passing the test requires that the system shutdown within a specified period of time.

The test is comprised of the following steps:

Steps 1 to 7 measure shutdown and boot time with non-volatile cache disabled

  1. Disable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  2. Issue a Flush command.

  3. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

  4. Initiate a shutdown power transition.

  5. Delay for 2 minutes after the systems boots.

  6. Extract shutdown and boot time from the system's Performance Diagnostics event log.

  7. Repeat steps 2-6 five times.

    Steps 8 to 14 measure shutdown and boot time with non-volatile cache enabled

  8. Enable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  9. Issue a Flush command.

  10. Issue 64 MB of random IO using 64 KB IOs to unique offsets. i.e. no offset IO will be issued to the same offset twice in this test.

    NOTE: These will be the same IO which were issued in Step 1.

  11. Initiate a shutdown power transition.

  12. Delay for 2 minutes after the systems reboots.

  13. Extract shutdown and boot times from the system's Performance Diagnostics event log.

  14. Repeat steps 9-13 five times.

  15. Calculate the average for shutdown and boot duration measurements with the non-volatile cache turned on and turned off respectively.

5.3.3.2.1 Passing this test requires that shutdown and boot (i.e. displaying of the desktop) completes within a set amount of time. The test fails if any of the following conditions is true:

  • The average time for the system to shutdown for the non-volatile cache enabled case is 15 seconds longer than the non-volatile cache disabled case

  • The average time for the system to boot for the non-volatile cache enabled case is 5% above the non-volatile cache disabled case

5.3.4 General Use

The concerns around general use performance are vast and this set of tests is most likely to grow over time as engineering samples for separated NV cache solutions are received and can be evaluated. The goal of these tests is reproduce common problematic behavior and ensure that in the face of said behavior a separated NV cache solution can deliver an high performance experience.

5.3.4.1 Heavy Random Write Activity with Read

The goal of this test is to ensure in the presence of a significant amount of write activity that IOs are not blocked for long periods of time while book keeping and other flush activities associated with the NV cache are performed. The test script file for this test case with write caching disabled is 5.3.4.1.WC0.io.txt. The test script file for this test case with write caching enabled is 5.3.4.1.WC1.io.txt. The passing criteria for both the write cache enabled and disabled cases are the same.

The test is comprised of the following steps:

Steps 1 to 7 measure read time during flush with non-volatile cache disabled

  1. Disable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  2. Issue a Flush command.

  3. Issue 64 MB of random IO using sizes randomly chosen from 4 KB to 64 KB. No effort is made to ensure the offsets are unique on thread 1.

  4. Issue a FlushFileBuffers call on thread 1.

  5. Issue a random read on thread 2.

  6. Measure IO time of the random read from step 5.

  7. Repeat steps 2-6 six times.

    Steps 8 to 14 measure read time during flush with non-volatile cache enabled

  8. Enable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  9. Issue a Flush command.

  10. Issue 64 MB of random IO using sizes randomly chosen from 4 KB to 64 KB. No effort is made to ensure the offsets are unique on thread 1.

  11. Issue a FlushFileBuffers call on thread 1.

  12. Issue a random read on thread 2.

  13. Measure IO time of the random read from step 12.

  14. Repeat steps 9-13. six times.

  15. Calculate the median IO time for each run in steps with the non-volatile cache turned on and turned off respectively.

5.3.4.1.1 Passing this test requires that the random read on thread 2 issued in Step 3 complete within a set amount of time. The test fails if any of the following conditions is true:

  • The median IO time for the non-volatile cache enabled case is 10ms above the non-volatile cache disabled case

5.3.4.2 Heavy Random Write Activity

The goal of this test is to ensure in the presence of a significant amount of write activity that IOs are not blocked for long periods of time while book keeping and other flush activities associated with the NV cache are performed. The test script file for this test case with write caching disabled is 5.3.4.2.WC0.io.txt. The test script file for this test case with write caching enabled is 5.3.4.2.WC1.io.txt. The passing criteria for both the write cache enabled and disabled cases are the same.

The test is comprised of the following steps:

Steps 1 to 5 measure IO times with 15 threads writing the same IO pattern to different files with non-volatile cache disabled

  1. Disable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  2. Issue a Flush command.

  3. Each of the 15 threads issues 64 MB of random IO using 64 KB IOs to unique offsets. Each thread will write to its own file using the same IO pattern. i.e. no offset IO will be issued to the same offset twice in this test.

  4. Measure IO time of each IO.

  5. Repeat steps 2-4 six times.

    Steps 6 to 10 measure IO times with 15 threads writing to the same offsets in different files with non-volatile cache enabled.

  6. Enable non-volatile cache as outlined in section 3.5.2.1 earlier in this specification.

  7. Issue a Flush command.

  8. Each of the 15 threads issues 64 MB of random IO using 64 KB IOs to unique offsets. Each thread will write to its own file using the same IO pattern. i.e. no offset IO will be issued to the same offset twice in this test.

  9. Measure IO time of each IO.

  10. Repeat steps 7-9 six times.

  11. Calculate the median IO time for each run with the non-volatile cache turned on and turned off respectively.

5.3.4.2.1 Passing this test requires that the IOs complete within a set amount of time. The test fails if any of the following conditions is true:

  • The median IO time for the non-volatile cache enabled case is 10ms above the non-volatile cache disabled case

5.4 Realistic User Performance Test Cases

The tests outlined so far have focused on synthetic workloads and were geared towards testing the behavior for baseline scenarios. In this section, we outline some realistic user performance test cases. These are geared towards ensuring that a separated-cache solution does not result in a performance degradation for real-world workload scenarios. We first outline the real-world scenarios and then outline our methodology for running these tests.

5.4.1 Real-world Scenarios

Each of the scenarios listed below correspond to a real-world scenario which results in some amount of write activity, with or without interactive user inputs, on a machine. For each scenario below we provide some statistics as observed in a trace when the scenario was run. The scenarios range in duration from one to three minutes and exhibit low to moderate CPU activity. The disk utilization over the duration of the trace is observed to be less than 15% in each scenario.

5.4.1.1 Document download

This scenario involves downloading a couple of documents from the internet. The observed statistics are as shown in the following table.

Trace Duration | 80 s
System Utilization Statistics | CPU Util. 18% and Disk Util. 9%
I/O Count Statistics | 2378 I/Os with 27.5 % Reads
I/O Size Statistics | 70.26 MB with 76.35 % Reads
Flush Count | 85

Test Case File: DocumentDownload.IOPattern.txt

5.4.1.2 Image editing

This scenario involves editing images and saving them as they are viewed in a slide show. The editing was limited to adjusting the color and/or the exposure. The observed statistics are as shown in the following table.

Trace Duration | 138 s
System Utilization Statistics | CPU Util. 19% and Disk Util. 3%
I/O Count Statistics | 1905 I/Os with 52.17 % Reads
I/O Size Statistics | 63.72 MB with 79.93 % Reads
Flush Count | 94

Test Case File: ImageEditing.IOPattern.txt

5.4.1.3 Video Download

This scenario involves downloading a video over the internet. The observed statistics are as shown in the following table.

Trace Duration | 194 s
System Utilization Statistics | CPU Util. 9% and Disk Util. 1%
I/O Count Statistics | 679 I/Os with 28.42 % Reads
I/O Size Statistics | 118.17 MB with 41.21 % Reads
Flush Count | 44

Test Case File: VideoDownload.IOPattern.txt

5.4.1.4 Application Install

This scenario involves installing an application over the internet. The observed statistics are as shown in the following table.

Trace Duration | 184 s
System Utilization Statistics | CPU Util. 22% and Disk Util. 12%
I/O Count Statistics | 8566 I/Os with 54.1 % Reads
I/O Size Statistics | 300.42 MB with 73.12 % Reads
Flush Count | 390

Test Case File: AppInstall.IOPattern.txt

5.4.1.5 Ripping an Audio CD

This scenario involves ripping an audio CD and saving the tracks to disk. The observed statistics are as shown in the following table.

Trace Duration | 179 s
System Utilization Statistics | CPU Util. 52% and Disk Util. 1%
I/O Count Statistics | 2777 I/Os with 22.61 % Reads
I/O Size Statistics | 97.35 MB with 8.37 % Reads
Flush Count | 222

Test Case File: RipCD.IOPattern.txt

5.4.2 Methodology

In this section, we outline our methodology for running these tests as well as what we measure to assess system performance.

5.4.2.1 Emulating Real-world Workloads

We use a workload emulation methodology to run these tests; this approach reduces the overhead both from a scenario maintainability viewpoint as well as the task of running these tests. Moreover, this technique allows one to stress and focus on the workload aspect of interest, namely disk I/O. The technique essentially involves using tracing to identify the workload details. We then use this detailed workload information to replay the trace.

The workload emulator is essentially an IO replay tool and issues the read, write and flush commands in the order and while adhering to the inter-arrival times observed in the trace. A large file is created on the disk and all I/Os observed in the trace are issued to this file. Since, we are only interested in I/O emulation the CPU utilization as observed above is not reciprocated. Any background I/O, operating system related or otherwise, would result in slightly different I/O statistics during workload emulation. Finally, note that the disk utilization observed can vary significantly from that observed above depending on the disk characteristics.

5.4.2.2 Measuring performance

As before, we seek to compare the system performance when the non-volatile cache feature is enabled to when it is disabled. The performance is measured in the context of the scenario.

  • While running these tests we use hooks in the workload emulator to measure the workload metrics of interest. We measure the response time for each I/O operation for each I/O type namely, disk read, disk write and disk flush. Each scenario is run multiple times for both the case when the non-volatile cache feature is enabled as well as when it is disabled. The goal is to ensure that the performance for the two cases is statistically similar without any visible outliers. The performance metrics of interest are the average and maximum I/O time observed for each I/O type. The test fails if any of the following is true:
    1. Average I/O time for any I/O type for NVC enabled is 10ms longer than the NVC disabled case
    2. Maximum I/O time for any I/O type for NVC enabled is 20ms longer than the NVC disabled case

6 Appendix: Partner Q&A

Q. Is it okay to re-order non-FUA writes around FUA writes, in any manner between two flushes? Note, that this question only makes sense when write-buffering is enabled.

A. From a disk consistency point only non-FUA writes that can occur and be observed in a bus-trace before a FUA-write between two flushes are the ones that were indeed issued before the FUA-write.

Q. Is it okay to disable write-buffering by default?

A. We take write-buffering to mean the disk setting that is exposed to an end-user, and which historically one can toggle on demand. Please see Section 3.4.6.2 for more details.

Q. The performance requirements around power transitions seem to indicate that it is acceptable to observe performance degradation in a separated-cache solution?

A. In general, one would expect a separated-cache solution to yield a better experience for the end-user around power-transition scenarios such as resuming from standby/hibernate or when booting the system. However, the tests outlined in this document are not comprehensive performance tests per se and merely aim at ensuring that the end-user experience is comparable to what he would observe if using a regular hard disk.

Q. Why are percentage metrics used when specifying the goals for the standby/hibernate performance tests and an absolute metric being used for shutdown?

A. While, a percentage based performance metric is ideal as it is oblivious of the absolute performance of the system being tested. A raw time based performance, however, was necessary for shutdown as Windows has a timeout associated with shutdown (barring a service having registered for the SERVICE_CONTROL_PRESHUTDOWN notification).

Q. Why have representative performance numbers not been provided for the power transition (standby/hibernate/shutdown) performance tests?

A. The performance numbers observed can vary significantly from system to system depending on the hardware configuration. This is also why the performance goals specified are not absolute and have been specified relative to the baseline performance on the same system when the NVCache mode is disabled.

Q. How do you ensure that writes issued for a test are observed in the bus-analyzer trace given that the disk may be spun-down during the test?

A. To ensure that the writes issued during the test for the synthetic data reliability tests are observed in the bus-analyzer trace, each Flush command will result in an automatic issue of an NVCache flush command in succession. Note, that since these tests only aim to verify ordering and do not make any timing measurements, any performance impact is ignored.

Q. Is it okay to invalidate non-volatile cache contents and do a roll-back in the rare case of a double power-failure?

A. The final disk state in the case of a power loss should mimic in essence what is observed on a regular disk. When write buffering is enabled a successful flush on a regular disk implies that the data has been committed to disk. So, non-volatile cache contents can be invalidated to the point the host did not receive a successful flush command for any of the data that gets invalidated. If write-buffering is disabled on the system, none of the writes that were successfully completed can be invalidated.

Q: Why don't H-HDD vendors have to run the evaluation tests?

A: Every premium storage solution is unique and has its own strengths and weaknesses. We evaluate devices on their own merit rather than comparing premium storage solutions. This allows us to focus on the characteristics most appropriate to a given device.

  1. This is potentially a very common scenario in Vista where the system is in the "Balanced" power mode by default. In the default settings for this power mode the non-volatile cache feature is enabled on battery and is disabled when on AC power.

  2. Note that specifying flag FILE_FLAG_WRITE_THROUGH when opening a file implies the file is opened in the write-back mode. Specifying the flag implies the file is opened in the write-through mode.

Run Time: Manual Test: 2 days, Logo test: 5 minutes
Log File: Manual tests: Results.xml, DTM Test: SCSEvaluationResultsChecker.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2008

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Bus analyzer for controller interface type (SATA, ATA, and so on).

  • If bus analyzer requires a host machine to capture traces, a second machine will be needed to perform this function. This machine need not have the test hardware or meet any test requirements. Its sole purpose will be to capture a bus trace.

Running Separated Cache Solution Evaluation test

Launch the "Separated Cache Solution Evaluation Test (LOGO)" from device console. When prompted for the results file, browse to the file that was created by running the manual test steps previously. Click Load. The test should copy this file and execute on the client.

Code Tour

File Manifest

File | Location
SCSEvaluationResultsChecker.exe | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk\SCSEvaluation
SCSEvaluationResults.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk\SCSEvaluation
SCSEvaluation.msi | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk\SCSEvaluation

Test Assertions

5.2.2.1.io.txt Basic Write / Flush Test, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.2.ff.io.txt Basic Write / Flush Test, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.2.io.txt Basic Write / Flush Test, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.3.1.ff.io.txt Basic Write / Flush Test with crash, Write buffering disabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.3.1.io.txt Basic Write / Flush Test with crash, Write buffering disabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.3.2.ff.io.txt Basic Write / Flush Test with crash, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.3.2.io.txt Basic Write / Flush Test with crash, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.4.1.ff.io.txtBasic Write / Flush Test with power loss, Write buffering disabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.4.1.io.txt Basic Write / Flush Test with power loss, Write buffering disabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.4.2.ff.io.txt Basic Write / Flush Test with power loss, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.4.2.io.txt Basic Write / Flush Test with power loss, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.5.1.ff.io.txt Basic Write / Flush Test with double power loss, Write buffering disabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.5.1.io.txt Basic Write / Flush Test with double power loss, Write buffering disabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.5.2.ff.io.txt Basic Write / Flush Test with double power loss, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.2.5.2.io.txt Basic Write / Flush Test with double power loss, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.1.1.io.txt Standby / Resume test, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.1.2.io.txt Standby / Resume test, Write buffering enabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.2.1.ff.io.txt Standby / Resume test with crash during resume, Write buffering disabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.2.1.io.txt Standby / Resume test with crash during resume, Write buffering disabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.2.2.ff.io.txt Standby / Resume test with crash during resume, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.2.2.io.txt Standby / Resume test with crash during resume, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.3.1.io.txt Standby / Resume test with crash during standby, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.3.2.ff.io.txt Standby / Resume test with crash during standby, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.3.2.io.txt Standby / Resume test with crash during standby, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.4.1.ff.io.txt Standby / Resume test with power loss on resume, Write buffering disabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.4.1.io.txt Standby / Resume test with power loss on resume, Write buffering disabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.4.2.ff.io.txt Standby / Resume test with power loss on resume, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.4.2.io.txt Standby / Resume test with power loss on resume, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.5.1.io.txt Standby / Resume test with power loss on resume and recovery, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.5.2.ff.io.txt Standby / Resume test with power loss on resume and recovery, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.3.5.2.io.txt Standby / Resume test with power loss on resume and recovery, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.1.1.io.txt Hibernate / Resume test, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.1.2.io.txt Hibernate / Resume test, Write buffering enabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.2.1.io.txt Hibernate / Resume test with crash during resume, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.2.2.ff.io.txt Hibernate / Resume test with crash during resume, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.2.2.io.txt Hibernate / Resume test with crash during resume, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.3.1.io.txt Hibernate / Resume test with crash during hibernate, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.3.2.ff.io.txt Hibernate / Resume test with crash during hibernate, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.3.2.io.txt Hibernate / Resume test with crash during hibernate, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.4.1.io.txt Hibernate / Resume test with power loss on resume, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.4.2.ff.io.txt Hibernate / Resume test with power loss on resume, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.4.2.io.txt Hibernate / Resume test with power loss on resume, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.5.1.io.txt Hibernate / Resume test with power loss on resume and recovery, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.5.2.ff.io.txt Hibernate / Resume test with power loss on resume and recovery, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.4.5.2.io.txt Hibernate / Resume test with power loss on resume and recovery, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.5.1.1.io.txt Shutdown / Restart test, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.5.1.2.io.txt Shutdown / Restart test, Write buffering enabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.5.2.1.io.txt Shutdown / Restart test with crash during shutdown, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.5.2.2.ff.io.txt Shutdown / Restart test with crash during shutdown, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.5.2.2.io.txt Shutdown / Restart test with crash during shutdown, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.5.3.1.io.txt Shutdown / Restart test with power loss during shutdown, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.5.3.2.ff.io.txt Shutdown / Restart test with power loss during shutdown, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.5.3.2.io.txt Shutdown / Restart test with power loss during shutdown, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.5.4.1.io.txtShutdown / Restart test with power loss during shutdown and recovery, Write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.5.4.2.ff.io.txt Shutdown / Restart test with power loss during shutdown and recovery, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.2.5.4.2.io.txt Shutdown / Restart test with power loss during shutdown and recovery, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.1.1.WC0.io.txt Suspend with heavy write activity, Write buffering disabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.1.1.WC1.io.txtSuspend with heavy write activity, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.1.2.WC0.io.txt Suspend with heavy write activity, Write buffering disabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.1.2.WC1.io.txt Suspend with heavy write activity, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.2.1.WC0.io.txt Hibernate with heavy write activity, Write buffering disabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.2.1.WC1.io.txt Hibernate with heavy write activity, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.2.2.WC0.io.txt Hibernate with heavy write activity, Write buffering disabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.2.2.WC1.io.txt Hibernate with heavy write activity, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.3.1.WC0.io.txt Shutdown with heavy write activity, Write buffering disabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.3.1.WC1.io.txt Shutdown with heavy write activity, Write buffering enabled, 1 flush / 10 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.3.2.WC0.io.txt Shutdown with heavy write activity, Write buffering disabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.3.2.WC1.io.txtShutdown with heavy write activity, Write buffering enabled, 1 flush / 2 writes
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.4.1.WC0.io.txt Heavy random write activity with read, write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.4.1.WC1.io.txt Heavy random write activity with read, write buffering enabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.4.2.WC0.io.txt Heavy random write activity, write buffering disabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
5.3.4.2.WC1.io.txt Heavy random write activity, write buffering enabled
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
AppInstall.IOPattern.txt Application installation
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
DocumentDownload.IOPattern.txt Document download
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
ImageEditing.IOPattern.txt Image editing
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
RipCD.IOPattern.txt Ripping an audio CD
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
Additional Information:
VideoDownload.IOPattern.txt Video download
Test Assertion GUID:
Windows Logo Program: STORAGE-0012
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

This test verifies that the drive returns the correct error code and works with different command combinations.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running SMART test utility

Run test as a DTM job.

Command Syntax

Command option | Description
smarttst <drive number> |

Code Tour

File Manifest

File | Location
smarttst.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Test Assertions

SMART_GET_VERSION: bReserved should be zero.
Test Assertion GUID: e195012d-c8ea-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements
Additional Information: Content will be published
SMART_GET_VERSION: a call to DeviceIOControl with handle to device and bogus IoControlCode should fail.
Test Assertion GUID: e1950131-c8ea-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements
Additional Information: Content will be published
SMART_GET_VERSION: a call to DeviceIOControl with handle to device and null IoControlCode should fail.
Test Assertion GUID: e1950132-c8ea-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements
Additional Information: Content will be published
SMART_GET_VERSION: bogus lpvInBuffer should not cause failure.
Test Assertion GUID: e1950133-c8ea-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol 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-0004 ATA/ATAPI based devices meet ATA/ATAPI protocol requirements
Additional Information: Content will be published


Storage Assessment Test

Type: Automated Test

Overview

The Storage Assessment Test measures the performance of disks on a computer by using winsat to check if their IO performance data can meet the requirements.

Details

The test passes the disk number of the target test device. It performs the Windows 7 Windows System Assessment Tool (WinSAT) disk format test for the block storage device. It measures the following performance requirements for any visible storage space utilization up to 95%:
Note % of utilization is % of "used space" seen through the Windows file system.

  • Disk Sequential 64K Byte Read

  • Disk Random 16K Byte Read

  • Disk Sequential 64K Byte Write

  • Average Read Time with Sequential Writes

  • Latency: 95th Percentile

  • Latency: Maximum

  • Average Read Time with Random Writes

Run Time: 90 minutes (depending on the size of block storage)
Log File: storat.wtl
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: storat.exe

Requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

If you are testing any drive the requires media, or testing in system-mode on a computer that contains drives that require media, you must insert media into the drives. The media that is used must be formatted.

Because this test case may require a different disk configuration than the other test cases, please run it last to prevent its partition changes from failing other test cases.

Command Syntax

Command option | Description
StorAT.exe | Without any options, the test requires the user to provide input.
/diskid [number] | Set the disk number.

Code Tour

File Manifest

File | Location
storat.exe | \tests\%ARCH%\nttest\driverstest\storage\wdk


Storage Data Verification Filter Test

Type: Automated Test

Overview

The Storage Data Verification Filter test checks the hard disk drive, the storage controller, or both 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. This test provides the ability to detect any error that a lower-level driver-hardware tests reports to locate the root cause of the data corruption.

The test will install a filter driver and set up AutoLogon for the DTM-created Administrator account on the computer. The test will then restart the computer. When the test completes the restart, the test will stress the storage device by simulating heavy database activity. If data corruption occurs at any time on the storage device, the computer will bugcheck.

When the stress portion of the test is complete, the filter driver will be removed and the computer will restart again.

Run Time: 72 hours
Log File:
System Restart Required: Yes
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running Storage Data Verification Filter Test

The test accepts two parameters for input:

  • A device instance identifier (ID) of the storage controller or disk.

  • A volume letter to target with stress.

DTM automatically provides these parameters when you schedule this test against a device in the Device Console window.

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 | For the logo test, FileSize is 800m (MB) and Runtime is 48 (hours).

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

Test Assertions

dataver Storage Data Verification Filter
Test Assertion GUID: 0405c6da-e689-461c-a41f-6ea9f084bc90
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Additional Information: This test case installs the 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-0001 Storage devices meet industry standards and Windows requirements
Additional Information: This 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 situation will cause the test to log a failure.The installed filter driver can detect hardware data corruption. This situation will cause the computer to bugcheck.


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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • DTM Log Dynamic Link Library or a DTM client service running on the test machine

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Media and Cleaning cartridge.

Processor

The test tool runs on the following processor architectures:

  • 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.

Code Tour

File Manifest

File | Location
SDStress.exe | [WTT\TestBinRoot]\nttest\DriversTest\storage\wdk\SDStress

Test Assertions

Device should not cause timeout.
Test Assertion GUID: 69ff82c9-c8f4-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet 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-0001 Storage devices meet industry standards and Windows requirements
Additional Information:
Device should perform under stress.
Test Assertion GUID: 69ff82cf-c8f4-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Additional Information:


Storage Imports Test

Type: Automated Test

Overview

The Storage Imports test verifies that a storage adapter driver follows the proper miniport architecture for its bus type. The tool also validates that the driver does not import functions from outside the port driver.

Details

The test is started against a particular device node that is identified by that device node's device instance path. The test queries the interface of that device node for the bus type (by using IOCTL_STORAGE_QUERY_PROPERTY: StorageAdapterDescriptor.) The test determines the driver for the device node by checking the Service property of the device node. The test then determines the type of miniport architecture of the driver and obtains a list of imported functions.

The miniport must match the architecture model that is required for the device's bus type. These architecture model requirements are defined in STORAGE-0002.

Run Time: 60 seconds
Log File: Storimports.wtl
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2008

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Running Storage Imports Test

Start this test against a device from the Device Console window in DTM. Device Console fills in the test's WDKDeviceID parameter with the instance path of the device that you select. The device that you select should be a storage adapter and should be configured on the test client, with storage attached.

If you want to run the test manually, you must copy the test binaries from their respective locations (listed in the File Manifest section) and run the test by using one of the command line variations that are listed in the following Command Syntax section.

Command Syntax

Command option | Description
StorImports.exe /device "[DeviceInstancePath]" | Runs the test against a device instance that is currently installed on the computer.
StorImports.exe /driver "[DriverName]" /bustype "[BusType]" | Runs the test against a driver (leave off the file name extension) of a specified bus type. Valid bus types include ATA, Fibre, iSCSI, RAID, SAS, SATA, or SCSI.

Code Tour

File Manifest

File | Location
StorImports.exe | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
StorageDevices.dll | ...\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
Link.exe | ...\tests\%ARCHITECTURE%\redist\linker
mspdb80.dll | ...\tests\%ARCHITECTURE%\redist\linker

Test Assertions

Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements


Storage Query Property

Type: Automated Test

Overview

The Storage Query Property test verifies a storage adapter driver's implementation of IOCTL_STORAGE_QUERY_PROPERTY for both the StorageDeviceProperty and StorageAdapterProperty.

Details

The test is passed the instance path of the target test device. The test sends IOCTL_STORAGE_QUERY_PROPERTY(StorageAdapterProperty, PropertyExistsQuery), and the adapter must return success. The test then sends IOCTL_STORAGE_QUERY_PROEPRTY(StorageAdapterProperty, PropertyStandardQuery) and examines the fields of the returned STORAGE_ADAPTER_DESCRIPTOR. The same is done with a child device for StorageDeviceProperty, examining the STORAGE_DEVICE_DESCRIPTOR.

The bus type that is returned should match the bus type that is specified by the PCI class code, sub class code, and programming interface.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Microsoft .NET Framework 2.0 (Installed automatically)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Code Tour

File Manifest

File | Location
QueryProperty.exe | \tests\%ARCH%\nttest\driverstest\storage\wdk
StorageDevices.dll | \tests\%ARCH%\nttest\driverstest\storage\wdk

Test Assertions

Storage adapter must support IOCTL_STORAGE_QUERY_PROPERTY
Test Assertion GUID:
Windows Logo Program: STORAGE-0002 Storage host controllers and adapters comply with industry standards and Windows requirements
Additional Information: "Bus-attached controllers must implement the correct class/subclass code as specified in PCI 2.3, Appendix D. This applies to all bus types including, but not limited to, IDE, Fibre Channel, SCSI, and SATA-based devices. Any device which implements RAID functionality regardless of whether the RAID implementation is done in hardware, firmware or in the driver code, must implement the PCI RAID Class Code (01/04) and not use the interconnect class code (for example, a SATA RAID controller must implement the 01/04 class code and not the AHCI class code 01/06/01)."..."Implementation of the BusType registry DWORD to correctly set the interface type in accordance with the enumeration in NTDDSTOR.H (see the WDK). This value must be set in the miniport's INF under the service's Parameters key - there is no programmatic way to set it and you may not rely on coinstallers as they do not run under all scenarios."


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.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running Symlink Regressions

Run the job from Job Explorer with valid target and source directories.

Code Tour

File Manifest

File | Location
symlinkregressions.exe | nttest\BASETEST\core_file_Services\NTFS\symlinkregressions.exe


Trim Test

Type: Automated Test

Overview

The Trim Test verifies that a SATA device that supports Trim performs according to the Logo requirements. Trim is a Data Set Management command feature described in the ATA/ATAPI Command Set-2 (ACS-2) or later. To obtain this specification, go to the T13 Technical Committee Web site at www.t13.org

Details

The Trim Test installs a test miniport based on msahci, which provides a framework for validating hardware. The Trim Test uses this ATA Miniport Hardware Validation framework to generate and measure the effects that Trim has on device performance. When the test completes, the test miniport will be uninstalled.

This test may trim or overwrite any or all of the sectors on the test device. As a result, the data on the drive will be lost. This test must be run against a secondary SATA device running in AHCI mode.
Run Time: 30 minutes*
Log File: minioctl.wtl
System Restart Required: Yes
Test Category: Storage > Hard Disk Drive (HDD)
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: minioctl.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • One or more SATA disks attached to the test system in AHCI configuration

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Command Syntax

Command option | Description
minioctl.exe | Without any options, shows usage information.
-d [Device] | Device path of disk to test (e.g. \\.\PhysicalDrive0)
-v [0|1|2] | Logging verbosity: 0 - test failures only; 1 - all test results; 2 - all debugging details. The verbosity can be changed at schedule time in the DTM.
-s [Seed] | Seed used for generating test cases. A seed can only be used to repro specific conditions when manually running this test.

Troubleshooting

The test writes the results to the log files minioctl.wtl and minioctl.txt. Use the log files to determine the cause of any failures.

Code Tour

File Manifest

File | Location
msahci.sys | [testbinroot]\nttest\driverstest\storage\wdk\ataminiport\
msahci.inf | [testbinroot]\nttest\driverstest\storage\wdk\ataminiport\
msahci.cat | [testbinroot]\nttest\driverstest\storage\wdk\ataminiport\
minioctl.exe | [testbinroot]\nttest\driverstest\storage\wdk\ataminiport\

Test Assertions

Logo Requirement

Assertion Description

N/A

Trim Support Test: Checks to see if the SATA device supports Trim as a Data Set Management feature as defined by ACS-2, Section 7.18.7.71

If Trim is not supported, the test assertions below will not be verified.

Storage-0024, Section 3.c

Trim Command Completion Performance: Verifies that the device can complete trim commands within the required time.

This assertion will generate and time a Trim (Data Set Management) command for a specified number of ranges. Currently, this process is used to verify command completion performance on commands specifying 1-512 ranges (Trimming 512 ranges uses 8 blocks of range entries as defined in by ACS-2, Section 7.10).

Storage-0024, Section 3.c

Trim Command Completion Performance With IO: Verifies that the device can complete trim commands within the required time in the presence of IO.

This test uses a procedure nearly identical to the Trim Command Completion Performance test, with the modification of staggering the Trim commands in between several windows of IO.

N/A

Trim Performance Degradation Test: Verifies that the Trim command does not degrade the performance of subsequent IO beyond an acceptable measurement. This test is currently experimental.

This test attempts to characterize the performance of a device for several generated patterns of IO. Then it attempts to characterize the performance of the same patterns of IO after inserting Trim commands. The focus is on identifying scenarios where the Trim command introduces performance degradation for subsequent IO, even if the Trim command completes quickly, as required in the previous test assertions.


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 scans the machine for optical drives. For each drive that it encounters, the test queries the drive about what media types it supports.

For each media type that the formatter tests support, it kicks of a formatter test pass. This test pass is a multi-phase process that typically includes the following steps:

  1. Format the media.

  2. Write some data to it.

  3. Eject and reload the media.

  4. Write some more data to the media.

  5. Format a second time.

  6. Write more data to it.

There are several verification passes during this process to ensure there is no data loss or corruption. The UDF Formatter Tests currently only test CD-R, CD-RW, DVD-R, DVD+R, DVD-RW, DVD+RW, and DVD-RAM media. Dual layer, Double layer, Blu-ray, and HD DVD media are not covered.

Run Time:
Log File: Can be specified with the /log command line parameter
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running UDF Formatter Tests

To run this test manually, do the following:

Before starting the tests, load the correct media into the drive.

Run UDFFormatTest.exe X: (assuming X: is the drive letter of the device that you are testing).

Run UDFFormatTest.exe without any arguments to show more command-line options.


USB 2.0 and 3.0 SCSI Compliance test (LOGO)

Type: Automated test

Overview

This test verifies Small Computer System Interface (SCSI) Command Descriptor Blocks (CDBs) sent to the Universal Serial Bus (USB) device. For more information, please refer to the "Overview" section of the SCSI Compliance test.

Details

Run time: 10 minutes
Log file: Scsicompliance.wtl
System restart required: No
Supported operating systems for logo or signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: Scsicompliance.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard disk drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Run the test as a Driver Test Manager (DTM) job.

Command Syntax

Command option | Description
Scsicompliance.exe | The options for the test are listed below.
/device | Specifies the device to be tested.
/logoprogram | Specifies the type of logo program.
/rmb | Use a value of 1 for devices that accept insertion/removal of media, such as a card reader. Otherwise, use a value of 0, such as for USB Flash Drives (UFDs).
/scenario | Specifies the type of scenario testing.

Code Tour

File Manifest

File | Location
Scsicompliance.exe | [testbinroot]\nttest\driverstest\storage\wdk

Test Assertions

ASSERTION: TestUnitReady Basic Verification Test
ASSERTION: REQUEST SENSE (6) Support Test
ASSERTION: REQUEST SENSE (6) RESPONSE CODE Test
ASSERTION: REQUEST SENSE (6) Sense Data Length Test
ASSERTION: FormatUnit test with Type 0 Protection
ASSERTION: READ (6) Basic Verification Test
ASSERTION: READ (6) Sequential Read Test
ASSERTION: READ (6) Random Read Test
ASSERTION: READ (6) Read-With-Disk-Cache-Cleared Test
ASSERTION: WRITE (6) Basic Functionality Test
ASSERTION: WRITE (6) Sequential Write Test
ASSERTION: WRITE (6) Random Write Test
ASSERTION: WRITE (6) Write-With-Disk-Cache-Enabled Test
ASSERTION: WRITE (6) Write-With-Disk-Cache-Disabled Test
ASSERTION: INQUIRY Basic Verification Test
ASSERTION: INQUIRY Test for error when PAGE CODE field is nonzero and EVPD=0.
ASSERTION: INQUIRY Retrieving standard inquiry data.
ASSERTION: INQUIRY Checking size of standard inquiry data.
ASSERTION: INQUIRY Testing device type field.
ASSERTION: INQUIRY Testing peripheral qualifier field.
ASSERTION: INQUIRY VERSION Field Test
ASSERTION: INQUIRY Checking RESPONSE DATA FORMAT.
ASSERTION: INQUIRY Checking additional length.
ASSERTION: INQUIRY Checking VENDOR IDENTIFICATION field.
ASSERTION: INQUIRY Checking PRODUCT IDENTIFICATION field.
ASSERTION: INQUIRY Checking PRODUCT REVISION LEVEL field.
ASSERTION: INQUIRY Command Support Data Test.
ASSERTION: INQUIRY Checking for Supported Vital Product Pages.
ASSERTION: INQUIRY Testing access to each supported Vital Product Data Page.
ASSERTION: INQUIRY Attempting Unit Serial Number Page 0x80.
ASSERTION: INQUIRY Attempting Device identification Page 0x83.
ASSERTION: INQUIRY Checking Identification Descriptors in VPD page 0x83.
ASSERTION: INQUIRY Checking Version Descriptors.
ASSERTION: INQUIRY Checking RMB bit
ASSERTION: MODE SELECT (6) Basic Test
ASSERTION: MODE SELECT (6) MODE SENSE (6) Attempting to get Caching mode page.
ASSERTION: MODE SELECT (6) MODE SENSE (6) Checking Parameters Savable (PS bit).
ASSERTION: MODE SELECT (6) MODE SENSE (6) Checking Mode Parameter Header
ASSERTION: MODE SELECT (6) MODE SENSE (6) Checking Caching Mode Page Length.
ASSERTION: MODE SELECT (6) MODE SENSE (6) Getting Changeable values.
ASSERTION: MODE SELECT (6) MODE SENSE (6) Getting default values.
ASSERTION: MODE SELECT (6) Changing WCE.
ASSERTION: MODE SELECT (6) MODE SENSE (6) Checking that WCE has been cleared.
ASSERTION: MODE SELECT (6) MODE SENSE (6) Checking that Saved Values have changed.
ASSERTION: MODE SELECT (6) setting WCE
ASSERTION: MODE SELECT (6) MODE SENSE (6) Checking that WCE has been set.
ASSERTION: MODE SELECT (6) Attempting to restore original values.
ASSERTION: MODE SELECT (6) MODE SENSE (6) Verifying values were restored.
ASSERTION: MODE_SENSE Basic Test
ASSERTION: MODE SENSE (6) Checking size of returned data.
ASSERTION: MODE SENSE (6) Checking MODE PARAMETER HEADER
ASSERTION: MODE SENSE (6) Test DBD (disable block descriptors) bit.
ASSERTION: MODE SENSE (6) Testing new data length when DBD bit is set.
ASSERTION: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set
ASSERTION: MODE SENSE (6) Testing Page Control Field
ASSERTION: MODE SENSE (6) Scanning All Mode Pages.
ASSERTION: MODE SENSE (6) Ensuring mandatory mode pages are supported
ASSERTION: MODE SENSE (6) Checking Individual Mode Pages
ASSERTION: MODE SENSE (6) Checking Informational Exception Mode Page
ASSERTION: MODE SENSE (6) Checking Power Condition Mode Page.
ASSERTION: MODE SENSE (6) Checking Caching Mode Page.
ASSERTION: MODE SENSE (6) Checking Device Specific Parameters
ASSERTION: Start Stop Unit Basic Test 1
ASSERTION: Start Stop Unit Basic Test 2
ASSERTION: Start Stop Unit Basic Test 3
ASSERTION: Start Stop Unit Basic Test 4
ASSERTION: Start Stop Unit unload test with IMMED bit clear
ASSERTION: Start Stop Unit load test with IMMED bit clear
ASSERTION: Start Stop Unit unload test with IMMED bit set
ASSERTION: Start Stop Unit load test with IMMED bit set
ASSERTION: Receive Diagnostic Results Page Code Valid Test
ASSERTION: Receive Diagnostic Results Page Code Test
ASSERTION: Send Diagnostic Results Page Basic Verification Test
ASSERTION: Send Diagnostic Results Background Short self-test
ASSERTION: Send Diagnostic Results Background Extended self-test
ASSERTION: Send Diagnostic Results Abort Background self-test
ASSERTION: Send Diagnostic Results Foreground Short self-test
ASSERTION: Send Diagnostic Results Foreground Extended self-test
ASSERTION: PreventAllowMediumRemoval prevent bit set test
ASSERTION: PreventAllowMediumRemoval prevent bit clear test
ASSERTION: READ CAPACITY (10) Basic Verification Test
ASSERTION: READ CAPACITY (10) PMI Test
ASSERTION: READ CAPACITY (10) Negative Test
ASSERTION: READ (10) Basic Functionality Test
ASSERTION: READ (10) Random Read Test
ASSERTION: READ (10) Sequential Read Test
ASSERTION: READ (10) Read-With-Disk-Cache-Cleared Test
ASSERTION: WRITE (10) Basic Functionality Test
ASSERTION: WRITE (10) Random Write Test
ASSERTION: WRITE (10) Write-With-Disk-Cache-Disabled Test
ASSERTION: WRITE (10) Sequential Write Test
ASSERTION: WRITE (10) Write-With-Disk-Cache-Enabled Test
ASSERTION: WRITE (10) FUA Test
ASSERTION: MODE SELECT (10) Basic Test
ASSERTION: MODE SELECT (10) MODE SENSE (10) Attempting to get Caching mode page.
ASSERTION: MODE SELECT (10) MODE SENSE (10) Checking Parameters Savable (PS bit).
ASSERTION: MODE SELECT (10) MODE SENSE (10) Checking Mode Parameter Header
ASSERTION: MODE SELECT (10) MODE SENSE (10) Checking Caching Mode Page Length.
ASSERTION: MODE SELECT (10) MODE SENSE (10) Getting Changeable values.
ASSERTION: MODE SELECT (10) MODE SENSE (10) Getting default values.
ASSERTION: MODE SELECT (10) Changing WCE.
ASSERTION: MODE SELECT (10) MODE SENSE (10) Checking that WCE has been cleared.
ASSERTION: MODE SELECT (10) MODE SENSE (10) Checking that Saved Values have changed.
ASSERTION: MODE SELECT (10) setting WCE
ASSERTION: MODE SELECT (10) MODE SENSE (10) Checking that WCE has been set.
ASSERTION: MODE SELECT (10) Attempting to restore original values.
ASSERTION: MODE SELECT (10) MODE SENSE (10) Verifying values were restored.
ASSERTION: MODE SENSE (10) Basic Test
ASSERTION: MODE SENSE (10) Checking size of returned data.
ASSERTION: MODE SENSE (10) Checking MODE PARAMETER HEADER
ASSERTION: MODE SENSE (10) Test DBD (disable block descriptors) bit.
ASSERTION: MODE SENSE (10) Comparing MODE PAGE data before and after DBD bit is set
ASSERTION: MODE SENSE (10) Testing Page Control Field
ASSERTION: READ (16) Support Test
ASSERTION: READ (16) Basic Functionality Test
ASSERTION: READ (16) Sequential Read Test
ASSERTION: READ (16) Random Read Test
ASSERTION: READ (16) Read-With-Disk-Cache-Cleared Test
ASSERTION: WRITE (16) Support Test
ASSERTION: WRITE (16) Basic Functionality Test
ASSERTION: WRITE (16) Sequential Write Test
ASSERTION: WRITE (16) Random Write Test
ASSERTION: WRITE (16) Write-With-Disk-Cache-Enabled Test
ASSERTION: WRITE (16) Write-With-Disk-Cache-Disabled Test
ASSERTION: READ CAPACITY (16) Allocation length test
ASSERTION: READ CAPACITY (16) Basic Verification Test
ASSERTION: READ CAPACITY (16) PMI Test
ASSERTION: READ CAPACITY (16) Negative Test
ASSERTION: REPORT LUNS Basic Verification Test
ASSERTION: REPORT LUNS LUN0 Test
ASSERTION: REPORT LUNS Data valid Test
ASSERTION: Security Protocol Out Basic Test
ASSERTION: Security Protocol In Basic Test
ASSERTION: ReportSupportedOpCodes with RTCD clear
ASSERTION: ReportSupportedOpCodes with RTCD set


VDS HCT

Overview

The VDS HCT test helps validate that the VDS H/W provider that is installed on the system is implementing the VDS interfaces according to the VDS specification.

Details

The computer that is running this test must have a storage subsystem connected to it with a VDS H/W provider installed on it. Virtual Disk Service (VDS) will load the H/W provider that is installed on the system during the service startup. The API calls to the H/W subsystem will be routed to the H/W provider by VDS. The test communicates with the H/W Subsystem using the APIs implemented by VDS H/W provider and verifies that the provider is implementing the APIs according to the VDS specification and VDS Logo requirements.

Initialization

The test loads VDS and queries VDS for the providers that are installed on the system. If it does not find any H/W provider on the system, the test quits immediately. If it finds a H/W provider, the test starts the appropriate tests based on the version and type of the provider.

Test Methodology

Each H/W provider implements a set of COM interfaces, depending on the type and version of the provider. Each of these interfaces implement one or more COM methods. The test determines the interfaces to be tested based on the provider type and sequentially calls tests for each interface that is applicable to the provider. Some of the interfaces might be optional according to the VDS specification and the test takes that into account while testing the interfaces.

Interface Tests

For each interface that is being tested, the test calls all of the methods of the interface with different parameter options.

The test verifies the following:

  • When good parameters are passed to the API, the API call returns success and works as expected.

  • When bad parameters are passed to the API, the API fails with appropriate error code.

  • For the objects created in the H/W provider, the test verifies that it adheres to the VDS Object model and COM consistency check.

  • The interaction between H/W provider and VDS service is correct. For example, a LUN that is provisioned on the subsystem and unmasked to the local system should appear as a disk on the system and LUN object and disk object should be associated with each other in VDS.

Results

The test will report failures if any of the required interface or method is not implemented according to the specifications.

Results Interpretation

The log file that is generated will log the details of the error along with the line number of the failure and all of the variations that succeeded before the failure. This information and the VDS trace file can help identify the bug in H/W provider or VDS.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • VDS H/W provider should be installed on the system and system should be connected to the storage array

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Troubleshooting

In order for LUNs to be created or deleted during the test, we recommend that you have at least 10 GB of free drive space on the array available before running the test. The default LUN create size is 100 MB, and the test will create a couple of test LUNs.

Note This space is not visible as partition (on VDS software provider) unless the LUN is created and unmasked to WWN port.


WLK Aggressive Optical Drive Test

Type: Automated Test

Overview

The aggressive optical drive test validates whether the drive remains spinning for at least 10 seconds unless a START STOP UNIT command is received to spin down the disk. Currently, it is not a WLK requirement that drives must remain spinning for at least 10 seconds; however, this will be a requirement in the future. This prevents the problem of drives aggressively spinning down, such as when FBI warnings are shown in media content and then have to be spun again. Aggressive drive spinning results in increased power consumption and wear and tear on the optical drive.

Details

This test consists of sending three preliminary reads to obtain an average of how long a short read (read while disk is spinning) takes. We then do a read after 10 seconds and compare the average short read value with the long read to see if the drive stopped.

Run Time: 2 minutes
Log File: DVDWLK.wtl
System Restart Required: No
Test Category: Storage
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: DVDWLK.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Windows Media Player

Hardware Requirements

The test tool requires the following hardware:

  • Machine with optical drive that is capable of playing DVDs

  • Any non-CSS-encrypted DVD that contains 30+ minutes of video content. Insert this DVD into the optical drive prior to running the test. A good source of content is the Microsoft Test Annex DVD that can be ordered at the following Microsoft web site: Order the DVD Test Annex

    Note This DVD is also required for the WLK CSS Negotiation/Region Check test.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64 (x86 with WOW)

  • IA64

Running the Test

Follow the below syntax to run the test. No other parameters are required. The test will register a failure if the read sent after the 10-second delay is greater than two standard deviations of the average of the short reads (which indicates that the drive has stopped spinning).

Command Syntax

Command option | Description
DVDWLK.exe | This test has required parameters. Without any parameters entered, the test will output help text
-d [string]: | Specifies the volume of the optical disk drive (for example, D:) When run in an automated setting with WTT, the Create Storage Parameters setup task will resolve the drive letter with the parameter StorageDriveLetter.
-1 [int]: | Since the test binary contains four separate tests, this parameter specifies that test case 1 (DVD Aggressive Optical Drive Test) should be run. It is necessary to also specify the number of times for the test to be run. This is set by default in the test job to 1.

Code Tour

File Manifest

File | Location
DVDWLK.exe | [testbinroot]\nttest\multimediatest\common\performance\Tools\


WLK CSS Negotiation Region Check Test

Type: Automated Test

Overview

The CSS Negotiation\Region Check test verifies that it does not take more than 20 ms to start and end the CSS session or conduct a region check on the DVD content. This test requires a CSS-encrypted DVD. The test operates by programmatically running Windows Media Player and taking an event trace log that records the negotiation and region check events and parses the log file, looking for any event that has a timestamp of longer than the bar of 20 ms.

Details

Run Time: 1 minute
Log File: DVDWLK.wtl
System Restart Required: No
Test Category: Storage
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: DVDWLK.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Windows Media Player

Hardware Requirements

The test tool requires the following hardware:

  • Machine with optical drive that is capable of playing DVDs

  • A specific DVD that contains some CSS-encrypted content. The Microsoft Test Annex DVD can be ordered at the following Microsoft web site: Order the DVD Test Annex

    This test requires the Test Annex DVD specifically and will fail if this DVD is not used.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

To run the test, simply use the syntax below. Failures may occur if there is no DVD in the drive, the DVD is not the specified DVD, or no repetition parameter or drive letter is provided.

Command Syntax

Command option | Description
DVDWLK.exe | This test has required parameters. Without any parameters entered, the test will output help text
-d [string]: | Specifies the volume of the optical disk drive (for example, D:) When run in an automated setting with WTT, the Create Storage Parameters setup task will resolve the drive letter with the parameter StorageDriveLetter. (Required parameter)
-2 [int]: | Since the test binary contains four separate tests, this parameter specifies that test case 2 (DVD CSS Negotiation/Region Check) should be run. It is necessary to also specify the number of times for the test to be run. This is set by default in the test job to 1. (Required parameter)

Code Tour

File Manifest

File | Location
DVDWLK.exe | [testbinroot]\nttest\multimediatest\common\performance\Tools\


WLK DVD Spindown Test

Type: Automated Test

Overview

The WLK DVD Spindown Test is designed to measure whether an optical disk drive adheres to the power saving feature enabled in Windows that spins down a drive at a certain point. Because different disk drives take different lengths of time to respond and spin down, the test is self-calibrating to measure spindown against the individual drive.

The test first sends out a read command to spin up the drive. While the drive is spinning, it issues another read command and then measures how long the read took to return. Afterwards, the disk is allowed to spin down, a second read is sent out, and the length of time it takes to return is measured. The drive is sent another read command and after a short delay, a START_STOP_DISC IOCTL is sent and another read command is issued, and the length of time this read takes is recorded. The test passes if the time it takes to read from the disk after the IOCTL is sent is similar in time to the length of time it takes to read from a disk that begins spun down.

With this process, we can determine programmatically if the disk drive correctly spun down in response to having been sent the IOCTL.

This test also takes a second measurement to determine whether the START_STOP_DISC IOCTL completes in under 20 ms. Both measurements must pass in order to pass this test.

Details

A DVD drive containing a non-protected DVD must be used when running this test. There will be a pop-up message warning if the test is run without a DVD in the drive.
Run Time: 5 minutes
Log File: DVDWLK.wtl
System Restart Required: No
Test Category: Storage
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: DVDWLK.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Windows Media Player

Hardware Requirements

The test tool requires the following hardware:

  • Machine with optical drive that is capable of playing DVDs

  • Any non-CSS-encrypted DVD that contains 30+ minutes of video content. Insert this DVD into the optical drive prior to running the test. A good source of content is the Microsoft Test Annex DVD that can be ordered at the following Microsoft web site: Order the DVD Test Annex

    Note This DVD is also required for the WLK CSS Negotiation/Region Check test.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64 (use x86 version through WoW)

  • IA64

Running the Test

To run the test, follow the syntax below. No user input is required after the initial test command is sent. At the end, the test will either pass or fail and the appropriate log file will record the error. Common sources of test job failure include not having a DVD in the optical drive and using incorrect command syntax. The test will not pass if the time that it takes to return a read command after the stop IOCTL is sent is within the range of the time it takes the disk to return a read when the drive is still spinning.

Command Syntax

Command option | Description
DVDWLK.exe | This test has required parameters. Without any parameters entered, the test will output help text
-d [string]: | Specifies the volume of the optical disk drive (for example, D:). When run in an automated setting with WTT, the Create Storage Parameters setup task will resolve the drive letter with the parameter StorageDriveLetter.
-0 [int]: | Since the test binary contains four separate tests, this parameter specifies that test case 0 (DVD Spindown) should be run. It is necessary to also specify the number of times for the test to be run. This is set by default in the test job to 1.
-s [int] | Specifies the short time delay in ms to wait before sending out a read command. The default is 4000 ms. The value should be short enough that the disk is still spinning when the read command is sent. (Optional parameter)
-l [int] | Specifies the long time delay in ms to wait before sending out a read command. The default is 60000 ms. The value should be long enough that the disk has a chance to spin down completely before sending out another read command. (Optional parameter)
-i [int] | Specifies the time delay in ms to wait to read disk after the Spindown IOCTL is sent. The default is 4000 ms. (Optional parameter)
-r [int] | Specifies the time period in ms that IOCTL must complete in.

Code Tour

File Manifest

File | Location
DVDWLK.exe | [testbinroot]\nttest\multimediatest\common\performance\Tools\


WLK Optical Drive Streaming Mode Test

Type: Automated Test

Overview

Streaming mode is a technique that allows more playback resilience when playing back scratched DVDs.

Details

Run Time: 1 minute
Log File: DVDWLK.wtl
System Restart Required: No
Test Category: Storage
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

  • Windows XP

  • Windows Server 2003

Program: DVDWLK.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Windows Media Player

Hardware Requirements

The test tool requires the following hardware:

  • Machine with optical drive that is capable of playing DVDs

  • Any non-CSS-encrypted DVD that contains 30+ minutes of video content. Insert this DVD into the optical drive prior to running the test. A good source of content is the Microsoft Test Annex DVD that can be ordered at the following Microsoft web site: Order the DVD Test Annex

    Note This DVD is also required for the WLK CSS Negotiation/Region Check test.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64 (x86 under WoW)

  • IA64

Running the Test

The test will return a PASS or FAIL. Review the generated log report for details specific to any failures.

Command Syntax

Command option | Description
DVDWLK.exe | This test has required parameters. Without any parameters entered, the test will output help text
-d [string]: | Specifies the volume of the optical disk drive (for example, D:) When run in an automated setting with WTT, the Create Storage Parameters setup task will resolve the drive letter with the parameter StorageDriveLetter.
-3 [int]: | Since the test binary contains four separate tests, this parameter specifies that test case 3 (Streaming Mode test) should be run. It is necessary to also specify the number of times for the test to be run. This is set by default in the test job to 1.

Code Tour

File Manifest

File | Location
DVDWLK.exe | [testbinroot]\nttest\multimediatest\common\performance\Tools\


Streaming Media and Broadcast Devices Testing

This section describes how to test streaming media devices for the Windows Logo.

This section includes the following topics:

DVD Playback Testing Overview

Broadcast Receiver Testing Overview

Video Capture Testing Overview

Streaming Media and Broadcast Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


DVD Playback Testing Overview

The procedures that are presented in this section outline the process for testing your DVD Playback for proper functionality with Microsoft Windows operating systems. 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.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

DVD Playback Tests

The tests that you need to run depend on the capabilities of the device or system that you are testing. To see the complete list of tests that might be required for your device, see DVD Playback Tests.

Hardware Requirements

The following hardware is required for DVD Playback 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 of the following:
    • Test DVD software or hardware decoder solution
    • Test Moving Picture Expert Group-2 (MPEG-2) software or hardware decoder solution

  • One computer with the following hardware:

    • x86-based or x64-based processor with a minimum speed of 450 megahertz (MHz)

    • 256 MB of RAM

    • One AGP or PCI display adapter

  • One 17-inch monitor with at least 1024 x 768 x 24 bits per pixel (bpp) resolution.

  • One display adapter and driver combination

  • One keyboard

  • One mouse (or any pointing or drawing device)

  • One IDE hard disk drive with at least a 4 GB capacity and PIO-4 or DMA capability

  • One DVD 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 Windows Driver Kit (WDK) on DVD

  • WHQL DVD Test Annex 3.0. You can order this DVD from Windows Hardware Compatibility Test Kits.

Tester Knowledge Requirements

To run the DVD Playback tests, testers must know how to:

  • 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 WDK.

This section includes:

Preparing for DVD Playback Testing

Running the DVD Playback Tests

Development Resources

Microsoft DirectX Software Development Kit (SDK)


Preparing for DVD Playback Testing

Before you run the DVD Playback tests, you must configure your test system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see DVD Playback Testing Overview.

Many of the tests in the Microsoft Windows Driver Kit (WDK) 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.

Test System Configuration

To configure the test system for DVD Playback testing, do the following:

  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.

After you have prepared for testing, you can run the DVD Playback tests.


Running the DVD Playback Tests

To run the DVD Playback logo tests and create a submission cabinet file (.cab) to send to the Microsoft Windows Hardware Quality Labs (WHQL) for logo approval, do the following:

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

  1. Open DTM Studio.

  2. On the Explorers menu, click Device Console. (You can also switch to the Device Console window by clicking the Device Console tab in the lower left corner of DTM Studio.)

  3. From the list at the upper left corner of the Device Console window, select your DTM controller.

  4. At the bottom of the Device Console window, click the Load button.

  5. Select a Device Job Schedule file that you previously saved.

  6. Skip to the steps in the To select and schedule logo tests procedure.

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

  1. Open DTM Studio.

  2. On the Explorers menu, click Device Console. (You can also switch to the Device Console window by clicking the Device Console tab in the lower left corner of DTM Studio.)

  3. In the list in the upper left corner of the Device Console window, select your DTM controller.

  4. In the View By frame, select the Submission option.

  5. In the Submission list on the right side of the Device Console window, click <New Submission>, and follow the instructions in the Create New Submission wizard that appears.

  6. Do the following to choose the 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. Click Device Submission, select the Streaming Media and Broadcase > DVD Decoder logo program, and then click Next.

    4. Select a Qualification Level, and then click Next.

    5. Enter a name for the submission, select the machine pool that contains the machines to use for the submission, and then click Next.

    6. Select the I am not providing an INF or Driver Package check box, and then click Finish.

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

To select and schedule logo tests

  1. In the list at the bottom of the Device Console window, select the displayed logo tests.

  2. Click the Add Selected button.

  3. Click the Schedule button.

To monitor logo test progress

  • Observe logo test progress by using job monitor and manually intervene if the test requires it. You can manually refresh the logo tests status in the Device Console window by pressing F5 or by clicking Refresh on the View menu.

  • Examine the results of a job in 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.

The following jobs should show up:

  • Name:Copy Binaries for DVD Annex Tests

  • Name:DVD Annex - NTSC Playback Test

  • Name:DXVA2 API Test

  • Name:DVD Annex - PAL Playback Test

  • Name:DVD Annex - Audio Test

  • Name:DVD Annex - Decode Test

  • Name:DVD Annex - Graphics Test

  • Name:DVD Annex - Sequence Test

  • Name:DVD Annex - Subpicture Test

  • Name:DVD Annex - Video Automated Test

  • Name:DVD Annex - Video Format Test

  • Name:DVD Annex - Video Manual Test

  • Name:MPEG-2 Decoder Test - WHQL Check


Broadcast Receiver Testing Overview

The procedures presented in this section outline the process for testing your Broadcast Receiver for the Windows Logo and Additional Qualifications Logo programs. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). The terminology in the next table is used.

Table 1: Terminology and Abbreviation

Term | Meaning
AQ | Additional Qualifications
BDA | Broadcast Driver Architecture
NTSC | National Television Systems Committee
ATSC | Advanced Television Systems Committee
PAL | Phase Alternating Line
SECAM | Sequential Color Avec (with) Memory
DVB | Digital Video Broadcasting
QAM | Quadrature Amplitude modulation
CA | Conditional Access
CAS | Conditional Access Source
DUT | Device Under Test
PBDA | Protected Broadcast Driver Architecture
Tuner capabilities | One of hybrid, combo, single
Form Factor | PCI, PCIe, USB
Broadcast receiver card | TV tuner card

To qualify for one of the Logo programs, you must run all of the tests that the DTM identifies as required for that Logo for that device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo

Using the Test Procedure Help Topics

The Broadcast Receiver Testing Overview Topic is divided into the following types of topics:

Broadcast Receiver Testing Overview:

The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing for Broadcast Receiver Testing:

The preparing topics describe how to configure the system or systems for Windows Logo testing and for Additional Qualifications testing.

Running the Broadcast Receiver Tests:

The running topics describe how to run to run the tests for your device or system.

Troubleshooting Broadcast Receiver Testing:

This section describes any troubleshooting steps to take if you run into problems.

Broadcast Receiver Tests

Documentation for the individual tests is in the Streaming Media and Broadcast Tests section. The tests that you need to run depend upon the capabilities of the device or system being tested, and the Logo for which you want your device to qualify.

Run time: Depending upon the test you are running, 5 minutes to 6 hours per test.

Hardware requirements

See the test description for each Broadcast Receiver test for hardware requirements.

Software requirements

See the test description for each Broadcast Receiver test for software requirements.

Tester knowledge requirements

Broadcast Receivers are TV tuner cards. These cards include analog receivers, digital receivers, combination (combo), or hybrid cards.

Testing for Broadcast Receivers covers the following analog broadcast receivers:

  • NTSC

  • NTSC_M_J

  • PAL

  • SECAM

Testing for Broadcast Receivers covers the following digital broadcast receivers:

  • ATSC

  • DVB-C

  • DVB-S

  • DVB-T

  • ISDB-T

  • ISDB-S

  • Proprietary

  • QAM

Hybrid tuner cards fall into both categories. You must receive Windows Logos for the analog and digital sides by specifying a Device Interface property. The next figure shows the logical representation of a Hybrid and a Combo tuner to the operating system.

Diagram of Hybrid and Combo Tuners (Figure one)

The above figure does not refer to a tuner's internal architecture. Instead, it refers to the logical representation of the tuner device to the Windows operating system via device interfaces.

The correct method to distinguish a combo tuner from a hybrid tuner is to include a new device interface property called a TunerInstanceId in the driver INF file. This in turn, adds a registry key when the driver is installed. Windows uses the combination of the tuner's ContainerId and TunerInstanceId to determine compatibility between the analog and digital filters.

The important parts of the device's installation file (INF file) are highlighted in bold below to illustrate how to correctly add the device interface property to the INF file.

Adding the Analog TV Interface:

AddInterface={a799a800-a46d-11d0-a18c-00a02401dcd4},%TunerReferenceGuid%,NTSC_Interface,

The TunerInstanceID is the only change you need to make in the INF file for your device. The value must be a DWORD. Note that the value of 0 is reserved for system use. Also note that the values must be the different for Combo tuners, as noted below:

[NTSC_Interface]
AddReg=NTSC_Interface.AddReg

[NTSC_Interface.AddReg]
HKR,,CLSID,,%CLSID_CTVTunerFilter%
HKR,,FriendlyName,,%TunerFriendlyName%
;add tunerInstanceID entry
HKR,,TunerInstanceID,0x00010001,10 ;Note this value

;In the corresponding ATSC tuner filter do the following
;Digital BDA tuner filter
AddInterface={71985F48-1CA1-11d3-9CC8-00C04F7971E0},%BDATuneReferenceGuid%,BDATUNE_Interface,

[BDATUNE_Interface]
AddReg=BDATUNE_Interface.AddReg

[BDATUNE_Interface.AddReg]
HKR,,CLSID,,%Proxy.CLSID%; {17CCA71B-ECD7-11D0-B908-00A0C9223196}
HKR,,FriendlyName,,%BDATuneFriendlyName%
;add tunerInstanceID entry
HKR,,TunerInstanceID,0x00010001,11 ;Note this value is different

The next figure shows the logical representation of a Dual Hybrid tuner card to the operating system.

Diagram of a Dual Hybrid TV Tuner (Figure two)

Notes:

  • The TunerInstanceId device interface property is a registry key setting required for Windows compatibility with hybrid tuners that have previously shipped. The TunerInstanceId device interface property is a qualifier used to match an analog tuner filter to its corresponding digital tuner filter on the same tuner. You can then configure Windows Media Center to use one tuner or the other, but not both tuners.

  • You can set TunerInstanceId to be any value between 1 and 0xffffffff.

  • Do not set TunerInstanceId to anything less than 1, which is reserved for system use. If a TunerInstanceId is not present in the INF file for a hybrid tuner that has already shipped, then Windows automatically uses a value of 0.

  • All combo tuners should also use the TunerInstanceId device interface property registry key to ensure compatibility with future versions of Windows Media Center. In the currently released version of Windows Media Center (Vista), this registry key has no effect because Vista does not support both PAL and DVB at the same time.

Windows Logo and Additional Qualifications Programs:

The Windows Logo program tests the tuner card and driver for an initial set of qualifications independent of Windows Media Center. The Additional Qualifications Logo program tests the tuner and driver for Microsoft Windows Media Center specific qualifications.

Program Contents:

The Broadcast Receiver Logo programs test common functionality in addition to specific tuner card tests. The tuner card must pass all of the functionality tests required for a Logo to receive a Windows Logo for the tuner card.

The Broadcast Receiver program includes the following tests:

  • Device Fundamental Tests

  • Broadcast Receiver Tests

  • CardBus Tests

The tests depend upon the capabilities of the device or system that you are testing. To see the complete list of tests that might be required for your device, see Broadcast Receiver Tests.

Broadcast Receiver Tests: The tests depend upon the capabilities of the device or system that you are testing. To see the complete list of tests that might be required for your device, see Broadcast Receiver Tests.

Protected Broadcast Driver Architecture:

You can use a Protected Broadcast Driver Architecture (PBDA) device and/or driver to extend the Media Center First Run experience. In doing this, you must meet the requirements set forth in the document available at Developing Protected Broadcast Drivers in Windows.


Preparing for Broadcast Receiver Testing

Before testing, you must configure the system and install the operating system as described in the Setting Up DTM section earlier in this documentation. The rest of this Broadcast Receiver Testing Overview section, and the Streaming Media and Broadcast Tests section, later in this documentation, assume that you have completed this system configuration requirement. Additional requirements specific to testing Broadcast Receivers are called out.

Many of the tests in the Windows Logo 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, by default, 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.

Configuring the Test Environment

This section describes specific, additional broadcast receiver configurations required for testing. See the Configuring the Test Environment earlier in this documentation.

You need a minimum of 2 computers, however, 3 are recommended. The reference test configuration for testing tuners is shown in the following figure.

Diagram of a Tuner Test Configuration (Figure three)

The next table describes each component. See the Streaming Media and Broadcast Tests section for specific requirements for each test.

Table 2: Component Description

Component | Description
DTM Controller | Must be running Windows Server 2003 SP1 or SP2 WLK 1.4 must be installed (DTM Studio Optional and supported) x86 or amd64
DTM Studio | Can be running Windows XP with SP2, Windows Server 2003 with SP1, Windows Vista, or Windows Server 2008 DTM Studio interfaces with the controller and the client to test tuner functionality. x86 and amd64
DTM Client | Operating System is Test-Dependent. See the specific test documentation in the Streaming Media and Broadcast Tests section. Tuner and tuner driver reside here. X86 and amd64
TV Tuner | The tuner under test X86 and amd64 driver
Media Feed | Specific to the test and tuner/driver under test
Router/Switch | Self explanatory

To set up your test configuration:

  1. Provide the appropriate signals to the Broadcast Receiver cards that are being tested on all test machines.

  2. Install the Broadcast Receiver cards that you are testing on the client machines.

  3. Install the DTM Client software on each test machine.

Preparing Computers for Logo Tests

Before running any of the Windows Logo tests, you must:

  • Create a Machine Pool for your tuner card clients

  • Move the tuner card client to the Machine Pool

Creating Machine Pool for Tuner Clients

Tuner tests require clients to belong to Machine Pools with specific policies and dimensions. To satisfy this requirement, you can create a separate machine pool meeting the requirements to which your tuner clients belong.

To create a tuner card client machine pool:

  1. Right-click the machine pool root (the default value is $), and click Add Machine Pool.

  2. On the Add Machine Pool, in the Name text box, type a name for the machine pool (for example, Tuner), and select the Allow Scheduler... check box.

    Note It is not necessary to change the default settings for Job Deliver Agent and Machine Pool Behavior. You do not need to add anything else after you type a name for the pool.

  3. Click Apply, and then OK. The new Machine Pool (Tuner in this example) is displayed in the Machine Pool pane.

For additional information on creating Machine Pools, see the Grouping Client Computers into Machine Pools section.

Performing Extra Preparation for Additional Qualifications

Before running any of the Additional Qualifications (AQ) Tuner automation tests, you must perform the following tasks:

  1. Ensure that the required MCE\MachineLocation dimension is the name of a valid Channel Library XML file for your specific testing environment.

  2. Add required AQ Dimensions.

  3. Reserve at least 35 GB of free hard drive space for tests that produce recordings.

  4. Create your valid Channel Library XML file.
  5. Create your valid Profile Configuration files.

Creating a Valid Channel Library XML File

To prepare to run AQ tests, if the default is not adequate, you must create a valid Channel Library XML file specific to your test environment. This Channel Library XML file must adhere to the structure specified in the mcchannel.xsd Schema file, found in the following default location:

  • x86fre: "[%SystemDrive%]\Program Files\Microsoft Driver Test Manager\Tests\x86fre\NTTest\multimediatest\ehome\tools\portability" or

  • amd64fre: "[%SystemDrive%]\Program Files\Microsoft Driver Test Manager\Tests\amd64fre\NTTest\multimediatest\ehome\tools\portability"

This location also includes sample Channel Library XML files, which you can use, and your choice of x86fre or amd64fre depends upon the test computer's platform.

An example of a Channel Library XML file with representative channel structures is shown in the code below. The <Location> tag value (Arlington in the example below) must match the following:

  • The Channel Library XML File name, for example Arlington.xml

  • The MCE\MachineLocation dimension name

Code Example of a Channel Library XML File (Figure four) Code Example of a Channel Library XML File (Figure four) Code Example of a Channel Library XML File (Figure four) Code Example of a Channel Library XML File (Figure four) Code Example of a Channel Library XML File (Figure four)

Creating a Valid Profile Configuration File

To prepare to run AQ tests, if the default is not adequate, you must create two valid Profile Configuration files specific to your test environment. These Profile Configuration files must be created and live in one of the following default locations:

  • x86fre: [%SystemDrive%]\Program Files\Microsoft Driver Test Manager\Tests\x86fre\NTTest\multimediatest\ehome\tools\AQTest
  • amd64fre: [%SystemDrive%]\Program Files\Microsoft Driver Test Manager\Tests\amd64fre\NTTest\multimediatest\ehome\tools\AQTest

This location includes two Profile Configuration files, which you must update to match your test environment configuration. Your choice of x86fre or amd64fre depends upon the test computer’s platform.

An example of the Profile Configuration file settings and values are as follows:

Note Values in bold cannot be modified. You can only modify the other values below that your device is capable of utilizing.

[MCE Based Tuner Test App]
LogFile.Log File=AQTest_VerifyAllTuners.log
TuneReqType=0
NTSCDefaultChannel=44
NTSCAnotherChannel=79
NTSCCopyNeverChannel=66
NTSCCountryCode=1
NTSCUseCableInput=1
ATSCDefaultChannel=39
ATSCAnotherChannel=9
UDCRDefaultPhysicalChannel=101
UDCRDefaultProgramNumber=1
UDCRAnotherPhysicalChannel=103
UDCRAnotherProgramNumber=3
ATSCUseCableInput=0
PALDefaultChannel=65
PALAnotherChannel=64
PALCountryCode=49
PALUseCableInput=0
SECAMDefaultChannel=5
SECAMAnotherChannel=23
SECAMCountryCode=33
SECAMUseCableInput=0
FMRadioDefaultChannel=88500000
FMRadioAnotherChannel=98100000
DVBTDefaultCarrier=482000
DVBTDefaultONID=9018
DVBTDefaultTSID=24576
DVBTDefaultSID=25664
DVBTAnotherSID=25728
DVBSDefaultCarrier=11837000
DVBSDefaultONID=1
DVBSDefaultTSID=1101
DVBSDefaultSID=28106
DVBSDefaultSymbolRate=27500000
DVBSDefaultPolarisation=1
DVBSDefaultLNBSource=1
DVBSDefaultOrbitalPosition=0
DVBSAnotherCarrier=12545000
DVBSAnotherONID=1
DVBSAnotherTSID=1107
DVBSAnotherSID=17501
DVBSAnotherSymbolRate=22000000
DVBSAnotherPolarisation=1
DVBSAnotherLNBSource=1
DVBSAnotherOrbitalPosition=0
UseSTB=0
DeleteRecordingsWhenDone=1
PauseTestAppToAttachDebugger=0
KillEhRecvrProcess=0
DVBAudio=16
DVBVideo=4
ISDBTAudio=8
ISDBTVideo=4
UDCRAudio=4
UDCRVideo=1
ATSCAudio=4
ATSCVideo=1
Position=53, 87, 1013, 617
Options=403
RunCount=2
Search=
LogWindowLevel=10
LogLog FileLevel=10
FontName=MS Shell Dlg
FontAttr=-11 400 0 0
NumTests=1
testcasename0000=Advanced Tuner Tests\Signal Quality & TunerInstanceID
Tests\HybridAndHeteroTunerVerificationAdvancedSignalQuality

Setting Machine Dimensions Required for Additional Qualifications Tests

Before running any of the Additional Qualifications Tuner automation tests, you must set all required machine dimensions.

The machine dimensions shown in the next table are required for AQ tests.

Table 3: Required Machine Dimensions

Machine Dimension | Value
MCE\MachineLocation | Name of Channel Library XML file
MCE\TunerType | Specific to broadcast type under test
MCE\TV\Guide\DesiredRegion | The ISO 3166 two-letter string code
MCE\TV\Tuners\NumberOf<TunerType> | The number of <TunerType> of broadcast tuners under test
MCE\TV\Tuners\NumberOfTuners | The total number of tuners

Note Make sure that the machine dimensions you have set exactly match both of the supported capabilities of the tuner device, as well as the physically connected feeds. For example, if you have set your machine dimensions to indicate ATSC and NTSC support, then your device must be capable of NTSC and ATSC, and you must have NTSC and ATSC feeds connected to it.

Table 4: Optional Machine Dimensions

Machine Dimension | Value
MCE\TV\Guide\ZipCode | Zip code to use during First Run setup

Note First Run will always use the first lineup listed on the lineup setup page to download the guide data.

The following screen shot shows an example of these machine dimensions entered into DTM Studio.

Screen shot of an Example of Machine Dimensions in DTM Studio (Figure five)

The following examples and nomenclature will help you set the machine dimensions required to run the Media Center AQ tests.

Table 4: Machine Dimension Descriptions

Machine Dimension | How to describe the value
MCE\TV\Tuners\NumberOf<TunerType> | How many physical tuners, on the device, support the specified "<TunerType>"?
MCE\TV\Tuners\NumberOfTuners | How many simultaneous recordings can take place or how many separate physical tuners are on the device?

Key:

"+" means COMBO: defined as a device which contains multiple physical tuners

"/" means HYBRID: defined as a device which contains multiple broadcast types on a single physical tuner

Examples:

  • A device that has two physical NTSC tuners would be described as NTSC+NTSC

  • A device that has one physical tuner, which supports both PAL and DVB-T would be described as DVB-T/PAL

  • A device that has one physical tuner which supports ATSC and QAM, and another physical tuner which supports NTSC would be described as ATSC/QAM+NTSC

Here are examples of the dimensions that need to be set for various common tuner device configurations:

ATSC/NTSC (hybrid)

MCE\TV\Tuners\NumberOfNTSC 1

MCE\TV\Tuners\NumberOfATSC 1

MCE\TV\Tuners\NumberOfTuners 1

ATSC+NTSC (combo)

MCE\TV\Tuners\NumberOfNTSC 1

MCE\TV\Tuners\NumberOfATSC 1

MCE\TV\Tuners\NumberOfTuners 2

ATSC/NTSC/QAM

MCE\TV\Tuners\NumberOfNTSC 1

MCE\TV\Tuners\NumberOfATSC 1

MCE\TV\Tuners\NumberOfQAM 1

MCE\TV\Tuners\NumberOfTuners 1

ATSC/QAM+ATSC/QAM

MCE\TV\Tuners\NumberOfATSC 2

MCE\TV\Tuners\NumberOfQAM 2

MCE\TV\Tuners\NumberOfTuners 2

ATSC/QAM+NTSC

MCE\TV\Tuners\NumberOfNTSC 1

MCE\TV\Tuners\NumberOfATSC 1

MCE\TV\Tuners\NumberOfQAM 1

MCE\TV\Tuners\NumberOfTuners 2

ATSC/QAM

MCE\TV\Tuners\NumberOfATSC 1

MCE\TV\Tuners\NumberOfQAM 1

MCE\TV\Tuners\NumberOfTuners 1

DVB-C

MCE\TV\Tuners\NumberOfDVBC 1

MCE\TV\Tuners\NumberOfTuners 1

DVB-S+DVB-S+DVB-T/NTSC/PAL+DVB-T/NTSC/PAL

MCE\TV\Tuners\NumberOfDVBS 2

MCE\TV\Tuners\NumberOfDVBT 2

Then one of these, depending on what broadcast type you are testing:

MCE\TV\Tuners\NumberOfPAL 2

MCE\TV\Tuners\NumberOfNTSC 2

MCE\TV\Tuners\NumberOfTuners 4

DVB-T

MCE\TV\Tuners\NumberOfDVBT 1

MCE\TV\Tuners\NumberOfTuners 1

DVB-T+DVB-T

MCE\TV\Tuners\NumberOfDVBT 2

MCE\TV\Tuners\NumberOfTuners 2

DVB-T+DVB-T+PAL+PAL

MCE\TV\Tuners\NumberOfDVBT 2

MCE\TV\Tuners\NumberOfPAL 2

MCE\TV\Tuners\NumberOfTuners 4

DVB-T/PAL

MCE\TV\Tuners\NumberOfDVBT 1

MCE\TV\Tuners\NumberOfPAL 1

MCE\TV\Tuners\NumberOfTuners 1

DVB-T+PAL

MCE\TV\Tuners\NumberOfDVBT 1

MCE\TV\Tuners\NumberOfPAL 1

MCE\TV\Tuners\NumberOfTuners 2

ISDB-T

MCE\TV\Tuners\NumberOfISDBT 1

MCE\TV\Tuners\NumberOfTuners 1

ISDB-T+ISDB-T

MCE\TV\Tuners\NumberOfISDBT 2

MCE\TV\Tuners\NumberOfTuners 2

NTSC

MCE\TV\Tuners\NumberOfNTSC 1

MCE\TV\Tuners\NumberOfTuners 1

NTSC+NTSC

MCE\TV\Tuners\NumberOfNTSC 2

MCE\TV\Tuners\NumberOfTuners 2

NTSC_M_J

MCE\TV\Tuners\NumberOfNTSCJ 1

MCE\TV\Tuners\NumberOfTuners 1

PAL/SECAM

One of these, depending on what broadcast type you are testing:

MCE\TV\Tuners\NumberOfPAL 1

MCE\TV\Tuners\NumberOfSECAM 1

MCE\TV\Tuners\NumberOfTuners 1

PAL/SECAM+PAL/SECAM

One of these, depending on what broadcast type you are testing:

MCE\TV\Tuners\NumberOfPAL 2

MCE\TV\Tuners\NumberOfSECAM 2

MCE\TV\Tuners\NumberOfTuners 2

DVB-S

MCE\TV\Tuners\NumberOfDVBS 1

MCE\TV\Tuners\NumberOfTuners 1

NTSC/PAL

One of these, depending on what broadcast type you are testing:

MCE\TV\Tuners\NumberOfNTSC 1

MCE\TV\Tuners\NumberOfPAL 1

MCE\TV\Tuners\NumberOfTuners 1

PAL

MCE\TV\Tuners\NumberOfPAL 1

MCE\TV\Tuners\NumberOfTuners 1

PAL/SECAM/NTSC

MCE\TV\Tuners\NumberOfNTSC 1

Then one of these, depending on what broadcast type you are testing:

MCE\TV\Tuners\NumberOfPAL 1

MCE\TV\Tuners\NumberOfSECAM 1

MCE\TV\Tuners\NumberOfTuners 1

ATSC/NTSC/DVB-T/PAL

MCE\TV\Tuners\NumberOfATSC 1

MCE\TV\Tuners\NumberOfDVBT 1

Then one of these, depending on what broadcast type you are testing:

MCE\TV\Tuners\NumberOfPAL 1

MCE\TV\Tuners\NumberOfNTSC 1

MCE\TV\Tuners\NumberOfTuners 1

The examples listed above are only to help demonstrate a more understandable way of determining your machine dimensions. If Media Center does not support a specific configuration (such as NTSC & PAL or PAL & SECAM) then it is likely that the First Run automation will not support this, which is why you see the asterisks next to certain dimension combinations.

If, after attempting the above method, you are unable to get the automated First Run (Config) job in DTM to pass, it is recommended that you perform First Run manually. Once you have manually completed First Run for all broadcast types you must then set the machine dimension "MCE\TV\Tuners\FirstRunComplete" to "True" on that specific machine. This is a workaround and should only be used if you are blocked from successfully completing First Run using the automation

To set required AQ machine dimensions:

  1. On the DTM Studio Main Menu, click Explorers and select Job Monitor.

  2. On the Job Monitor page, click the machine pool and then double-click the machine in the results pane to display the machine properties page.

  3. On the Machine Details page, select the Machine Dimensions tab

  4. On the Machine Dimensions tab, click the Edit Machine button and scroll to the very bottom of the page.

  5. At the bottom of the page, click in the white space to display the available machine dimensions.

  6. Select the required machine dimensions from the drop down list box and click Save Machine, at the top of the page.

Moving Tuner Card Client to the Machine Pool

By default, each machine that you installed the DTM client on is added to the Default Pool. You must move the tuner card client computer from the Default Pool to the machine pool set up as described above.

See the Grouping Client Computers into Machine Pools section for how to do this.


Running the Logo Tests

This section discusses how to test your Broadcast Receiver card.

Creating a Tuner Submission

For basic submission information, see the Generic Logo Submission exercise topic earlier in this documentation. This section calls out Tuner-specific submission information.

To create a submission:

  1. On the Main Menu, click Explorers, and click Device Console.

  2. On the Device Console page, in the Submission drop down list, click <New Submission>. The Create New Submission Wizard opens.

  3. On the Create New Submission page, select the client operating system from the Select OS text box, and click Next.

  4. On the next Create New Submission page, in the Select Category list box, select the submission category, and click Next.

  5. On the next Create New Submission page, in the Logo Type list box, select the logo type of the submission you are creating and click Next.

  6. On the next Create New Submission page, in the Qualification Level list box, select the qualification level of the submission you are creating and click Next.

  7. On the next Create New Submission page, in the Name for new Submission text box, enter the name for your submission. In the Machine Pool text box, select the Machine Pool in which your client computer resides, and click Next.

  8. On the next Create New Submission page, use the Browse button to enter the path and file name of the INF file for the tuner you are testing, and click Load. Alternatively, select one of the check boxes at the bottom of the page. Click Next.

  9. On the next Create New Submission page, in the Additional Qualifications list box, check any additional qualifications for the submission you are creating, and click Next.

  10. On the last Create new Submission page, review the values for the submission. Click Finish to finish creating the submission, or Back to change any of the values.

  11. After clicking Finish, the submission loads in the Device Console page.

  12. In Available Jobs, select the check box at the top of the job tree to run all of the jobs that are listed, or expand the job tree to choose the jobs individually. A submission should include all jobs that are listed.

  13. When you have selected all appropriate jobs, click Add selected.

  14. Click Schedule Jobs. After a short time, the client computer reboots into Test Mode, and the tests that you selected are executed.

  15. Respond to the prompts on the screen of the client machine.

  16. Use Job Monitor in DTM Studio to track the progress of jobs as they are run. Be sure to have the correct machine pool and test machine highlighted in Job Monitor when you track this status.

  17. When the tests are complete, click Status in Device Console, review the information that is provided, and correct any issues that are identified.

Creating a Package

When all tests pass you can create a package to submit.

To create a package:

  1. On the Main Menu, click Explorers, and click Device Console.

  2. In the Submission drop down list box, select a submission for which you want to create the package.

  3. On the Device Console page, in the left pane, right-click anywhere and click Create Submission Package.

  4. On the Save As page, select a name and location for the package to be created, and click Save.

  5. When creation of the package has completed, you can navigate to the folder in which you saved the package and open the package file in Microsoft Driver Test Manager Log Viewer to review the package. Percentage of Passing Logo Tests must be 100%.

Viewing Test Results

After the test has completed, you can view results for the test.

To view the Result Report for a Job in DTM:

  1. When the test is finished, the Job and Task Execution Status is shown on the Job Monitor. Right-click the completed job in Job Monitor and click View Result Report.

  2. Right-click the Job in the Job Execution Status pane and click Job Results from the menu to display the Result Report. In the Result Report, click the log location link and open TvWLPLog.xml file


Troubleshooting Broadcast Receiver Testing

You should have a reasonable quality video and FM connections to the machine. Poor quality video feed might impact tests. If you are experiencing trouble running the tests, check the feed first.

See the Troubleshooting DTM Problems in the Getting Started Section of the Windows Logo Kit Help.

To run a single test in DTM Studio:

  1. Open DTM Studio.

  2. In DTM Studio, on the Main Menu, click Explorers, and click Job Explorer.

  3. On the Job Explorer page, locate the job you want to run, right-click the Job, and click Schedule.

  4. On the Schedule Jobs page, select the computer on which you want to run the test, make any other changes on each of the tabs on that page, and when finished, click Create Schedule in the Task Bar.

  5. The test will execute shortly after clicking Create Schedule. Follow the prompts, and view results when the test has completed.

Running a Windows Logo Test at the Command Line

This section describes how to run a Windows Logo test at the command line. This involves running the following three executables:

  • Tvwlpgraphicstests.exe

  • Tvwlpsystemstests.exe

  • Tvwlptunertests.exe

The command line syntax for tvwlpgraphicstests.exe is:

Usage: TvWLPGraphicsTests [/mobile ] TestName ["deviceid"]

TestName - must be one of the following test cases:

GRAPHICS-0043: Display driver supports minimum display timings and modes where applicable

GRAPHICS-0001: Display adapter supports output connectors with content protection features and provides control via PVP and COPP DDIs

GRAPHICS-0055: Display subsystem that supports Media Center functionality supports digital television (EIA

/CEA-861B) resolutions and timings over digital interfaces

TestName may also be 'display_tests' to run the graphics test cases

The command line syntax for tvwlpsystemstests.exe is:

Usage: TvWLPSystemsTests TestName

TestName - must be one of the following test cases:

SYSFUND-0065: System that ships a tuner meets CPU performance guidelines while recording programs

SYSFUND-0043: 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 that ships a tuner enables DMA

The command line syntax for tvwlptunertests.exe is:

Usage: TvWLPTunerTests TestName ["deviceid"] LogoProgramId

LogoProgramID - must be one of the following:

BroadcastReceiver~ATSC

BroadcastReceiver~DVB-C

BroadcastReceiver~DVB-S

BroadcastReceiver~DVB-T

BroadcastReceiver~ISDB-T

BroadcastReceiver~ISDB-S

BroadcastReceiver~NTSC

BroadcastReceiver~NTSC_M_J

BroadcastReceiver~PAL

BroadcastReceiver~Proprietary

BroadcastReceiver~QAM

BroadcastReceiver~SECAM

TestName - must be one of the following test cases:

STREAM-0023: TV Tuner Analog Tests

STREAM-0057: TV tuner capture card supports automated capture graph building with Media Center video control

STREAM-0016: TV tuner detects signals from all input sources

STREAM-0014: Resources are not acquired until the Device Acquire state

STREAM-0015: TV tuner properly signals channel changes

STREAM-0021: Digital TV tuner uses the Broadcast Driver Architecture (BDA)

STREAM-0017: USB TV tuner has a unique serial number

STREAM-0060: PBDA Tuner Implements DRM

STREAM-0066: TV tuner can change channels 500 times

STREAM-0073: TV tuner can function after 5 reboots - *** This test should only be run from Microsoft Device Test Manager (DTM)

STREAM-0065: ALL TV Tuners must support at least 6 hours of uptime

C:\WD>

To run a Windows Logo test at the command line:

  1. Create a working directory on the client/test machine. (for example c:\wd)

  2. Copy the following files from DTM controller to the working directory:

    • tvwlpgraphicstests.exe
    • tvwlpsystemstests.exe
    • tvwlptunertests.exe
    • tvwlpvbimonitor.ax
    • tvwlpaudiomonitor.ax
    • tvwlpsourcefilter.ax
    • tvwlpmpeg2monitor.ax

    These files are typically located on the controller at the following default locations, and which you copy over, depend upon architecture of the test computer:

    • 32-Bit: [%SystemDrive%]\Program Files\Microsoft Driver Test Manager\Tests\x86fre\nttest\MultimediaTest\eHome\Tools\TvWLPTest
    • 64-Bit: [%SystemDrive%]\Program Files\Microsoft Driver Test Manager\Tests\amd64fre\nttest\Multimedia Test\eHome\Tools\TvWLPTest

  3. Copy the following Logger binary from DTM controller to the working directory:

    • WTTLog.dll

    This DLL file is typically located on the controller at the default location of: [%SystemDrive%]\Program Files\Microsoft Driver Test Manager\Controller

  4. Register TVWLP monitor filters on the test machine by running the following commands (using the example working directory of C:\WD:
    • regsvr32 C:\WD\TvWLPVBIMonitor.ax
    • regsvr32 C:\WD\TvWLPAudioMonitor.ax
    • regsvr32 C:\WD\TvWLPSourceFilter.ax
    • regsvr32 C:\WD\TvWLPMpeg2Monitor.ax

  5. For each command, click OK on the RegSvr32 confirmation dialog box.

  6. Launch a command window with admin privileges, and cd to your working directory created in Step 1 above.

  7. Type the name of the executable containing the test you want to run, for example, tvwlptunertests.exe, followed by a space.

  8. Type the subtest, for example STREAM-0023 followed by a space.

  9. Get the Device Instance Path from Device Manager (in Control Panel) by doing the following:
    a. Open the Control Panel.
    b. Select Device Manager in the Control Panel.
    c. Select the device (usually under Sound, video...) and right-click for Properties.
    d. Click the Details tab.
    e. Select Device Instance Path in the drop-down list box.
    f. Select the Value, right-click, and click Copy.

  10. In the command window, paste the copied Device Instance Path string between double quotes after the name of the test executable followed by a space ("tvwlptunertests.exe " in this example, no double quotes; added to show space). Enter the LogoProgramID (BroadcastReceiver~NTSC in this example) specific to your test and platform, and press the Enter key. Screen shot of the Administrator Command Prompt window with the Paste command selected

  11. On the Please Provide Tuning Parameters page (specific to the test and platform), enter the correct information, and click OK. Screen shot of the Administrator Command Prompt window behind the Please Provide Tuning Parameters dialog box

  12. You should see a success notification, and if you don't, please see the Troubleshooting section. Screen shot of the Administrator Command Prompt window with a Passed notification

The following table describes the requirements that you can test individually.

Table 5: Test Requirements

Requirement ID | Type | Requirement Description
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). Digital TV tuner provides signal quality and other diagnostic information.
STREAM-0023 | Tuner Tests | Analog TV Tuner: 1)Implements stereo audio decoding for indented broadcast region 2)Supports content protections 3)Tuners dependent upon host processing of VBI meet minimum requirements 4)Support exhaustive scanning APIs 5) Premium TV tuner supports both audio and video capture.
STREAM-0057 | Tuner Tests | TV tuner capture card supports automated capture graph building with Media Center video control. TV tuner Driver uniquely identifies the Tuner and its mediums
STREAM-0065 | Tuner Tests | ALL TV Tuners must support at least 6 hours of uptime
STREAM-0066 | Tuner Tests | TV tuner can change channels 500 times
GRAPHICS-0001 | Display Tests | Display adapter supports output connectors with content protection features and provides con trol via PVP and COPP DDIs
GRAPHICS-0043 | Display Tests | Display driver supports minimum display timings and modes where applicable
GRAPHICS-0055 | Display Tests | Display subsystem that supports Media Center functionality supports digital television (EIA/ CEA-861B) resolutions and timings over digital interfaces
SYSFUND-0043 | Systems Tests | Systems implement a minimum of 2 user-accessible, fully powered USB 2.0 ports for desktop sys tems and 1 for mobile systems
SYSFUND-0064 | Systems Tests | System that ships a tuner enables DMA
SYSFUND-0065 | Systems Tests | System that ships a tuner meets CPU performance guidelines while recording programs


Broadcast Receiver Testing for IP Devices

Proprietary Submissions

The Proprietary Logo category is required for IP devices. In addition, manual review is required for Proprietary submissions. As a result, the following error message will appear when you run the Tuner - Serial Number Test:

THIS LOGO SUBMISSION REQUIRES A MANUAL REVIEW BY THE BROADCAST RECEIVER PRODUCT TEAM

Creating new submissions

There are two main differences when using the submission wizard to create new submissions for IP devices:

  • Driver Selection -- IP devices do not implement a tuner driver on the target machine. They are treated as Network devices and do not provide an .INF or driver during submission. Therefore, in the Create New Submission window, select I am not providing an .INF or driver package.

  • Device Selection -- There is no device instance on the target machine. Therefore, in the Create New Submission window, select Device Not Listed.

Aside from these two differences, the steps in the submission wizard process are consistent with other Broadcast Receiver Logo submissions.

The Tuner-Serial Number Test (SREAM-0017)

When running the Tuner-Serial Number Test (SREAM-0017), the Broadcast Receiver Proprietary window will appear with the following message:
Please provide the name of the BDA Source Filter for the device under test.

You will need to type the "friendly name" of the BDA Source Filter that represents the device being tested. For PBDA devices, this identifier can be determined by examining the following registry key:

HKLM\Software\microsoft\windows\currentversion\mediacenter\service\ehprivjob\OCURDevices

The sub-key name is also the BDA Source Filter name.

Alternatively, GraphEdt, a tool that is included with the Windows 7 Windows Driver Kit, can be used to determine the filter name:

  1. On the Graph menu, select Insert Filters.

  2. In the Which filters do you want to insert? window, expand the BDA Source Filters node.


Broadcast Receiver Testing for DMB-TH Devices

Preparing the DMB-TH WLK test environment

To prepare for the DMB-TH WLK test, follow these steps:

  1. Update WLK1.4 with QFE001 and QFE013.

  2. On the Main Menu, click Explorers, and then click Job Monitor.

  3. On the Job Monitor page, in the Machine Pool list box, right-click the Root item (find the $ item), and then select the item Add Machine Pool from the machine pool tree view.

  4. On the Add Machine Pool page, enter your machine pool name into the Name text box, and then click OK.

  5. Drag your DTM client from the Default Pool into your created Machine Pool.

  6. Wait for the DTM configuration job to finish.

  7. Copy the Channel Library file into %systemdriver%\program files\Microsoft Driver Test Manager\Tests\x86fre (and amd64fre)\NTTest\multimediatest\ehome\tools\portability.

    Note Please see the "Editing a Channel library file" section below for more information.

  8. Select the DTM client from the Machine list, right-click the mouse, and then select Edit.

  9. On the Edit Machine page, select the tab Machine Dimensions from the tab index, and then drag the scrollbar to the bottom of the screen.

  10. Add the following Machine Dimensions:

    • MCE\MachineLocation = ChannelLibraryName

      Note Do not include the file name extension in the name. For example, if the channel library is "DMBTHChannel.xml", type "DMBTHChannel" into the text box.

    • MCE\TunerType = X
    • MCE\TV\NumberOfDMBTH = X
    • MCE\TV\NumberOfTuners = X
    • MCE\Win7\FirstRunComplete = True

  11. Click Save Machine on the tool box.

Editing a Channel library file

To create a Channel library file or edit a Channel library file, follow these steps:

  1. Create "ChannelLibraryName.xml" file using the correct DMB-TH information.

    Note Replace "ChannelLibraryName" with the name of your choice.

  2. Place this file on the DTM Controller in one of the following locations:
    • x86fre: [%SystemDrive%]\Program Files\Microsoft Driver Test Manager\Tests\x86fre\NTTest\multimediatest\ehome\tools\portability
    • amd64fre: [%SystemDrive%]\Program Files\Microsoft Driver Test Manager\Tests\amd64fre\NTTest\multimediatest\ehome\tools\portability

The following is a sample ChannelLibraryName.xml:

<!-- Signal type="DMB-TH" -->

<Signal>

<Type>DMB-TH</Type>

<Channel>

<Tunable>1</Tunable>

<Name>CCTV-1</Name>

<Frequency>666000000</Frequency>

<ONID>2184</ONID>

<TSID>28</TSID>

<SID>601</SID>

</Channel>

......

</Signal>

Creating a submission

To create a DMB-TH device logo submission, follow these steps:

  1. On the Main Menu, click Explorers, and then click Device Console.

  2. On the Device Console page, in the Submission drop down list, click <New Submission>. The Create New Submission Wizard opens.

  3. On the Create New Submission page, select the client operating system from the Select OS text box, and then click Next.

  4. On the next Create New Submission page, in the Select Category list box, select the Device Submission category, and then click Next.

  5. On the next Create New Submission page, in the Logo Type list box, select Broadcast Receiver Proprietary and then click Next.

  6. On the next Create New Submission page, in the Qualification Level list box, select Logo and then click Next.

  7. On the next Create New Submission page, in the Name for new Submission text box, type the name for your submission. In the Machine Pool text box, select the Machine Pool in which your client computer resides, and then click Next.

  8. On the next Create New Submission page, use the Browse button to enter the path and file name of the INF file for the tuner you are testing, and click Load. Alternatively, select one of the check boxes at the bottom of the page. Click Next.

  9. On the next Create New Submission page, check the Device Not Listed box, and then click Next.

  10. On the next Create New Submission page, in the Additional Qualifications list box, check the Media Center box if you want to qualify for additional Qualifications, and then click Next.

  11. On the last Create new Submission page, review the values for the submission. Click Finish to finish creating the submission or Back to change any of the values.

  12. After clicking Finish, the submission loads in the Device Console page.

  13. In Available Jobs, select the check box at the top of the job tree to run all of the jobs that are listed, or expand the job tree to choose the jobs individually. A submission should include all of the jobs that are listed.

  14. When you have selected all appropriate jobs, click Add selected.

  15. Click Schedule Jobs. After a short time, the client computer reboots into Test Mode, and the tests that you selected are executed.

  16. Respond to the prompts on the screen of the client machine.

  17. Use Job Monitor in DTM Studio to track the progress of jobs as they are run. Be sure to have the correct machine pool and test machine highlighted in Job Monitor when you track this status.

  18. When the tests are complete, click Status in Device Console, review the information that is provided, and correct any issues that are identified.

Notes

  • In WLK 1.4, DMB-TH submissions require manual review. The Tuner-Verification Test (Manual) will fail with the following error by design:

    THIS LOGO SUBMISSION REQUIRES A MANUAL REVIEW BY THE BROADCAST RECEIVER PRODUCT TEAM. Please contact the product team for information about this test.

  • If you are running the "Tuner - Additional Qualifications - Digital TV tuners are required to support Protected Broadcast Driver Architecture (PBDA) (manual)" test, and your driver and device do not support DRM, you can select No in the client PC dialog box.

  • If you are running the "Tuner - Additional Qualifications - PBDA devices need to author extensibility pages according to the Windows Media Center guidelines (manual)" test, the DMB-TH driver must include extensibility pages for the signal detect and show. Therefore, the Media Center must show the signal detect pages.

Creating a Package

When all tests pass, you can create a package to submit.

To create a package, follow these steps:

  1. On the Main Menu, click Explorers, and then click Device Console.

  2. In the Submission drop down list box, select a submission for which you want to create the package.

  3. For any failed test results, include the WHQL_Submission_Readme file, along with any errata numbers (if applicable).

  4. On the Save As page, select a name and location for the package to be created, and click Save.

  5. When creation of the package is complete, you can navigate to the folder in which you saved the package and open the package file in Microsoft Driver Test Manager Log Viewer to review the package. Percentage of Passing Logo Tests must be 100%.

Viewing Test Results

After the test has completed, you can view results for the test.

To view the Result Report for a Job in DTM, follow these steps:

  1. When the test is finished, the Job and Task Execution Status is shown on the Job Monitor. Right-click the completed job in Job Monitor and click View Result Report.

  2. To display the Result Report, right-click the job in the Job Execution Status pane and click Job Results from the menu.

  3. In the Result Report, click the log location link and open the TvWLPLog.xml file.


Video Capture Testing Overview

The procedures that are presented in this section outline the process for testing your video capture device for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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.

Note You must use the latest version of the WLK to compile your driver in order for it to pass testing and obtain a logo.

Note TV Tuners are covered by the Broadcast Receiver logo program and are not covered by the video capture testing.

The test procedures in this section 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 Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

Video Capture Tests

The tests that you need to run depend on the capabilities of the device or system that you are testing. To see the complete list of tests that could be required for your device, see Video Capture Tests.

Run time: approximately 1 hour

Hardware Requirements

The following hardware is required for video capture 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.

  • The device to be tested.

  • If your device has a media storage unit, the unit must contain a medium with at least 50% of the medium filled with sample content. For example, a camcorder with a DV tape unit should have a tape inserted that is at least half-recorded. You could simply set the camera up in an office looking out the window or door and record for half an hour. Some of the video capture tests will play portions of that content repeatedly during testing. None of the content is included in the logo submission.

  • One computer with the following:
    • One x86-based or x64-based processor with a minimum speed of 450 MHz
    • 512 MB of RAM
    • One AGP or PCI display adapter

  • One 17-inch monitor with at least 1024x768x24 bits per pixel (bpp) resolution.

  • One display adapter/driver combination.

  • One keyboard.

  • One mouse (or any pointing or drawing device).

  • One IDE hard disk drive with at least 4 GB space and PIO-4 or DMA capability.

Software Requirements

The following software is required to run the video capture tests:

  • One of the following operating systems:
    • 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 Logo Kit (WLK)

Tester Knowledge Requirements

To run the video capture tests, testers must know how to:

  • Install the video capture device hardware.

  • Install the manufacturer-supplied device driver, if necessary.

  • Install the operating system from the product DVD.

  • Install the WLK.

For a development resource for Video Capture testing, see Microsoft DirectX Software Development Kit (SDK).

This section includes:

Preparing for Video Capture Testing

Running the Video Capture Tests

Troubleshooting Video Capture Testing


Preparing for Video Capture Testing

Before running the video capture 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 Video Capture Testing Overview.

Many of the tests in the Microsoft Windows Logo Kit (WLK) 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.) The WLK now configures the client system so that autologo is enabled. However, if the test is being run outside of the WLK, you may need to 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 How to turn on automatic logon in Windows XP.

Test System Configuration

To configure the test system for video capture testing, do the following:

  1. Install the appropriate Microsoft Windows operating system on the test system.

  2. Install the hardware to be tested on the test system.

  3. Install the manufacturer-supplied device driver, if necessary, on the test system.

  4. Check that the video capture device functions properly on the test system.

  5. If appropriate, enable autologon functionality.

  6. Set up DTM.


Running the Video Capture Tests

To run the video capture logo tests and create a submission cabinet file (.cab) to send to the Microsoft Windows Hardware Quality Labs (WHQL) for logo approval, do one of the following:

Run the logo tests from a previously saved Device Job Schedule file

  1. Open DTM Studio.

  2. On the Explorers menu, click Device Console. (You can also switch to the Device Console window by clicking the Device Console tab in the lower left corner of DTM Studio.)

  3. From the list at the upper left corner of the Device Console window, select your DTM controller.

  4. At the bottom of the Device Console window, click the Load button.

  5. Select a Device Job Schedule file that you previously saved.

  6. In the list at the bottom of the Device Console window, select the displayed logo tests.

  7. Click the Add Selected button.

  8. Click the Schedule button.

Use the Create New Submission wizard to select and run logo tests

  1. Open DTM Studio.

  2. On the Explorers menu, click Device Console. (You can also switch to the Device Console window by clicking the Device Console tab in the lower left corner of DTM Studio.)

  3. In the list in the upper left corner of the Device Console window, select your DTM controller.

  4. In the View By frame, select the Submission option.

  5. In the Submission list on the right-side of the Device Console window, click <New Submission>, and follow the instructions in the Create New Submission wizard that appears.

  6. Do the following to choose the 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. Click Device Submission, select Streaming Media and Broadcast > Video Capture logo program, and then click Next.
    4. Select a Qualification Level, and then click Next.
    5. Enter a name for the submission, select the machine pool that contains the machines to use for the submission, and then click Next.
    6. If the device has its own drivers, enter the location in the Driver Install File area, and then click Finish.

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

  8. Do the following to select and schedule logo tests:
    1. In the list at the bottom of the Device Console window, select the displayed logo tests.
    2. Click the Add Selected button.
    3. Click the Schedule button.
  9. Do the following to monitor logo test progress:
    1. Observe logo test progress by using Job Monitor, and manually intervene if the test requires in. You can refresh the logo tests status in the Device Console window by pressing F5 or by clicking Refresh on the View menu.
    2. Examine the results of a job in 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.

The following tests should show up in the Available Job pane of Device Console:

  • Blink Video Capture Fidelity Test (Standard) (MANUAL)

  • Audio or Video Capture and Control (Blink)

  • Pressure Security Test (Standard)

  • UVC Logo Test


Troubleshooting Video Capture Testing

Some camcorders will automatically enter a low-power state if they are not in active use. Ensure that your device is running when you start the tests.


Streaming Media and Broadcast Receiver Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


Audio or Video Capture and Control (Blink)

Type: Automated Test

Overview

The Blink test is a test for multimedia video capture devices and IEEE AV/C protocol video capture devices.

Details

Video capture devices are cameras and audio/video (A/V) input devices that bring streaming multimedia data into a computer. These devices provides the video in a format that the Microsoft Windows operating system and its client applications can use.

Video capture devices come in two physical 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 the Device Manager utility, you will see each device show up under a different class (even though they are both video capture devices).

Cameras can be categorized as either still image or streaming image devices. Still image cameras are designed to capture single frames at a high resolution for use, and streaming image video capture cameras are designed to capture a series of frames that are 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 that are attached (that is, tethered) to a computer with an IEEE 1394 or USB cable that provides both power and input/output (I/O). Some USB webcams include batteries and simple onboard storage for still pictures so that they can function independently.

Camcorders are fully functional if they are attached to a computer or if they are not. Camcorders have sophisticated on-board storage for recording streaming audio and video. Tape is the usual storage medium, but a few devices record to a writeable DVD. Camcorders are audio and video capture devices. DV and MPEG2 are the most common streaming media that are supported.

This test includes the functionality of the deprecated AV/C Tape Subunit Compliance Test (MSTapeTst.exe). This tests IEEE 1394 AV/C devices for spec compliance. See the IEEE 1394 Trade Association's Web site for details.

There are two types of video capture devices that have separate logo programs:

  • Cameras that are designed for single frame image capture.

  • Broadcast Receivers (also called TV Tuners) are hardware and software that bring broadcast signals (through a cable, a satellite, or over the air) into a computer . Broadcast audio/video options includes FM radio, analog television tuners (NTSC, PAL, or SECAM), and digital television tuners (ARIB, ATSC, DVB, and DSS).

When the Blink test starts, it automatically enumerates all devices that are audio/video capture devices by using the Microsoft DirectShow API. DirectShow is the Windows Multimedia API and its use is required for the logo program.

Run Time: 15 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running Audio or Video Capture and Control (Blink)

You must install the video capture device on the test system and it must be enumerated before you install the Windows Driver Kit (WDK).

If the device has a recording medium (such as a tape, disk, or memory card), you must load the medium in the device.

Note Some camcorders will go into a power-save mode or turn themselves off when they are not used. You must ensure that the device is turned on before you run the Blink test.

The test log will provide details on any failures, including if the computer stops responding (that is, "hangs" or "crashes").

Command Syntax

Command option | Description
blink.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .pro file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to test.
BlinkStandard.pro | The profile file (.pro) of the test cases to run.

Code Tour

File Manifest

File | Location
blink.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\avcore\vidcap\external\

Test Assertions

STREAM-0003 Streaming Media device supports multiple client applications using a single device
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 can support multiple clients at once, with only one client actively using the device at a time and the other clients merely acquiring the device.
STREAM-0006 Streaming media device support is based on DirectShow architecture
Windows Logo Program: STREAM-0006 Streaming media device supports multiple client applications by using a single device
Additional Information: Support for streaming media devices must be based on DirectShow. You can use substitute components instead of DirectShow components that are provided with the operating system. Substitute components must include equivalent functionality that is based on the components that are provided with the operating system and must support at least the same inputs and outputs that are defined for DirectShow.
Windows Logo Program: STREAM-0004 Streaming media device supports multiple client applications by using a single device
Additional Information: Streaming Media devices must be able to control multiple instances of the device with multiple application usage. An example would be a computer with three identical USB webcams, each being used by a different application. A second example would be a computer with two TV receivers, each being independently used by two different applications.

Windows Logo Program: STREAM-0008 Streaming media device supports multiple client applications by using a single device
Additional Information: Devices that are designed to comply with the USB Video Class specifications must work with the USB video class driver. These devices also must comply with the requirements that are set in 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 camera complies with USB Video Class specifications
Windows Logo Program: STREAM-0053 Streaming media device supports multiple client applications by using a single device
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 that are 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.


DVD Annex - Audio Test

Overview

This test verifies that a DVD decoder supports audio.

Details

The DVD Annex - Audio test suite includes tests for the following 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.

  • Running 5.1 Channel test

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

Running DVD Annex - Audio Test

To run this test manually, insert Test Annex v3 disc 1 in the DVD drive and run the test executable.

Command Syntax

Command option | Description
DVDAnnex.exe audio | Starts the test application for the audio profile.

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
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
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

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
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
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


DVD Annex - Decode Test

Overview

The DVD Annex - Decode test verifies the following DVD decode-related functionality:

  • X Parade

  • Clock 60 Hz

  • 24fps Film

  • 60 Hz Video

  • 7.95 Mb

  • Highest

  • Cycling Bit Rate

  • V-bench

  • Half Horizontal

  • Jazz Montage

Details

The test cases in this test verify a DVD decoder's ability to successfully perform its basic function, video playback. Although you should 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, you cannot visually discern whether the device that you are testing is delivering smooth motion. Sometimes, you can easily identify a skipped picture, but you should also 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, the system has a problem just like 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. To help train your eye, consider watching these sequences on a TV and learning how they look normally.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

Running DVD Annex - Decode Test

To run this test manually, insert Test Annex v3 Disc 1 in the DVD drive.

Command Syntax

Command option | Description
DVDAnnex.exe decode | Starts the test application for the decode profile.

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
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
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
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
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
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
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
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
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
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


DVD Annex - Graphics & Menu Support Test

Overview

This test examines the ability of a DVD decoder to decode menus and handle subpicture.

Details

The DVD Annex - Graphics & Menu Support test examines DVD decoder performance for consistent implementation of freeze frame.

This test includes the following test cases:

  • Motion Menu - Menu that Ends

  • Motion Menu - Menu that Loops

  • Field/Frame Freeze Weave

  • Field Freeze Bob

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

Running DVD Annex - Graphics & Menu Support Test

To run this test manually, insert Test Annex v3 Disc 1 in the DVD drive.

Command Syntax

Command option | Description
DVDAnnex.exe graphics | Starts the test application for the graphics profile.

Test Assertions

6.19.17DVD 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
6.19.18DVD 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
6.19.19DVD 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
6.19.20DVD 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
6.19.21DVD 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


DVD Annex - NTSC Playback Test

Overview

The DVD Annex - NTSC Playback test verifies that Microsoft DirectShow application programming interface (API) handling is correct and that quality is maintained during DVD playback.

Details

This test verifies DirectShow handling and quality and includes a test case for Line 21 Closed Caption handling.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

Running DVD Annex - NTSC Playback Test

To run this test manually, insert Test Annex v3 Disc 2 NTSC side in the DVD drive.

Command Syntax

Command option | Description
DVDAnnex.exe NTSCPlayback | Starts the test application for the NTSC playback profile.

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
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
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
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
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
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
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
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
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
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
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


DVD Annex - PAL Playback Test

Overview

The DVD Annex - PAL Playback test verifies that Microsoft DirectShow application programming interface (API) handling is correct for PAL and that quality is maintained during DVD playback.

Details

This test verifies DirectShow handling for PAL and quality.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

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
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
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
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
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
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


DVD Annex - Sequence/Branching 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 that are supported by the DVD-Video standard for user-selectable scenarios for interactive source material. These test sequences check navigation and buffer management subsystems and measure the usable throughput of the device that you are testing.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

Running DVD Annex - Sequence/Branching Test

To run this test manually, insert the Test Annex v3 Disc 1 in the DVD drive.

Command Syntax

Command option | Description
DVDAnnex.exe sequence | Starts the test application for the sequence profile.

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

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

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

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


DVD Annex - Subpicture Test

Overview

The DVD Annex - Subpicture test suite verifies the functional specifications for the menu overlay subsystem.

Details

This test suite includes the following tests:

  • The Subpicture Palette (DCS) test checks a range of subpicture palette and alpha assignment values.

  • The Default Palette Color Index test checks three index values on a menu by using the default DVD-Video palette.

  • The Running the Default Palette Color Index test check three index values on a menu by using a custom color palette.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

Running DVD Annex - Subpicture Test

To run this test manually, insert Test Annex v3 Disc 1 in the DVD drive.

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
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
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
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
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

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


DVD Annex - Video Automated Test

Overview

The DVD Annex - Video Automated test suite is designed to verify that the DVD content can match various playback scenarios and match user experience expectations.

Details

This test suite includes the following test case:

  • Excessive Cropping

  • Aspect Ratio

  • Forced Letterbox

Results for the test cases are evaluated automatically. You do not need to interact with the test.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

Running DVD Annex - Video Automated Test

To run this test manually, insert Test Annex v3 Disc 1 in the DVD drive.

Command Syntax

Command option | Description
DVDAnnex.exe | Starts the test application.

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
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
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
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
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


DVD Annex - Video Format Test

Overview

The DVD Annex - Video Format test is designed to verify that DVD content handles different video formats.

Details

This test includes the following test cases:

  • Content defined aspect ratio

  • 16x9 aspect ratio

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

Running DVD Annex - Video Format Test

To run this test manually, insert Test Annex v3 Disc 1 in the DVD drive.

Test Assertions

DVD playback and MPEG 2 decode is Content Defined Aspect Ratio compliant.
Test Assertion GUID: C835DA1A-3FC9-4404-93E2-E964859A9F41
Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components
DVD playback and MPEG 2 decode is 16x9 Aspect Ratio compliant.
Test Assertion GUID: 71F4005D-5EDB-4dfb-BEF7-28F94A674943
Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components


DVD Annex - Video Manual Test

Overview

The DVD Annex - Video Manual test suite is designed to verify that the DVD content can match various playback scenarios and match user experience expectations.

Details

This test suite includes the following test cases:

  • Pan and Scan

  • Film

  • Video

  • Variations/Speed

  • Variations/Discontinuity

  • Variations/Mixed Mode

  • Chapter Breaks

Results from the test cases are evaluated manually. User interaction is required.

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 Manual 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 that cover a range of laboratory practices and content types.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

Running DVD Annex - Video Manual Test

To run this test manually, insert Test Annex v3 Disc 1 in the DVD drive.

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
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
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
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
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
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
DVD playback and MPEG 2 decode is Mixed Mode: Alternate X (USER) compliant
Test Assertion GUID: 9605843A-F59F-4c9b-BE8F-F57E1E19FD95
Windows Logo Program: DVD Playback is interoperable with DirectShow components
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


MPEG-2 Decoder Test - WHQL Check

Overview

The MPEG-2 Decoder Test - WHQL Check (Configuration Validation) test verifies the Microsoft DirectDraw, Microsoft DirectShow, and Microsoft DirectSound capabilities of the system configuration. It ensures that the system is capable of playing back DVDs and verifies that the decoder is ready to work on Windows.

Details

N/A

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows Server 2003

  • Windows XP

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Test Assertions

DVD Diagnostics
Test Assertion GUID: 90F84901-B9DB-4190-A351-94826615C98C
Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components
System Information
Test Assertion GUID: 3E1CDFCD-FD70-474a-97EF-B530C117288B
Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components
DSound Information
Test Assertion GUID: 3048BE56-0CCC-472b-9E96-448E89578982
Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components
Waveout Information
Test Assertion GUID: 1F441DB3-0A91-4110-8790-464ACB10DE00
Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components
Decoder Information
Test Assertion GUID: 5CCA9B56-9FC1-4c21-94CB-B13EFC6D1FE4
Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components
VMR Compatibility
Test Assertion GUID: 33272DE2-6EBB-4394-901E-697ECEF52AE7
Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components
Is ASPI32 Enabled
Test Assertion GUID: D57E0201-020E-4533-B694-65D80C05BB8D
Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components
SCManager ASPI32
Test Assertion GUID: 2F3A0888-59E7-4b01-85CD-BE8514148A26
Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components


Pressure Streaming Device test

Type: Automated Test

Overview

The Pressure Streaming Device test checks the streaming device and driver implementation. Some test cases check for correct error handling by devices and their drivers. If the devices or drivers incorrectly handle these test cases, the computer might stop responding (that is, "hang" or "crash").

Details

The PressureTest is a quality assurance test for multimedia device drivers.

When the test starts, it automatically enumerates all devices with one of the following KSCATEGORY values, which are defined in the KSMEDIA.H header file in the Microsoft Windows Driver Kit (WDK):

  • KSCATEGORY_CAPTURE

The test then enumerates the devices that are found in each category.

The following example shows a subset of the enumeration display, with device "Friendly Name" preceding the internal device name.

Class KSCATEGORY_CAPTURE

Device #29 [TestCap Capture]: \\?\root#media#0000#{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, as it finds applicable devices. To open the Device Selection dialog box, on the Options menu, click Select Devices (or press CTRL+D). You can select none, one, some, or all devices.

All selected test cases are run sequentially against the first device that is 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 attempt to verify the driver's ability to survive when it is sent malformed and invalid data. Drivers that fail this testing will typically cause the computer to stop responding (that is, either crash or hang--hanging is rare, but it does occur).

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 result is considered a driver FAIL.

Run Time: 15 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running Pressure Streaming Device test

Install your device and driver and have them running before you start this test.

The test log will provide details about 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 test application and runs the test cases that are specified in the profile file (.pro).
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to test.
pressurestandard.pro | The profile file (.pro) of the test cases to run.

Code Tour

File Manifest

File | Location
pressuretest.exe | [testbinroot]\nttest\multimediatest\avcore\vidcap\external\

Test Assertions

GRAPHICS-0053 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: A display adapter or chipset with integrated tuner or video capture devices that are using WDDM drivers must expose their functionality through the WDDM capture infrastructure.
STREAM-0001 Streaming media device driver is based on AVStream class and WDM
Windows Logo Program: STREAM-0001 Display device exposes integrated tuner functionality through WDDM capture infrastructure
Additional Information: Device drivers for any streaming media device must use the AVStream class Windows Driver model (WDM) device driver model as defined in the WDK. AVStream replaces 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 that are defined in the WDK.
STREAM-0002 Streaming media device handles error conditions without hanging, crashing, or causing a blue screen on the system
Test Assertion GUID: faf0532f-a9f2-4157-8e12-a617b7a8acb5
Windows Logo Program: STREAM-0002 Display device exposes integrated tuner functionality through WDDM capture infrastructure
Additional Information: Error conditions include (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.
STR-0019 UVC-capable device complies with USB Video Class specifications
Test Assertion GUID: 12E86C83-D25A-459E-A499-78690E57D6B6
Windows Logo Program: STREAM-0008 Display device exposes integrated tuner functionality through WDDM capture infrastructure
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 Video Capture device does not expose a preview pin
Test Assertion GUID: 5AFFF2F7-D99A-4DFD-B2E0-E52953B47E2C
Windows Logo Program: STREAM-0052 Display device exposes integrated tuner functionality through WDDM capture infrastructure
Additional Information: Video capture devices must expose a capture pin that can be used to create multiple streams that allow both preview and capture.
Video capture driver implements VideoInfoHeader2
Windows Logo Program: STREAM-0055 Display device exposes integrated tuner functionality through WDDM capture infrastructure
Additional Information: WDM streaming video capture device drivers must implement support for VIDEOINFOHEADER2 to indicate video source information such as interlace format.


Tuner-500 Channel Change Test (Manual)

Type: Manual Test

Overview

The Tuner-500 Channel Changes job verifies that a driver and device can undergo a set of 500 channel changes between two separate channels.

Details

There is a single application called TvWLPTunerTests that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0066

Title: All TV Tuners must support 500 channel changes.

Success: This test will succeed if:

  1. Test can successfully issue channel change requests between at least two different channels for a total of 500 times.

  2. Test will ensure that different frequencies are used for the two channels.

Failure: This test will fail if:

  • Any of the above steps fail

Run Time: 10 Minutes
Log File: TvWLPlog.xml
System Restart Required: No
Supported operating systems for Windows Logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Tuner-500 Channel Change Test

To run this test, do the following:

  1. Insert the tuner card into the machine or connect it through USB.

  2. Run the three Run-First configuration jobs in Driver Test Manager (DTM).

  3. Connect a valid RF signal to the card of the appropriate broadcast format (such as NSTC, SECAM, or ATSC).

  4. Run this test to iterate and test each of the requirements listed earlier.

Command Syntax

Command Option | Description
tvwlptunertests.exe <STREAM-0066> "<Device ID of device you want to test> | Executes tvwlptunertests.exe for the Test Case ID and Device ID as specified.

Code Tour

File Manifest

File | Default Location
TVWLPTunerTests.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPAudioMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPSourceFilter.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPMPeg2Monitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPVBIMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest

Test Assertions

Test Assertion GUID: E5F9503C-E9F8-4A67-9EF3-872A05CE55B3

Windows Logo Program: Windows Logo program


Tuner - Additional Qualifications - All Devices must be able to Record Programs

Type: Automated Test

Overview

The Tuner-Record Programs verifies that the tuner driver and device are able to record various programs.

Details

There is a single application called MCEHost that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0072: All Devices must be able to record programs

Success: This test will succeed if the tuner driver and device can successfully complete the required steps so that we are able to:

  • Verify that a 5 minute recording can be made.

  • Verify that a recording can be scheduled sometime in the future

Failure: This test will fail if any of the above steps fail, or if:

  • The recorded data is corrupt.

  • The recording does not take place.

Run Time: 15 minutes
Log File:TvWLPlog.xml
System Restart Required: No
Supported operating systems for Additional Qualifications Logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in DTM Studio.

Code Tour

File Manifest

File | Default Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: 36DE0938-6A1E-4586-9EA9-0149BDABA1C6


Tuner - Additional Qualifications - All Devices must support Time-Shifted Playback

Type: Automated Test

Overview

The Tuner-Time-Shifted Playback verifies that using the Media Center PVR controls a stream can be played, paused, rewound, fast-forwarded, stopped, and re-set.

Details

There is a single application called MCEHost that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0071: All Devices must support time-shifted playback

Success: This test will succeed if while using the Media Center PVR controls a stream can be:

  • Played

  • Paused

  • Rewound

  • Fast-Forwarded

  • Stopped

  • Re-Set

Failure: This test will fail if any of the above steps fail, or if there are any glitches in the video stream after applying one of the Media Center PVR controls.

Run Time: 15 minutes
Log File:TvWLPlog.xml
System Restart Required: No
Supported operating systems for Additional Qualifications Logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in DTM Studio.

Code Tour

File Manifest

File | Default Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: 76D9C598-2ECA-41FD-B2CE-E42745F999E7


Tuner - Additional Qualifications - All Scheduled Recordings must wake up a device

Type: Automated Test

Overview

This test verifies that all scheduled recordings must wake up the tuner device when the scheduled recordings are set to begin recording.

Details

There is a single application called MCEHost that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0076: All scheduled recording must wake up a Device

Success: This test will succeed if the tuner driver and device are able to do all the following:

  1. Wake up when a scheduled recording is set to take place in the future and the machine is in a sleep state.

  2. Schedule a 5 minute recording for 10 minutes into the future

  3. Send the machine into a S1-S3 state.

  4. 11 minutes later, verify that the machine woke up and recorded the 5 minute show.

Failure: This test will fail if:

  1. Any of the above steps fail.

  2. The tuner driver and device are not able to successfully wake the machine up from a hibernate and a sleep state when it is time to begin the recording.

  3. The recording does not start and finish without error.

  4. The completed recording is not able to be played back in Media Center

Run Time: 15 minutes
Log File:TvWLPlog.xml
System Restart Required: No
Supported operating systems for Additional Qualifications Logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in DTM Studio.

Code Tour

File Manifest

File | Default Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: EFA6DEFC-9092-4499-A5D1-BE3F55FAB791


Tuner - Additional Qualifications - All TV Tuners must be able to scan for services multiple times

Type: Automated Test

Overview

Verifies that the tuner device can scan for services multiple times and is able to detect all of the channels listed in the Channel Library XML file during each scan.

Details

Windows Media Center scans for services. The test succeeds if three scans successfully detect the configured channels.

This test verifies the following requirements:

STREAM-0062: All TV Tuners must be able to scan for services multiple times

Success: This test succeeds if all of the following actions are performed:

  1. Windows Media Center deletes any existing services.
  2. Use tuner to scan for services.
  3. Verify that all of the services listed in the Channel Library XML file were located during the scan.
  4. Repeat steps 1 through 3 three times total.

Failure: This test will fail if:

  • Total number of services in the Channel Library XML file is less than 1.
  • Any of the steps above fail.

Run Time: 15 minutes
Log File:TvWLPlog.xml
System Restart Required: No
Supported operating systems for Additional Qualifications Logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in DTM Studio

Code Tour

File Manifest

File | Default Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: 16419C3B-95EA-4E48-8D1D-C8A27B06202B


Tuner - Additional Qualifications - All TV Tuners must resume from hibernation multiple times

Type: Automated Test

Overview

The Tuner-Resume from standby and hibernation test verifies that the driver and device are able to function successfully by streaming Live TV after resuming.

Details

There is a single application called MCEHost that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0061

Title: All TV Tuners must resume from standby and hibernation multiple times

Success: This test will succeed if the test is able to successfully:

  • Start playing Live TV

  • Send the machine into S3 sleep state (must cover both hibernation and sleep)

  • Wake the machine

  • Verify Live TV is still streaming

  • Run the above loop a total of 10 times

Failure: This test will fail if:

  • Any of the above steps fail.

Run Time: 15 minutes
Log File:TvWLPlog.xml
System Restart Required: No
Supported operating systems for Additional Qualifications Logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in DTM Studio.

Code Tour

File Manifest

File | Default Location
Contents of the default location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: 548D45FD-6517-4081-A8FD-B4195897C0DA


Tuner - Additional Qualifications - Devices with multiple TV Tuners must support simultaneous use of all the Tuners

Type: Automated Test

Overview

This test verifies that devices with multiple TV Tuners must support simultaneous use of all of the tuners.

Details

There is a single application called MCEHost that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0068: Devices with multiple TV Tuners must support simultaneous use of all the tuners

Success: This test will succeed if it is able to do the following:

  1. Verify that a tuner capable of simultaneous recordings is present on the system and is currently configured by Media Center.

  2. Verify that you can schedule two recordings on separate channels.

  3. Begin and complete the recordings.

Failure: This test will fail if any of the above steps fail, or if any of the following occur:

  • No tuners can be configured in Media Center.

  • Two recordings cannot be scheduled simultaneously, where one of the recordings is of the broadcast standard being tested.

  • Any of the recordings fail.

Skip: This test will skip if any of the following occur:

  • A single tuner device is being tested.

  • A hybrid device is being tested.

Discussion: Must be able to record on all streams at once. Channels that are to be used need to be stored in a Channel Library XML file.

Run Time: 10 minutes
Log File:TvWLPlog.xml
System Restart Required: No
Supported operating systems for Additional Qualifications Logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in DTM Studio.

Code Tour

File Manifest

File | Default Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: 77C13DA3-3767-40A1-862C-6BAFB9E89179


Tuner - Additional Qualifications - Digital TV Tuners are required to support Protected Broadcast Driver Architecture (PBDA)

Type: Manual Test

Overview

This test verifies that the tuner driver is able to be set up in Media Center for any digital broadcast type that it supports PBDA as well as stream Live TV.

Details

There is a single application called MCEHost that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0060: Digital TV Tuners are required to support Protected Broadcast Driver Architecture (PBDA)

Success: This test will succeed if the tuner driver and device are able to complete First Run and then stream (play) Live TV from a protected stream within Media Center.

  • Complete First Run for any and all supported digital broadcast types of the PBDA device.

  • Stream (play) Live TV using a protected stream within Media Center.

  • Confirm Content Protection is present

  • Verify DRM implementation within the driver

Failure: This test will fail if:

  • The device is not able to complete First Run.

  • The device is not able to stream (play) Live TV using a protected stream within Media Center.

  • The stream used is not protected

  • DRM capabilities are not implemented within the driver

Skip: This test will skip if:

  • The user indicates that this PBDA device does not support protected content

Run Time: 10 minutes
Log File: TvWLPLog.xml
System Restart Required: No
Supported operating systems for Windows Logo testing:

  • Windows 7

Requirements

Software Requirements

  • Software components included with the device under test (DUT).

  • Tuner Driver

  • Test computer running a supported Windows operating system (see above for list)

Minimum Hardware Requirements

Test computer that meets the following minimum requirements:

  • Device to be tested

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in the DTM.

Code Tour

File Manifest

File | Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: B8D5DCB1-05CA-4057-8F88-FFEDBDC1F46B


Tuner - Additional Qualifications - Digital TV Tuners must support Surprise Removal of CAS Smartcard

Type: Manual Test

Overview

The Tuner-Surprise Removal of CAS smartcard test verifies that Digital TV Tuners support surprise removal of CAS smartcard.

Details

There is a single application called MCEHost that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0067: Digital TV Tuners must support surprise removal of CAS smartcard

Success: This test will succeed if all of the following succeed:

  1. Start live TV through Media Center

  2. Verify that CAS card is in place through PBDA API

  3. Send MsgBox asking user to remove CAS card.

  4. Verify that no processes have crashed.

  5. Ask user to re-insert CAS card.

  6. Verify that live TV can be re-started.

Failure: This test will fail if any of the above steps fail.

Run Time: 10 minutes
Log File:TvWLPlog.xml
System Restart Required: No
Supported operating systems for Additional Qualifications Logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in DTM Studio.

Code Tour

File Manifest

File | Default Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: 421A6538-37FB-4889-A179-D740A7A946CC


Tuner - Additional Qualifications - First Run and Live TV in Media Center

Type: Automated Test

Overview

The Tuner-First Run and Live TV verifies that the tuner driver is able to be set up in Media Center for any broadcast type that it supports as well as stream Live TV.

Details

There is a single application called MCEHost that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0074: All Devices must complete First Run and play LiveTV within Media Center

Success: This test will succeed if the tuner driver and device are able to do all of the following:

  1. Complete First Run and then stream (play) Live TV from within Media Center.

  2. Complete First Run for any and all supported broadcast types of the device.

  3. Stream (play) Live TV for any and all supported broadcast types of the device.

Failure: This test will fail if:

  1. The device is not able to complete First Run for a supported broadcast type of the device.

  2. The device is not able to stream (play) Live TV for a supported broadcast type of the device.

Run Time: 15 minutes
Log File:TvWLPlog.xml
System Restart Required: No
Supported operating systems for Additional Qualifications Logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in DTM Studio.

Code Tour

File Manifest

File | Default Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: 9F97C5FF-924B-4518-A47B-7CA44CB61A43


Tuner - Additional Qualifications - Hybrid or Combo Implementation Test Suite

Type: Automated test

Overview

The device must correctly declare the relationships (combo or hybrid) among all of its tuner instances.

Details

Windows Media Center is used to configure all tuners. The combo and/or hybrid relationships of the tuner instances are then tested. The test succeeds if the declared relationships are validated.

This test verifies the following requirements:

STREAM-0091: Hybrid or Combo Implementation Test Suite

Success: This test succeeds if the criteria below are met for each configured tuner instance on the submitted device:

  • Any hybrid tuner instances cannot be used in parallel.

  • Any combo tuner instances can be used in parallel.

  • All independent tuner instances can be used in parallel.

  • On each successful tune request, the tuner instance streams data.

  • Run the tests above a total of two times.

Failure: This test fails if:

  • Any of the above steps fail.

Run time: 1 minute
Log file: STREAM-0091_AQTest_HybridComboImplementationTestSuite_VerifyAllTuners.wtl
System restart required: No
Supported operating systems for additional qualifications logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1-GHz processor

  • 1 GB of system RAM

  • 40 GB free disk space

  • Audio support

  • Windows keyboard

  • Two-button pointing device

  • Minimum graphics card and display support:
    • DirectX 9 support
    • Supported Windows Display Driver Model (WDDM) driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in Driver Test Manager (DTM) Studio.

Code Tour

File Manifest

File | Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: 56F07ADC-C4D7-4928-BC3A-E0FA3B3A388D


Tuner - Additional Qualifications - ISDB-Tuners must support BML

Type: Automated Test

Overview

This test must support BML verifies that BML data is being passed through the tuner driver.

Details

There is a single application called MCEHost that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0063: ISDB-T Tuners must support BML

Success: This test will succeed if the driver and device can successfully:

  • Pass BML data to Media Center

Failure: This test will fail if the above fails.

Run Time: 10 minutes
Log File: TvWLPlog.xml
System Restart Required: No
Supported operating systems for Additional Qualifications Logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in DTM Studio.

Code Tour

File Manifest

File | Default Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: FC93F29D-0968-429F-AB55-09BABB4F06C1


Tuner - Additional Qualifications - PBDA devices need to author extensibility pages according to the Windows Media Center guidelines

Type: Manual Test

Overview

This test provides information for Windows Media Center Customized Product Requirements. Specific information is available at the following link:

Windows Media Center Customized Product Requirements

Details

This section describes the requirements details.

Tuner

See the information available at the following link:

Windows Media Center Customized Product Requirements

Run Time: Various
Log File: N/A
System Restart Required: No
Supported operating systems:Windows 7

Requirements

Software Requirements

See the information available at the following link:

Windows Media Center Customized Product Requirements

Hardware Requirements

See the information available at the following link:

Windows Media Center Customized Product Requirements

Processor

See the information available at the following link:

Windows Media Center Customized Product Requirements

Running the Tuner - Additional Qualifications - PBDA devices need to author extensibility pages according to the Windows Media Center guidelines Test

N/A


Tuner - Additional Qualifications - Signal Quality and Signal Lock Test Suite

Type: Automated test

Overview

When requested, all of the digital tuner instances on a physical tuner must be able to calculate and report signal quality and signal lock to Windows Media Center within the required interval.

Details

Windows Media Center is used to configure the tuner. The tuner’s signal reporting is then tested. This test succeeds if signal characteristics are consistently reported.

This test verifies the following requirements:

STREAM-0092: Signal Quality and Signal Lock Test Suite

Success: This test succeeds if the following requirements are satisfied for each configured digital tuner instance on the submitted device with a good quality TV signal:

  • Consistently returns a signal lock.

  • Consistently returns a signal quality value >= 50%.

  • The signal quality values are consistent and in 10% proximity to each other. Out of 100 reported signal quality values on the same TV signal, a maximum of 10% of these values are allowed to vary more than 10% of the average value.

  • Consistently takes less than 250 ms to receive signal statistics.

  • Repeat the steps above for a total of two times.

Failure: This test will fail if:

  • Any of the above steps fail.

Run time: 1 minute
Log file: STREAM-0092_AQTest_SignalQualitySignalLockTestSuite_AllTuners.wtl
System restart required: No
Supported operating systems for additional qualifications logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1-GHz processor

  • 1 GB of system RAM

  • 40 GB free disk space

  • Audio support

  • Windows keyboard

  • Two-button pointing device

  • Minimum graphics card and display support:
    • DirectX 9 support
    • Supported Windows Display Driver Model (WDDM) driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Schedule the test in Device Test Manager (DTM) Studio.

Code Tour

File Manifest

File | Location
Contents of the Default Location | [%Program Files%]\Microsoft Driver Test Manager\Tests\<architecture>\nttest\multimediatest\ehome\Tools

Test Assertions

GUID: E623A786-941C-4486-A8C5-E4DB9AD38EA8


Tuner-Analog Tests

Type: Manual Tests

Overview

The Tuner-Broadcast Region Audio Test verifies that analog TV tuners implement stereo audio decoding for their intended broadcast region. Analog TV tuners must include stereo audio decoding. If SAP is available in the device's intended market, it must also be implemented.

Details

This test verifies the following requirements:

  • STREAM-0010

  • STREAM-0013

  • STREAM-0024

  • STREAM-0028

  • STREAM-0029

  • STREAM-0056

STREAM-0010

Note This requirement only applies to analog tuners.

The Tuner-Audio Video Capture Test (TvWLPTunerTests) verifies that both audio and video capture must occur on the same physical device, with tightly synchronized audio/video (A/V) elementary streams--less than 100ms phase skew (which determines audio and video synchronization, failure of which causes lip-synch issues); multiple small host capture buffers (a minimum of 64 buffers and a maximum of 32 KB per buffer); and low interrupt rates (less than 500 per second).

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 that is 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 The Video and Audio can be on the same pin.

Failure: This test will fail if any of the preceding steps fail.

STREAM-0013

The Tuner-Driver Uniquely Identifies its Mediums Test verifies that, for dual tuner support, tuner drivers instance the tuner's mediums. Each device instance must specify a unique ID that is independent of the medium. The GUID remains the same across device and operating system instances and reinstalls. However, the ID field of the medium structure must differ between device instances. You can create this difference by using a global counter inside the driver and acquiring an ID for a device instance at Plug and Play (PnP) start time through a safe increment on this counter as long as it persists across device instances.

STREAM-0013: Test Tuner Driver Uniquely Identifies Tuner and Its Mediums

Success: This test will succeed if all of 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 can 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.

    Note A single pin can match the video and audio mediums in both steps 3 and 4.

  • The test can 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 A single pin can match the video and audio mediums in both steps 3 and 4

  • The test can locate at least one TvAudio filter and crossbar filter 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 preceding steps fail.

Title: Test Dual Tuner Supports Additional Requirements

Success

This test will succeed if all of the following steps succeed:

  1. The test does not find multiple analog or digital tuner instances of the same type and hardware ID (the hardware ID is not PnpId or DeviceInstanceId).

  2. The test finds multiple analog or digital tuner instances of the same type and hardware ID.

  3. The tuner's UniqueID from the IGetCapabilitiesKey interface is unique from other devices on the system.

  4. The tuner's video and audio mediums are not NULL and have different values.

  5. 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.

  6. 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 if there are multiple analog or digital tuner instances of the same type and hardware ID and if any of the following fail:

  1. The specified tuner's UniqueID from the IGetCapabilitiesKey interface is not unique from other devices on the system.

  2. The tuner's video and audio mediums are NULL or have the same values.

  3. 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.

  4. 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-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 or Broadcast Region requires it, the secondary audio channel.

Failure: This test will fail if:

  • The analog tuner graph does not successfully build (that is, the graph is not run).

  • The analog tuner's audio decoding does not support: stereo; the main audio channel; and if the Country Code or Broadcast Region requires it, the secondary audio channel.

STREAM-0028: Test NTSC Tuner for Content Protection

The Tuner-Content Protection Test verifies that an NTSC TV tuner supports content protection.

NTSC TV tuners must comply with the following requirements:

  • Pass line 20 VBI data that contains CGMS-A, as specified by IEC 61880, to Media Center.

  • Pass line 21 VBI data that contains CGMS-A, as specified by EIA-608-B, to Media Center.

Success: This test will succeed if the NTSC tuner's VBI stream from the NTSC tuner contains Macrovision/APS and CGMS content protection bits.

Failure: This test will fail if:

  • The NTSC tuner graph does not successfully build and run.

  • The NTSC tuner's VBI stream from the NTSC tuner does not contain Macrovision/APS and CGMS content protection bits

STREAM-0029: Premium Analog TV tuners must support raw VBI pass through

Premium Analog TV tuners must support raw VBI pass through of the following lines:

  • Lines 10 through 21 (and 322 through 333) for NTSC, and lines 7 through 23 (and 320 through 335) for PAL/SECAM, must be captured as part of the VBI stream.

  • In PAL/SECAM, line 23 can appear as a black video line for the visible video signal to prevent any changes to the video image area.

  • The tuner must output all captured VBI lines in raw form on the capture filter with a separate capture pin.

There is a single application called TvWLPTunerTests that iterates through all of the requirements for this job. Any failures will fail the entire job.

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.

  • Any of the above specified NTSC or PAL VBI characteristics fail.

Premium Analog TV tuners must support raw VBI pass through of all lines that are listed below: and support the capture of the following data formats:

Lines 10 through 21 (and 322 through 333) for NTSC and lines 7 through 23 (and 320 through 335) for PAL/SECAM must be captured as part of the VBI stream. In PAL/SECAM, line 23 can appear as a black video line for the visible video signal to prevent any changes to the video image area.

The tuner must output all captured VBI lines in raw form on the capture filter with a separate capture pin.

Raw VBI data must be captured at a true sampling rate of 27 or 28.63 MHz (8 x Fsc for NTSC). Artificial oversampling from a lesser sampling rate is not allowed. The resulting samples must comply with the timing requirements in the EIA-608-B and BT.653 specifications for closed captioning and teletext, respectively. The captured data must cover the entire data line (including clock run-in) along with a suitable margin of extra samples on both sides.

All VBI samples must be supplied in undecoded, luma-only format (1400 to 2000 luma samples/VBI line) including all scan lines that might contain encoded data signals on each video field. To ensure accurate data reception, data transmitted on all lines of the VBI must be oversampled exactly 4.7 or 5 times the North American Basic Teletext (NABTS) data bit rate (or locale-specific data bit rate).

For example, if 288 bits of NABTS data on a scan line, approximately 1,354 one-byte samples, plus the necessary margin, must be captured per scan line if 4.7x oversampling is used. This count would be 1,440 one-byte samples if 5x oversampling were used. This number represents the number that are required for timing tolerances in the NABTS specification and also for timing uncertainties within the capture hardware. If the hardware cannot provide 4.7 or 5 times oversampled VBI data, the device-specific driver must compensate by resampling, so that 4.7 or 5 times oversampled data are presented to the operating system

STREAM-0056 Title: Analog TV Tuners Must Support Exhaustive Scanning APIs in PAL and SECAM Regions

The Tuner-Exhaustive Scanning Test verifies that an Analog TV tuner supports Exhaustive Scanning APIs in PAL and SECAM regions. A TV tuner that is designed for analog tuning in PAL and SECAM regions must implement the Scanning DDI by supporting the exhaustive scanning properties that are defined in KSMedia.h. These new interfaces provide support for both hardware and software driven scanning, with hardware scanning being the preferred solution.

Success: This test will succeed if all of the following steps succeed:

  • Build a PAL analog filter graph with the tuner.

  • Locate the IScanningTunerEx interface.

  • Query the number of standards that are supported.

  • For each standard supported, query the Broadcast GUID, settling time, and tvStandardsSupported.

  • Set default values by using SetScanSignalTypeFilter().

  • Begin PerformExhaustiveScan().

  • Get the estimated scan duration from QueryTunerStatus(). The estimated scan duration must be from 5 seconds through 3 minutes.

  • Wait for the 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 the exhaustive scan to successfully complete.

  • Check that the scan reached the requested higher frequency.

Failure: This test will fail if any of the preceding steps fail.

Run Time: 5 minutes
Log File: TvWLPLog.xml
System Restart Required: No
Supported operating systems for Windows Logo testing:

  • Windows Vista

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Test computer that meets the following minimum requirements:
    • 1 GHz processor
    • 1 GB of system RAM
    • 40 GB free hard drive space
    • Audio support
    • Windows keyboard
    • Two button pointing device
  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support
    • Input Video sources per supported broadcast type (PAL, NTSC, ATSC, DVB-T, ...)
    • For Analog Tuners, a source of Macrovision/APS for the broadcast type (PAL, SECAM, NTSC)
    • For Analog NTSC Tuners, a source of CMGS-A embedded in the VBI data.

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Tuner-Analog Tests

To run the tuner analog tests, do the following:

  1. Insert the tuner card into the machine or connect it through USB.

  2. Run the three Run-First configuration jobs for Driver Test Manager (DTM).

  3. Connect a valid RF signal to the card of the appropriate broadcast format (such as NSTC, SECAM, or ATSC).

  4. Run this test to iterate and test each of the requirements listed earlier.

Command Syntax

Command option | Description
tvwlptunertests.exe STREAM-0023 "<Device ID of device you want to test>" | Executes tvwlptunertests.exe for the Test Case ID and Device ID as specified.

Code Tour

File Manifest

File | Default Location
TVWLPTunerTests.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPAudioMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPSourceFilter.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPMPeg2Monitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPVBIMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest

Test Assertions

Test Assertion GUID: FE800C70-BCA6-4021-827F-69033338266C

Windows Logo Program: Windows Logo program


Tuner-Automated Graph Building Test

Type: Manual Test

Overview

STREAM-0057: The Tuner-Automated Graph Building Test verifies that a TV tuner that supports Media Center functionality implements automated capture graph building with Media Center video control.

Details

This test verifies the following requirements:

  • STREAM-0012

  • STREAM-0057

STREAM-0057: Test Tuner Video Control Graph Building

Success

This test will succeed if the Microsoft Video Control ActiveX object can be used to:

  • Build, run, and stop Microsoft DirectShow graphs by using the analog or digital Tuner instances of the specified Tuner device.

  • (For each of the filter graphs that contain a distinct Tuner instance (FM, TV Analog, BDA, and so on) of the specified Tuner device, while the first graph is still built) Build, run, and stop a second analog or digital tuner graph by using a second Tuner instance of the same type and Tuner device.

A TV tuner capture card that supports Media Center functionality must support automated capture graph building with Media Center video control (VidControl). That is, the Microsoft Video Control must be able to:

  • Enumerate available tuners by finding the correct registry entry.

  • For digital tuners, build a capture graph that connects the Microsoft Network provider to the Tuner Source Filter and Tuner Capture Filter.

    For analog tuners, build a segmented graph that includes the necessary crossbars, encoder, mux, and demux.

  • Where necessary, make VBI pin connections for RAW or sliced VBI.

  • Transition the graph to run state and tune to a channel to view content.

Failure: This test will fail if any of the preceding steps fail.

Run Time: 5 minutes
Log File: TvWLPLog.xml
System Restart Required: No
Supported operating systems for Windows Logo testing:

  • Windows Vista

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support
    • Input Video sources per supported broadcast type (PAL, NTSC, ATSC, DVB-T)
    • For Analog Tuners, a source of Macrovision/APS for the broadcast type (PAL, SECAM, NTSC)
    • For Analog NTSC Tuners, a source of CMGS-A embedded in the VBI data

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Tuner-Automated Graph Building Test

To run this test, do the following:

  1. Insert the tuner card into the machine or connect it through USB.

  2. Run the three Run First configuration jobs in Driver Test Manager (DTM).

  3. Run this test to iterate through the requirements listed earlier.

Command Syntax

Command option | Description
"tvwlptunertests.exe STREAM-0057 "<Device ID of device you want to test | Executes tvwlptunertests.exe for the Test Case ID and Device ID as specified.

Code Tour

File Manifest

File | Default Location
TVWLPTunerTests.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPAudioMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPSourceFilter.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPMPeg2Monitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPVBIMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest

Test Assertions

Test Assertion GUID: 3371DCBD-3392-476F-8DB6-EB017C95311C

Windows Logo Program: Windows Logo program


Tuner-BDA Test

Type: Automated Test

Overview

The Tuner-BDA Test verifies that:

  • Digital TV tuners use the Broadcast Driver Architecture (BDA), as defined in the "Broadcast Driver Architecture Drivers" section in the Microsoft Windows Driver Kit (WDK) documentation.

  • The Tuner-Signal Quality Diagnostic Test verifies that a Digital TV tuner provides signal strength, signal quality, signal present, and signal lock status diagnostic information through the Broadcast Driver Architecture (BDA) interface KSPROPSETID_BdaSignalStats, as defined in the Microsoft DirectX SDK.

  • Devices and systems in regions with Digital TV standards that BDA does not yet support are exempt from this requirement. Support for BDA is not required. This exemption allows for proprietary Digital TV implementations and is valid until support for the regional Digital TV standard is provided by BDA.

    The relationship of the SignalStrength, SignalQuality, SignalPresent, and SignalLocked parameters is:
    • SignalPresent and SignalLocked are both expected to be TRUE
    • SignalStrength, SignalQuality are both expected to be non-zero

Details

There is a single application called TvWLPTunerTests that iterates through all of the requirements for this job. Any failures will fail the whole job.

  • This test verifies the following:

    STREAM-0021: Test Digital Tuner Uses Broadcast Driver Architecture

    Success: This test will succeed if all of the following steps are successful:
    1. Build a digital filter graph with the tuner.
    2. Tune to the Primary channel in the default tuning space.
    3. Run the graph and wait 3 seconds to let data move through the graph.
    4. Locate the BDA Network Provider Filter.
    5. Query the BDA Network Provider filter for the following interfaces and call various methods on the interfaces:
      • IFrequencyMap
      • IMPEG2_TIF_CONTROL
      • IBDA_NetworkProvider
      • IScanningTuner
      • ITuner
      • IBDA_TIF_REGISTRATION
    6. Locate the BDA Network Tuner Filter.
    7. Query the BDA Network Tuner filter for the following interfaces and call various methods on the interfaces:
      • IBDA_DeviceControl
      • IBDA_SignalStatistics
      • IBDA_FrequencyFilter
      • IBDA_AutoDemodulate
      • IBDA_DigitalDemodulator
      • IBDA_LNBInfo
    8. Locate the optional BDA Demod Filter.
    9. Locate the BDA Capture Filter.

    10. Stop and deconstruct the digital filter graph.

      Failure: This test will fail if any of the preceding steps fail.
Run Time: 5 minutes
Log File: TvWLPLog.xml
System Restart Required: No
Supported operating systems for Windows Logo testing:

  • Windows Vista

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • A two button pointing device

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Tuner-BDA Test

To run the Tuner-BDA Test:

  1. Insert the tuner card into the machine or connect it through USB.

  2. Run the three Run-First configuration jobs in Driver Test Manager (DTM).

  3. Connect a valid RF signal to the card of the appropriate broadcast format (such as NSTC, SECAM, or ATSC).

  4. Run this test to iterate and test each of the requirements listed earlier.

Command Syntax

Command option | Description
tvwlptunertests.exe STREAM-0021 "<Device ID of device you want to test>" | Executes tvwlptunertests.exe for the Test Case ID and Device ID as specified.

Code Tour

File Manifest

File | Default Location
TVWLPTunerTests.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest

Test Assertions

Test Assertion GUID: DBB71945-7DD2-4BC1-B35B-7BFFE7811991

Windows Logo Program: Broadcast Receiver

STREAM-0021 Digital TV tuners use the Broadcast Driver Architecture (BDA)

Additional Information: It is expected that IBDA_SignalStatistics be fully implemented on the Control Node of the BDA Source (Tuner) Filter.


Tuner Channel Change Test (Manual)

Type: Manual Test

Overview

The Tuner Channel Change Test verifies whether a driver and device can undergo a set of channel changes between two separate channels.

Details

A single application called TvWLPTunerTests iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:
STREAM-0015
Title: All TV Tuners must support channel changes.

Success: This test will succeed if the following occur:

  • Test can successfully issue channel change requests between at least two different channels.

  • Test ensures that different frequencies are used for the two channels.

Failure: This test will fail if any of the above fail

Run Time: 10 Minutes
Log File: TvWLPlog.xml
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program: Tvwlptunertests.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Tuner Channel Change Test

To run this test, follow these steps:

  1. Insert the Tuner card into the machine or connect it through USB.

  2. Connect a valid RF signal to the card of the appropriate broadcast format (such as NSTC, SECAM, or ATSC).

  3. Run this test to iterate and test each of the listed requirements.

Command Syntax

Command option | Description
tvwlptunertests.exe <STREAM-0015> "<Device ID of device you want to test> |  | Executes tvwlptunertests.exe for the Test Case ID and Device ID as specified.

Code Tour

File Manifest

File | Default Location
TVWLPTunerTests.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPAudioMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPSourceFilter.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPMPeg2Monitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPVBIMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest

Test Assertions

{362C0D94-1C2F-416b-871B-21967FCCA315}


Tuner-Input Sources Test

Type: Manual Test

Overview

This test verifies that a TV tuner can detect signals from all implemented input sources (such as RF). Sharing connections internally between S-Video and composite auxiliary inputs makes discrete signal detection between these two inputs impossible. The driver must correctly expose the proper mediums and media types that are related to information off the crossbar pins to determine which S-Video or composite jack matches to which S-Video jack.

Details

There is a single application called TvWLPTunerTests that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirement:

STREAM-0016

Title: Test Tuner Detects Signals from All Input Sources

Success: This test will succeed if an input signal is detected on all the input sources.

Failure: This test will fail if:

  • The analog or digital tuner graph does not successfully build and run.

  • A signal is not detected on all of the input sources.

Run Time: 5 minutes

Log File: TvWLPLog.xml

Supported operating systems for Windows Logo testing:

  • Windows Vista

  • Windows 7

Program: Windows Logo

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Tuner-Input Sources Test

This job verifies that the TV tuner works as expected. For this test to work properly, it must be provided a variety of input sources (such as RF) of the broadcast type (such as PAL, NTSC, or ATSC) the card supports.

STREAM-0016 will ask user to connect the RF input to the card to verify correct functionality:

To run the Tuner-Input Sources Test:

  1. Insert the tuner card into the machine or connect it through USB.

  2. Run the three Run-First configuration jobs in Driver Test Manager (DTM).

  3. Connect a valid RF signal to the card of the appropriate broadcast format (such as NSTC, SECAM, or ATSC).

  4. Run this test to iterate and test each of the requirements listed earlier.

Command Syntax

Command option | Description
tvwlptunertests.exe STREAM-0016 "<Device ID of device you want to test>" | Executes tvwlptunertests.exe for the Test Case ID and Device ID as specified.

Code Tour

File Manifest

File | Default Location
TVWLPTunerTests.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPAudioMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPSourceFilter.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPMPeg2Monitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPVBIMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest

Test Assertions

Test Assertion GUID: CA7940CE-D9F8-4058-899C-54F2AAFA265B
Windows Logo Program: Windows Logo program


Tuner - Long Haul Test (Manual)

Type: Manual Test

Overview

This test verifies that the driver and device can successfully continually stream video for a total of 6 hours.

Details

There is a single application called MCEHost that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0065

Title: Tuner - Long Haul Test

Success: This test will succeed if the device can successfully:

  • Start playing video

  • Verify that video is still playing, once every minute, for 6 hours.

Failure: This test will fail if:

  • Any of the above steps fail.

Run Time: 6 Hours, depending upon boot time
Log File: TvWLPlog.xml
System Restart Required: No
Supported operating systems for Windows Logo testing:

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Tuner-Long Haul Test

To run this test, do the following:

  1. Insert the tuner card into the machine or connect it through USB.

  2. Run the three Run-First configuration jobs in Driver Test Manager (DTM).

  3. Connect a valid RF signal to the card of the appropriate broadcast format (such as NSTC, SECAM, or ATSC).

  4. Run this test to iterate and test each of the requirements listed earlier.

Command Syntax

Command Option | Description
tvwlptunertests.exe STREAM-0065 "<Device ID of device you want to test> | Executes tvwlptunertests.exe for the Test Case ID and Device ID as specified.

Code Tour

File Manifest

File | Default Location
TVWLPTunerTests.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPAudioMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPSourceFilter.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPMPeg2Monitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPVBIMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest

Test Assertions

Test Assertion GUID: 5814D816-FA16-4366-AB2F-D35F38C3BE4E

Windows Logo Program: Windows Logo program


Tuner- Reboot Test (Manual)

Type: Manual Test

Overview

This test verifies that a tuner driver and device is able to function after five consecutive reboots of the OS.

Details

There is a single application called TvWLPTunerTests that iterates through all of the requirements for this job. Any failures will fail the entire job.

STREAM-0073: All Devices must function after 5 reboots.

Success: This test will succeed if the tuner driver and device are able to do all of the following:

  1. Build a graph to display live TV

  2. Reboot the machine

Repeat the steps 2-4 a total of 5 times

Failure: This test will fail if any of the above steps fail, or if the tuner driver or device is unable to play Live TV any of the reboots of the OS.

Run Time: 30 minutes
Log File: TvWLPlog.xml
System Restart Required: No
Supported operating systems for Windows Logo testing:

  • Windows 7

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Tuner- Reboot Test

To run this test, do the following:

  1. Insert the tuner card into the machine or connect it through USB.

  2. Run the three Run-First configuration jobs in Driver Test Manager (DTM).

  3. Connect a valid RF signal to the card of the appropriate broadcast format (such as NSTC, SECAM, or ATSC).

  4. Run this test to iterate and test each of the requirements listed earlier.

Command Syntax

Command Option | Description
tvwlptunertests.exe STREAM-0073 "<Device ID of device you want to test> | Executes tvwlptunertests.exe for the Test Case ID and Device ID as specified.

Code Tour

File Manifest

File | Default Location
TVWLPTunerTests.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPAudioMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPSourceFilter.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPMPeg2Monitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPVBIMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest

Test Assertions

Test Assertion GUID: C18594A8-840B-41e3-B0C4-D7EFB028ED94
Windows Logo Program: Windows Logo program


Tuner-Resource Acquisition Test

Type: Manual Test

Overview

This test verifies that all (capture-side) show filters in a TV graph do not acquire any singleton resources while the graph is in pause mode. This requirement allows different graphs serving different functions to be created and cached away without impacting each other. Only when the graph leave the pause state should any limited resource be acquired.

Details

There is a single application called TvWLPTunerTests that iterates through all of the requirements for this job. Any failures will fail the entire job.

This test verifies the following requirements:

STREAM-0014

Title: Tuner - Resource Acquisition Test

Success: This test will succeed if all of the following steps succeed:

  • Build two separate analog or digital tuner graphs by 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 preceding steps fail.

Failure of this test typically means that a filter has acquired a particular singleton hardware resource before being told to enter the acquire state. This failure blocks multiple graphs being left in the stop state, which seriously degrades performance when changing tasks. However, to test this situation, the code creates and run several tuner graphs that acquire a large amount of video memory. We recommended that you turn off Desk Top Compositing before running this test.

Run Time: 5 minutes
Log File: TvWLPLog.xml
System Restart Required: No
Supported operating systems for Windows Logo testing:

  • Windows Vista

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Tuner-Resource Acquisition Test

To run the Tuner-Resource Acquisition Test:

  1. Insert the video cards into the machine or connect through USB.

  2. Run the three Run-First configuration jobs in Driver Test Manager (DTM).

  3. Connect a valid RF signal to the card of the appropriate broadcast format (such as NSTC, SECAM, or ATSC).

  4. Run this test to iterate and test each of the requirements listed earlier.

Command Syntax

Command option | Description
tvwlptunertests.exe STREAM-0014 "<Device ID of device you want to test> | Executes tvwlptunertests.exe for the Test Case ID and Device ID as specified.

Code Tour

File Manifest

File | Default Location
TVWLPTunerTests.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPAudioMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPSourceFilter.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPMPeg2Monitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPVBIMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest

Test Assertions

Test Assertion GUID: E1B3C5E9-E3D9-44D3-BFC4-580C8A5DDC57

Windows Logo Program: Windows Logo program


Tuner-Serial Number Test (Manual)

Type: Manual Test

Overview

This test verifies that a USB TV tuner implements the iSerialNumber field to ensure unique serial numbers across devices of the same model. To reuse the same physical device object (PDO) and to ensure that the device experience is unchanged whether the device is reinserted into the same port or a new port, you must store a serial number on your device. The serial number must be unique for all devices that share the same device installation identifier.

Details

This test verifies the following requirement:

STREAM-0017

Title: Tuner-Serial Number Test (Manual)

Success: This test will succeed if the USB TV tuner is a USB 2.0 compatible tuner. This tuner has the same Plug and Play (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 from the same vendor that a user inserts 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 instructions, such as when the user is asked to insert additional tuner from same vendor.

Skip: This test will skip if the device is not a USB device.

A USB TV tuner must implement USB 2.0 high-speed support.

A USB TV tuner must implement the iSerialNumber field to ensure unique serial numbers across devices of the same model.

Run Time: 5 minutes
Log File: TvWLPLog.xml
System Restart Required: No
Supported operating systems for Windows Logo testing:

  • Windows Vista

  • Windows 7

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

  • Tuner Driver

Hardware Requirements

The test tool requires the following hardware:

  • The device under test

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

  • Minimum Graphics Card and Display Support:
    • DirectX 9 or Greater support
    • Supported WDDM Driver
    • 128 MB of on-board graphics card memory
    • Pixel Shader 2.0 support
    • 32 bits per pixel or greater support

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Tuner-Serial Number Test (Manual)

To run this test, do the following:

  1. Insert the tuner card into the machine or connect it through USB.

  2. Run the three Run-First configuration jobs in Driver Test Manager (DTM).

  3. Connect a valid RF signal to the card of the appropriate broadcast format (such as NSTC, SECAM, or ATSC).

  4. Run this test to iterate and test each of the requirements listed earlier.

Command Syntax

Command option | Description
tvwlptunertests.exe STREAM-0017 "<Device ID of device you want to test> | Executes tvwlptunertests.exe for the Test Case ID and Device ID as specified.

Code Tour

File Manifest

File | Default Location
TVWLPTunerTests.exe | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPAudioMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPSourceFilter.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPMPeg2Monitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest
TVWLPVBIMonitor.ax | ..\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest

Test Assertions

Test Assertion GUID: A150251F-EB54-440a-AEA2-9E7CFDB3C7CB

Windows Logo Program: Windows Logo program


USB Video Class logo test

Type: Automated Test

Overview

The USB Video Class logo test checks that USB bus Video Capture devices are compliant with the USB Video Class specifications from the USB.org standards body. The released spec versions 1.0 and 1.1 are available from USB.org.

Details

The test checks all Video Capture devices on a test system. If the device uses the USB bus, the test gets the device's current USB configuration and checks the descriptors for spec compliance. The test is completely automated and the log will detail any failure cases. The supporting logo requirement is STREAM-0053.
Run Time: Under 3 minutes
Log File: ShellRunner.wtl
System Restart Required: No
Test Category:
Supported operating systems for Windows Logo testing:

  • Windows 7

  • Windows Vista

Program: ShellRunner.exe, UVCLogo.dll

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the USB Video Class logo test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Video Capture devices which are not on a USB bus will produce a SKIP.

Command Syntax

Command option | Description
ShellRunner.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to be tested.
UVCLogoWLK.pro | The .profile file of test cases to be run.

Code Tour

File Manifest

File | Location
ShellRunner.exe | [testbinroot]\nttest\multimediatest\AVCore\VidCap\External\
UVCLogo.dll | [testbinroot]\nttest\multimediatest\AVCore\VidCap\External\
UVCLogoWLK.pro | [testbinroot]\nttest\multimediatest\AVCore\VidCap\External\


Video Fidelity test

Type: Manual test

Overview

The Video Fidelity test provides an automated analysis of a video capture device's fidelity using a reference test chart.

Details

The Video Fidelity is a new optional Test Case for Video Capture devices.

The test verifies video quality by analyzing the captured result using a known source (the reference test chart) under specified conditions. Test charts are available at the following Applied Image Inc Web site.

Refer to the Microsoft Webcam Fidelity test charts, or send them the image below so they can determine your model.

Image of the Video Fidelity test chart

Test Chart

The chart above consists of a spectrally neutral 18% reflectance background interspersed with a regular uniform grid pattern. Markers have been placed denoting common aspect ratios for use with aspect ratio and distortion measurements. In the center of the chart, there are two rows that each consist of 8 patches increasing incrementally in optical density (OD).

This test requires a one-time setup of the following conditions:

  • The camera should be positioned so that entire area of the test chart, including markers, are visible in capture preview.

  • The camera should be placed close enough that the test chart occupies most of the image.

  • The test chart should appear with minimum tilt and distortion.

  • The environment should exclude uncontrolled light sources, such as window light or regular office lights).

  • We recommend placing two ISO-compliant light sources at 45 degrees. These light sources should have controlled light temperature and intensity.

  • The ISO-compliant light sources should be positioned to provide adequate uniform light for the test chart, with minimize glare and reflection.

Each measurement is being done for four light settings:

  • Low-intensity indoor

  • Low-intensity daylight

  • High-intensity daylight

  • High-intensity indoor

Figure of a setup for conducting a Video Fidelity test

When you are finished, the test case can be run repeatedly to assist developer analysis. There is an interactive portion of the test where the tester corrects the aim of the video capture device, before the test is actually launched. When this is done (and the camera is secured), the test can be run repeatedly.

Run Time: The one-time physical setup of the test could require several hours. Running the test itself should take about 5 to15 minutes. There is an interactive portion of the test where the tester corrects the aim of the video capture device, before the test is actually launched. When this is done, the test can be run under 5 minutes.
Log File: BlinkXtra.wtl
System Restart Required: No
Supported operating systems for Windows Logo testing:

  • Windows 7

Program: Blink.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • The manual setup (extensive)

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Video Fidelity test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

This is an OPTIONAL logo test.

Test Execution

Tests are part of Shell98-based Blink application (existing part of Logo kit). To execute tests, follow these steps:

  1. Make sure that you have the appropriate environment, as described above.

  2. Start Blink.

  3. Select Tests (Tests\Select Tests...) ... Webcam Video Fidelity \ (22.0.0) Video Fidelity test.

  4. Run the test (Tests\Run). You will see a dialog box that asks if you have the appropriate conditions.

  5. Click Continue. You will see a live preview window and another dialog box that explains how to properly position the camera.

  6. Calibrate the camera position so that the image appears straight and the least distorted, and the test chart occupies most of the image. Make sure that all markers are visible. Click Continue.

  7. You will see a dialog box asking for certain light settings. Make sure that you have the proper lighting and click OK.

  8. The desktop will turn black for a few seconds while the application makes a snapshot. (This prevents distortions from monitor light.)

  9. The application will repeat step 7 for all four light conditions. Then, the application starts image analysis to recognize markers. Depending on image size and quality, this may take up to 3 minutes. When this is done, you should see the following image. Magenta crosses indicate recognized markers, the green rectangle shows an estimation of the measured area, and yellow squares should lie within grid cells. If markers are not recognized correctly, you can manually modify them: click correspondent "Correct ... marker" to enter editing mode. Or you can adjust the camera positioning. Figure of the results of a Video Fidelity test in the form of a grid with yellow squares in its cells

  10. When the markers are correctly identified, click Markers are correct, continue.

  11. The test application performs its measurements.

  12. Steps 7-11 are repeated for all light conditions.

Measurements

Basic image quality aspects of web cameras can be measured and evaluated. The following parameters are being measured:

  1. Aspect ratio. Aspect ratio is measured as ratio of distances (NW-NE) and (NE-SE). It should be equal to 10/7 = 1.429. Test allows for 5% deviation from this value (i.e. allowed range is [1.353; 1.495])

  2. Geometric distortion. Measured as ratio of (NN-SS) to (NE-SE). It should be equal to 1. Test allows for 3% deviation from this value (i.e. allowed range is [0.97; 1.03]) Image of the Video Fidelity test chart that shows deviations

    Since the test does not estimate position of SS directly, the following calculations are used:

    a. Calculate A = (NE-SE) distance; line L0 goes through NE and SE.
    b. Line L1 goes through NW and NE.
    c. line L2 is parallel to L0 and goes through NN.
    d. Estimation of (NN-SS) is A + 2 * S * P, where P is distance from NN to intersection of L1 and L2; S = 1 if NN above L1, or -1 if below.

  3. Exposure accuracy / Radiometry. The test calculates the average green, red, and blue color components within the central area of the test chart (the gray area between the intensity bands). The test requires that avg(Green) should be within [115; 215], which indicates correct lightness transfer; and abs(avg(Red) -avg( Green)) < 20 and -15 < avg(Green) - avg(Blue) < 20, which indicates correct color transfer.

  4. Exposure uniformity and color balance. These tests ensure that the image preserves light balance and color balance, i.e., the image appears uniformly lit and colored. Thus, we calculate averages for Green (G), Red (R) and Blue (B) over 20px x 20px regions of all 62 grid cells (cells within markers minus gradients in the center). We then calculate standard deviation for each color channel (R, G, B) and require that sqrt(stddev(G)^2 + stddev(R-G)^2 + stddev(G-B)^2)<15.0

Command Syntax

Command option | Description
Blink.exe | Without any options, the test enumerates devices.
-c [string] | Starts the application and runs the test cases that are specified in the .profile file.
-h [string] | Specifies the Plug and Play (PnP) identifier (ID) of the device to be tested.
BlinkWLKFidelity.pro | The .profile file of test cases to be run.

Code Tour

File Manifest

File | Location
Blink.exe | [testbinroot]\nttest\multimediatest\AVCore\VidCap\External\


System Testing

The sections in this topic describe the system test categories that Driver Test Manager (DTM) supports for Windows 7, Windows Vista, Windows Server 2008, Windows Server 2008 R2, Windows Home Server, and Windows XP.

Windows 7

On Windows 7, DTM supports the following system test categories:

  • All-In-One

  • Desktop

  • Mobile

  • Motherboard

  • Previously Logo'd Motherboard

  • Ultra-Mobile

  • GPU Family Update

The system test categories for Windows 7 are categorized into five form factors:

All-In-One

A uniprocessor or multiprocessor system that has a permanently attached integrated display. This is a fixed form factor desktop system that typically includes integrated components based out of mobile hardware designs.

Desktop

A uniprocessor or multiprocessor computer that requires AC power for continuous operation.

Mobile

A uniprocessor or multiprocessor computer that a person can physically carry, has integrated display and input devices, and has a battery that can provide continuous operation when the computer is 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 has a 10.2 inch or smaller screen size.

Note GPU family update is not a separate form factor. You need to run the GPU family update only when you are swapping GPU across the family on a system that has already passed a full system run, as defined in Windows Logo Policy-0017.

Windows Vista

On Windows Vista, DTM supports the following system test categories:

  • All-In-One (Business)

  • All-In-One (Consumer)

  • All-In-One (Business and Consumer)

  • Desktop (Business)

  • Desktop (Consumer)

  • Desktop (Business and Consumer)

  • Mobile (Business)

  • Mobile (Consumer)

  • Mobile (Business and Consumer)

  • Motherboard (Business)

  • Motherboard (Consumer)

  • Motherboard (Business and Consumer)

  • Previously Logo'd Motherboard (Business)

  • Previously Logo'd Motherboard (Consumer)

  • Previously Logo'd Motherboard (Business and Consumer)

  • Ultra-Mobile (Business)

  • Ultra-Mobile (Consumer)

  • Ultra-Mobile (Business and Consumer)

The system test categories for Windows Vista are categorized in the following qualification levels:

Premium

A product that is being tested is 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 to enable a premium experience.

Basic

A product that is being tested is 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 Windows. The basic logo requirements ensure reliability, stability, security, and proper installation, and implements functionality that take advantage of some of the latest Windows innovations.

The system test categories for Windows Vista are categorized in two market segments:

  • Business
    • Information worker. This segment 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. This segment 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 is 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 people can easily and confidently use technology to achieve their goals and pursue their passions.

The system test categories for Windows Vista are categorized into five form factors:

All-In-One

A uniprocessor or multiprocessor system that has a permanently attached integrated display. This is a fixed form factor desktop system that typically includes integrated components based out of mobile hardware designs.

Desktop

A uniprocessor or multiprocessor computer that requires AC power for continuous operation.

Mobile

A uniprocessor or multiprocessor computer that a person can physically carry, has integrated display and input devices, and has a battery that can provide continuous operation when the computer is 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.

Windows Server 2008

On Windows Server 2008, DTM supports the following system test categories:

  • Server

Windows Server 2008 R2

On Windows Server 2008 R2, DTM supports the following system test categories:

  • Server

  • Supported

  • Server Virtualization Validation

Windows Home Server

On Windows Home Server, DTM supports the following system test categories:

  • Home Server

Windows XP

On Windows XP, DTM supports the following system test categories:

  • Netbook (ULPC)

This section includes:

System Requirements for the Targeted Logo System

Preparing Your System for Logo System Testing

Running Logo Tests for System Submissions

Submitting Logo Test Results

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


System Requirements for the Targeted Logo System

For system testing, your computer must meet the following operating system and hardware requirements.

Operating System Requirements

You must use one of the following operating systems to run system tests:

  • Windows 7 - Test on Windows 7 Home Premium or greater

  • Windows Server 2008 R2 Datacenter

  • Windows Server 2008 x86 Datacenter

  • Windows Vista, with the following restrictions:
    • You cannot use the Home Basic edition of Windows Vista to earn a Consumer-Premium logo.
    • You cannot use Ultimate N or Business N edition of Windows Vista for logo testing.
    • You must use the Ultimate Edition of Windows Vista to earn a logo for the Business and Consumer test category.
    • The Ultimate Edition of Windows Vista is recommended for logo testing.
    • The Starter Edition of Windows Vista is not supported for logo testing.

  • Microsoft Windows Server 2003

  • Microsoft Windows XP

Hardware Requirements

The following hardware is required for system testing:

  • One computer that meets the minimum software requirements. This computer is the "system under test" and must include the following:
    • x86-based, x64-based, and Itanium-based processor architectures
    • The following amounts of memory, depending on the operating system and logo program that you are targeting:
      • Windows 7
        • X86: at least 1 GB of RAM
        • X64: at least 2GB of RAM
      • Windows Server 2008 R2
        • The maximum RAM that the system can support
      • Windows Server 2008 x86
        • The maximum RAM that the system can support
      • Windows Vista
        • Basic logo: at least 512 MB of RAM
        • Premium logo: at least 1 GB of RAM
      • Microsoft Windows Server 2003
        • The maximum RAM that the system can support
      • Microsoft Windows XP
        • At least 128 MB of RAM
    • A logo-compliant ACPI BIOS with ACPI enabled by default
    • A hard disk drive with at least 20 GB of available memory on drive C
    • A Windows keyboard
    • A two-button pointing device
    • A color display monitor that is capable of at least 1024x768 resolution, with 32 bits per pixel (bpp) and 60 Hz
    • A CD or DVD drive
    • An audio device (if the test system supports audio)
    • An audio loopback cable (if the test system supports audio)
    • A network adapter

  • One network hub

  • One USB flash drive (if the test system supports Trusted Platform Module [TPM])

  • One data CD (that is, non-audio CD)

  • One USB 2.0 hub

  • One additional computer. Some tests might require an additional system to complete testing. The additional computer should already have a logo.

  • One serial loopback RS232C connector that meets the following specifications:
    Connect This Pin To This Pin

    Tx

    Rx

    RTS

    CTS, DCD (Same as CD)

    DTR

    DSR, RI

  • Audio Precision Machine - Model System Two + Connector Cables (with associated software installed on a second computer).


Preparing Your System for Logo System Testing

Before running system tests, you must configure the test system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware and software requirements, see System Requirements for the Targeted Logo System.

Many of the tests in DTM 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 How to turn on automatic logon in Windows XP.

To configure the test system

When you use DTM for system testing, you must complete the following system configuration tasks to prepare the system for logo system testing.

Important Before you begin testing, make sure that you enable all of the devices in the test system and load all of the related drivers.

To assemble the test environment for DTM system testing, do the following:

  1. On the test system, install a network adapter.

  2. Connect the test system to a network hub.

  3. Connect the additional system to the network hub.

  4. Set the test system BIOS to support the S3 sleep state.

  5. On the test system, install the appropriate Microsoft Windows operating system.

  6. During this installation of the operating system, delete any existing partitions, and create a boot partition. Note, for Business Logo see note at bottom of page.

  7. During installation of the operating system, you must also add the test system to a domain or workgroup.

  8. Install any manufacturer-supplied drivers that devices in the test system require.

  9. On the test system, install the DTM client software from the DTM controller.

  10. On the additional system, install the appropriate Windows operating system.

  11. During installation of the operating system, add the additional system to the same domain or workgroup that the test system belongs to.

  12. Install one serial loopback connector on the serial port of the test system.

To configure the computers in the test environment for DTM system testing, do the following:

  1. Use the following procedure to configure the power options on the test system:
    • Click Start, click Control Panel, and then double-click Power Options.
    • In the Power Options Properties dialog box, click the Power Schemes tab and do the following:
      • In the Turn off monitor list, click Never.
      • In the System standby list, click Never.
      • If there is a System hibernates list, click Never.
    • In the Power Options Properties dialog box, click the Hibernate tab, and clear the Enable hibernation check box.

  2. Repeat step 1 on the additional system.

  3. Insert a valid data CD into the CD or DVD drive of the test system.

    Important The data CD must remain in the test system's disk drive while you complete testing.

Note Additional installation procedures for the operating system are required to test for business level logos in order to pass BitLocker partition settings.

To partition a drive with no operating system for BitLocker

Windows Vista

  1. Start the computer from the nextref_vista product DVD.

  2. In the initial Install Windows screen, choose your Installation language, Time and currency format, and Keyboard layout, and then click Next.

  3. In the next Install Windows screen, click System Recovery Options, located in the lower-left of the screen.

  4. In the System Recovery Options dialog box, choose your keyboard layout, and click Next.

  5. In the next System Recovery Options dialog box, make sure no operating system is selected. To do this, click in the empty area of the Operating System list, below any listed entries, and then click Next.

  6. In the next System Recovery Options dialog box, click Command Prompt.

  7. Use the Diskpart application to create the partition for the operating system volume. At the command prompt, type diskpart, and then press ENTER.

  8. Type select disk 0.

  9. Type clean to erase the existing partition table.

  10. Type create partition primary size=1500 to set the partition you are creating as a primary-type partition.

  11. Type assign letter=S to give this partition the S: designator.

  12. Type active to set the new partition as the active partition.

  13. Type create partition primary to create another primary-type partition. You will install Windows on this larger partition.

  14. Type assign letter=C to give this partition the C: designator.

  15. Type list volume to display all the volumes on this disk. You will see a listing of each volume, volume numbers, letters, labels, file systems, types, sizes, status, and information. Make sure that you have two volumes that are formatted as NTFS, and that you know the labels for both volumes.

  16. Type exit to close the diskpart application.

  17. Type format c: /y /q /fs:NTFS to format the C volume.

  18. Type format s: /y /q /fs:NTFS to format the S volume.

  19. Type exit to close the command prompt.

  20. In the System Recovery Options window, use the close window icon in the upper-right (or press ALT+F4) to close the window to return to the main installation screen.

    Important Make sure that you do not shut down or restart the computer.

  21. Click Install now and proceed with the nextref_vista installation process. Install nextref_vista on the larger partition, C: (the operating system volume).

Windows 7

A separate, active system partition will automatically be created when you install Windows 7 to a drive without any partitions.

After you have configured your test systems, you can run the logo tests for systems testing.


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, do the following:

Note The following procedures assume that you have completed the DTM setup and installation procedures for both the DTM client and DTM Studio.

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

  1. Open DTM Studio.

  2. On the Explorers menu, click Device Console. (You can also switch to the Device Console window by clicking the Device Console tab in the lower left part of DTM Studio.)

  3. Select your DTM controller from the Data Store dropdown list in the upper left part of the Device Console window.

  4. Click the Submission option in the Submission frame. This is selected by default.

  5. 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.

    Note If you have an existing submission, you will see the submission name appear in the Submission list. You can select your submission name to continue testing with an existing submission.

  6. 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 System Submission as your submission category, and then click Next.

    3. Select one of the following subcategories for your qualification level, and then click Next.

      • Windows Vista:
        • All-In-One (Business)
        • All-In-One (Consumer)
        • All-In-One (Business and Consumer)
        • Desktop (Business)
        • Desktop (Consumer)
        • Desktop (Business and Consumer)
        • Mobile (Business)
        • Mobile (Consumer)
        • Mobile (Business and Consumer)
        • Motherboard (Business)
        • Motherboard (Consumer)
        • Motherboard (Business and Consumer)
        • Previously Logo'd Motherboard (Business)
        • Previously Logo'd Motherboard (Consumer)
        • Previously Logo'd Motherboard (Business and Consumer)
        • Ultra-Mobile (Business)
        • Ultra-Mobile (Consumer)
        • Ultra-Mobile (Business and Consumer)
      • Windows 7:
        • All-In-One
        • Desktop
        • Mobile
        • Motherboard
        • Previously Logo'd Motherboard (
        • Ultra-Mobile
        • GPU Family Update

          Note You must complete a full system submission before running the GPU family update category on that system for swapping GPUs from different families, as defined in Windows Logo Policy-0017. The GPU family update category is a subset of tests to verify graphics subsystem only.

      • Microsoft Windows Server 2008:
        • Server
      • Microsoft Home Server:
        • Home Server
      • Microsoft Server 2008 R2:
        • Server
        • Supported
        • Server Virtualization Validation
      • Microsoft Windows XP:
        • Netbook (ULPC)

      Note After you choose a subcategory for Windows Vista, you must choose a qualification level of Premium or Basic, and then click Next.

    4. Enter a name for the submission, select the machine pool that contains the machine to use for the submission, and then click Next.

    5. Choose the system from the resource pool that will be submitted for a logo, and then click Next. Go to step F if you are making a Windows 7 submission. For all other operating systems, click Finish. You can use any resources that have a matching identifier for testing.

    6. For Windows 7 submission, choose one or more additional qualifications. If you are not testing for an addition qualification, leave the check boxes blank. Click Finish.

To select and schedule logo tests:

  1. In the filtered list on the right side of the Device Console window, select the displayed logo tests.

  2. Click the Add Selected button.

  3. Click the Schedule button.

Note System tests that require some manual intervention will have "(Manual)" at the end of the test name.

To monitor logo test progress:

  • Observe logo test progress by using Job Monitor, and manually intervene if the test requires it. You can manually refresh the logo tests status in the Device Console window by pressing F5 or by clicking Refresh on the View menu.

  • Examine the results of a job in Result Explorer and diagnose the source of any errors. Rerun logo tests if necessary until they pass successfully.

  • If you click the Submission Status button, you will 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

To obtain a "Designed for Microsoft Windows" logo, your last step 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. In DTM Studio, 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 Winqual Web site and follow the instructions to submit your package.

Note You can also check on the status of your submission by visiting the Winqual Web site.


System Power and Performance Test Suite Overview

Introduction

This overview describes the set of tests that currently make up the System Power and Performance Test Suite (SPPTS), which is used to evaluate the performance, reliability of power transitions, and how well Client systems are optimized for battery life. These tests help ensure that end users have well performing systems during the various usage scenarios that the SPPTS covers. We have observed that the overall system performance can vary significantly and well performing systems require optimizations throughout the entire system, including BIOS, hardware, drivers, and various OS components. None of these tests are required to pass either the System or Device Logos; they are provided to supply the information needed to optimize end user OEM systems.

The SPPTS enables users to set up and run all of the tests described below. The SPPTS also includes several applications that are used at various times during the testing process. The SPPTS is broken up into two areas of focus:

  • Performance Test Jobs

  • Power Test Jobs

Performance Test Jobs

These jobs evaluate how well the system enters and exits various power transitions, as well as the performance of the hard disk and graphics adapter's video memory bandwidth, which can cause other system wide performance issues. In addition, providing a great user experience for power transitions will help extend battery life on mobile platforms.

Boot Test

We have observed that the end to end boot times in lab environment are significantly different than the average boot times experienced in the field. We have found several key factors that contribute to the increased amount of time in boot on OEM systems, including the increase in the amount of disk reads that occur during the boot sequence, driver delays, and third party services that are installed on the system. While BIOS time should be considered as part of the boot sequence, we do not have a method to measure this and this is not evaluated as part of the Boot test. We have also observed several responsiveness issues after the desktop is visible caused by excessive startup applications and creating tray icons. To determine post-boot responsiveness upon completing main path boot, the test samples every 100ms to look for idle periods. If there was no CPU or disk activity at normal or higher priority for at least 80 of the 100ms, the 100ms time is accumulated. The test then waits until 10 seconds of "idle" time is accumulated before completing.

The boot sequence is broken up into six different phases, as described below. The MainPathBoot referred to above is defined in phases two through five.

  1. OS Loader: Loader initialization, loading drivers marked as BOOT_START

  2. PreSMSS (Includes BootPnp and System PNP): Basic kernel initialization and PnP, starts when kernel is initialized and ends when PnP has completed

  3. SessionInit(SMSSInit): Contains activities such as autochk, loading the registry, and video initialization, which starts when the PreSMSS phases is completed and ends when the system and user sessions are initialized

  4. WInLogon Init: Contains the initialization of the Service Control Manager and services, displaying the logon UI and welcome screen, and launching the desktop process. Starts when the SMSSInit phase completes and ends when the desktop process has been launched

  5. Explorer Init: Represents the time required for Explorer (the desktop) to load its settings and initialize, starts when the WinlogonInit phase completes and ends when the desktop is available to the user

  6. Post Boot: The time after the desktop has been created until the system "idles out." This is meant to convey the amount of background activity initiated in boot that is impacting the user now that they are logged in

For a more detailed description of the boot sequence, please see the "On/Off Transitions Performance Analysis" whitepaper in the "Additional Resources section" below.

Standby Test

We have observed that the end to end time that it takes to resume a system from standby can vary significantly depending on hardware, drivers, and applications. As laptop usage increases, entering and exiting standby is a growing usage scenario. The goal of this test is to evaluate the user experience in entering and resuming from standby. In addition, providing a good user experience can potentially create battery savings opportunities as well. Data that we have gathered from customers suggests that entering standby in less than 5 seconds and resuming from standby in less than 1 second is achievable on customer shipping systems. In Windows Vista, SuperFetchTM improves the performance of subsequent standby/resume transitions by pre-fetching information from previous standby and resume transitions. The test looks at these subsequent runs for timing evaluation to ensure SuperFetchTM has properly trained the system. The test also analyzes the cold resume that looks at the first transition after a reboot to ensure that the system does not have pages from a recently performed sleep transition in memory. Finally, the test looks at a warm resume to ensure that the system has the necessary pages from disk needed to support the transition in memory from a recent transition. This is considered the "best case" for this scenario. The current test does not look at post resume responsiveness at this time. However, this test should be done manually to look at CPU and disk activity post resume to ensure that users have a responsive system when the desktop is painted.

The standby sequence is broken up into three different phases:

  1. Suspend Applications: The time required for applications to process the WM_POWERBROADCAST notification.

  2. Suspend Services: The time required for services to suspend.

  3. Suspend Devices: The time required for devices to suspend.

The resume sequence is broken up into four different phases:

  1. BIOSInit: The time required for the BIOS to initialize and hand control to the OS.

  2. Resume Devices: The time required to resume the system and paint the desktop.

  3. ResumeServices: The time required to resume services.

  4. ResumeApps: The time required to resume applications.

For a more detailed description of the standby sequence please see the "On/Off Transitions Performance Analysis whitepaper" in the "Additional Resources" section below.

Hibernate Test

Similar to the standby test, hibernating and resuming from hibernate can vary significantly depending on hardware, drivers, and application workload. Many of the issues that prevent a system from achieving a good standby experience may also impact the hibernate experience as well. In the case of hibernate, disk performance is an additional factor that can impact the performance of this scenario. The goal of this test to evaluate how well the system performs in hibernating the system and resuming from hibernate.

The hibernate sequence is broken up into four different phases:

  1. Suspend Applications: The time required for applications to process the WM_POWERBROADCAST notification.

  2. Suspend Services: The time required for services to suspend.

  3. Suspend Devices: The time required for devices to suspend.

  4. HiberfileWrite: The amount of time spent writing the hiberfile to disk, which can vary from run to run.

The resume sequence from hibernate is broken up into four different phases:

  1. HiberFile Read: The amount of time spent reading the hiberfile from disk.

  2. Resume Devices: The time required to resume the system and paint the desktop.

  3. ResumeServices: The time required to resume services.

  4. ResumeApps: The time required to resume applications.

For a more detailed description of the hibernate sequence please see the "On/Off Transitions Performance Analysis whitepaper" in the "Additional Resources" section below.

Shutdown Test

We have observed that the end to end shutdown time on shipping systems can vary significantly depending on hardware, drivers, and services. The majority of the problems that have caused significant delays in shutdown time are due to various services that timeout during the shutdown process. The shutdown process on today's systems is broken up into two sessions: the user session (shutting down applications) and the system session (shutting down services and system processes).

For a more detailed description of the shutdown sequence please see the "On/Off Transitions Performance Analysis whitepaper" in the "Additional Resources" section below.

Power Test Jobs

Idle Trace Test

Idle scenarios are commonly found in client systems, and idle energy efficiency is critical for energy conservation and longer battery life. We have spent substantial effort in reducing system activity during idle for Windows 7. However, this may not benefit our end customers without reducing additional sources of idle activity from OEM/ISV/IHV applications and drivers.

Common energy-efficiency issues found in idle scenarios include the following:

  • High CPU Utilization reducing CPU residency time in the lowest-power C-state and P-state

  • Frequent timer activities preventing power management opportunity, particularly for future hardware platforms

  • Frequent Disk IOs resulting in high disk power

  • USB devices not entering suspend state when not in use

Our idle tests aim to help discover these issues and present them in the results.xml

Power Policy Check

The majority of these settings are exposed in the UI in Windows Vista and Windows 7. It is important that the settings are captured in the SPPTS prior to changing power policy settings required for other tests. The test first identifies all of the power plans that are currently available on the system. It then captures all of the power plan settings for each power plan.

IE Launch Time Test

Launch IE and wait for the "about tabs" page to completely render. This test launches IE five times and measures the time it takes to render the "about tabs". The test also reports the average load time, in milliseconds for all installed and enabled IE add-ons. We strongly suggested that the total averaged load time for pre-installed add-ons should be under 100msec.

The Disk Check PIO Mode Check, Disk Write Cache Check, and WinSAT Video Memory Bandwidth Check have all been eliminated as separate tests and are now run as part of the Pre-Test Setup job that is run as a normal part of any of the Test Job listed above. The test results are reported in the results.xml that is generated at the end of each test. The following are the metrics from the results.xml in the OSConfig section for these tests:

<Metric name="disk_transfermode_channel_1" comment="Ultra DMA Mode 5" type="info" />

<Metric name="disk_transfermode_channel_0" comment="Ultra DMA Mode 5" type="info" />

<Metric name="disk_cache_disabled_pre" units="boolean" value="0" />

<VideoMemBandwidth units="MB/s">1921.41000</VideoMemBandwidth>

The System Under Test set-up procedure that is used in the Microsoft labs to test retail Vista SP1 and Windows 7 is as follows:

  1. Run through the Windows installation process, accepting all defaults.

  2. Add a user name during installation, but do not set a password.

  3. At the Local Settings screen, select the local time zone.

  4. Ensure that at the Windows Update screen during installation, the default (run Windows Update automatically) is selected.

  5. Complete the installation process, and update the BIOS version if necessary.

  6. Manually run Windows Update to ensure the latest drivers are present on the system, and restart the machine.

  7. After the restart, run Windows Update again to ensure all the updates were taken, and then turn off Windows Update.

  8. If there are any devices that are still missing drivers, go to the OEM/Manufacturer website to install the driver. This is especially true for graphics where the standard VGA driver should not be used.

  9. There should be no addition window pop-ups after a final reboot before starting the testing.

  10. Remove all media from CD/DVD drive(s) on the System Under Test before starting the testing.

  11. Remove any external USB drives on the System Under Test before starting the testing.

  12. Remove any kernel debugger connections.

When the lab is testing an OEM image or an upgrade to Windows 7 from an OEM image, complete the following steps:

  1. Run the manufacturer-specific Auto Update process. Do not turn-off that auto-update process.

  2. Complete the Anti-Virus application setup; force a definition update and scan of the hard drive.

  3. Complete the installation of additional manufacturer applets.

  4. There should be no addition window pop-ups after a final reboot before stating the testing.

Additional Resources

Windows Performance Tools Kit:

http://www.microsoft.com/whdc/system/sysperf/perftools.mspx

  • Xbootmgr.exe
    • Automates On/Off trace collection
  • Xperf.exe
    • Generates On/Off transition summary reports
    • Provides raw text dumps for detailed, low-level analysis
  • Xperfview.exe
    • Provides graphical visualizations of performance data

On/Off Transition Performance Analysis of Windows Vista:

http://www.microsoft.com/whdc/system/sysperf/On-Off_Transition.mspx

Windows On/Off Transitions Solutions Guide::

http://www.microsoft.com/whdc/system/pnppwr/powermgmt/OnOffTrans.mspx

Energy Efficiency Portal:

  • http://www.microsoft.com/whdc/system/pnppwr/mobilepwr.mspx

  • Battery Life Solutions Guide: http://www.microsoft.com/whdc/system/pnppwr/mobile_bat.mspx#

Windows Performance Analysis Developer Center:

http://msdn.microsoft.com/en-us/performance/default.aspx

Windows Performance Analysis forum:

http://social.msdn.microsoft.com/Forums/en-US/wptk_v4/threads/

Event Tracing for Windows MSDN docs:

http://msdn2.microsoft.com/en-us/library/aa363787.aspx

Windows Internals:

"Windows Internals 5th edition" by Mark Russinovich and David Solomon


Media Playback Performance Test Suite

Overview

The Media Playback Performance test suite consists of several test jobs that use the Windows Media Player to playback reference audio and video content. The test matrix includes testing on AC and DC power settings, full screen and windowed screen modes, and many other custom settings. ETW logs are collected during each playback test that is executed. These ETW logs contain rich information, including system and application events, which are used to measure the user experience, analyze, and root cause performance and quality issues. After a test pass completes, the ETW logs are parsed, and output CSV and XML files are generated. The output CSV and XML files contain key metrics that indicate whether the playback experience was good (0 glitches) or needs improvement (more than 0 glitches). The results in the CSV file are also rolled up into the main results XML file, which is generated by the System Power and Performance Test Suite (SPPTS) jobs. In order to analyze and identify the cause of audio and video glitches reported by the media playback tests, please refer to the Media Performance Analysis Toolkit (MediaPerfView.exe), which enables developers and testers to correlate audio and video glitches with other system or driver activity. Additional details on the Media Performance Analysis Toolkit are located in this help document.

The Media Playback Tests include the following variations of A/V formats supported natively in Windows 7:

  • Audio

    AACRaw, AAC, ADTS, MP3, WMA Standard and Lossless, WAV

  • Video

    AVCHD/MTS, xVid, DVD 24p, DVD 60i, H.264, MP4, MP2, MP1, MJPEG, DV, WMV/VC1

The Media Playback tests support the following custom settings:

  • Power Sources: AC (power cord plugged in) or DC (on battery)

  • Power Plans: Balanced, Power Saver, High Performance, and Balanced with Optimize for Video Quality

  • Playback Modes: Full screen and windowed mode

  • DXVA enabled or disabled

  • DWM enabled or disabled

  • CPU or GDI stress enabled or disabled

  • Supported SKUs: Limit tests to only run on specific SKUs

  • Captions: Enable or Disable captions during DVD playback

On desktops, there is no user interaction required; however, on laptops, a dialog box will appear prompting you to unplug and reconnect the AC Power cord before and after DC (battery) tests. Follow these steps to execute the test pass:

  • Step 1: Test Pass Prerequisites:

    Install Windows 7 image with OEM customizations and applications.

    Download test content package from the WLK Connect site.

    Burn and insert the test movie DVD into the DVD drive.

  • Step 2: Run the tests:

    Schedule the test job that is most appropriate for the test machine.

  • Step 3: Triage and analyze results:

    Use XML and CSV output, MediaPerfView Analysis Tool.

Step 1 - Prerequisites

Install the Windows 7 OEM image including all customizations, driver updates, and applications.

Only the Media Playback Performance test job named "Media Playback Tests - Pri 0 - Short Run" does not require any additional downloads or the test DVD in the DVD drive. All other Media Performance tests require the 11 GB content download. The media test jobs that contain "[DVD in drive required]" require you to insert the test movie DVD into the DVD drive on the test machine. Follow these steps to download the test content and burn a test DVD:

  1. Media Playback Test Content Package (11gb)

    The Media Playback Tests that contain "[External content download required]" in the title require that this content package be downloaded and extracted to a specific path on the DTM server. This content package contains 11 GB of audio and video media required by the optional Media Playback Tests. The test content package can be downloaded from the following WLK Connect site:

    Note You must be invited to the "WLK 1.5 Build Snap" program on Microsoft Connect to be able to access this link. Also, you will need to sign in to MS Connect before you can view the page.

    https://connect.microsoft.com/site668/Downloads/DownloadDetails.aspx?DownloadID=24836

    After downloading the 11 GB zip file to the DTM server, extract the contents of the zip file to the following path on the DTM server:%systemdrive%\Program Files\Microsoft Driver Test Manager\Tests\x86fre\NTTest\basetest\fqts\tests\media\content

    If you are prompted to overwrite existing files, select Yes to overwrite existing files. For example, the following folders and files should exist after extracting this compressed media content to the DTM server.

    Sample content file paths:

    • %systemdrive%\Program Files\Microsoft Driver Test Manager\Tests\x86fre\NTTest\basetest\fqts\tests\media\content\37_WTV_640x480_30_8000kbps.wtv
    • %systemdrive%\Program Files\Microsoft Driver Test Manager\Tests\x86fre\NTTest\basetest\fqts\tests\media\content\DVD_60i_24p\VIDEO_TS\VIDEO_TS.IFO

  2. Test Movie DVD

    Media Playback Tests that contain "[DVD in drive required]" in the title require you to insert a test movie DVD into the DVD drive before scheduling the jobs. The 11 GB test content package contains the ISO image that must be burned to a blank DVD. The following is a sample path to the DVD ISO file: %systemdrive%\Program Files\Microsoft Driver Test Manager\Tests\x86fre\NTTest\basetest\fqts\tests\media\content\DVD_60i_24p\DiscImage.iso

    After burning this ISO image to blank DVDs, insert the DVDs into each test machine that these jobs will be scheduled on.

Step 2 - Scheduling Media Playback Tests

Overview of terminology in Media Playback job titles

Some of the media playback performance jobs contain "[Low]", "[Mid]", and/or "[High]" in the job title. These are different profiles intended for different classes of machines. Media Test jobs that contain:

  • "[Low]" in the job title contain audio content and standard definition (SD) video content, which is suitable for testing on low-end machines.

  • "[Mid]" in the job title use a profile that contains all of the content that exists in the low-end profile, plus mid-end video content such as 5mbps 720p.

  • "[High]"in the job title use a profile that contains all content in the low-end, mid-end profiles, plus high-end video content such as 30mbps 1080p content

Media playback jobs that contain "[External content download required]" in the title require a separate 11 GB media test content download on the DTM server (see the "Prerequisites" section above for details). Media playback jobs that contain "[DVD in drive required]" in the title require the test DVD be inserted in the DVD drive (see the "Prerequisites" section above for details). The test scenarios that are executed as part of each test job are defined in CSV definition files that are located on the DTM controller. An example folder path to input definition files is the following:

%systemdrive%\Program Files\Microsoft Driver Test Manager\Tests\x86fre\NTTest\basetest\fqts\tests\media

Media Playback Test Job Descriptions

  • Media Playback Tests - Pri 0 - Short Run - [External content download not required]

    This job does not require the additional 11 GB test content download or the test DVD in the DVD drive. It contains a few core scenarios that are aimed at low, mid, and high-end machines.

  • Media Playback Tests - Audio Only - [Low, Mid, High], [DVD in drive not required], [External content download required]

    This job contains audio only content and is suitable for low, mid, and high-end machines. The main purpose of this job is to verify audio content plays back without any glitching.

  • Media Playback Tests - AudioVideo - [High], [DVD in drive required], [External content download required]

    This is a superset of all other jobs and contains audio and video content that is expected to playback on low, mid, and high-end machines. This job also contains the DVD playback from DVD drive scenarios.

  • Media Playback Tests - AudioVideo - [High], [DVD in drive NOT required], [External content download required]

    This is a superset of all other jobs and contains audio and video content that is expected to playback on low, mid, and high-end machines. This is the same as the test job above, however, this job does not contain the DVD playback from DVD drive scenarios.

  • Media Playback Tests - AudioVideo - [Mid], [DVD in drive required], [External content download required]

    This job contains audio and video content that is suitable for mid end machines. It contains SD and 720p video profiles. The test DVD is required by this job.

  • Media Playback Tests - AudioVideo - [Mid], [DVD in drive NOT required], [External content download required]

    This job contains audio and video content that is suitable for mid end machines. It contains SD and 720p video profiles. This is the same as the test job above, however, the test DVD is not required by this job.

  • Media Playback Tests - AudioVideo - [Low], [DVD in drive required], [External content download required]

    This job contains audio and video content that is suitable for low end machines. It contains SD video profiles. The test DVD is required by this job.

  • Media Playback Tests - AudioVideo - [Low], [DVD in drive NOT required], [External content download required]

    This job contains audio and video content that is suitable for low end machines. It contains SD video profiles. This is the same as the test job above, however, the test DVD is not required by this job.

Step 3 - Viewing, Triaging, and Analyzing Media Playback Test Results

Test Output

The Media Playback performance test results for each test job are combined into a single CSV file. The high-level performance and quality metrics are also copied to output XML files that match the same output schema as the System Power and Performance Test Suite results are stored in. The ETW and output CSV/XML logs are not copied to the DTM controller after a test pass completes. The test logs remain on the local test machines in the following location:

%SystemDrive%\FQTSResults\%WDKSubmissionId%

WDKSubmissionId is a DTM Dimension that is generated on a per test submission basis. And example path is the following:

C:\FQTSResults\13_sppts_lap4_Win7_x86\Media

The CSV output can be consumed in a spreadsheet processor. Highlight values greater than 0 in columns such as "Video_Glitch," "AEGlitchKSandNonKS,", or "DWM_Schedule_Glitch." These metrics indicate scenarios that experienced glitching. The column labeled "ETWFilePath" contains the links to the ETW logs used to generate the results. Please note that after the DTM executes a job, it removes the "job working directory" so the paths to the ETL files will have to be renamed to the path where the logs were copied to.

The results are also copied to a results XML file, which is also located in the Media results folder. The results XML can be consumed in a web browser. When a problem such as long ISRs or DPCs greater than 3ms, or audio/video glitches, is reported in the result files, the MediaPerfView tool can be used to analyze the ETW logs and root cause failures or regressions identified during a test pass.

Media Performance Analysis Toolkit

This kit is an add-on package to Windows Performance Toolkit. It contains a graphic trace analysis tool, MediaPerfView, used for analyzing ETW logs (*.etl). MediaPerfView displays system-wide instrumentation data collected in an ETW trace and visualizes a wide range of kernel and user-mode events fired during the tracing session. The graphical user interface allows ease of event correlation and comparison from different sources, and can be used to quickly pinpoint problems and identify troublesome patterns for playback scenarios. Media Performance Analysis Toolkit also includes scripts that you can use to manually collect traces for a stand-alone scenario. The Windows Media Performance site on MS Connect contains the Media Performance Analysis Toolkit, along with case studies for analyzing ETW logs. To view the following links, you must request access to the Windows Media Performance site on MS Connect at https://connect.microsoft.com/site/sitehome.aspx?SiteID=776. To do this, please follow these steps:

  1. Register your company email address on http://connect.microsoft.com.

  2. Update your profile settings to allow Microsoft to send you invitations to programs on MS Connect.
    a. Go to http://connect.microsoft.com, and then click Your Profile.
    b. If you agree, select Yes to the following question: "I would like to be contacted about participating in new Microsoft Connect programs, surveys, and events."
    c. Save your profile settings.

  3. Send an email to avperfod@microsoft.com to request access to the Windows Media Performance site on MS Connect.

Note You will also need to sign in to MS Connect before you can access the following pages.

Media Performance Analysis Toolkit

https://connect.microsoft.com/site776/Downloads/DownloadDetails.aspx?DownloadID=29695

Media Performance Whitepaper

https://connect.microsoft.com/site776/Downloads/DownloadDetails.aspx?DownloadID=18205

Frequently Asked Questions

Q: I have my own A/V test content, can I integrate into the Test Kit?

A: Yes. Add a new scenario or row to the TestPassDefinition file and edit the TestRunCmd value to reference custom content files. The Test Pass Definition CSV files are located on the DTM under the following path:\x86fre\NTTest\basetest\fqts\tests\media

Q: What can I do if the battery dies while the tests are still running on DC?

A: Edit the Test Pass Definition CSV file in notepad and remove several scenarios that run on DC (see the PowerSource column). The Test Pass Definition CSV files are located on the DTM under the following path:\x86fre\NTTest\basetest\fqts\tests\media

Q: Can I remove the tests that run on battery from the test pass?

A: Yes. Edit the TestPassDefinition CSV files in notepad or a spreadsheet processor and remove all rows where the PowerSource field contains "DC". The Test Pass Definition CSV files are located on the DTM under the following path:\x86fre\NTTest\basetest\fqts\tests\media

Q: Where are the ETW and test output CSV/XML logs stored?

A: The test logs are not copied to the DTM controller. After a Media Playback test pass, the logs are copied to a local path on each test machine. Please refer to "Step 3 - Viewing, Triaging, and Analyzing Media Playback Test Results," which contains the specific location where the test logs are stored.

Feedback & Support

Pease send questions and bug reports for the Media Playback Tests to the support email alias: avperfod@microsoft.com


System Power and Performance Test Suite Setup Guide

Introduction

This guide is a quick reference on how to set up and use the System Power and Performance Test Suite (SPPTS).

Supported operating system:

  • Windows 7

Installing SPPTS

To install SPPTS, follow these steps:

  1. Install Windows Logo Kit (WLK) on the local Windows Server 2003 system.

    Note For detailed system requirements and installation instructions, please see Install.htm - Installation Guide .

  2. Install Device Test Manager (DTM) Studio on either the server or another system.

    Note For detailed steps on how to do this, please see Setting Up DTM.

  3. Install DTM Client on the system(s) under test.

    Note For detailed steps on how to do this, please see Setting Up DTM.

    Note For instructions on setting up the system under test, please see the "System Under Test Procedure" section below.

  4. On the DTM Studio system, create a machine pool and move the system(s) under test to that newly created machine pool.

    Note For detailed steps on how to do this, please see Setting Up DTM.

  5. In the main DTM Studio window, click the Explorers tab, then click Device.
  6. On the Submission menu , click <new submission>.
  7. In the Create New Submission window, click the Windows operating system that the system under test has installed on it, and then click Next.
  8. In the next Create New Submission window, select System Submission, and then click Next.
  9. In the next Create New Submission window, select System Power and Performance Test Suite, and then click Next.
  10. In the next Create New Submission window, type a name for the test run in the Name for new submission box.
  11. Select the machine pool that you created in step 4, and then click Next.
  12. In the next Create New Submission window, select the system under test that you moved to the machine pool in step 4, and then click Next.
  13. In the final Create New Submission window, click Finish.
  14. The Device Console window appears with a list of all the tests that are part of the SPPTS. Select the check boxes of individual tests to runor select the check box to the left of the Systems Test Folder icon.

    Note Microsoft recommends that you run the following tests:

    • Boot Shutdown
    • Hibernate
    • Idle
    • IE Launch
    • Media Playback Pri 0
    • Standby

    The remaining Media Playback Tests are optional and require that you install additional media content on your DTM Controller system. For the media installation process, please see Media Playback Performance Test Suite. The Media Playback Pri 0 test does not require any additional media content for test execution. All of the tests can be run individually or in any grouping that you want.

  15. Click Add Selected and then click Schedule Jobs.
  16. The jobs begin to execute.
  17. Monitor the jobs' progress from the Job Monitor page.

    Note To see the status of a child job: In the Test Execution Status pane, right-click a run job and then click Child Job Result. In the Job Execution Status pane, click Setup Tasks, and the task status for the child job will appear in the Task Execution Status pane.

  18. All of the test pass results are stored locally on the system under test.

  19. After the test pass completes, examine the Results.xml and Test_output.html files. The Results.xml file contains all of the important results from each test that is executed as part of the test pass. The Test_output.html file is a report that displays Results.xml in a more readable format. It is the best place to begin interpreting the results from the completed test pass.

    The following is a snippet of the report, which details the Boot Shutdown test:

    Note The IE Launch test results directory contains the .etl files for the five runs that the IE Launch test executes. These files are the actual trace files collected by the Xperf tool. The WarmStartIELaunch.xml files are the extracted data results elements from the .etl files for each run. The Warmstart_ie_launch_results.xml is the final output results for all five runs .

    Note For a more detailed walkthrough of the test pass results, please see the Windows On/Off Transitions Solutions Guide, which has detailed descriptions of the different on/off transitions, and a description of how to interpret the results from each test.

System Under Test Setup Procedure

To set up the system under test, follow these steps:

  1. Install Windows, accepting all defaults.
  2. Add a user name during installation, but do not set a password.
  3. In the Local Settings window, select the local time zone.
  4. In the Windows Update window, make sure that Run Windows Update Automatically is selected.
  5. Complete the installation process, and update the BIOS version if necessary.
  6. Manually run Windows Update to ensure that the latest drivers are present on the system, and restart the machine.
  7. After the restart, run Windows Update again to confirm that all the updates were successful, and then turn off Windows Update.
  8. If there are any devices that are still missing drivers, go to the manufacturer website to install the driver. This is especially true for graphics devices, where the standard VGA driver should not be used.
  9. There should be no additional pop-ups after a final restart.
  10. Remove all media from the CD/DVD drives on the system under test.
  11. Remove any external USB drives from the system under test.
  12. Remove any kernel debugger connections.

If you need to test an original equipment manufacturer (OEM) image or an upgrade to Windows 7 from an OEM image, then complete the following additional steps:

  1. Run the manufacturer-specific automatic update process. Do not turn off the automatic update process.
  2. Complete the antivirus application setup and force a definition update and scan of the hard drive.
  3. Complete the installation of additional manufacturer applets.
  4. There should be no addition pop-ups after a final restart before starting testing.

Additional Resources

  • Windows Performance Analysis Tools: http://www.microsoft.com/whdc/system/sysperf/perftools.mspx
    • Xbootmgr.exe: Automates on/off trace collection
    • Xperf.exe: Generates on/off transition summary reports and provides raw text dumps for detailed, low-level analysis
    • Xperfview.exe: Provides graphical visualizations of performance data
  • Windows On/Off Transition Performance Analysis: http://www.microsoft.com/whdc/system/sysperf/On-Off_Transition.mspx
  • Windows On/Off Transitions Solutions Guide: http://www.microsoft.com/whdc/system/pnppwr/powermgmt/OnOffTrans.mspx
  • Energy Efficiency Portal: http://www.microsoft.com/whdc/system/pnppwr/mobilepwr.mspx
  • Mobile Battery Solutions Guide for Windows Vista: http://www.microsoft.com/whdc/system/pnppwr/mobile_bat.mspx
  • Windows Performance Analysis Developer Center: http://msdn.microsoft.com/en-us/performance/default.aspx
  • Windows Performance Toolkit forum: http://social.msdn.microsoft.com/Forums/en-US/wptk_v4/threads/
  • Event Tracing for Windows: http://msdn.microsoft.com/en-us/library/bb968803.aspx
  • Windows Internals: “Windows Internals 5th edition” by Mark Russinovich and David Solomon


System Power and Performance Test Suite Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


System Power and Performance Test Suite IE Launch Test

Type: Automated Test

Overview

Launch IE and wait for the "about tabs" page to completely render.

Details

This test will execute one "cold" test run to stabilize memory contents, followed by five "warm" test runs. The test also reports the average load time in milliseconds for all installed and enabled IE add-ons. We highly recommend that the total average load time for pre-installed add-ons be under 100 msec.

Run Time: 45 minutes

Log File: XMLAggregator.exe

FQTS.txt Note This is the log file for all of the events that are logged as part of the test execution. It is intended as a troubleshooting aid.

System Restart Required: Yes
Test Category: Supported operating systems for an informative system performance measurement Note This is not a logo test.
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running System Power and Performance Test Suite IE Launch Test

This test will always return Pass. Review the test results .xml file for specific system performance details.

Example XML output from this test (results from the five runs of the IE Launch test):

<Test xsi:type="WarmStartIELaunchTest" name="warmstart_ie_launch">

<Errors />

- <Runs>

- <Run iteration="1" filename="Run1.WarmStartIELaunch.xml">

<Metric name="ie_warm_launch" units="msec" value="1081" />

</Run>

- <Run iteration="2" filename="Run2.WarmStartIELaunch.xml">

<Metric name="ie_warm_launch" units="msec" value="450" />

</Run>

- <Run iteration="3" filename="Run3.WarmStartIELaunch.xml">

<Metric name="ie_warm_launch" units="msec" value="426" />

</Run>

- <Run iteration="4" filename="Run4.WarmStartIELaunch.xml">

<Metric name="ie_warm_launch" units="msec" value="416" />

</Run>

- <Run iteration="5" filename="Run5.WarmStartIELaunch.xml">

<Metric name="ie_warm_launch" units="msec" value="389" />

</Run>

There are also a number of other results files and log files that are collected during the test job run. These include the following directories:

  • Logs All of the log files collected during the test job run.

  • MiscAll of the different result files that are generated during the test job run.

  • PowerCFG The results of the in the box Windows 7 PowerCFG job.

  • PowerPolicyAll of the power polices on the System Under Test.

  • WinSAT FormalThe results of the in the box Windows 7 WinSAT Formal job.

  • WArmStartIELaunchAll of the "raw" Xperf timing traces.


System Power and Performance Test Suite Idle Trace Test

Type: Automated

Overview

This test evaluates the amount of activity that occurs on the system when the system is idle with no user interaction.

Details

The amount of activity that occurs during the idle state can have a significant impact on the overall battery life of the system. These tests look at CPU activity, disk activity, C-state and P-state residency, and finally the system timer tick that is currently set on the system. CPU and Disk activity can be analyzed by capturing an idle trace of the system. C-state residency requires looking both at the idle trace as well as using the inbox PowerCFG tool to see which C-states are being exposed on the system. The C-State and P-State residency are both reported in a separate test as the system timer tick test. There is an example xml output of the CPU activity test below.
Run Time: 60 minutes

Log Files:

XMLAggregator.wtl

FQTS.txt Note This is a log file for all of the events that are logged as part of the test execution. This is intended as a troubleshooting aid.

System Restart Required: No

Test Category: Supported operating systems for informative system power measurements (Note This is not a logo test)

Requirements:

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

Hardware Requirements

The test tool requires the following hardware:

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the System Power and Performance Test Suite Idle Trace Test

This test will always return Pass. Review the test results xml file for the specific system power details.

Example XML output from this test:

<Test xsi:type="IdleCPUTest" name="idle_cpu">

<Metric name="cpu_utilization_total" units="%" value="4.39" />

<Metric name="cpu_utilization_threads" units="%" value="1.59" />

<Metric name="cpu_utilization_dpcisrs" units="%" value="2.80" />

<Metric name="cpu_utilization_source1" units="%" value="2.65" comment="hal.dll!0xfffff800028125d0" />

<Metric name="cpu_utilization_source2" units="%" value="0.56" comment="svchost.exe" />

<Metric name="cpu_utilization_source3" units="%" value="0.32" comment="svchost.exe" />

<Metric name="cpu_utilization_source4" units="%" value="0.28" comment="System" />

<Metric name="cpu_utilization_source5" units="%" value="0.12" comment="sppsvc.exe" />

<Metric name="cpu_utilization_source6" units="%" value="0.07" comment="ataport.SYS!0xfffff88000db8f44" type="info" />

<Metric name="cpu_utilization_source7" units="%" value="0.04" comment="svchost.exe" type="info" />

<Metric name="cpu_utilization_source8" units="%" value="0.04" comment="svchost.exe" type="info" />

<Metric name="cpu_utilization_source9" units="%" value="0.04" comment="services.exe" type="info" />

<Metric name="cpu_utilization_source10" units="%" value="0.02" comment="ntoskrnl.exe!0xfffff800029ad7f0" type="info" />

<Metric name="idle_wake_sources_lt_100ms" units="count" value="2" />

<Metric name="idle_wake_sources_lt_100ms_source1" units="msec" value="17" comment="hal.dll!0xfffff80002815808" />

<Metric name="idle_wake_sources_lt_100ms_source2" units="msec" value="33" comment="ntoskrnl.exe!0xfffff800029ad7f0" />

<Metric name="pstate_min" value="1596" />

<Metric name="pstate_residency_min" units="%" value="98.91" />

<Metric name="pstate_count_cpu0" units="count" value="2" />

<Metric name="pstate_residency_cpu0_p0" units="%" value="1.09" />

<Metric name="pstate_residency_cpu0_p1" units="%" value="98.91" />

<Metric name="pstate_count_cpu1" units="count" value="2" />

<Metric name="pstate_residency_cpu1_p0" units="%" value="1.09" />

<Metric name="pstate_residency_cpu1_p1" units="%" value="98.91" />

<Metric name="pstate_count_cpu2" units="count" value="2" />

<Metric name="pstate_residency_cpu2_p0" units="%" value="1.09" />

<Metric name="pstate_residency_cpu2_p1" units="%" value="98.91" />

<Metric name="pstate_count_cpu3" units="count" value="2" />

<Metric name="pstate_residency_cpu3_p0" units="%" value="1.09" />

<Metric name="pstate_residency_cpu3_p1" units="%" value="98.91" />

<Metric name="cstate_deepest" value="1" />

<Metric name="cstate_residency_min" units="%" value="99.36" />

<Metric name="cstate_count_cpu0" units="count" value="2" />

<Metric name="cstate_residency_cpu0_c0" units="%" value="0.24" />

<Metric name="cstate_residency_cpu0_c1" units="%" value="99.76" />

<Metric name="cstate_count_cpu1" units="count" value="2" />

<Metric name="cstate_residency_cpu1_c0" units="%" value="0.41" />

<Metric name="cstate_residency_cpu1_c1" units="%" value="99.59" />

<Metric name="cstate_count_cpu2" units="count" value="2" />

<Metric name="cstate_residency_cpu2_c0" units="%" value="0.31" />

<Metric name="cstate_residency_cpu2_c1" units="%" value="99.69" />

<Metric name="cstate_count_cpu3" units="count" value="2" />

<Metric name="cstate_residency_cpu3_c0" units="%" value="0.64" />

<Metric name="cstate_residency_cpu3_c1" units="%" value="99.36" />

<Errors />

</Test>

- <Test xsi:type="IdleDiskTest" name="idle_disk">

<Metric name="idle_diskio_interval_0_5_mins" units="count" value="0" description="Files with frequent DiskIOs and max interval is 0 to 5 minutes" />

<Metric name="idle_diskio_interval_5_10_mins" units="count" value="0" description="Files with frequent DiskIOs and max interval is 5 to 10 minutes" />

In the above example, the CPU Utilization w/o Idle is 4.39%, which is above the suggested 2%. Any value greater than 2% should be investigated, as it would lead to poorer battery life on mobile systems. There were no results in the above example for the Idle_Disk portion of the test.

The example above shows a Quad-CPU with both the processor C-States and P-States and the reported residency for both states. All of the reported C-State residency C1 states are greater than the suggested 95%, and all of the reported P-State residency P1 states are greater than the suggested 98% in this example.

There are also a number of other results files and log files that are collected during the test job run. These include the following directories:

  • Logs all of the log files collected during the test job run

  • Miscall of the different result files that are generated during the test job run

  • PowerCFG the results of the in the box Windows 7 PowerCFG job

  • PowerPolicyall of the power polices on the System Under Test

  • WinSAT Formalthe results of the in the box Windows 7 WinSAT Formal job

  • Idle_CPUall of the "raw" Xperf timing traces

  • Idle_Diskall of the "raw" Xperf timing traces


System Power and Performance Test Suite Boot Shutdown Test

Type: Automated Test

Overview

This test evaluates the overall system Boot and Shutdown performance and collects the performance traces using xBootMgr.exe from the XPerf tool set.

Details:

In the case of the boot section of the test, the test completes a total of six training runs. The first two runs are done through the use of the -prepsystem flag. The purpose of preparing the system is to allow the system to complete defragmentation of the hard disk to ensure that the disk is optimally laid out prior to starting testing. This activity happens every three days at idle when the system is on AC power, thus ensuring that this has been done prior to starting testing. Following the two prep runs an additional four runs are completed to allow Readyboot to properly train the system. This improves boot times and ensured better timing consistency on subsequent runs. Finally, the test completes three timing runs to capture variability from run to run, followed by three analysis runs to capture trace information. The test uses xBootMgr, which initiates the shutdown process and provides tracing capability.

In the case of the shutdown section of the test, there is no need for training runs to complete. Therefore, the test completes three timing runs to capture variability from run to run, followed by three analysis runs to capture trace information. The test uses xBootMgr, which initiates the shutdown process and provides tracing capability.

Run Time: 60 minutes
Log Files:
XMLAggregator.wtl
FQTS.txt Note This is a log file for all of the events that are logged as part of the test execution. This is intended as a troubleshooting aid.
System Restart Required: Yes
Test Category: Supported operating systems for an informative system performance measurement (Note This is not a logo test)

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

Hardware Requirements

The test tool requires the following hardware:

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the System Power and Performance Test Suite Boot Shutdown Test

This test will always return Pass. Review the test results xml file for the specific system performance details.

Example XML output from this test:

<Test xsi:type="BootTest" name="boot">

<Errors />

- <Runs>

- <Run iteration="1" filename="run1.boot.xml">

<Metric name="os_loader" units="msec" value="844" />

<Metric name="boot_pnp" units="msec" value="3640" />

<Metric name="system_pnp" units="msec" value="294" />

<Metric name="smss_pre" units="msec" value="4212" />

<Metric name="smss_init" units="msec" value="5325" />

<Metric name="winlogon_init" units="msec" value="4023" />

<Metric name="explorer_init" units="msec" value="699" />

<Metric name="post_boot" units="msec" value="11400" />

<Metric name="other_kernel_init" units="msec" value="278" />

<Metric name="boot_to_desktop" units="msec" value="15104" />

<Metric name="etUserPerceivedBoot" units="msec" value="16604" />

<Metric name="bios_init" units="msec" value="7817" />

<Metric name="graphics_adapter_session0" units="usec" value="1159310" />

<Metric name="graphics_adapter_session1" units="usec" value="1713040" />

<Metric name="graphics_adapter_predesktop_dwm_cpu_usage" units="usec" value="228324" />

<Metric name="bootprefetch_starttime" units="msec" value="3579" />

<Metric name="bootprefetch_duration" units="msec" value="1446" />

<Metric name="bootprefetch_cache_deletiontime" units="msec" value="60376" />

<Metric name="bootprefetch_hitratio" units="%" value="95.800" />

<Metric name="bootprefetch_request_hitratio" units="%" value="82.200" />

<Metric name="bootprefetchkb" units="kb" value="147844" />

<Metric name="bootprefetch_prefetches" units="count" value="3717" />

<Metric name="bootprefetch_pendkb" units="kb" value="359" />

<Metric name="bootprefetch_pends" units="count" value="22" />

<Metric name="bootprefetch_hitkb" units="kb" value="143455" />

<Metric name="bootprefetch_hits" units="count" value="9048" />

<Metric name="bootprefetch_misskb" units="kb" value="1109" />

<Metric name="bootprefetch_misses" units="count" value="65" />

<Metric name="bootprefetch_writekb" units="kb" value="18055" />

<Metric name="bootprefetch_writes" units="count" value="1366" />

<Metric name="bootprefetch_skipkb" units="kb" value="27104" />

<Metric name="bootprefetch_skips" units="count" value="5" />

<RunErrors />

</Run>

- <Run iteration="2" filename="run2.boot.xml">

<Metric name="os_loader" units="msec" value="845" />

<Metric name="boot_pnp" units="msec" value="3639" />

<Metric name="system_pnp" units="msec" value="292" />

<Metric name="smss_pre" units="msec" value="4229" />

<Metric name="smss_init" units="msec" value="5292" />

<Metric name="winlogon_init" units="msec" value="3969" />

<Metric name="explorer_init" units="msec" value="714" />

<Metric name="post_boot" units="msec" value="11400" />

<Metric name="other_kernel_init" units="msec" value="298" />

<Metric name="boot_to_desktop" units="msec" value="15050" />

<Metric name="etUserPerceivedBoot" units="msec" value="16550" />

<Metric name="bios_init" units="msec" value="7872" />

<Metric name="graphics_adapter_session0" units="usec" value="1156451" />

<Metric name="graphics_adapter_session1" units="usec" value="1690148" />

<Metric name="graphics_adapter_predesktop_dwm_cpu_usage" units="usec" value="234293" />

<Metric name="bootprefetch_starttime" units="msec" value="3578" />

<Metric name="bootprefetch_duration" units="msec" value="1454" />

<Metric name="bootprefetch_cache_deletiontime" units="msec" value="60124" />

<Metric name="bootprefetch_hitratio" units="%" value="95.800" />

<Metric name="bootprefetch_request_hitratio" units="%" value="82.300" />

<Metric name="bootprefetchkb" units="kb" value="148008" />

<Metric name="bootprefetch_prefetches" units="count" value="3720" />

<Metric name="bootprefetch_pendkb" units="kb" value="806" />

<Metric name="bootprefetch_pends" units="count" value="53" />

<Metric name="bootprefetch_hitkb" units="kb" value="143589" />

<Metric name="bootprefetch_hits" units="count" value="9051" />

<Metric name="bootprefetch_misskb" units="kb" value="899" />

<Metric name="bootprefetch_misses" units="count" value="59" />

<Metric name="bootprefetch_writekb" units="kb" value="18246" />

<Metric name="bootprefetch_writes" units="count" value="1354" />

<Metric name="bootprefetch_skipkb" units="kb" value="27104" />

<Metric name="bootprefetch_skips" units="count" value="5" />

<RunErrors />

</Run>

- <Run iteration="3" filename="run3.boot.xml">

<Metric name="os_loader" units="msec" value="847" />

<Metric name="boot_pnp" units="msec" value="3639" />

<Metric name="system_pnp" units="msec" value="291" />

<Metric name="smss_pre" units="msec" value="4190" />

<Metric name="smss_init" units="msec" value="5393" />

<Metric name="winlogon_init" units="msec" value="4049" />

<Metric name="explorer_init" units="msec" value="729" />

<Metric name="post_boot" units="msec" value="11600" />

<Metric name="other_kernel_init" units="msec" value="260" />

<Metric name="boot_to_desktop" units="msec" value="15209" />

<Metric name="etUserPerceivedBoot" units="msec" value="16909" />

<Metric name="bios_init" units="msec" value="8036" />

<Metric name="graphics_adapter_session0" units="usec" value="1168772" />

<Metric name="graphics_adapter_session1" units="usec" value="1703906" />

<Metric name="graphics_adapter_predesktop_dwm_cpu_usage" units="usec" value="234600" />

<Metric name="bootprefetch_starttime" units="msec" value="3578" />

<Metric name="bootprefetch_duration" units="msec" value="1439" />

<Metric name="bootprefetch_cache_deletiontime" units="msec" value="60404" />

<Metric name="bootprefetch_hitratio" units="%" value="96.000" />

<Metric name="bootprefetch_request_hitratio" units="%" value="82.400" />

<Metric name="bootprefetchkb" units="kb" value="148156" />

<Metric name="bootprefetch_prefetches" units="count" value="3725" />

<Metric name="bootprefetch_pendkb" units="kb" value="1001" />

<Metric name="bootprefetch_pends" units="count" value="57" />

<Metric name="bootprefetch_hitkb" units="kb" value="143992" />

<Metric name="bootprefetch_hits" units="count" value="9065" />

<Metric name="bootprefetch_misskb" units="kb" value="840" />

<Metric name="bootprefetch_misses" units="count" value="51" />

<Metric name="bootprefetch_writekb" units="kb" value="18117" />

<Metric name="bootprefetch_writes" units="count" value="1365" />

<Metric name="bootprefetch_skipkb" units="kb" value="27104" />

<Metric name="bootprefetch_skips" units="count" value="5" />

<RunErrors />

</Run>

</Runs>

</Test>

- <Test xsi:type="ShutdownTest" name="shutdown">

<Errors />

- <Runs>

- <Run iteration="1" filename="Run1.shutdown.xml">

<Metric name="total_shutdown" units="msec" value="7061" />

<Metric name="pre_shutdown" units="msec" value="222" />

<Metric name="user_session" units="msec" value="4724" />

<Metric name="system_session" units="msec" value="582" />

<Metric name="kernel_shutdown" units="msec" value="1533" />

</Run>

- <Run iteration="2" filename="Run2.shutdown.xml">

<Metric name="total_shutdown" units="msec" value="4568" />

<Metric name="pre_shutdown" units="msec" value="216" />

<Metric name="user_session" units="msec" value="2498" />

<Metric name="system_session" units="msec" value="582" />

<Metric name="kernel_shutdown" units="msec" value="1272" />

</Run>

- <Run iteration="3" filename="Run3.shutdown.xml">

<Metric name="total_shutdown" units="msec" value="4415" />

<Metric name="pre_shutdown" units="msec" value="227" />

<Metric name="user_session" units="msec" value="2416" />

<Metric name="system_session" units="msec" value="551" />

<Metric name="kernel_shutdown" units="msec" value="1221" />

</Run>

</Runs>

</Test>

The above example shows the results from the three timing runs of the Boot section of the System Power and Performance Test Suite Boot Shutdown Test and the results of the three timing runs from the Shutdown section. The total Boot time for each run is calculated by totaling the sum of all of the boot phases, OSLoaderDuration, BootPnP, SystemPnP, OtherKernelInit, SessionInit, WinlogonInit, ExplorerInit, and PostBoot. The PostBoot duration value has to be adjusted by subtracting 10000msec before the final Boot Time value is calculated. In the boot_1.etl.xml example run above, the total boot time would be, 20.43 sec.

The total system Shutdown time is calculated by totaling the different shutdown phases: PreShutdown, UserSession, SystemSession, and KernelShutdown. In the above shutdown_1.etl.xml run, the TotalShutdown time is 7.061sec.

For a detailed description of the Boot and Shutdown times and their different phases please refer to the "On/Off Transition Performance Analysis of Windows Vista" whitepaper available at http://www.microsoft.com/whdc/system/sysperf/On-Off_Transition.mspx

There are also a number of other results files and log files that collected during the test job run. These include the following directories:

  • Logs all of the log files collected during the test job run

  • Miscall of the different result files that are generated during the test job run

  • PowerCFG the results of the in the box Windows 7 PowerCFG job

  • PowerPolicyall of the power polices on the System Under Test

  • WinSAT Formalthe results of the in the box Windows 7 WinSAT Formal job

  • Bootall of the "raw" Xperf timing traces

  • Shutdownall of the "raw" Xperf timing traces


System Power and Performance Test Suite Hibernate Test

Type: Automated Test

Overview

This test measures the overall system Hibernate Suspend and Resume performance.

Details

The test separates timing and analysis runs due to the increased instrumentation required for the analysis runs that may impact the timing. In the case of hibernate and resume from hibernate, the test completes a total of three training runs to allow SuperFetchTM to properly train the system, which will improve hibernate and resume performance and ensure better timing consistency on subsequent runs. The test then reboots the system and waits 5 minutes to allow for any post boot activity to complete prior to completing one cold analysis run. Finally, the test completes three timing runs in order to capture variability from run to run followed by one analysis run to help capture how the system behaves after several hibernate/resume transitions.
Run Time: 60 minutes
Log Files:
XMLAggregator.wtl
FQTS.txt Note This is a log file for all of the events that are logged as part of the test execution. This is intended as a troubleshooting aid.
System Restart Required:
Test Category: Supported operating systems for an informative system performance measurement (Note This is not a logo test)

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

Hardware Requirements

The test tool requires the following hardware:

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the System Power and Performance Test Suite Hibernate Test

This test will always return Pass. Review the test results xml file for the specific system performance details.

Example XML output for this test:

- <Test xsi:type="HibernateTest" name="hibernate">

<Errors />

- <Runs>

- <Run iteration="1" filename="Run1.suspend.xml">

<Metric name="suspend_apps" units="usec" value="1635499" />

<Metric name="suspend_services" units="usec" value="15163" />

<Metric name="query_devices" units="usec" value="14123" />

<Metric name="suspend" units="usec" value="2656000" />

<Metric name="resume" units="usec" value="1927000" />

<Metric name="suspend_devices" units="usec" value="733556" />

<Metric name="resume_devices" units="usec" value="420031" />

<Metric name="hiberfile_write" units="usec" value="6228000" />

<Metric name="hiberfile_read" units="usec" value="3956000" />

<Metric name="hiber_pages_written" units="pages" value="45658" />

<Metric name="suspend_total" units="usec" value="8884000" />

<Metric name="resume_total" units="usec" value="5883000" />

<Metric name="graphics_adapter_suspend" units="usec" value="230531" />

<Metric name="graphics_adapter_resume" units="usec" value="165030" />

<Metric name="hiber_file_extents_start" units="sectors" value="74868560" type="info" />

<Metric name="hiber_file_extents_end" units="sectors" value="78011279" type="info" />

</Run>

- <Run iteration="2" filename="Run2.suspend.xml">

<Metric name="suspend_apps" units="usec" value="1612786" />

<Metric name="suspend_services" units="usec" value="16483" />

<Metric name="query_devices" units="usec" value="12696" />

<Metric name="suspend" units="usec" value="2697000" />

<Metric name="resume" units="usec" value="2032000" />

<Metric name="suspend_devices" units="usec" value="670868" />

<Metric name="resume_devices" units="usec" value="522276" />

<Metric name="hiberfile_write" units="usec" value="6213000" />

<Metric name="hiberfile_read" units="usec" value="3900000" />

<Metric name="hiber_pages_written" units="pages" value="44722" />

<Metric name="suspend_total" units="usec" value="8910000" />

<Metric name="resume_total" units="usec" value="5932000" />

<Metric name="graphics_adapter_suspend" units="usec" value="210259" />

<Metric name="graphics_adapter_resume" units="usec" value="168101" />

<Metric name="hiber_file_extents_start" units="sectors" value="74868560" type="info" />

<Metric name="hiber_file_extents_end" units="sectors" value="78011279" type="info" />

</Run>

- <Run iteration="3" filename="Run3.suspend.xml">

<Metric name="suspend_apps" units="usec" value="1624827" />

<Metric name="suspend_services" units="usec" value="15809" />

<Metric name="query_devices" units="usec" value="13962" />

<Metric name="suspend" units="usec" value="2583000" />

<Metric name="resume" units="usec" value="1899000" />

<Metric name="suspend_devices" units="usec" value="701635" />

<Metric name="resume_devices" units="usec" value="393250" />

<Metric name="hiberfile_write" units="usec" value="6645000" />

<Metric name="hiberfile_read" units="usec" value="3887000" />

<Metric name="hiber_pages_written" units="pages" value="44781" />

<Metric name="suspend_total" units="usec" value="9228000" />

<Metric name="resume_total" units="usec" value="5786000" />

<Metric name="hiber_pages_written_reg" units="pages" value="44244" />

<Metric name="graphics_adapter_suspend" units="usec" value="208144" />

<Metric name="graphics_adapter_resume" units="usec" value="164582" />

<Metric name="hiber_file_extents_start" units="sectors" value="74868560" type="info" />

<Metric name="hiber_file_extents_end" units="sectors" value="78011279" type="info" />

</Run>

</Runs>

In the above example the Hibernate Suspend total time is calculated by totaling the Suspend and HiberfileWrite times. In the hibernate_1.etl.xml run above, the Hibernate Suspend total is 8.884sec. The Hibernate Resume total time is calculated by totaling the Resume and HiberfileRead times. In the hibernate_1.etl.xml run above, the Hibernate Resume total is 5.883sec. For a detailed description of Hibernate Suspend and Resume times and their different phases, refer to the "On/Off Transition Performance Analysis of Windows Vista" whitepaper available at http://www.microsoft.com/whdc/system/sysperf/On-Off_Transition.mspx

There are also a number of other results files and log files that collected during the test job run. These include the following directories:

  • Logs all of the log files collected during the test job run

  • Miscall of the different result files that are generated during the test job run

  • PowerCFG the results of the in the box Windows 7 PowerCFG job

  • PowerPolicyall of the power polices on the System Under Test

  • WinSAT Formalthe results of the in the box Windows 7 WinSAT Formal job

  • Hibernateall of the "raw" Xperf timing traces


System Power and Performance Test Suite Power Policy Test

Type: Automated Test

Overview

This test obtains the Power Policy settings available for the system

Details

This test helps ensure that systems are configured properly to take advantage of the power policy capabilities that can help extend battery life on mobile systems. It also ensured that the settings are Energy Star 4.0 compliant. The majority of these settings are exposed in the UI in Windows Vista, except for the Domain Idle Accounting settings. The test first identifies all of the power plans that are currently available on the system, and then captures all of the power plan settings for each power plan.

Run Time: 15 minutes
Log File:
\XMLAggregator.exe
FQTS.txt Note This is a log file for all of the events that are logged as part of the test execution. This is intended as a troubleshooting aid.
System Restart Required:
Test Category: Supported operating systems for an informative set of system power details (Note This is not a logo test)

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

Hardware Requirements

The test tool requires the following hardware:

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the System Power and Performance Test Suite Power Policy Test

This test will always return Pass. Review the test results xml file for the specific system power details.

Example XML output from this test:

<Test xsi:type="PowerPolicyTest" name="PowerPolicy">

<Metric name="power_wirelessadapter_ac" value="0" description="balanced" comment="Maximum Performance" />

<Metric name="power_wirelessadapter_dc" value="0" description="balanced" comment="Medium Power Saving" />

<Metric name="power_sleeptimeout_ac" value="0" description="balanced" />

<Metric name="power_sleeptimeout_dc" value="0" description="balanced" />

<Metric name="power_usb_selectivesuspend_ac" value="1" description="balanced" comment="Enabled" />

<Metric name="power_usb_selectivesuspend_dc" value="1" description="balanced" comment="Enabled" />

<Metric name="power_displaytimeout_ac" value="5" description="balanced" />

<Metric name="power_displaytimeout_dc" value="5" description="balanced" />

<Metric name="power_wirelessadapter_ac" value="0" description="high performance" comment="Maximum Performance" type="info" />

<Metric name="power_wirelessadapter_dc" value="0" description="high performance" comment="Maximum Performance" type="info" />

<Metric name="power_sleeptimeout_ac" value="0" description="high performance" type="info" />

<Metric name="power_sleeptimeout_dc" value="0" description="high performance" type="info" />

<Metric name="power_usb_selectivesuspend_ac" value="1" description="high performance" comment="Enabled" type="info" />

<Metric name="power_usb_selectivesuspend_dc" value="1" description="high performance" comment="Enabled" type="info" />

<Metric name="power_displaytimeout_ac" value="10" description="high performance" type="info" />

<Metric name="power_displaytimeout_dc" value="10" description="high performance" type="info" />

<Metric name="power_wirelessadapter_ac" value="0" description="power saver" comment="Maximum Performance" type="info" />

<Metric name="power_wirelessadapter_dc" value="0" description="power saver" comment="Maximum Power Saving" type="info" />

<Metric name="power_sleeptimeout_ac" value="0" description="power saver" type="info" />

<Metric name="power_sleeptimeout_dc" value="0" description="power saver" type="info" />

<Metric name="power_usb_selectivesuspend_ac" value="1" description="power saver" comment="Enabled" type="info" />

<Metric name="power_usb_selectivesuspend_dc" value="1" description="power saver" comment="Enabled" type="info" />

<Metric name="power_displaytimeout_ac" value="2" description="power saver" type="info" />

<Metric name="power_displaytimeout_dc" value="2" description="power saver" type="info" />

<Errors />

</Test>

There are three different power policies available on the system and they are displayed above: Balanced, High Performance, and Power Save.


System Power and Performance Test Suite Standby Test

Type: Automated Test

Overview

This test collects standby suspend and resume performance traces using xBootMgr.exe from the XPerf tool set.

Details

The test separates timing and analysis runs due to the increased instrumentation required for the analysis runs that may impact the timing. In the case of standby and resume from standby, the test completes a total of three training runs to allow SuperFetchTM to properly train the system, which will improve standby and resume performance and ensure better timing consistency on subsequent runs. The test then reboots the system and waits 5 minutes to allow for any post boot activity to complete prior to completing one cold analysis run. Finally, the test completes three timing runs to capture variability from run to run, followed by one analysis run to help capture how the system behaves after several standby/resume transitions.
Run Time: 60 minutes
Log Files:

XMLAggregator.wtl

FQTS.txt Note This is a log file for all of the events that are logged as part of the test execution. This is intended as a troubleshooting aid.
System Restart Required:
Test Category: Supported operating systems for an informative system performance measurement (Note This is not a logo test)

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

Hardware Requirements

The test tool requires the following hardware:

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the System Power and Performance Test Suite Standby Test

This test will always return Pass. Review the test results xml file for the specific system performance details.

Example XML output from this test:

<Test xsi:type="StandbyTest" name="standby">

<Errors />

- <Runs>

- <Run iteration="1" filename="Run1.suspend.xml">

<Metric name="suspend_apps" units="usec" value="554273" />

<Metric name="suspend_services" units="usec" value="17314" />

<Metric name="query_devices" units="usec" value="1275" />

<Metric name="suspend" units="usec" value="2704000" />

<Metric name="resume" units="usec" value="570000" />

<Metric name="suspend_devices" units="usec" value="559186" />

<Metric name="resume_devices" units="usec" value="329713" />

<Metric name="hiberfile_write" units="usec" value="3846000" />

<Metric name="bios_init" units="usec" value="176000" />

<Metric name="resume_bios_and_devices" units="usec" value="505713" />

<Metric name="suspend_total" units="usec" value="6550000" />

<Metric name="resume_total" units="usec" value="746000" />

<Metric name="graphics_adapter_suspend" units="usec" value="345024" />

<Metric name="graphics_adapter_resume" units="usec" value="209526" />

</Run>

- <Run iteration="2" filename="Run2.suspend.xml">

<Metric name="suspend_apps" units="usec" value="545382" />

<Metric name="suspend_services" units="usec" value="17359" />

<Metric name="query_devices" units="usec" value="1302" />

<Metric name="suspend" units="usec" value="2274000" />

<Metric name="resume" units="usec" value="623000" />

<Metric name="suspend_devices" units="usec" value="509927" />

<Metric name="resume_devices" units="usec" value="342757" />

<Metric name="hiberfile_write" units="usec" value="3823000" />

<Metric name="bios_init" units="usec" value="176000" />

<Metric name="resume_bios_and_devices" units="usec" value="518757" />

<Metric name="suspend_total" units="usec" value="6097000" />

<Metric name="resume_total" units="usec" value="799000" />

<Metric name="graphics_adapter_suspend" units="usec" value="299461" />

<Metric name="graphics_adapter_resume" units="usec" value="210632" />

</Run>

- <Run iteration="3" filename="Run3.suspend.xml">

<Metric name="suspend_apps" units="usec" value="564457" />

<Metric name="suspend_services" units="usec" value="17680" />

<Metric name="query_devices" units="usec" value="1421" />

<Metric name="suspend" units="usec" value="2402000" />

<Metric name="resume" units="usec" value="573000" />

<Metric name="suspend_devices" units="usec" value="513174" />

<Metric name="resume_devices" units="usec" value="472726" />

<Metric name="hiberfile_write" units="usec" value="3763000" />

<Metric name="bios_init" units="usec" value="181000" />

<Metric name="resume_bios_and_devices" units="usec" value="653726" />

<Metric name="suspend_total" units="usec" value="6165000" />

<Metric name="resume_total" units="usec" value="754000" />

<Metric name="graphics_adapter_suspend" units="usec" value="298063" />

<Metric name="graphics_adapter_resume" units="usec" value="209197" />

</Run>

</Runs>

</Test>

In the above example the Suspend total time is calculated by totaling the Suspend times. In the standby_1.etl.xml run above, the Suspend total is 6.65sec. The Suspend Resume total time is calculated by totaling the Resume times. In the standby_1.etl.xml run above, the Resume total is .764sec. For a detailed description of the Standy Suspend and Resume times and their different phases, refer to the "On/Off Transition Performance Analysis of Windows Vista" whitepaper available at http://www.microsoft.com/whdc/system/sysperf/On-Off_Transition.mspx

There are also a number of other results files and log files that collected during the test job run. These include the following directories:

  • Logs all of the log files collected during the test job run

  • Miscall of the different result files that are generated during the test job run

  • PowerCFG the results of the in the box Windows 7 PowerCFG job

  • PowerPolicyall of the power polices on the System Under Test

  • WinSAT Formalthe results of the in the box Windows 7 WinSAT Formal job

  • Standbyall of the "raw" Xperf timing traces


System Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


Aero Acceptance Test

Overview

The Aero Acceptance Test (AeroAT.exe) is the logo test for SYSFUND-046, often called the "Aereo" requirement. AeroAT runs on Windows Vista and will indicate if a computer passes or fails the Aero logo requirements.

Note This test applies to client only.

Details

AeroAT uses the WinSAT DWM assessment to make its measurements. WinSAT.exe is the system assessment tool that is built into Windows Vista. AeroAT examines the configuration of the computer, constructs an appropriate WiNSAT command, the runs the WinSAT DWM assessment five times. AeroAT then selects the best score that is produced from the five runs. If this measurement exceeds the logo requirement, the computer passes.

How AeroAT finds WinSAT.EXE

By default, AeroAT use the version of WinSAT that resides in the operating system in the %systemroot%\System32 folder. If the version of WinSAT in the System32 directory is older than build 5367, AeroAT will look for a newer version of WinSAT in the same directory as AeroAT.exe.

There are two command switches that you can use to control which copy of WinSAT.exe that AeroAT uses.

  • The -local switch forces AeroAT to use the version of WinSAT that is in the same directory as AeroAT.exe.

  • The -wsp switch specifies a specific copy of WinSAT for the test by providing a relative or absolute path.

CSV File OutputThe -csv <filename> command switch causes AeroAT to save detailed test information to a CSV file. The output file can be on the local computer or on a server. AeroAT is designed so that you can collect data from many computers in one CSV file on a server. For example, you could run the following command on many computers:

Aeroat -csv \\titan\AeroATData\allmachines.csv

This command will run AeroAT and save the data from all of the computers to the file allmachines.csv on the "aeroATData" share on the "titan" server.

Note The account that AeroAT runs under on a computer needs write access to the share and file on the server.

The data is saved in an ASCII, comma-separated value (CSV) format. You can read this file with Microsoft Excel.

AeroAT saves data in the following columns.

  • MachineName is the name of the computer on which the assessment was run.

  • User name is the name of the user that is logged in and that ran the test.

  • User is the "friendly name" of the user that is logged in and that ran the test.

  • OsVersion is the version number of the operating system that the test ran on.

  • OsBuild is the build number of the operating system that the test ran on.

  • OsProduct is the product name of the operating system that the test ran on.

  • OsBrand is the brand string of the operating system that the test ran on.

  • OsBuildLab is the branch name of the operating system that the test ran on.

  • AeroAT Version is the version of AeroAT that you used to run the test.

  • WinSAT Path is the path to the version of WinSAT.exe that you used to run the test.

  • WinSAT Version is the version of WinSAT.exe that you used to run the test.

  • Adapter is the adapter string that the resident LDDM driver returned.

  • Driver Version is the driver assembly's version number. This number is the same value that you can find in the Driver tab in Device Manager under Display Adapter.

  • Driver Date is the driver assembly's date. This date is the value that you can find in the Driver tab in Device Manager under Display Adapter.

  • Date is the date and time, in human-readable format, when the test was run.

  • RataDie is the date and time when the test was run. You can use the format to sort rows by date and time. The format is <day>:<time> where <day> is the number of days since December 31 of the year zero in the proleptic Gregorian calendar. Thus, day one occurs on January 1st of the year. The <time> field is the number of milliseconds since 12:00 A.M. (the start of the day).

Note This information is the note that is passed into AeroAT by using the -note command switch. If the switch was not used, this field is blank.

  • Ded Vid Mem is the amount of dedicated video memory.

  • Ded Sys Vid Mem is the amount of system memory that is dedicated to video memory.

  • Shared Sys Mem is the amount of memory that is a dynamic value and changes.

  • Phys Memory is the amount of physical system memory that is available to the operating system.

  • Pri-Mon W is the width, in pixels, of the computer's primary monitor.

  • Pri-Mon H is the height, in pixels, of the computer's primary monitor.

  • Total Pixels is the total number of pixels on the computer's primary monitor (width x height).

  • Num Monitors is the number of monitors that are attached to the computer.

  • Asmt W is the width of the render textures that are used for the assessment.

  • Asmt H is the height of the render textures that are used for the assessment.

  • Win Pcnt Sz is the percent size of the windows (textures) that are used for the assessment.

  • Win W is the width of the windows (textures) that are used for the assessment.

  • Win H is the height of the windows (textures) that are used for the assessment.

  • Num Wins is the number of windows (textures) that are used for the assessment.

  • Win Tex Sz is the size of a window (textures), in bytes.

  • Tot Tex Sz is the total size of the window textures, in bytes.

  • Iters is the number of iterations that were run.

  • Bandwidth is the graphics sub-system's reported memory bandwidth.

  • Range is the range of measurement taken.

  • Range % is the range divided by the arithmetic mean (average) of the measurements.

  • Status is PASS or FAIL.

  • Units is the units of the measurements (for example, MB/s represents megabytes per second).

After these columns, the CSV file contains a field that is marked with an asterisk (*) character. This asterisk divides the information fields from the data fields.

The fields after this marker are the individual measurements that AeroAT took.

Run Time: Approximately 1 minute
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • 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

Running Aero Acceptance Test

Command Syntax

Command option | Description
-v | Enable verbose output.
-vv | Enable very verbose output.
-iter <n> | Run the "WinSAT DWM" command <n> times. The default is 5.
-csv <file name> | Save results to the specified CSV file.
-note <text> | Include the text in the CSV output. The text can be in quotes.
-bf <file name> | Save a batch file to <file name> that can be used to run WinSAT with the same command line parameters that are used in the test.
-wsp <exe name> | Use the version of WinSAT that the EXE name specifies.

Cautions

Video playback, or large numbers of open windows can interfere with this test.

Troubleshooting

AeroAT is merely a wrapper for WinSAT. If the test appears to fail and there is no obvious error, use AeroAT with the -bf <fn> switch. This switch will create a batch file that you can use to run WinSAT and determine the underlying error. Note, it can sometimes be helpful to add the -v switch to the WinSAT command line. This switch will cause WinSAT to display extra diagnostic information to the console window. You can also examine the WinSAT log file, which is saved in %systemroot%\winsat\winsat.log.

Test Assertions

Windows Logo Program: SYSFUND-0046 Premium system ships with display adapter or chipset with the Aero theme enabled by default


Boot Test (SYSTEM)

Type: Automated Test

Overview

This test verifies the adherence to the system requirements for supporting the 2.2 TB boot scenario.

Details

For more information on this test, see Boot Test.


BitLocker Drive Encryption BIOS Interface Logo Test

Overview

This test validates that the BIOS on this platform meets the Windows 7, Windows Vista, Windows Server 2008, and Windows Server 2008 R2 BitLocker Drive Encryption feature requirements.

Note This test applies to both client and server.

Details

This test is a test of pre-operating system functionality.

This test is executed in the pre-operating system environment and not on the Microsoft Windows operating systems in order to get access to the TCG BIOS interface. The Tcgtest.exe binary 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 restart. 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 file name TCGTestPre.xml; the second run of Tcgtest.exe (after the reboot) will generate the log with the file name 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Server 2008

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • TPM 1.2 (the TPM must be enabled, activated, and ownership must not have been taken)

  • BitLocker Drive Encryption should be turned off (or not bound to the TPM)

Processor

  • x86

  • x64

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:

  • Make sure that Tcgpreos.exeis in the same directory asTcgtest.exe.

  • To start the test and initialize the test environment, type the following in the command line:

    Tcgtest.exe

  • Upon return to the command line prompt, manually restart the system; test results are determined in the pre-OS phase of this restart.

After the system restarts, you can see test results by typing the following in the command line:
Tcgtest.exe

Manual Interaction

This test may put the machine to sleep or hibernate using a timer to wake it back up. Not all platforms support waking on a timer. Such platforms will require the test operator to manually wake the machine from sleep, or power on the machine after hibernation.

TPM State:

To run this test in DTM, you must have the TPM enabled, the TPM activated and the TPM must have no owner. You can usually accomplish these steps by using the system BIOS setup utility to clear, enable, and activate the TPM, but not all BIOS setup tool implementations achieve the correct state by following the steps. The location of the TPM setting in the BIOS utility may vary.

BIOS with capabilities to hide the TPM:

Some BIOS implementations have features to hide the physical presence of TPM from the platform by not enumerating the TPM device through ACPI. Unless the platform is manufactured to permanently and irreversibly prevent usage of the TPM, it must not be hidden while running this test.

Command Syntax

Command option | Description
tcgtest.exe | Enter this after system restarts.

Code Tour

File Manifest

File | Location
tcgtest.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\biosif
tcgpreos.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\tools

Test Assertions

1Validate 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 secure startup by using system firmware security enhancements
2Validate correct recovery from S4 (Hibernate)
Test Assertion GUID: 48c4ebbb-0f73-4e9a-bd8a-9bdc96f7b7da
Windows Logo Program: SYSFUND-0031 Systems implementing TPM support secure startup 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.
3Validate correct recovery from S3 (Suspend)
Test Assertion GUID: 458ba7ac-e574-4109-adcb-5b066ecced31
Windows Logo Program: SYSFUND-0031 Systems implementing TPM support secure startup 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.
4Prepare Environment for PreOS Tests
Test Assertion GUID: E3B099A1-92FA-4491-A611-9BAA4070C970
Windows Logo Program: SYSFUND-0031 Systems implementing TPM support secure startup by using system firmware security enhancements
5Validate 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 secure startup 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]
6TCPA ACPI Table Test
Test Assertion GUID: 26af1a0d-2b96-4929-86b6-ee57f4ef0653
Windows Logo Program: SYSFUND-0031 Systems implementing TPM support secure startup 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)
7Validate the consistency of the TCPA EventLog
Test Assertion GUID: 234f708f-296b-4d5b-af7d-41110562808e
Windows Logo Program: SYSFUND-0031 Systems implementing TPM support secure startup 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


BitLocker Drive Encryption BIOS USB Logo Test

Type: Automated Test

Overview

The BIOS USB Storage test for the BitLocker Drive Encryption (BitLocker) feature of Windows Vista and Windows Server 2008 validates that the system BIOS support for USB storage class devices meets the BitLocker feature requirements.

Note This test applies to both client and server.

Details

This test tests:

  1. (In the operating system environment) System write operations to a USB mass storage class device.

  2. (In the pre-operating system environment) System BIOS read operations from a USB mass storage class device.

Run Time: 5 minutes
Log File:FveUsbPreTest.xml and FveUsbPostTest.xml
System Restart Required: Yes
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Server 2008

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • WDK standard USB Flash Drive (FAT / FAT32). This device should not be encrypted.

Processor

  • x86

  • x64

Running BitLocker Drive Encryption BIOS USB Logo Test

  • Run the job from the DTM environment.

  • A tester must be present or configure autologon to properly run this test.

  • You will also need a valid user account and a USB Flash Drive (FAT / FAT32).

  • Alternatively, do the following to run this test manually:

  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 FveUsbPostTest.exe.

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\usbLogo

Test Assertions

1BIOS USB write operation succeeds
Test Assertion GUID: 33E37DCE-57BE-11DA-8BDE-F66BAD1E3F3A
Windows Logo Program: SYSFUND-0069 Systems support secure startup by providing system firmware support for writing to and reading from USB flash devices in the pre-operating system environment
2BIOS USB read operation succeeds
Test Assertion GUID: 64834B74-5BD0-11DA-8BDE-F66BAD1E3F3A
Windows Logo Program: SYSFUND-0069 Systems support secure startup by providing system firmware support for writing to and reading from USB flash devices in the pre-operating system environment


Display Devices - Verify Digital Connector

Type: Automated Test

Overview

This test verifies that any system to be logo-tested has at least one digital connector. Digital connectors provide higher bandwidth for resolutions and support hotplug detection.

Details

The following connector types recognized by this test:

  • DisplayPort Embedded

  • DisplayPort External

  • DVI

  • HDMI

  • Internal

  • SDI

  • UDI Embedded

  • UDI External

Run Time: Less than 1 minute
Log File: InternalAdaptersTest.xml
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: InternalAdaptersTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

Test returns either PASS or FAIL. A fail on this test indicates the system did not report any digital connectors on the system. The test might report SKIP if the test cannot obtain all the paths, due to QueryDisplayConfig returning a non-success result.

Command Syntax

Command option | Description
InternalAdaptersTest.exe | Without any options, the test lists the available tests contained within the executable, but does not run any tests.
HasDigital | Executes the test described in this document.

Code Tour

File Manifest

File | Location
InternalAdaptersTest.exe | [WTT\TestBinRoot]\nttest\windowstest\graphics\d3d\Integration\DXGIGDIInterop

Test Assertions

SYSFUND-0218


DX10 Graphics Enforcement Test

For detailed information about this test, please go to DX10 Graphics Enforcement Test.


HAL Test

Type: Automated Test

Overview

The HAL Test verifies high precision event timer (HPET) hardware for logo requirements.

This test verifies that:

  • The system that you are testing is using an HPET device.

  • The HPET frequency is between 10 MHz and 500 MHz.

  • The timer does not glitch or run backward.

Note This test applies to both client and server.

Details

You can run this test manually by using the haltest.exe timers /logo command. This command is the only supported command line for logo testing.

To debug test failures, you need complete log files. This test will generate a log file called haltest.wtl. Be sure to include this file with any questions about failing results. You might also need to include a kernel debugger remote session.

The test succeeds or fails based on the pass and failure count rollup that appears at the end of the haltest.wtl log file that is created when you run haltest.exe timers /logo. Each subtest within the log file must pass for the overall result to be "pass."

For more information, see the Guidelines For Providing Multimedia Timer Support topic on the Microsoft Windows Hardware Developer Central (WHDC) Web site and IA-PC HPET (High Precision Event Timers) Specification.

Run Time: 5-10 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 the test, start the test, wait for the test to finish, and then examine haltest.wtl for results.

Command Syntax

Command option | Description
haltest timers /logo | Timers only for HPET validation

Cautions

You must set the system time increment to the default when the test is run. Otherwise, the test will fail. Applications such as Microsoft 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.

Test Assertions

HPET Description and Performance Counter frequency requirment.HPET Description and Performance Counter frequency requirment.
Test Assertion GUID: c36d304a-ac81-4698-ba64-b8d1178b2586
Windows Logo Program: Anonymous
Additional Information: Content will be published


Logo - S3 Resume Time Verification

Type: Automated Test

Overview

The S3 resume logo test validates that the system resumes from the ACPI S3 sleep state within 2 seconds.

The test cycles the system through four sleep transitions and validates that the total resume time is less than 2000 milliseconds for each of the last three sleep transitions. Hybrid sleep is disabled for each of the sleep transitions and total time is measured as the sum of the BIOS Initialization and Driver Initialization phase durations.

Note This test applies to client only.

Details

The S3 resume logo test uses the PwrTest tool to cycle the system through four ACPI S3 sleep transitions. The total resume time of each sleep transition is measured. The total resume time is validated to be less than 2000 milliseconds for each of the last three sleep transitions. Total resume time is measured as the sum of the BIOS Initialization and Driver Initialization phase durations.

Note If the system is equipped with fully-buffered DIMMs (FB-DIMM), the System_HasFBDIMM parameter should be set to 1. This parameter enables the test to automatically adjust the total resume time threshold to 7000 milliseconds.

For more information about optimizing a system for S3 resume performance, see Measuring System Resume Performance on Windows Vista.

Run Time: 8 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Test Assertions

Windows Logo Program: SYSFUND-0004 System resumes from ACPI S3 state in ≤2 s


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.

Note This test applies to client only.

Details

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.

  • ES

  • Displays and records thread execution state changes. Thread execution states allow applications and services to temporarily override power management settings such as the monitor and sleep idle timeouts.

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

es for thread execution state changes

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 Microsoft Windows Driver Kit (WDK) tools that use the WTTlog interface.

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
/unattend | Indicates the system should wake unattended. PwrTest will not request the display to be enabled between each sleep cycle. | This feature is disabled by default.

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 Info 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.

Execution State Scenario Information

The PwrTest Execution State scenario is designed to log and display thread execution state change events.

Applications and services may temporarily override power management settings such as the monitor and sleep idle time outs by changing their thread execution state. Execution state for a given thread can be changed through the Microsoft Win32 SetThreadExecutionState() API.

The Execution State scenario will display and log in real-time applications and services that are changing their thread execution state. This can be useful to diagnose applications and services that are preventing the monitor or system from going idle.

For more information about the SetThreadExecutionState() API, see SetThreadExecutionState on the MSDN Web site.

To learn more about the Execution State scenario, type:

PwrTest /es /?

The PwrTest /es scenario can be exited by pressing the 'q' key.

Note, PwrTest is not capable of determining changes to thread execution state before the Execution State scenario is started.

Argument | Description | Default value
(no arguments) | n/a | n/a

Examples

PwrTest /es

PwrTest will display and log changes to thread execution state.

XML Logfile Output

The Execution State scenario generates the following XML elements:

<ExecutionState>

<EsChange>

<Time>09:13:47</Time>

<Process>\Device\HarddiskVolume1\Program Files\Windows Media Player\wmplayer.exe</Process>

<RawState>0x80000001</RawState>

<Continuous>TRUE</Continuous>

<System>TRUE</System>

<Display>FALSE</Display>

<AwayMode>FALSE</AwayMode>

</EsChange>

<EsChange>

<Time>09:13:47</Time>

<Process>\Device\HarddiskVolume1\Program Files\Windows Media Player\wmplayer.exe</Process>

<RawState>0x80000003</RawState>

<Continuous>TRUE</Continuous>

<System>TRUE</System>

<Display>TRUE</Display>

<AwayMode>FALSE</AwayMode>

</EsChange>

</ExecutionState>

This table describes the Execution State scenario XML elements in detail:

Element | Description
<ExecutionState> | Contains information related to the execution state scenario. Only one <ExecutionState> element per PwrTest log file.
<EsChange> | Contains information related a single thread execution state change event. There will be one <EsChange> element for each thread execution state change event recorded in the PwrTest log file.
<Time> | Indicates the time when the execution state change event occurred.
<Process> | Indicates the path to the image file for the process that requested the execution state change.
<RawState> | Indicates the request execution state. This state is a 32-bit value of type EXECUTION_STATE (see Windows.h).
<Continuous> | Indicates if the process requested the execution state change to be continuous (ES_CONTINUOUS).
<System> | Indicates if the process requested the system to be available (ES_SYSTEM_REQUIRED).
<Display> | Indicates if the process requested the display to be available (ES_DISPLAY_REQUIRED).
<AwayMode> | Indicates if the process requested away mode to be enabled (ES_AWAYMODE_REQUIRED).

Run Time: 10 minutes
Log File:PwrTestLog.xml
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Code Tour

File Manifest

File | Location
pwrtest.exe | tools\acpi\pwrtest

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


RCTester : ehome - Premium System Tests - IR

Type: Automated Test

Overview

The test verifies that system is capable of supporting premium Media Center IR functionality. Tests SYSFUND-0042.

Note This test applies to client only.

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:

  1. The remote must contain all the required buttons.

  2. All the buttons on the remote must work.

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, the test 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, the test populates the row as "unassigned."

Log File: RCTester.xml
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Media Center IR remote control and receiver

Processor

  • x86

  • x64

Running RCTester : ehome - Premium System Tests - IR

Command Syntax

Command option | Description
RCTester | ???

Code Tour

File Manifest

File | Location
RCTester.exe |


Unreported Memory IO Test (resstomp)

Overview

The resstomp tool ensures that all resources that are currently in use are correctly reported to the operating system.

Note This test applies to x86 only.

Details

This tool creates a tree of in-use resources that the operating system has been informed of. By using this information, the test 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, a piece of hardware is decoding that address and has not told the operating system that the address is in use. This situation can lead to indeterminate results if the Microsoft Windows operating system assigns that "free" address to another piece of hardware and two 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.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Test Assertions

Test Assertion GUID: D0FFD18A-A7B4-4106-9C11-9DA6158E439E


Resume From Standby

Overview

The Resume from Standby (Rpat.exe) test tool is a tool that developers, testers, and system integrators can use to discover which drivers are creating a 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 helps system integrators figure out where to focus their efforts to meet the new Vista resume-from-standby requirements.

Note This test applies to client only.

Details

This tool is located in the \tools\acpi\rpat folder in the Microsoft Windows Driver Kit (WDK). In this documentation, we've used tables to simulate the HTML. There may be minor differences in formatting and table graphics.

Rpat.exe

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 an .etl file generated by Pwrtst.exe. By default, Rpat.exe 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:

Generated by S3 | Resume tool
BIOS Init Time | 2254 ms
Device Resume Time | 636 ms
Resume Time | 666 ms

Device durations

The device durations section describes how long each specific device took to resume from standby. This list is ordered from the slowest device to the fastest.

Device | Duration (ms) |
NVIDIA GeForce FX 5950 Ultra (LDDM) | 274 | ||||||||||||||||||||||||||||||
Texas Instruments OHCI Compliant IEEE 1394 Host... | 209 | |||||||||||||||||||||||||
USB Mass Storage Device | 157 | ||||||||||||||||
Intel 82801EB USB Universal Host Controller | 97 | |||||||||
Intel 82801EB USB Universal Host Controller | 97 | |||||||||
Intel 82801EB USB Universal Host Controller | 97 | |||||||||

You can see here that, as is typical, the graphics controller took the longest to resume.

If you click a device name, you will see a summary of which drivers were using the device, how much time each one took, and the dependencies between them. For example, if you click the "USB Mass Storage Device" link in the previous table, you get:

USB Mass Storage Device
Identification: | USB\VID_10DF&PID_0500\00600000026A
Class: | USB
Manufacturer: | Compatible USB storage device
Location Information: | Port#0008.Hub_#005

Driver | BeginTime - End Time | ms
system32\DRIVERS\USBSTOR.SYS | 67072-67072 | || |
system32\DRIVERS\USBSTOR.SYS | 67072-67072 | || |
system32\DRIVERS\usbhub.sys | 67072-67228 | ||||||||||||||||||||||||||||||||||||| |
system32\DRIVERS\USBSTOR.SYS | 67229-67229 |  | |||
system32\DRIVERS\ubshub.sys | 67229-67229 |  | |||

In the previous table, you can see that the last two operations blocked on Usbhub.sys.

Important: 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 table shows the same information as the previous table, 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 previous table.

Device Timeline
The following graph shows the timeline for the devices. Time is in milliseconds (ms)
Device | BeginTime - EndTime |
ACPI x86-based PC | 66539 - 66542 | || |
Microsoft ACPI-Compliant System | 66544 - 66574 | ||||||||||||||||||||||||||||||| |
System board | 66574 - 66574 |  | ||
PCI bus | 66574 - 66574 |  | ||

The above except shows that the system board device took negligible time to resume from standby but, as expected, blocked on the ACPI-Compliant System. Clicking a hyperlink in the tool 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.

Driver Duration
The following graph shows the cumulative time spent in each driver. Time is in milliseconds (ms).
Driver | Duration (ms) |
Microsoft USB Universal Host Controller miniport driver | 280 | |||||||||||||||||||||||||||||||||||||||
 | 274 | |||||||||||||||||||||||||||||||||||||
Microsoft ACPI driver | 272 | |||||||||||||||||||||||||||||||||||

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 a future release.

Run Time: 5 min
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

Code Tour

File Manifest

File | Location
rpat.exe | \tools\acpi\rpat


Signed Driver Check (CheckLogo)

Type: Manual Test

Overview

Signed Driver Check (CheckLogo) is a test tool that verifies that 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.

Note This test applies to both client and server.

Details

  1. 1) XP operating system driver validation.

  4. Submissions for Windows XP must have valid signatures. Drivers shipped with Windows (inbox drivers) are valid in this scenario for this test.

  5. 2) Server 2003 operating system driver validation.

    Submissions for Windows Server 2003 must have valid signatures. Drivers shipped with Windows (inbox drivers) are valid in this scenario for this test.

  6. 3) Basic level logo submission.

    Submissions submitted for basic level logo should check drivers for logo signature for available logo programs and unclassified signature for drivers that do not have a logo program. Drivers shipped with Windows (inbox drivers) are valid in this scenario for this test.

  7. 4) Premium level logo submission.

    Submissions submitted for premium level logo must check drivers for premium level logo attributes (WLP A.1.1.1.1) for all available logo programs with premium logo availability. Drivers shipped with Windows (inbox drivers) are valid in this scenario for this test.

  8. 5) Stand-alone execution.

The test job(s) must be available outside of the DTM for customers to run independently to verify driver level signatures.

Run Time: 10 min
Log File:chklogo6.wtl
System Restart Required: No

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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]

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 System must contain premium-logo qualified devices if there is a premium testing program for the device

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 must contain premium-logo qualified devices if there is a premium testing program for the device

Troubleshooting

Issue:

You may receive the following message, which is an autotriage message to help you fix the problem associated with the test result: ERROR: No Logo Level Attribute on file. This message is a valid failure.

Resolution:

If this message begins with Signed by: Microsoft Windows Hardware Compatibility Publisher and ends with This file has a 0 level logo, then the driver was signed through the Microsoft unclassified signature program. Drivers submitted in a logo system must meet the logo requirements. Please obtain the logo versions of these drivers for a system submission.


Single Computer Display Object Test

Type: Automated Test

Overview

This test verifies that the computer shows up as a single device in the Devices and Printers folder in accordance with Windows Logo requirement SYSFUND-0200. In brief, this requirement requires that all hardware that is part of the physical computer or laptop is reported as being inside the computer container.

Details

Run Time: 2 seconds
Log File: ComputerSingleTest.xml
System Restart Required: No
Test Category: System Tests
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: ComputerSingleDDOTest.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • WTTLog (included with the WLK)

Hardware Requirements

The test tool requires the following hardware:

  • Computer that meets the minimum software requirements

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the Test

Before running the test, unplug all unnecessary hardware. For desktop computers, monitors, mouse and keyboards can be left connected. The test will run and create a log file. The log file will indicate PASS or FAIL. If the test fails, the devices that were reported as not being part of the computer will be listed in the log file.

Command Syntax

Command option | Description
SingleComputerDDOTest.exe | Without parameters the help context will be displayed.
-Desktop | Run the test in Desktop mode. Mouse, keyboards and monitors may be connected.
-Laptop | Run the test in laptop mode.

Code Tour

File Manifest

File | Location
SingleComputerDDOTest.exe | [osbinroot]\DFPTest\SingleComputerDDOTest.exe

Test Assertions

The GUID for the test is 0e7aea02-2712-422f-a9cd-ffbe470fd391.

The following message is printed for a failure: "Devices were found that are part of the computer but were reported as removable from the computer."


SMBIOS HCT

Overview

The SMBIOS HCT test validates the system's SMBIOS data.

Note This test applies to both client and server.

Details

This application will gather the SMBIOS data and validate it against the SMBIOS specifications that are available from the DMTF.

Run Time: less than 1 minute
Log File:smbios.xml
System Restart Required: No

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 -logo |

Troubleshooting

Issue:

You receive the following error message:

SMBiosCheckSystemMemoryDeviceTables - System Memory Device with Size of 0 found! Systems seeking Server logo must have all memory slots populated! If there is a memory device in each slot, consult with your BIOS developer as this is a bug in the SMBIOS implementation.

Resolution:

Fill every DIMM slot with the largest amount of memory possible, based on what the system design permits. This may require mixing the DIMM sizes and types.

If you still see this error message after populating all of the memory slots, you can resolve the issue by updating the SMBIOS. For additional help on how to do this, please work with your BIOS developer.

Test Assertions

SYS-BIOS-18System 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.


Storage Device Stress test (SDStress) (Deprecated)

Type: Automated Test

Overview

This test stresses the hard disk drives and CD-ROM drives in a system and validates storage API commands.

Note This test applies to both client and server.

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
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

  • DTM Log Dynamic Link Library or a DTM client service running on the test machine.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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.

Code Tour

File Manifest

File | Location
SDStress.exe | [WTT\TestBinRoot]\nttest\DriversTest\storage\wdk\SDStress

Test Assertions

Device should not cause timeout.
Test Assertion GUID: 69ff82c9-c8f4-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device should handle IOCTL_STORAGE_CHECK_VERIFY.
Test Assertion GUID: 69ff82ca-c8f4-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device should support GetDiskFreeSpaceEx and have more than 10 MB free.
Test Assertion GUID: 69ff82cb-c8f4-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Drive must be of known type, determined by GetDriveType.
Test Assertion GUID: 69ff82ce-c8f4-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements
Device should perform under stress.
Test Assertion GUID: 69ff82cf-c8f4-11da-94f5-00123f3a6b60
Windows Logo Program: STORAGE-0001 Storage devices meet industry standards and Windows requirements


GlitchFree WMV HD 720p video playback quality test (SYSFUND-0062)

Type: Automated Test

Overview

The System and Device WLK test, GlitchFree WMV HD 720p video playback quality test, utilizes the Windows System Assessment Tool (Winsat.exe) to playback 720p WMV content in Windows Vista and Windows 7. The test contains the following four cases:

  1. Case 0 - Winsat decodes and plays back the content faster than real-time. The test verifies that the content plays back within the allotted time and the expected number of frames are rendered.

  2. Case 1 - Winsat decodes and plays back the content in real time. The test captures ETL logs and tracks the number of video glitches logged by the EVR (enhanced video renderer). The maximum number of allowed video glitches is 25. The test also tracks the total duration of all glitches. In other words, a glitch can be 10ms long or 100ms long. If the sum of the glitch durations exceeds the max allowed of 150ms, this case will fail.

  3. Case 2 - ISR/DPC duration test: This test is designed to validate that individual ISR/DPC duration does not exceed a 3ms threshold. In addition, the test will also ensure that a cumulative duration of every ISR/DPC within a 10ms window does not exceed 4ms. Both conditions aim at ensuring that device drivers are well behaved. The goal is to ensure that time critical multimedia threads can run on a regular basis, with limited interruptions from ISR/DPCs.

  4. Case 3 - Verify VSync cadence events from drivers. This case ensures that the GPU DPC VSync cadence follows a well behaved pattern. Fluctuations in GPU DPC Vysnc frequency during media playback can result in glitches during media playback. The test criteria establish that the cadence fluctuation should not exceed +/- 90% of the average VSync cadence window. For instance, in a 60Hz monitor, the expected VSync DPC cadence is 16.666ms; the test will fail if any VSync DPC is fired within less that 1.6ms from the previous one or later than 31.666 ms from the previous one. When the duration between two vsyncs is greater than 32.667ms, this often results in a perceivable video glitch. When the distance between two vsyncs is less than 1.667ms, this is often caused by the driver double firing vsyncs, or vsyncs that are a few microseconds (us) apart.

Details

Run Time: 10 minutes.
Log File: GFHD.wtl and ETL logs
System Restart Required: No
Test Category: Multimedia Playback
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program: GFHD.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • DWM and Aero theme with transparency must be enabled

  • 800 x 600 minimum resolution

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 800 by 600 resolution, 32-bits per pixel, 60 Hz

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

When running this test manually (outside of the DTM), run the following command from an elevated (admin) command prompt:

@reg add "HKLM\SOFTWARE\Microsoft\Windows Media Foundation" /v WMIInstrumentation /t REG_DWORD /d 1 /f

Then run the following command from an elevated command prompt:

GFHD.exe -0 10 -1 10 -2 10 -3 10 -c 142 -m 40000 -t 6500000 -g 25 -p 1500000 -i 3000000 -s 4000000 -n 10000000 -a 90

The test runs through cases 0, 1, 2, and 3 described above. If one of the cases fails, the log will indicate why the test failed. The ETL logs contain more information on why the test case is failing. The Windows Performance Toolkit (XPerfView.exe) can be used to analyze the ETL logs:

Windows Performance Analysis Developer Center

How to play back the video outside of the GFHD.exe binary

GFHD.exe utilizes the WinSAT tool to playback the media content. The following command can be used to execute the video playback test using WinSAT.exe:
WinSAT.exe mfmedia -input %windir%\performance\winsat\WinSat.wmv -play -show -v -ns -noetw -xml output.xml

Troubleshooting

This section contains information about what to look for when a case fails.

Case 0 and Case 1

  1. The CPU or GPU may not be capable of decoding the content in a timely manner.

  2. Concurrent system activity and load on the system is preventing the Media pipeline from decoding and rendering frames on time.

  3. A potential bug in the DXVA or GPU driver.

Case 2

  1. At least one DPC or ISR took more than the maximum allowed by the test.

  2. An ISR/DPC storm in either a single or multiple drivers. The criteria for defining a storm are defined in the test.

  3. Consider using the Windows Performance Toolkit mentioned above to narrow down which drivers on the system are either causing a DPC/ISR storm or a long ISR/DPC.

Case 3

  • An irregular VSync cadence can be caused by a potential bug in the GPU driver or by long ISRs/DPCs and/or ISR/DPC storms.

How to collect more information to debug failures

XPerf.exe is a tool that ships with the Windows Performance Toolkit. This tool can be used to manually collect ETW traces with additional ETW providers enabled. These traces can be consumed by tools such as XPerfView.exe to narrow down the cause of failures. XPerf.exe can also be used to convert the binary ETW log into text.

  1. Install the Windows Performance Toolkit from the Windows Performance Analysis Developer Center .

  2. Create the Get Media Traces script.
    a. On Windows 7:
    1. Launch Notepad.exe and create a file named GetMediaTraces_Win7.cmd
    2. Save GetMediaTraces_Win7.cmd in the same directory where XPerf.exe is located.
    3. Copy the text from the GetMediaTraces_Win7 command scripts in "Sample Scripts for Manual ETW Trace Collection" below into the clipboard.
    4. Paste the text into GetMediaTraces_Win7.cmd and save the file.
    b. On Windows Vista:
    1. Launch Notepad.exe and create a file named GetMediaTraces_Vista.cmd
    2. Save GetMediaTraces_Vista.cmd in the same directory where XPerf.exe is located.
    3. Copy the text from the GetMediaTraces_Vista command scripts in "Sample Scripts for Manual ETW Trace Collection" below into the clipboard.
    4. Paste the text into GetMediaTraces_Vista.cmd and save the file.

  3. Open two elevated command prompt windows.

  4. In the first command prompt window, navigate (change directories) to the location of XPerf.exe and GetMediaTraces command script.

  5. Run one of the following scripts:
    a. On Windows 7, run GetMediaTraces_Win7.cmd <filename>

    b. On Windows Vista, run GetMediaTraces_Vista.cmd <filename>

    Note <filename> is the name of the scenario that you are capturing a trace for.

  6. Press any key to START tracing

  7. In the second command window:
    a. Run WinSAT.exe mfmedia -input %windir%\performance\winsat\WinSat.wmv -play -show -v -ns -noetw -xml output.xml
    b. Wait for video playback to finish.

  8. Press any key to STOP tracing.

  9. Use tools such as XPerfView.exe (part of the Windows Performance Toolkit) to analyze the traces.

  10. If it's not possible to narrow down the cause of a failure using the GetMediaTraces scripts above and the Windows Performance Toolkit, please contact the owner of SYSFUND-0062 and provide a link to the GFHD.wtl and all ETL logs generated by the test.

Sample Scripts for Manual ETW Trace Collection

GetMediaTraces_Win7.cmd (for Windows 7 use only) GetMediaTraces_Vista.cmd (for Windows Vista use only)
@echo off

if "%1"=="" (goto USAGE)
echo.
set LogFileName=%1
echo LogFileName=%LogFileName%
echo.

echo.
echo _____________________________________________________
echo.
echo    Verify script is run from an elevated CMD prompt
echo.
echo _____________________________________________________
echo.
if exist %windir%\system32\ntdll.dll.original (del %windir%\system32\ntdll.dll.original)
copy %windir%\system32\ntdll.dll %windir%\system32\ntdll.dll.original
if not exist %windir%\system32\ntdll.dll.original (goto ERR_ELEVATE_CMD_PROMPT)
del %windir%\system32\ntdll.dll.original

echo.
echo _____________________________________________________
echo.
echo           verify XPerf tools exist
echo.
echo _____________________________________________________
echo.
if not exist .\xperf.exe (goto ERR_MISSING_XPERF)
echo.

echo.
echo _____________________________________________________
echo.
echo    Set regkeys required for ETW instrumentation
echo.
echo _____________________________________________________
echo.
@reg add "HKCU\SOFTWARE\Microsoft\MediaPlayer\Preferences" /v AcceptedPrivacyStatement /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Microsoft\Windows Media Foundation\Platform" /v FreeWppTrace /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Microsoft\Windows Media Foundation" /v WMIInstrumentation /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Microsoft\Windows Media" /v WmiInstrumentation /t REG_DWORD /d 1 /f
@reg add "HKLM\Software\Microsoft\Windows Media\Network" /v WmiInstrumentation /t REG_DWORD /d 1 /f
@reg add "HKLM\Software\Microsoft\Windows Media Player NSS" /v WmiInstrumentation /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Microsoft\DirectX" /v GlitchInstrumentation /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Microsoft\Debug\quartz.dll" /v PERFLOG /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Debug\quartz.dll" /v PERFLOG /t REG_DWORD /d 1 /f
echo.

echo.
echo _____________________________________________________
echo.
echo           Define ETW Provider list
echo.
echo _____________________________________________________
echo.
set TRACE_LARGE_BUFFERS=-BufferSize 1024 -MinBuffers 120 -MaxBuffers 480

REM ******** Kernel Mode
set KERNEL_BASIC=LOADER+PROC_THREAD+CSWITCH+DISK_IO+HARD_FAULTS+PROFILE+INTERRUPT+NETWORKTRACE+DPC+Latency+POWER
set KERNEL_DVD=LOADER+PROC_THREAD+CSWITCH+DISK_IO+HARD_FAULTS+PROFILE+INTERRUPT+NETWORKTRACE+DPC+Latency+POWER+FILE_IO+FILE_IO_INIT
set KERNEL_FULL=LOADER+PROC_THREAD+CSWITCH+DISK_IO+DISK_IO_INIT+HARD_FAULTS+VIRT_ALLOC+PROFILE+INTERRUPT+DPC+NETWORKTRACE+ALPC+DISPATCHER+POWER+REGISTRY+FILE_IO+FILE_IO_INIT+PERF_COUNTER+SPINLOCK+Latency

REM ******** StackWalk
set STACK_BASIC=-stackwalk ProcessCreate+ImageLoad+ThreadCreate+HardFault+Profile+CSwitch
set STACK_FULL=-stackwalk ProcessCreate+ProcessDelete+ImageLoad+ImageUnload+ThreadCreate+ThreadDelete+CSwitch+ReadyThread+Profile+DiskFlushInit+FileFlush+RegFlush+HardFault+VirtualAlloc+VirtualFree+PowerSetPowerAction+PowerSetPowerActionReturn

REM ******** Circular Mode
set CIRCULAR100=-FileMode Circular -MaxFile 100

REM ******** Platform
Set DVDNav=75d4a1bb-7cc6-44b1-906d-d5e05be6d060
set TRACE_DXVA2=a0386e75-f70c-464c-a9ce-33c44e091623:0xffff:5
set MF=MediaFoundation
set MF2=Microsoft-Windows-MF
set MFPLAT=Microsoft-Windows-MediaFoundation-Platform
set MFPLAT2=Microsoft-Windows-MediaFoundation-Performance
set MFPLAY=Microsoft-Windows-MediaFoundation-PlayAPI
set DSHOW=28CF047A-2437-4b24-B653-B9446A419A69
set DSHOW2=Microsoft-Windows-DirectShow-Core
set MFTS=TerminalServer-MediaFoundationPlugin
set CDROM=58db8e03-0537-45cb-b29b-597f6cbebbfd
set REDBOOK=58db8e03-0537-45cb-b29b-597f6cbebbfe
set DO_MEDIA=%DVDNav%+%TRACE_DXVA2%+%MFPLAT%+%MFPLAT2%+%MF2%+%MFPLAY%+%DSHOW%+%DSHOW2%+%MFTS%+%CDROM%+%REDBOOK%

REM ******** Audio
set AE_Classic=a6a00efd-21f2-4a99-807e-9b3bf1d90285:0x000000000000ffff:0x5
set AE_PortCLS_HDAudio=9502CBC6-AA74-4eff-BA91-D9329BCCE758
set AE_USBAudio=A011308E-E43B-4120-AD04-C023BB14F2B6
set AE1=AudEngCritical
set AE2=AudEngEvent
set AE3=AudEngVerbose
set AE=Microsoft-Windows-Audio
set AUDIO=e27950eb-1768-451f-96ac-cc4e14f6d3d0:0x7FFFFFFF:32
set KMIXER=642d9ed0-4fc3-4634-aec0-3d1839abf101
set DO_AUDIO=%AE_Classic%+%AE%+%AUDIO%+%KMIXER%+%AE_PortCLS_HDAudio%+%AE_USBAudio%

REM ******** Power
set POWER=Microsoft-Windows-Kernel-Power
set PROCESSOR_POWER=Microsoft-Windows-Kernel-Processor-Power
set SERIALSYNC=862007f7-6e50-4044-9082-dfa078c63a83
set POWERCFG=Microsoft-Windows-PowerCfg
set POWERCPL=Microsoft-Windows-PowerCpl
set POWERTBL=Microsoft-Windows-Power-Troubleshooter
set POWERMODE=Microsoft-Windows-UserModePowerService
set DO_POWER=%POWER%+%PROCESSOR_POWER%+%SERIALSYNC%+%POWERCFG%+%POWERCPL%+%POWERTBL%+%POWERMODE%

REM ******** DX/DWM
set DWMWIN7=Microsoft-Windows-Dwm-Core
set DWMAPIGUID=71dd85bc-d474-4974-b0f6-93ffc5bfbd04::6
set SCHEDULEGUID=8cc44e31-7f28-4f45-9938-4810ff517464:0xffff:6
set SCHEDULEGUID2=8c9dd1ad-e6e5-4b07-b455-684a9d879900:0xffff:6
set DWMGUID=ed56cd5c-617b-49a5-9b80-eca3e02414bd::6
set REDIRGUID=25bd019c-3858-4ea4-a7b3-55b9ec8977e5::6
set DX=DX
set DO_DXCORE=%DWMWIN7%+%DWMAPIGUID%+%SCHEDULEGUID2%+%DWMGUID%+%REDIRGUID%+%DX%

REM ******** MMCSS
set TRACE_MMCSS=f8f10121-b617-4a56-868b-9df1b27fe32c:0xffff:5

set KERNEL_FLAG=%KERNEL_BASIC% %STACK_BASIC% %TRACE_LARGE_BUFFERS%
set USER_FLAG=%DO_MEDIA%+%DO_DXCORE%+%DO_AUDIO%+%DO_POWER%+%TRACE_MMCSS% %TRACE_LARGE_BUFFERS%

echo.
echo _____________________________________________________
echo.
echo     Press any key to START tracing
echo.
echo _____________________________________________________
echo.
pause

echo.
echo _____________________________________________________
echo.
echo   Stop logging in case the previous session was not stopped, then starting ETW tracing
echo.
echo _____________________________________________________
echo.
REM xperf.exe -stop "NT Kernel Logger" mysession

echo.
echo _____________________________________________________
echo.
echo   xperf.exe -on %KERNEL_FLAG%
echo.
echo _____________________________________________________
echo.
xperf.exe -on %KERNEL_FLAG%

echo.
echo _____________________________________________________
echo.
echo xperf.exe -start mysession -on %USER_FLAG%
echo.
echo _____________________________________________________
echo.
xperf.exe -start mysession -on %USER_FLAG%

echo.
echo _____________________________________________________
echo.
echo     Press any key to STOP tracing
echo.
echo _____________________________________________________
echo.
pause

echo.
echo _____________________________________________________
echo.
echo  Stop tracing
echo.
echo  xperf.exe -stop "NT Kernel Logger" mysession -d %LogFileName%.etl
echo.
echo _____________________________________________________
echo.
echo.
xperf.exe -stop "NT Kernel Logger" mysession -d %LogFileName%.etl

echo.
echo.
echo _____________________________________________________
echo.
echo   Generated trace %LogFileName%
echo.
echo _____________________________________________________
echo.

goto :EOF

:USAGE
echo.
echo.
echo _____________________________________________________
echo.
echo    USAGE
echo.
echo _____________________________________________________
echo.
echo      [Script requirements]
echo.
echo         1) Windows Win7
echo         2) Elevated command prompt
echo.
echo      [Script Arguments]
echo.
echo         1) Filename for the ETW log
goto :EOF

:ERR_ELEVATE_CMD_PROMPT
echo.
echo _____________________________________________________
echo.
echo   ERROR - Not running from elevated cmd prompt!
echo.
echo _____________________________________________________
echo.
echo.
echo   This script must be run from an elevated cmd prompt!
echo.
echo   Press any key to continue...
echo.
pause
goto EOF

:ERR_MISSING_XPERF
echo.
echo _____________________________________________________
echo.
echo       Error!   Missing XPerf tools
echo.
echo _____________________________________________________
echo.
echo  This script requires the Windows Performance Toolkit (Xperf.exe).
echo.
echo  Please download XPerf.exe and copy this sript to the same
echo.
echo  folder as XPerf.exe.
echo.
echo   Press any key to continue...
echo.
pause
goto :EOF

:EOF

@echo off

if "%1"=="" (goto USAGE)
echo.
set LogFileName=%1
echo LogFileName=%LogFileName%
echo.

echo.
echo _____________________________________________________
echo.
echo    Verify script is run from an elevated CMD prompt
echo.
echo _____________________________________________________
echo.
if exist %windir%\system32\ntdll.dll.original (del %windir%\system32\ntdll.dll.original)
copy %windir%\system32\ntdll.dll %windir%\system32\ntdll.dll.original
if not exist %windir%\system32\ntdll.dll.original (goto ERR_ELEVATE_CMD_PROMPT)
del %windir%\system32\ntdll.dll.original

echo.
echo _____________________________________________________
echo.
echo           verify XPerf tools exist
echo.
echo _____________________________________________________
echo.
if not exist .\xperf.exe (goto ERR_MISSING_XPERF)
echo.

echo.
echo _____________________________________________________
echo.
echo    Set regkeys required for ETW instrumentation
echo.
echo _____________________________________________________
echo.
@reg add "HKCU\SOFTWARE\Microsoft\MediaPlayer\Preferences" /v AcceptedPrivacyStatement /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Microsoft\Windows Media Foundation\Platform" /v FreeWppTrace /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Microsoft\Windows Media Foundation" /v WMIInstrumentation /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Microsoft\Windows Media" /v WmiInstrumentation /t REG_DWORD /d 1 /f
@reg add "HKLM\Software\Microsoft\Windows Media\Network" /v WmiInstrumentation /t REG_DWORD /d 1 /f
@reg add "HKLM\Software\Microsoft\Windows Media Player NSS" /v WmiInstrumentation /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Microsoft\DirectX" /v GlitchInstrumentation /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Microsoft\Debug\quartz.dll" /v PERFLOG /t REG_DWORD /d 1 /f
@reg add "HKLM\SOFTWARE\Debug\quartz.dll" /v PERFLOG /t REG_DWORD /d 1 /f
echo.

echo.
echo _____________________________________________________
echo.
echo           Define ETW Provider list
echo.
echo _____________________________________________________
echo.
set TRACE_LARGE_BUFFERS=-BufferSize 1024 -MinBuffers 120 -MaxBuffers 480

REM ******** Kernel Mode
set KERNEL_BASIC=LOADER+PROC_THREAD+CSWITCH+DISK_IO+HARD_FAULTS+PROFILE+INTERRUPT+NETWORKTRACE+DPC+Latency+POWER
set KERNEL_DVD=LOADER+PROC_THREAD+CSWITCH+DISK_IO+HARD_FAULTS+PROFILE+INTERRUPT+NETWORKTRACE+DPC+Latency+POWER+FILE_IO+FILE_IO_INIT
set KERNEL_FULL=LOADER+PROC_THREAD+CSWITCH+DISK_IO+DISK_IO_INIT+HARD_FAULTS+VIRT_ALLOC+PROFILE+INTERRUPT+DPC+NETWORKTRACE+ALPC+DISPATCHER+POWER+REGISTRY+FILE_IO+FILE_IO_INIT+PERF_COUNTER+SPINLOCK+Latency

REM ******** StackWalk
set STACK_BASIC=-stackwalk ProcessCreate+ImageLoad+ThreadCreate+HardFault+Profile+CSwitch
set STACK_FULL=-stackwalk ProcessCreate+ProcessDelete+ImageLoad+ImageUnload+ThreadCreate+ThreadDelete+CSwitch+ReadyThread+Profile+DiskFlushInit+FileFlush+RegFlush+HardFault+VirtualAlloc+VirtualFree+PowerSetPowerAction+PowerSetPowerActionReturn

REM ******** Circular Mode
set CIRCULAR100=-FileMode Circular -MaxFile 100

REM ******** Platform
Set DVDNav=75d4a1bb-7cc6-44b1-906d-d5e05be6d060
set TRACE_DXVA2=a0386e75-f70c-464c-a9ce-33c44e091623:0xffff:5
set MF=MediaFoundation
set DSHOW=28CF047A-2437-4b24-B653-B9446A419A69
set CDROM=58db8e03-0537-45cb-b29b-597f6cbebbfd
set REDBOOK=58db8e03-0537-45cb-b29b-597f6cbebbfe
set DO_MEDIA=%DVDNav%+%TRACE_DXVA2%+%DSHOW%+%CDROM%+%REDBOOK%

REM ******** Audio
set AE_Classic=a6a00efd-21f2-4a99-807e-9b3bf1d90285:0x000000000000ffff:0x5
set AE_PortCLS_HDAudio=9502CBC6-AA74-4eff-BA91-D9329BCCE758
set AE_USBAudio=A011308E-E43B-4120-AD04-C023BB14F2B6
set AE1=AudEngCritical
set AE2=AudEngEvent
set AE3=AudEngVerbose
set AUDIO=e27950eb-1768-451f-96ac-cc4e14f6d3d0:0x7FFFFFFF:32
set KMIXER=642d9ed0-4fc3-4634-aec0-3d1839abf101
set DO_AUDIO=%AE_Classic%+%AUDIO%+%KMIXER%+%AE_PortCLS_HDAudio%+%AE_USBAudio%

REM ******** DX/DWM
set DWMAPIGUID=71dd85bc-d474-4974-b0f6-93ffc5bfbd04::6
set SCHEDULEGUID=8cc44e31-7f28-4f45-9938-4810ff517464:0xffff:6
set SCHEDULEGUID2=8c9dd1ad-e6e5-4b07-b455-684a9d879900:0xffff:6
set DWMGUID=ed56cd5c-617b-49a5-9b80-eca3e02414bd::6
set REDIRGUID=25bd019c-3858-4ea4-a7b3-55b9ec8977e5::6
set DX=DX
set DO_DXCORE=%DWMAPIGUID%+%SCHEDULEGUID2%+%DWMGUID%+%REDIRGUID%+%DX%

REM ******** MMCSS
set TRACE_MMCSS=f8f10121-b617-4a56-868b-9df1b27fe32c:0xffff:5

set KERNEL_FLAG=%KERNEL_BASIC% %STACK_BASIC% %TRACE_LARGE_BUFFERS%
set USER_FLAG=%DO_MEDIA%+%DO_DXCORE%+%DO_AUDIO%+%TRACE_MMCSS% %TRACE_LARGE_BUFFERS%

echo.
echo _____________________________________________________
echo.
echo     Press any key to START tracing
echo.
echo _____________________________________________________
echo.
pause

echo.
echo _____________________________________________________
echo.
echo   xperf.exe -on %KERNEL_FLAG%
echo.
echo _____________________________________________________
echo.
xperf.exe -on %KERNEL_FLAG%

echo.
echo _____________________________________________________
echo.
echo xperf.exe -start mysession -on %USER_FLAG%
echo.
echo _____________________________________________________
echo.
xperf.exe -start mysession -on %USER_FLAG%

echo.
echo _____________________________________________________
echo.
echo     Press any key to STOP tracing
echo.
echo _____________________________________________________
echo.
pause

echo.
echo _____________________________________________________
echo.
echo  Stop tracing
echo.
echo  xperf.exe -stop "NT Kernel Logger" mysession -d %LogFileName%.etl
echo.
echo _____________________________________________________
echo.
echo.
xperf.exe -stop "NT Kernel Logger" mysession -d %LogFileName%.etl

echo.
echo.
echo _____________________________________________________
echo.
echo   Generated trace %LogFileName%
echo.
echo _____________________________________________________
echo.

goto :EOF

:USAGE
echo.
echo.
echo _____________________________________________________
echo.
echo    USAGE
echo.
echo _____________________________________________________
echo.
echo      [Script requirements]
echo.
echo         1) Windows Vista
echo         2) Elevated command prompt
echo.
echo      [Script Arguments]
echo.
echo         1) Filename for the ETW log
goto :EOF

:ERR_ELEVATE_CMD_PROMPT
echo.
echo _____________________________________________________
echo.
echo   ERROR - Not running from elevated cmd prompt!
echo.
echo _____________________________________________________
echo.
echo.
echo   This script must be run from an elevated cmd prompt!
echo.
echo   Press any key to continue...
echo.
pause
goto EOF

:ERR_MISSING_XPERF
echo.
echo _____________________________________________________
echo.
echo       Error!   Missing XPerf tools
echo.
echo _____________________________________________________
echo.
echo  This script requires the Windows Performance Toolkit (Xperf.exe).
echo.
echo  Please download XPerf.exe and copy this sript to the same
echo.
echo  folder as XPerf.exe.
echo.
echo   Press any key to continue...
echo.
pause
goto :EOF

:EOF


System - Additional Qualifications - Windows Media Center Requirements

Type: Manual Test

Overview

This test provides information for Windows Media Center Customized Product Requirements. Specific information is available at the following link:

Windows Media Center Customized Product Requirements

Note This test applies to client only.

Details

This section describes the requirements details.

Run Time: Various
Log File: N/A
System Restart Required: No
Supported operating systems:Windows 7

Requirements

Software Requirements

See the information available at the following link:

Windows Media Center Customized Product Requirements

Hardware Requirements

See the information available at the following link:

Windows Media Center Customized Product Requirements

Processor

See the information available at the following link:

Windows Media Center Customized Product Requirements

Running the Additional Qualifications - Windows Media Center Requirements Test

See the information available at the following link:

Windows Media Center Customized Product Requirements


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 ensures that the devices are still functional after these state changes through SimpleIO stress testing.

Note This test applies to both client and server.

Details

The System - Common Scenario Stress with IO job is the System Logo Category 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 Windows Device Manager and is not class 'LegacyDriver'.

Run Time: 3 hours
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Running System - Common Scenario Stress with IO

  • Ensure your machine pool has been configured for the proper logo program.

  • Create a system submission (Logo) in Device Console.

  • Run System - Common Scenario Stress with IO test from Device Console.

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. You can also find this information in the table of contents for the WDK documentation under Windows Driver Kit > Other Tools > Windows Device Testing Framework > Automated Scenarios.

You may receive an error message similar to the following: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid." This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

  • For redundant network paths, add an additional NIC connected to the network.

Some machines will go into standby mode at the end of the test on Windows XP. If this occurs, you must wake the machine manually to complete the test. This is acceptable for Logo submission. If automation is required, you can wake the system by calling PoSetSystemState(ES_USER_PRESENT) from kernel mode.


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, this job tries to ensure that the devices are still functional after the changes in state through SimpleIO stress testing.

Note This test applies to both client and server.

Details

The System - Disable Enable With IO job is the "System" 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 target only disableable devices. A disableable device is a device that has the Disable option available in Windows Device Manager and that is not the "LegacyDriver" class.

Run Time: 2 Hours
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

To run this job, do the following:

  • Ensure that your machine pool has been configured for the proper logo program.

  • Create a system submission (Logo) in the Device Console window.

  • Run the System - Disable Enable With IO Job from Device Console.

Troubleshooting

The underlying scenario was developed by using the new Microsoft Windows Device Testing Framework (WDTF). The Windows Driver Kit (WDK) contains extensive documentation for using and extending this framework in your own driver development process. For more information, search the WDK Help documentation for "Windows Device Testing Framework".

You may receive an error message similar to the following: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid." This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

  • For redundant network paths, add an additional NIC connected to the network.


System - Embedded Signature Verification

Type:Automated

Overview

The tool will run a query on all the services found in the system and search for the boot start type. Tool will find the driver location and check if the driver has embedded signature on. Test will pass if all boot start type drivers have embedded signature on them. The test will fail and will provide a log file if there are any boot start type drivers that are not embedded signed.

Note This test applies to both client and server.

Details

The tool will query all services found in the system. Out of all the services found in the system, the tool will then check for services that are boot start type, and query for their driver location. If no driver location found from the service query, the tool will look for the driver under the default location [SystemDrive]\Windows\system32\drivers. If still driver is not found, the tool will prompt the user to enter the location of the driver. Tool will then run signtool.exe to verify if these boot start type drivers has embedded signature on them or not. The test will only pass if all boot start type drivers has embedded signature, else it will fail and point out which driver is causing it to fail in the log file created.
When service query does not provide driver location and driver is not found at %systemdrive%\windows\system32\drivers folder.
Run Time:
Log File:embeddedsignature.wtl
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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 <Name of Test>

<All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if...>


System - Partition Validation Test

Type: Automated Test

Overview

This test is required to obtain a logo for 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. This test is required to obtain a logo for Windows 7 systems.

For Windows Vista, a properly configured system that supports BitLocker Drive Encryption must have a separate system partition (configured as Active, System), separate from the Windows Vista operating system partition (configured as Boot, Page File, Crash Dump). The system partition must be a minimum of 1.5 GB.

For Windows 7, a properly configured system must have a separate system partition (configured as Active, System), separate from the Windows 7 operating system partition (configured as Boot, Page File, Crash Dump). The system partition must be a minimum of 100MB.

Note This test applies to client only.

Details

This test tool validates that the system provides a second hard disk drive (HDD) partition, separate from the operating system partition, that is formatted as NTFS and meets minimum size requirements.

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
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • For Windows Vista: Hard drive with a minimum of two partitions. Partition 1: Minimum of 1.5GB configured as Active, System. Partition 2: Minimum of 20GB (or Vista minimum requirement) configured as Boot, Page File, Crash Dump

  • For Windows 7: Hard drive with a minimum of two partitions. Partition 1: Minimum of 100MB configured as Active, System. Partition 2: Minimum of 20GB (or Windows 7 minimum requirement) configured as Boot, Page File, Crash Dump

Processor

  • x86

  • x64

Running System - Partition Validation Test

Make sure that the DTM Framework is installed.

As an alternative, run this test without DTM by following these steps:

  • Run the following in the command line: SSSystemPartitionValidation.exe

Command Syntax

Command option | Description
SSSystemPartitionValidation.exe |

Code Tour

File Manifest

File | Location
SSSystemPartitionValidation.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\spvlogo

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


System - Sleep Stress with IO

Type: Automated Test

Overview

The System - Sleep Stress with IO job ensures that the system and its devices can be cycled through all supported sleep states. Additionally, this job ensures that the devices are still functional after these state changes through SimpleIO stress testing.

Note This test applies to both client and server.

Details

The System - Sleep Stress with IO job is the "System" 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: 40 minutes
System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Running System - Sleep Stress with IO

To run this test, do the following:

  • Ensure that your machine pool has been configured for the proper logo program.

  • Create a system submission (Logo) in the Device Console window.

  • Run the System - Sleep Stress With IO job from Device Console.

Troubleshooting

The underlying scenario was developed using the new Microsoft Windows Device Testing Framework (WDTF). The Windows Driver Kit (WDK) contains extensive documentation for using and extending this framework in your own driver development process. For more information, search the WDK Help documentation for "Windows Device Testing Framework".

You may receive an error message similar to the following: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid." This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

  • For redundant network paths, add an additional NIC connected to the network.

Some machines will go into standby mode at the end of the test on Windows XP. If this occurs, you must wake the machine manually to complete the test. This is acceptable for Logo submission. If automation is required, you can wake the system by calling PoSetSystemState(ES_USER_PRESENT) from kernel mode.


System-Tuner-DMA Test

Type: Automated Test

Overview

The System-Tuner-DMA Test (TvWLPSystemsTests) verifies that a system that includes a tuner that has direct memory access (DMA) enabled on all storage devices in the system.

Note This test applies to client only.

Details

TvWLPSystemsTest is a command-line application that Driver Test Manager (DTM) calls that verifies most of the Media Center requirements of the Microsoft Windows Logo Program.

This test verifies the following requirement:

  • SYSFUND-0064

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: 5 minutes
Log File: TvWLPLog.xml
System Restart Required: No
Supported operating systems for Windows Logo testing:

  • Windows Vista

  • Windows 7

Requirements

Software Requirements

Software components included with the device that is being tested.

The test tool runs on the following Windows operating systems:

  • Windows Vista

  • Windows 7

Hardware Requirements

The following hardware is required for this test:

  • Device to be tested

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Windows keyboard

  • Two button pointing device

Processor

  • x86

  • x64

Running System-Tuner-DMA Test

Run this test in DTM. The test will iterate through the appropriate requirements.

Command Syntax

Command option | Description
tvwlpsystemstests.exe SYSFUND-0064 | Executes Sysfund-0064 requirement.

Code Tour

File Manifest

File | Default Location
tvwlpsystemstests.exe | [%SYSTEMDRIVE%]\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest\

Test Assertions

Test Assertion GUID:
B86FA0D8-3713-45F5-8190-935A39FC8904
Windows Logo Program: Windows Logo program


System-Tuner-Performance Test

Type: Automated Test

Overview

The System-Tuner-Performance Test (TvWLPSystemsTests) verifies that a system that includes one or more TV tuners that meet performance and quality requirements during record and playback scenarios.

Note This test applies to client only.

Details

TvWLPSystemsTests is a command-line application that DTM calls that verifies most of the Media Center requirements.

This test verifies the following requirement:

  • SYSFUND-0065

Title: Media Center Dropped Frame and CPU utilization test

Success: Tests are logged during a 30-minute period for Windows TV playback and will pass if Zero Dropped Frames are logged and CPU utilization is not measured outside of the specification.

Average CPU utilization must not exceed 70%

CPU utilization must not exceed 80% over any 3 second interval

CPU utilization must not reach 100% for any 1 second interval

Failure: Each test will fail and log its failure if the measured criteria is out of specification.

When all tuners in a system are recording and one of the recordings is played back, the following requirements must be met over a 30-minute period:

  • The average CPU utilization must not exceed 70%.

  • The CPU utilization must not exceed 80% over any 3-second interval.

  • The CPU utilization must not reach 100% for any 1-second interval.

  • There must be zero frame drops.

Performance measurements are defined at the CPU's highest performance state.

Run Time: 30 minutes
Log File: TvWLPLog.xml
System Restart Required: No

Supported operating systems for Windows Logo testing:

  • Windows Vista

  • Windows 7

Requirements

Software Requirements

Software components included with the device that is being tested.

The test tool runs on the following Windows operating systems:

  • Windows Vista

  • Windows 7

Hardware Requirements

The following hardware is required for this test:

  • Device to be tested

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

Processor

  • x86

  • x64

Running System-Tuner-Performance Test

Run this test in DTM. This test will iterate through the appropriate requirements.

Command Syntax

Command option | Description
tvwlpsystemstests.exe SYSFUND-0065 | Executes the Sysfund-0065 requirement.

Code Tour

File Manifest

File | Location
tvwlpsystemstests.exe | [%SYSTEMDRIVE%]\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest\

Test Assertions

Test Assertion GUID:
A3AB9C2A-37CF-4E6F-BB7D-8A09A84ABAE7

Windows Logo Program: Windows Logo program


System-USB Test

Type: Manual Test

Overview

The System-USB Test (TvWLPSystemsTests) verifies that a system has user-accessible, fully-powered USB 2.0 ports.

Note This test applies to client only.

Details

TvWLPSystemsTests is a command-line application that DTM calls 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

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.

Run Time: 5 minutes
Log File: TvWLPLog.xml
System Restart Required: No

Supported operating systems for Windows Logo testing

  • Windows Vista

  • Windows 7

Program:

Requirements

Software Requirements

Software components included with the device that is being tested.

The test tool runs on the following Windows operating systems:

  • Windows Vista

  • Windows 7

Hardware Requirements

The following hardware is required for this test:

  • Device to be tested

  • 1 GHz processor

  • 1 GB of system RAM

  • 40 GB free hard drive space

  • Audio support

  • Windows keyboard

  • Two button pointing device

Processor

  • x86

  • x64

Running System-USB Test

Run this job in DTM and follow the on-screen instructions. This test will iterate through the appropriate requirements.

To run this test manually, you need two non-composite USB 2.0 devices plugged in while running this test. USB 1.1 and composite USB devices should not be connected to the system while the test is running. Use of these devices might cause a false failure.

Command Syntax

Command option | Description
tvwlpsystemstests.exe SYSFUND-0043 | Executes the Sysfund-0043 requirement.

Code Tour

File Manifest

File | Location
tvwlpsystemstests.exe | [%SYSTEMDRIVE%]\Program Files\Microsoft Driver Test Manager\Tests\<architecture>\NTTest\multimediatest\ehome\tools\tvwlptest\

Test Assertions

  • Test Assertion GUID:
  • 8A6E34EE-B27A-4DE2-A4A7-49974C0CE9A5
  • Windows Logo Program: Windows Logo program


Test for EDID Requirements (Manual)

Type: Manual Test

Overview

This test parses through the Extended Display Identifier (EDID) and verifies that the parameters specified match those of the physical device.

Details

Run Time: A few minutes
Log File: CCDEdid.xml
System Restart Required: No
Program: CCDEdid.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Windows 7

  • Windows Vista

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Keyboard

  • Mouse

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • IA64

Running the test

All test cases return PASS. Review the test results in the log file for specific details about failures.

Command Syntax

Command option | Description
CCDEdid.exe | Without any options, run the test.

Code Tour

File Manifest

File | Location
CCDEdid.exe | [testbinroot]\NTTEST\WINDOWSTEST\Graphics\wddm\bin


TCG BIOS DOS Test Tool

Overview

This test validates the functions of the Trusted Computing Group (TCG) Int 1Ah, sub-function BBh, the interface that the BitLocker Drive Encryption (BDE) feature of Windows Vista and later operating systems depends on.

Note This is a test tool intended to speed up TCG BIOS development and does not have to be run to meet a Windows Logo requirement.

Note This test applies to client only.

Details

This TCG BIOS development test tool is shipped with the WLK as a precompiled, 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."

Run Time:
Log File:
System Restart Required:
Test Category:

Supported operating systems for Logo or Signature testing:

  • MS-DOS

  • Windows 7

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • BIOS that implements the TCG-specified INT 1Ah, sub-function BBh, interface

  • TPM 1.2

  • Removable Boot Device

Processor

  • x86

  • X64

Running TCG BIOS DOS Test Tool

Hardware state preconditions for running the test:

  • The TPM_ACCESS_0.activeLocality must equal 1. (This test tool assumes the active locality is locality zero and it does not attempt to make locality zero active before sending a locality zero command to the TPM. Fortunately, this is the default state for the TPM when initial program loader code begins running.)

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 disk, a CD-ROM or a DVD that emulates an MS-DOS floppy, or a USB removable storage device that starts the system to an MS-DOS prompt.

Step 2: Start the system under test from the removable start 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 MS-DOS prompt, enter tcgbios.exe; if the test returns with an MS-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 start device that contains the tcgbios.exe file.

Step 4b: At the MS-DOS prompt, enter tcgbios.exe > tcgbios.log. (NOTE: If you used a read-only optical media for the removable start 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 restart the system in order to re-run the test.

Part 2 -- Interpreting 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 specifications can be downloaded from the TCG public website Trusted Computing Group .

The test results log is subdivided into the following parts, in sequence, from top to bottom:

**** 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.

**** StatusCheck ****

---------------------------------------------------------

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, this BIOS implements that function.

(d) An indication that the BIOS implements event logging; if EDI <> 0 and EDI <> ESI, 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 fact 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

**** Read PCR ****

---------------------------------------------------------

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 startup 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, the 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

**** Extend PCR ****

---------------------------------------------------------

This test uses the TCG_PassThroughToTPM function and the TCG_HashAll function (see section 12.10 of the TCG BIOS Specification) 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, the 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

**** HashAll ****

---------------------------------------------------------

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, the test results are:

PASS: Test vector correct

PASS: Test vector correct

PASS: Test vector correct

**** CompactHashLogExtendEvent ****

---------------------------------------------------------

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, the 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

**** ShutdownPreBootInterface ****

---------------------------------------------------------

This test validates that the TCG_ShutdownPreBootInterface function (see section 12.8 of the TCG BIOS Specification).

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, the test results are:

PASS: TCG API Present

PASS: Shutdown successful

PASS: TCG API no longer present

Code Tour

File Manifest

File | Location
tcgbios.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\tools

Test Assertions

Windows Logo Program: SYSFUND-0031 Systems implementing TPM support secure startup by using system firmware security enhancements


TCG TPM Integration Test

Type: Manual Test

Overview

The TCG TPM Integration test validates that the integration of the Trusted Platform Module (TPM) on the system motherboard meets the Windows 7, Windows Vista, Windows Server 2008 and Windows Server 2008 R2 BitLocker Drive Encryption feature requirements.

Note This test applies to both client and server.

For the latest documentation about this test, join the Windows Driver Kit and Windows Logo Kit Program on Microsoft Connect and download the latest Driver Test Manager (DTM) documentation.

Details

This is a test of the Trusted Computing Group (TCG) system integration. This test is run after a full boot and exercises the TPM and BIOS behavior, including taking ownership of the TPM, issuing and verifying TPM command execution, sending physical presence commands to change the state of the TPM, and verifying that TPM state changes occurred.

The Tpmsysint.exe binary file first removes security protection on the TPM driver to enable raw communication through the TDDL layer from user mode. It then reboots to apply the changes. The TPMSysInt.exe is used to run a set of tests to ensure the BIOS and TPM meet the requirements. Next all of the physical presence interface operations are performed with a reboot or a shutdown so the test operator may confirm the physical presence request in the system BIOS during boot. After the test tasks are completed the security is replaced on the TPM driver and a reboot occurs to apply the changes.

This test also configures the TPM Base Services (TBS) service to not start automatically while the test is run. As a result, the TBS services cannot call the TPM Driver while the tests are running. You should disable any third-party software that is installed on the computer that uses the TBS while the test is run, so it does not restart the TBS and interfere with the test. After the test completes the TBS is reconfigured to the start automatically.

Run Time: 30 to 60 minutes
Log File:TPMSysInt.xml
System Restart Required: Yes

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Server 2008

  • Windows Vista

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • TPM 1.2.

  • TPM-aware BIOS.

  • TPM State- To run this test in DTM, you must first have an endorsement key (EK) provisioned, the TPM enabled, the TPM activated, ownerinstall = TRUE, and no owner present. (Often, you can accomplish these steps by using the system BIOS setup utility to clear, enable, and activate the TPM, but not all BIOS setup tool implementations achieve the correct state by following the steps.) The location of the TPM setting in the BIOS utility might vary.

  • EK Provisioning- Microsoft recommends that platform manufacturers deliver TPM hardware to customers with an EK already provisioned. If the test platform does not have an EK provisioned, Microsoft recommends provisioning the EK by using the Microsoft Management Console (MMC) snap-in for TPM Management to initialize the TPM. This snap-in creates an EK for the TPM.

  • BIOS with capabilities to hide the TPM- Some BIOS implementations have features to hide the physical presence of TPM from the platform. Unless the platform is manufactured to permanently and irreversibly prevent usage of the TPM, it must not be hidden while running this test.

  • Disable any third-party software, which might call the Trusted Platform Module Base Services (TBS).

Processor

  • x86

  • x64

Running TCG TPM Integration Test

Setup

  • TPM State:

To run this test in DTM you must first have an endorsement key (EK) provisioned, the TPM enabled, the TPM activated, ownerinstall = true, and no owner present. (Often, you can accomplish these steps by using the system BIOS setup utility to clear, enable, and activate the TPM, but not all BIOS setup tool implementations achieve the correct state by following the steps.) The location of the TPM setting in the BIOS utility might vary.

  • EK Provisioning:

We recommend that platform manufacturers deliver TPM hardware to customers with an EK already provisioned. If the test platform does not have an EK provisioned, we recommends provisioning the EK by using the Microsoft Management Console (MMC) snap-in for TPM Management to initialize the TPM. This snap-in creates an EK for the TPM.

  • BIOS with capabilities to hide the TPM:

Some BIOS implementations have features to hide the physical presence of TPM from the platform. Unless the platform is manufactured to permanently and irreversibly prevent usage of the TPM, it must not be hidden while running this test.

  • Also ensure the requirements stated in the "Environment Requirements" section below have been satisfied.

Running the Test

Run the job in the DTM framework.

Manual Interaction

This test does require a user to be present at the system under test to validate the Physical Presence Interface. The testing of this interface requires multiple (14+) restarts (or shutdowns and power-ons) and the pressing of the ACCEPT key during the boot process to approve each physical presence request operation. The test operator must ACCEPT all physical presence requests during the boot process. If the platform requires itself to be turned off before executing a physical presence command, the test operator must manually turn on the platform for each physical presence command.

This test may put the machine to sleep or hibernate using a timer to wake it back up. Not all platforms support waking on a timer. Such platforms will require the test operator to manually wake the machine from sleep, or power on the machine after hibernation.

Additional Background

The Trusted Computing Group (TCG) specification for the TPM requires that some commands confirm execution of the command by a user physically present at the platform console. Many platforms implement the physical presence approval of a TPM command by requiring a restart or shutdown of the platform and prompting the user for approval in the pre-boot/BIOS environment. (The choice of restart or shutdown is up to the platform manufacturer.) The Windows Logo Kit (WLK) incorporates more rigorous testing of platforms' physical presence interface by forcing the physical presence confirmation to actually occur (usually by a restart or a shutdown). This change was necessary in the WLK because many platforms did not implement the physical presence functionality according to the TCG specifications, but still were able to pass the previous WLK tests. For the WLK TCG TPM Integration tests, platform manufacturers should approve all physical presence requests in the BIOS after the computer is rebooted or restarted. in future versions of the WLK, negative tests might exist where one or more physical presence requests should be denied.

Command Syntax

Command option | Description
tpmsysint.exe /testcaseid 2 | Removes protection on the TPM driver so tests can access it
tpmsysint.exe | Performs multiple tests of TPM functionality
tpmppi.exe /n ACPISubmitSetReq05 | Submit PPI operation #5
tpmppi.exe /n ACPISubmitGetReq05 | Verify PPI operation #5 is pending
tpmppi.exe /n ACPISubmitBasicGetTrans | Queries action to perform PPI operation and writes command script ppitransition.cmd
tpmppi.exe /n ACPISubmitGetResp05 | Verifies PPI operation #5 completed
tpmppi.exe /t 50 | Verifies TPM state set to the defaults
tpmppi.exe /n VerifyTPMIsUnowned | Verifies the TPM is unowned
tpmppi.exe /n ACPISubmitSetReq01 | Submit PPI operation #1
tpmppi.exe /n ACPISubmitGetReq01 | Verifies PPI operation #1 is pending
tpmppi.exe /n ACPISubmitGetResp01 | Verifies PPI operation #1 completed
tpmppi.exe /t 51 | Verifies TPM is enabled
tpmppi.exe /n ACPISubmitSetReq03 | Submit PPI operation #3
tpmppi.exe /n ACPISubmitGetReq03 | Verifies PPI operation #3 is pending
tpmppi.exe /n ACPISubmitGetResp03 | Verifies PPI operation #3 completed
tpmppi.exe /n ACPISubmitSetReq04 | Submit PPI operation #4
tpmppi.exe /n ACPISubmitGetReq04 | Verifies PPI operation #4 is pending
tpmppi.exe /n ACPISubmitGetResp04 | Verifies PPI operation #4 completed
tpmppi.exe /t 52 | Verifies TPM is enabled and activated
tpmppi.exe /n ACPISubmitSetReq02 | Submit PPI operation #2
tpmppi.exe /n ACPISubmitGetReq02 | Verify PPI operation #2 is pending
tpmppi.exe /n ACPISubmitGetResp02 | Verifies TPM operation #2 completed
tpmppi.exe /t 53 | Verifies TPM is activated and disabled
tpmppi.exe /n ACPISubmitSetReq07 | Submit PPI operation #7
tpmppi.exe /n ACPISubmitGetReq07 | Verifies PPI operation #7 is pending
tpmppi.exe /n ACPISubmitGetResp07 | Verifies PPI operation #7 completed
tpmppi.exe /n ACPISubmitSetReq06 | Submit PPI operation #6
tpmppi.exe /n ACPISubmitGetReq06 | Verifies PPI operation #6 is pending
tpmppi.exe /n ACPISubmitGetResp06 | Verifies PPI operation #6 completed
tpmppi.exe /n ACPISubmitSetReq09 | Submit PPI operation #9
tpmppi.exe /n ACPISubmitGetReq09 | Verifies PPI operation #9 is pending
tpmppi.exe /n ACPISubmitGetResp09 | Verifies PPI operation #9 completed
tpmppi.exe /n ACPISubmitSetReq08 | Submit PPI operation #8
tpmppi.exe /n ACPISubmitGetReq08 | Verifies PPI operation #8 is pending
tpmppi.exe /n ACPISubmitGetResp08 | Verifies PPI operation #8 completed
tpmppi.exe /n ACPISubmitSetReq11 | Submit PPI operation #11
tpmppi.exe /n ACPISubmitGetReq11 | Verifies PPI operation #11 is pending
tpmppi.exe /n ACPISubmitGetResp11 | Verifies PPI operation #11 completed
tpmppi.exe /t 54 | Verifies TPM disallows taking ownership
tpmppi.exe /n ACPISubmitSetReq10 | Submit PPI operation #10
tpmppi.exe /n ACPISubmitGetReq10 | Verifies PPI operation #10 is pending
tpmppi.exe /n ACPISubmitGetResp10 | Verifies PPI operation #10 completed
tpmppi.exe /n TakeOwnership | Takes ownership of the TPM
tpmppi.exe /n VerifyTPMIsOwned | Verifies the TPM is owned
tpmppi.exe /n ACPISubmitSetReq14 | Submit PPI operation #14
tpmppi.exe /n ACPISubmitGetReq14 | Verifies PPI operation #14 is pending
tpmppi.exe /n ACPISubmitGetResp14 | Verifies PPI operation #14 completed
tpmppi.exe /n VerifyTPMIsUnowned | Verifies TPM is not owned
tpmsysint.exe /testcaseid 1 | Replaces protection on TPM driver

Troubleshooting

When you try to determine the reason for test failures, it might be helpful to run the "TCG BIOS DOS Test Tool" to bypass the BIOS and examine how the TPM responds to its set of tests. The "TCG BIOS DOS Test Tool is not part of the set of tests run by the DTM Controller for Logo compliance, but it is documented in the "System Tests" section of the Driver Test Manager help documentation.

Code Tour

File Manifest

File | Location
tddl.dll | [WTT\TestBinRoot]\nttest\basetest\ngscb\tpminteg
tpmsysint.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\tpminteg
tpmppi.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\tpminteg

Test Assertions

1v1.2 TPM driver loaded successfully
Test Assertion GUID: 97F58D25-D7E9-3323-D6D6-E051445454A9

Windows Logo Program: SYSFUND-0030 Systems implementing support for secure startup and full volume encryption use TPM v1.2, or later

2v1.2 TPM driver successfully unloaded and reloaded
Test Assertion GUID: 97F58D25-D7E9-3323-D6D6-E051445454AA

Windows Logo Program: SYSFUND-0030 Systems implementing support for secure startup and full volume encryption use TPM v1.2, or later

3TPM starts up when commanded to do so.
Test Assertion GUID: 1E2EC9C1-1C7E-4859-B68E-0EDEBEA337CE

Windows Logo Program: SYSFUND-0030 Systems implementing support for secure startup and full volume encryption use TPM v1.2, or later

4TPM 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 secure startup and full volume encryption use TPM v1.2, or later

5After 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 secure startup and full volume encryption use TPM v1.2, or later

6TPM 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 secure startup and full volume encryption use TPM v1.2, or later

7TPM 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 secure startup and full volume encryption use TPM v1.2, or later

8System 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 secure startup and full volume encryption use TPM v1.2, or later

9TPM 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 secure startup and full volume encryption use TPM v1.2, or later

10TPM 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 secure startup and full volume encryption use TPM v1.2, or later

11TPM 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 secure startup and full volume encryption use TPM v1.2, or later

12TPM 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 secure startup and full volume encryption use TPM v1.2, or later

13TPM 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 secure startup and full volume encryption use TPM v1.2, or later

14TPM 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 secure startup and full volume encryption use TPM v1.2, or later

15TPM 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 secure startup and full volume encryption use TPM v1.2, or later

16TPM 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 secure startup and full volume encryption use TPM v1.2, or later

17TPM 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 secure startup and full volume encryption use TPM v1.2, or later

18TPM reads PCRs.
Test Assertion GUID: 24827510-ECB4-45a1-AE54-5F151007180D

Windows Logo Program: SYSFUND-0030 Systems implementing support for secure startup and full volume encryption use TPM v1.2, or later

19TPM extends PCRs.
Test Assertion GUID: 79C9A00E-5891-42a3-AC5E-A0630CA6EA88

Windows Logo Program: SYSFUND-0030 Systems implementing support for secure startup and full volume encryption use TPM v1.2, or later

20BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

21BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

22BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

23BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

24BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

25BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

26BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

27BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

28BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

29BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

30BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

31BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

32BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

33BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

34BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

35BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

36BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

37BIOS 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 secure startup and full volume encryption use TPM v1.2, or later

38Port IO Mode not detected
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4209000

Windows Logo Program: SYSFUND-0030 Systems implementing support for secure startup and full volume encryption use TPM v1.2, or later


TCG UEFI Protocols Test Tool

Overview

This utility is designed to test the implementation of the standard interface to the TPM on a UEFI platform. It also verifies functionality specified in the Trusted Computing Group (TCG) Platform Reset Attack Mitigation specification.

Note The tool is not used by the Windows Logo Tests, but is distributed with the Windows Logo Kit to assist platform manufacturers in troubleshooting test failures associated with SYS-FUND 0031.

Note This test applies to client only.

Related Industry Specifications:

TCG EFI Protocol

TCG Platform Reset Attack Mitigation Specification

Details

The tool runs the following nine tests:

  1. Calling EFI_TCG_PROTOCOL.StatusCheck()

  2. Using TPM_GetCapability to get the TPM version, spec level & vendor ID

  3. Reading PCRs 0 through 15

  4. Clearing PCR 16, hashing a value, reading the result, and comparing it to a pre-calculated value

  5. Calling EFI_TCG_PROTOCOL.HashAll() with three different data values to hash and comparing the results to pre-calculated values

  6. Calling EFI_TCG_PROTOCOL.LogEvent(), then checking the return value (examination of the actual log does not occur)

  7. Clearing PCR 16, calling EFI_TCG_PROTOCOL.TCGHashLogExtendEvent() to extend PCR 16 and log an event, reading PCR 16, using EFI_TCG_PROTOCOL.HashAll() to compute the expected PCR 16 value, and comparing it to the PCR 16 value (examination of the actual log does not occur)

  8. Setting the Memory Overwrite Request Bit ClearMemory bit to 1

  9. Setting the Memory Overwrite Request Bit ClearMemory bit to 0

Requirements

Software Requirements

The test tool requires the following software:

  • A UEFI shell

Hardware Requirements

The test tool requires the following hardware:

  • Platform to be tested

  • Windows keyboard

  • Firmware that implements the TCG EFI Protocol version 1.20

  • TPM 1.2

Versions of the Utility

There are two versions of the tool, because some firmware implementations do not work correctly when the base address is over the range addressable by 32 bits.

  1. tcgefi.efi has no specific constraints on the preferred base address.

  2. tcgefifw.efi is linked to use a 32-bit base address.

Running TCG UEFI BIOS DOS Test Tool

Copy the test executable so it is available to run from a UEFI shell. Then, type the test executable name at the UEFI shell prompt.

The tool does not accept command line arguments. After it is started, it accepts user input for which test to run. Pressing Enter runs all tests. Pressing a number 1 though 9 runs the corresponding test as numbered above.

Redirecting Output to a File

To redirect the output to a file use the following command:

     tcgefi.efi > result.txt

This will work most reliably when running the tool from the hard drive. It may be helpful to copy the tool from a USB device to the hard drive before running it.

Sample Output

Application started
Press Any Key to Continue
----------------------------------------------------------------------
-------------------------Begin Status Check---------------------------
-----> Status Check
    Size of the structure ProtocolCapability: 12
    Structure Version                       : 01.02
    Rev Structure Version                   : 00.00
    Protocol Spec Version                   : 01.02
    Rev Protocol Spec Version               : 00.00
    TPM Present      (00h=TPM Not Present)  : 0x1
    TPM Deactivated  (01h=TPM Deactivated)  : 0x0
    Feature Flag                            : 0
    Start Event Log Address                 : 0x7d4af000
    Last Event Log Address                  : 0x7d4b05ca
    Status Check result 0
<----- Status Check
 TEST PASS
 -------------------------End Status Check-----------------------------
----------------------------------------------------------------------
--------------------------------------------------------------------
-------------------------Begin Get Capability-------------------------
----->Get Capability
Command String Passed :
00 : 00 c1 00 00 00 12 00 00 00 65 00 00 00 1a 00 00
16 : 00 00
Command String Received :
00 : 00 c4 00 00 00 22 00 00 00 00 00 00 00 14 00 30
16 : 01 02 03 10 00 02 02 49 46 58 00 00 05 03 10 00
32 : 08 00 00 00 00 00 00 00 ab a7 ce 7b 00 00 00 00
48 : 18 a0 c6 7b 00 00 00 00 00 00 00 00 00 00 00 00
64 : 00 92 05 10 00 00 00 00 64 00 00 00 00 00 00 00
80 : 00 12 09 10 00 00 00 00 00 12 09 10 00 00 00 00
96 : 18 a0 c6 7b 00 00 00 00 00 00 00 00 00 00 00 00
112 : 00 92 05 10 00 00 00 00 64 00 00 00 00 00 00 00
128 : e8 ca 19 7d 00 00 00 00 00 12 09 10 00 00 00 00
144 : 00 00 00 00 00 00 00 00 28 b1 77 7a 00 00 00 00
160 : 98 2a 1f 7c 00 00 00 00 26 c5 1b 7c 00 00 00 00
176 : 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00
192 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
208 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
224 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
240 : 72 63 c6 50 99 2b 00 00 00 00 00 00 00 00 00 00
256 : e0 93 05 10 00 00 00 00 18 a0 c6 7b 00 00 00 00
272 : 01 00 00 00 00 00 00 00 00 00 00 00 00
TPM  version 1.2 (rev 3.16)
TPM  Spec level 2
TPM  VendorID IFX
<-----Get Capability
 TEST PASS
 -------------------------End Get Capability---------------------------
----------------------------------------------------------------------
--------------------------------------------------------------------
-------------------------Begin PCR Read-------------------------------
-----> Pcr Read
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 00
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 89 09 cd b0 12 69
16 : 76 4f 60 39 68 4e 62 f5 ba d0 e8 b8 1a e9
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 01
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 fa 9e 52 ce ac e4
16 : 0d 93 30 5c b6 95 84 6e 18 86 5b a4 20 fb
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 02
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 a4 c3 46 80 68 a2
16 : 89 76 1e 56 77 2a 7c 22 e4 fb ca 9f 9a 1d
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 03
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 b2 a8 3b 0e bf 2f
16 : 83 74 29 9a 5b 2b df c3 1e a9 55 ad 72 36
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 04
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 b2 a8 3b 0e bf 2f
16 : 83 74 29 9a 5b 2b df c3 1e a9 55 ad 72 36
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 05
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 b3 74 64 3d da fa
16 : 2d a8 87 7a 92 1d 37 ec 45 0a dc e6 55 21
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 06
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 b2 a8 3b 0e bf 2f
16 : 83 74 29 9a 5b 2b df c3 1e a9 55 ad 72 36
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 07
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 b2 a8 3b 0e bf 2f
16 : 83 74 29 9a 5b 2b df c3 1e a9 55 ad 72 36
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 08
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 00 00 00 00 00 00
16 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 09
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 00 00 00 00 00 00
16 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 0a
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 00 00 00 00 00 00
16 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 0b
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 00 00 00 00 00 00
16 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 0c
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 22 c6 b4 28 bd 20
16 : cb d5 c4 e3 1b 61 5c 01 a5 09 ac e2 c0 83
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 0d
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 00 00 00 00 00 00
16 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 0e
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 00 00 00 00 00 00
16 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<---- Pass Through to TPM
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 0f
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 00 00 00 00 00 00
16 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<---- Pass Through to TPM
PCR 0 :8909cdb01269764f6039684e62f5bad0e8b81ae9
PCR 1 :fa9e52ceace40d93305cb695846e18865ba420fb
PCR 2 :a4c3468068a289761e56772a7c22e4fbca9f9a1d
PCR 3 :b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
PCR 4 :b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
PCR 5 :b374643ddafa2da8877a921d37ec450adce65521
PCR 6 :b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
PCR 7 :b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
PCR 8 :0000000000000000000000000000000000000000
PCR 9 :0000000000000000000000000000000000000000
PCR 10 :0000000000000000000000000000000000000000
PCR 11 :0000000000000000000000000000000000000000
PCR 12 :22c6b428bd20cbd5c4e31b615c01a509ace2c083
PCR 13 :0000000000000000000000000000000000000000
PCR 14 :0000000000000000000000000000000000000000
PCR 15 :0000000000000000000000000000000000000000
<----- Pcr Read
 TEST PASS
 -------------------------End Pcr Read---------------------------------
----------------------------------------------------------------------
--------------------------------------------------------------------
-------------------------Begin PCR Extend-----------------------------
----->PCR Extend
----->Pcr 16 clear
----->Pass Through to TPM
pcrSelect            : 00 00 01
Command String Passed :
00 : 00 c1 00 00 00 0f 00 00 00 c8 00 03 00 00 01
Command String Received :
00 : 00 c4 00 00 00 0a 00 00 00 00
<-----Pass Through to TPM
PASS
<-----Pcr 16 clear
----->Pcr 16 Extend
----->Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 22 00 00 00 14 00 00 00 10 30 30
16 : 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
32 : 30 30
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 5f 7b a6 a3 68 90
16 : c8 c5 5d 1f 0b 93 57 7f d1 f9 be ad a3 c2
<-----Pass Through to TPM
PASS
 Pcr Value:5f 7b a6 a3 68 90 c8 c5 5d 1f 0b 93 57 7f d1 f9 be ad a3 c2
<-----Pcr 16 Exend
----->Hash All
Data to be hashed:
00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
16 : 00 00 00 00 30 30 30 30 30 30 30 30 30 30 30 30
32 : 30 30 30 30 30 30 30 30
PASS
Hashed Data :5f 7b a6 a3 68 90 c8 c5 5d 1f 0b 93 57 7f d1 f9 be ad a3 c2
<-----Hash All
----->Hash Comparision
 Hash of data :5f 7b a6 a3 68 90 c8 c5 5d 1f 0b 93 57 7f d1 f9 be ad a3 c2
 Pcr Value  :5f 7b a6 a3 68 90 c8 c5 5d 1f 0b 93 57 7f d1 f9 be ad a3 c2
HASH COMPARISION PASS
<-----Hash Comparision
<-----PCR Extend
 TEST PASS
 -------------------------End PCR Extend-------------------------------
----------------------------------------------------------------------
--------------------------------------------------------------------
-------------------------Begin Hash All-------------------------------
----->Hash All
Data to be hashed:
Hashed Data :da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09
----->Hash Comparision
HASH COMPARISION PASS
<-----Hash Comparision
----->Hash All
----->Hash All
Data to be hashed:
00 : 61 62 63
Hashed Data :a9 99 3e 36 47 06 81 6a ba 3e 25 71 78 50 c2 6c 9c d0 d8 9d
----->Hash Comparision
HASH COMPARISION PASS
<-----Hash Comparision
----->Hash All
----->Hash All
Data to be hashed:
00 : 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
16 : 71 72 73 74 75 76 77 78 79 7a
Hashed Data :32 d1 0c 7b 8c f9 65 70 ca 04 ce 37 f2 a1 9d 84 24 0d 3a 89
----->Hash Comparision
HASH COMPARISION PASS
<-----Hash Comparision
----->Hash All
 TEST PASS
 -------------------------End Hash All---------------------------------
----------------------------------------------------------------------
--------------------------------------------------------------------
-------------------------Begin Log Event------------------------------
Data to be hashed:
00 : 52 61 6e 64 6f 6d 54 65 73 74 44 61 74 61 00
PcrIndex : 16
EventType (EV_NO_ACTION=3) : 3
Digest:
00 : 53 a2 01 31 08 6a f5 47 8b 12 3d 91 38 f0 40 dd
16 : 0d 1c 79 42
Event Size : 15
 TEST PASS
 -------------------------End Log Event--------------------------------
----------------------------------------------------------------------
--------------------------------------------------------------------
-------------------------Begin Hash Log Extend------------------------
----->Hash Log Extend Event
-----> Pcr 16 clear
----->Pass Through to TPM
pcrSelect            : 00 00 01
Command String Passed :
00 : 00 c1 00 00 00 0f 00 00 00 c8 00 03 00 00 01
Command String Received :
00 : 00 c4 00 00 00 0a 00 00 00 00
<-----Pass Through to TPM
<-----Pcr 16 clear
-----> HashLogExtend
Data to be hashed :
00 : 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
16 : 71 72 73 74
Event:
00 : 10 00 00 00 03 00 00 00 14 a2 3a d7 0f 2a 5d d7
16 : 25 57 5d e6 c4 3e 1c dd 8b 15 e3 e5 14 00 00 00
32 : 61
Command String Passed:
00 : 98 c6 19 7d 00 00 00 00 14 00 00 00 00 00 00 00
16 : 04 00 00 00 98 2e c9 7b 00 00 00 00 a0 c5 19 7d
32 : 00 00 00 00 00 00 00 00 47 8a 04 10
 Direct HashLogExtend Status = 0
Event Log Address      0x7d19c5a8
<----- HashLogExtend
-----> Pcr Read 16
----> Pass Through to TPM
Command String Passed :
00 : 00 c1 00 00 00 0e 00 00 00 15 00 00 00 10
Command String Received :
00 : 00 c4 00 00 00 1e 00 00 00 00 06 00 fb e7 a5 c8
16 : 89 40 22 7a a8 7c f9 97 f5 f4 f5 0a a2 41
<---- Pass Through to TPM
Pcr 16 Value :0600fbe7a5c88940227aa87cf997f5f4f50aa241
<----- Pcr Read 16
----->Hash All
Data to be hashed:
00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
16 : 00 00 00 00 14 a2 3a d7 0f 2a 5d d7 25 57 5d e6
32 : c4 3e 1c dd 8b 15 e3 e5
Hashed Data :06 00 fb e7 a5 c8 89 40 22 7a a8 7c f9 97 f5 f4 f5 0a a2 41
<-----Hash All
----->Hash Comparision
HASH COMPARISION PASS
<-----Hash Comparision
<-----Hash Log Extend Event
 TEST PASS
 -------------------------End Hash Log Extend--------------------------
----------------------------------------------------------------------
--------------------------------------------------------------------
-------------------------Begin MOR SET Test------------------------
----->MOR Test
Successfully SET MOR Bit
TEST PASS
<-----MOR Test
-------------------------End MOR SET Test--------------------------
----------------------------------------------------------------------
--------------------------------------------------------------------
-------------------------Begin MOR RESET Test------------------------
----->MOR Test
Successfully  RESET MOR Bit
TEST PASS
<-----MOR Test
-------------------------End MOR RESET Test--------------------------
----------------------------------------------------------------------
 All of 9  Tests Passed!!

Code Tour

File Manifest

File | Location
tcgefifw.efi | [WTT\TestBinRoot]\nttest\basetest\ngscb\tools
tcgefi.efi | [WTT\TestBinRoot]\nttest\basetest\ngscb\tools

Test Assertions

Windows Logo Program: SYSFUND-0031 Systems implementing TPM support secure startup by using system firmware security enhancements


TPM TCG OS Interface Test (Manual)

Type: Manual Test

Overview

This test validates that, if present, the system's Trusted Platform Module (TPM) 1.2 complies with the industry standards from the Trusted Computing Group (http://www.trustedcomputinggroup.org). The test also validates that the system motherboard and firmware comply with the PC Client platform requirements from the Trusted Computing Group. Finally, the test validates whether Windows BitLocker Drive Encryption and other TPM related features work properly on the Windows platform with the Microsoft Windows inbox TPM driver. The related Windows Logo Kit requirements are SYS-FUND 0030 and SYS-FUND 0031.

The test passes if the platform does not have a TPM 1.2.

The test sends commands to the TPM to verify that it works correctly. The tests involve taking ownership of the TPM device. Test operator interaction is necessary to release ownership and enable the TPM for subsequent tests at the end of the test.

The test is applicable for Windows 7, Windows Server 2008 R2, and later operating systems. It is not supported for Vista and Windows Server 2008.

The test has been released as a preview test in WLK 1.5, but will be required in the future when the preview period is over.

The test supports TPM 1.2 revisions 85, 94, and 103.

Details

Interfaces used by the test:

The test uses direct communication with the Microsoft TPM driver to validate firmware and TPM device behavior. The TPM driver interface is not a public or documented interface. Using the TPM driver directly avoids complicating the test with TPM resource virtualization, which is part of the TPM Base Services (TBS) public interface. The test reconfigures permissions on the TPM driver to access the driver directly. The change in TPM driver permissions requires a reboot during the test setup actions and during the test clean up actions to reinstate the standard TPM driver permissions.

Prerequisites:

The test requires the following prerequisites:

  • The TPM device must be enumerated by the BIOS to the operating system. By default some hardware platforms hide the TPM from the operating system. The test operator must manually enumerate (unhide) the TPM in the BIOS configuration if it is not enumerated. Nomenclature for this setting may vary by platform manufacturer.

  • The BIOS must allow the TPM to be activated. Some hardware platforms have a BIOS option to deactivate the TPM. If present, the test operator must configure the BIOS setting to allow the TPM to be activated. Nomenclature for this setting may vary by platform manufacturer.

  • The BIOS must allow the operating system to manage the TPM by requesting physical presence interface operations, such as issuing a request for a TPM_ForceClear command. If the platform does not permit the operating system to issue physical presence interface operation requests, the test operator must change the BIOS configuration to permit the operating system to issue physical presence interface operation requests.

  • Microsoft does not support using the TPM on a hardware platform with a third party TPM driver. This test and other operating system features that use the TPM depend on the Microsoft TPM driver. For Windows 7, Windows Server 2008 R2, and later operating systems, if the platform has a third party TPM driver installed, it must be removed. The same information is true for Windows Vista and Windows Server 2008 operating systems, but this test does not apply for those operating systems.

  • The TPM must have an Endorsement Key created on it. TPMs have a persistent key called an Endorsement Key, which is generally permanent once created. Some TPM manufacturers create the TPM Endorsement Key on the device during TPM device manufacturing, while other TPM manufacturers do not. If the system does not have an Endorsement Key created on the TPM, the test operator must manually create the Endorsement Key. The Endorsement key may be created by using a custom tool from the OEM, or by using Start->Run->tpm.msc with administrator rights in the Windows operating system to launch the TPM Management Console and complete the action to "Initialize the TPM". The process to initialize the TPM creates the Endorsement Key, but it also takes ownership of the TPM. The test requires the TPM to not be owned, so after initializing the TPM in the TPM Management Console, the test operator should also use the action to "Clear the TPM" and then "Turn on" the TPM.

  • 3rd party applications that use the TPM must be off, even if the system is restarted. The test needs exclusive control of the TPM device to perform uninterrupted sequences of TPM commands. Use of TPM Base Services API by a 3rd party application will send commands to the TPM, confusing the test results. Any application that uses the TPM should be configured to not run while the test is in progress. This includes if the system is restarted.

  • The TPM should have the following flag settings when the test starts. Many of these settings are the defaults or are set for convenience during the test setup actions with test operator interaction. It is unusual for a test operator to need to manually modify these settings. Please refer to the Trusted Computing Group TPM Structure Specification to understand the TPM Flag Name definitions.

    TPM Flag Name

    Value

    Notes

    TPM_PF_OWNERSHIP

    TRUE

    Required to allow the test to take ownership of the TPM. This flag's value is commonly referred to as whether ownership of the TPM has been taken.

    TPM_PF_DEACTIVATED

    FALSE

    Whether or not the TPM will be deactivated during the next boot. The test needs the TPM to be activated, even after a reboot.

    TPM_PF_DISABLE

    FALSE

    The test needs the TPM to be enabled. This flag's value is commonly referred to as whether the TPM is enabled or disabled.

    TPM_PF_READPUBEK

    TRUE

    To take ownership of the TPM, the test must read the public part of the TPM's Endorsement Key.

    TPM_PF_DISABLEOWNERCLEAR

    FALSE

    At the end of the test, the TPM state is changed so ownership has not been taken of the TPM. This is done using the TPM_OwnerClear command, which fails if this setting is not FALSE.

    TPM_SF_DEACTIVATED

    FALSE

    The TPM must be activated for many of the tests commands to succeed. This flag's value is commonly referred to as whether the TPM is activated or deactivated.

    TPM_PF_PHYSICALPRESENCELIFETIMELOCK

    TRUE

    After the OEM completes manufacturing of a system with a TPM, this flag must be set to TRUE. The system under test should have completed the manufacturing process.

  • If the hardware platform supports sleep or hibernation, the operating system must be manually configured to allow sleep and hibernation. For example, if the platform supports hibernation, a location for a hibernation file must be specified in the operating system's power configuration settings.

Automatic test prerequisite provisioning included in test setup actions

For test operator convenience, the test is designed to automatically attempt the following TPM state changes during test setup actions:

  • deactivated -> activated [Flag name TPM_SF_DEACTIVATED]

  • disabled -> enabled [Flag name TPM_PF_DISABLE]

  • ownership taken -> ownership not taken [Flag name TPM_PF_OWNERSHIP]

Because TPM devices are designed to explicitly require user opt-in for TPM state changes when implemented on a PC Client platform, the process will involve test operator interaction.

The process works as follows:

  1. During the test setup actions, the test has the operating system request that the platform firmware prompt the user for approval of the necessary TPM state change during the boot process.

  2. The test shuts down or restarts the hardware platform.

  3. If the system is designed to require a shutdown instead of a restart, the test operator turns the hardware platform back on.

  4. During the boot process, the firmware prompts the test operator to approve the TPM state change by pressing an ACCEPT or REJECT key, which is usually defined as a function key on the keyboard.

  5. The test operator accepts the TPM state change by pressing the ACCEPT key.

  6. The firmware changes the TPM state.

  7. The operating system boots and the test continues automatically.

Test actions:

Setup:

  1. Change the permissions on the TPM driver so that the test can communicate with it directly, reboot, and the changes can take effect.

  2. Check the state of the TPM and issue physical presence command requests to change the TPM state so ownership has not been taken, the TPM is enabled, and the TPM is activated. The action restarts or shuts down the platform so that the TPM state change request is displayed to the test operator during the next boot of the platform. The test operator should accept the TPM state change during boot.

Tests:

  1. Queries the TPM version.

  2. Checks some TPM state prerequisites and displays the values of TPM PERMANENT flags and the ST CLEAR flags.

  3. Checks TPM_Startup was issued by the BIOS during boot.

  4. Checks TPM_SaveState may be issued.

  5. Checks TPM_ContinueSelfTest executes.

  6. Checks TPM_SelfTestFull executes.

  7. Checks TPM_GetTestResult executes.

  8. Checks TPM_GetRandom returns at least one byte of entropy.

  9. Checks all of the different sub capabilities that may be queried and displays their values.

  10. Reads PCRs 0 through 23, checks that PCRs 8 through 15 are reserved for the Static Operating System, and check that 17 through 22 are reserved for the Dynamic Operating System.

  11. Checks taking ownership of the TPM.

  12. Checks TPM_ResetLockValue.

  13. Checks using TPM_CreateWrapKey, TPM_LoadKey2, TPM_Seal, and TPM_Unseal without using PCRs.

  14. Checks using TPM_CreateWrapKey, TPM_LoadKey2, and TPM_Seal, TPM_Unseal using PCRs.

  15. Checks sealing with the Storage Root Key.

  16. Checks that the Microsoft TPM driver uses memory mapped I/O to communicate with the TPM device.

  17. Extends PCRs to verify that the PCRs for the Dynamic Operating System may not be extended from locality zero.

  18. Checks the PCRs extended by reading the PCR values.

  19. If the platform supports hibernation, the test hibernates the platform by using a wake timer to wake it back up, and checks that the PCR values match the original boot values for PCRs used by Windows BitLocker. For a hardware platform with conventional BIOS, this is PCRs 0, 2, 4, 5, 8, 9, and 10. For UEFI platforms, this is PCRs 0, 2, and 4.

  20. If the platform supports sleep, the test puts the platform to sleep by using a wake timer to wake it back up, after extending values into PCRs 15 and 23, and checks that the Static Root of Trust PCR values have their pre-sleep values restored. It also checks that the values of resettable PCRs are initialized to the correct default values. The Static Root of Trusted PCRs are 0-15. Resettable PCRs are 17-23.

  21. Checks changing the TPM owner authorization value and changing the TPM SRK authorization value.

  22. Checks TPM_OwnerClear executes. A side effect of this action is the TPM state is changed to disabled.

  23. Queries which ordinals the TPM supports.

Cleanup:

  1. If the tests complete successfully, the final state of the TPM will be disabled. A physical presence interface request operation will be issued to change the TPM state to enabled. The action restarts or shuts down the platform, so that the TPM state request is displayed to the test operator during the next boot of the platform. The test operator should accept the TPM state change during boot.

    Warning Failure to change the TPM state back to enabled may cause the TPM to not meet the prerequisites of other tests, like the TCG TPM Integration Test or the BitLocker BIOS Interface Test. Neither of these two tests automatically change the TPM to enabled during their test setup actions. Starting either of the tests with TPM state as disabled will cause them to fail.

  2. If the test fails to complete successfully, the final state of the TPM may be ownership has been taken. A physical presence interface request operation will be issued to change the TPM state to ownership has not been taken and the TPM is enabled. The action restarts or shuts down the platform so that the TPM state request is displayed to the test operator during the next boot of the platform. The test operator should accept the TPM state change during boot.

    Warning Failure to change the TPM state back to ownership has not been taken and enabled may cause the TPM to not meet the prerequisites of other tests, like the TCG TPM Integration Test or the BitLocker BIOS Interface Test. Neither of these two tests automatically change the TPM so that ownership has not been taken or make the TPM enabled during their test setup actions. Starting either of the tests with TPM ownership taken or the TPM state as disabled will cause them to fail.

  3. Change the permissions on the TPM driver back to normal and reboot so the changes take effect.

Run Time: 5 minutes to an hour (depending on system boot time and test operator interaction)
Log File: tcgosint.xml
System Restart Required: Yes (and the test operator must ACCEPT any TPM state changes during the boot process)
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program: The test binaries are tcgosint.exe and tpmppi.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running the Test

When running the test, the test operator should complete the following steps:

  1. Be present at the computer for the entire time the test runs.

  2. Configure the BIOS to allow use of the TPM and permit the OS to manage the TPM.

  3. Expect several reboots.

  4. If the system turns off its power, turn the system back on (this may happen more than once).

  5. Accept any requests to change the TPM state during the boot process

The test may put the platform to sleep and may hibernate the platform. For both of these actions, the test is designed to wake the system up after several minutes using a wake timer. Sometimes the wake timers do not work correctly. If this occurs, the test operator can manually wake the system back up from sleep or hibernation using the power button. Prematurely waking the platform from sleep or hibernation will not affect the test results. Sometimes the test operator may want to wake the platform prematurely to speed up the test; this is acceptable as well.

On some platforms, the operating system requests a physical presence command to change the state of the TPM. Also, it must turn off the platform so the test operator is prompted to approve the state change on the next boot of the platform. If the platform requires a shutdown to perform physical presence operations on the TPM, the test operator must manually turn the platform back on.

Some platforms have a very short time period to respond to a test operator prompt to approve a TPM state change. If the test operator does not respond quickly, the platform assumes the test operator does not approve the TPM state change. If the test operator misses approval of a TPM state change request, it may cause the test to fail or may cause other tests like the TCG TPM Integration Test or the BitLocker Drive Encryption BIOS Interface Logo Test to fail when run later. The test operator should be attentive in watching and responding to TPM state change requests during the boot process.

Command Syntax

This test does not support running the test executables manually.

Troubleshooting

  1. Download the latest errata from the Microsoft Connect site. Because this test is a preview test, there may be errata created for common situations identified after the test is released.

  2. Test failures frequently occur because the platform is not configured to meet the test prerequisites. Make sure that the system meets the prerequisites in the "Details" section above.

  3. The test output is designed to show all commands and responses sent to and received from the TPM device. The test output nomenclature is consistent with the specifications from the Trusted Computing Group. Refer the test failures to the TPM experts in your organization. The relevant industry specifications are published at http://www.trustedcomputinggroup.org/

Code Tour

File Manifest

File | Location
tddl.dll | [testbinroot]\nttest\basetest\ngscb
tcgosint.exe | [testbinroot]\nttest\basetest\ngscb
tpmppi.exe | [testbinroot]\nttest\basetest\ngscb


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 ensures that the devices are still functional after these state changes through SimpleIO stress testing.

Note This test applies to client only.

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 option available in Windows Device Manager and is not class 'LegacyDriver'.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

To run WDTF manually, follow these steps:

  1. After you install the WDTF through the WDK installation media, copy the files from WDKPath\WDTF\ProcessorArchitecture to a directory on the computer, where:

    • WDKPath is the path to the directory that you installed the Windows Driver Kit (WDK) on.
    • ProcessorArchitecture is the processor architecture of the computer that you install and run WDTF on. The WDK installs processor-specific versions of the files in the WDTF\amd64, WDTF\i386, and WDTF\ia64 subdirectories under the WDKPath directory.

    For example, if you installed the WDK in C:\WDK and want to install WDTF on an Itanium-based computer, copy the files from C:\WDK\WDTF\ia64 to a directory on the computer.

    Note You can copy and install these files on other computers that do not have the WDK or WLK installed.

  2. Open a command prompt window on the computer and navigate to the directory where the WDTF files were copied. For example, if you copied the files to a folder named \WDTF, you navigate to the folder by entering the following from the command line:

    cd \WDTF

  3. Enter the following command from the command line:

    InstallWDTF.cmd [/NoSampleScripts] [/NoRegister] [/InstallPath:<InstallPath>]

    (i.e. bin\RegisterWDTF.exe /nogacinstall)

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. You can also find this documentation in the table of contents of the WDK help documentation under Windows Driver Kit > Other Tools > Windows Device Testing Framework.

You may receive an error message similar to the following: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid." This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

  • For redundant network paths, add an additional NIC connected to the network.

Some machines will go into standby mode at the end of the test on Windows XP. If this occurs, you must wake the machine manually to complete the test. This is acceptable for Logo submission. If automation is required, you can wake the system by calling PoSetSystemState(ES_USER_PRESENT) from kernel mode.


WHEAHCT Windows Hardware Error Architecture Hardware Compliance Test Tool

Overview

The WHEAHCT test tool determines whether a server platform delivers the minimum set of resources required to enable WHEA. It is a tool provided by the WHEA feature team to certify OEMs or ODMs platform support for WHEA, a Windows Reliability Availability and Serviceability feature.

Requirements

This test tool can run on X64- and Itanium-based platforms running firmware compliant with the Windows Hardware Error Architecture Platform Design Guide. The system must be running a version of Windows 2008 R2 server. On IA64, a PSHED plug-in test driver (plugin.sys), which is supplied with the test tool, must be installed on the system. The driver is needed to inject machine check errors into the system.

Details

The WHEAHCT test tool primarily examines the error records delivered according to the Windows Hardware Error Architecture Platform Design Guide and WHQL requirements. Both fatal and corrected errors are injected, and the resulting records are validated during the test.

Windows reports the errors through the ETW, and the standard system event log holds the decoded, readable log entries.

Run Time: 20 minutes
Log File: wheahct.xml
System Restart Required: Yes
Supported operating systems for Logo or Signature testing:

  • Windows Server 2008 R2

Note The test injects a fatal error from the platform to the OS. The OS reacts to this fatal hardware error as if it is a real error. Because fatal hardware errors result in blue screen errors with Stop code 0x00000124, the fatal error part of the test will produce a system crash and result in a blue screen and reboot. If configured correctly, see the note below.

Note Automatic reboot after a system crash is a configurable behavior of the operating system. For correct execution of the test, the OS must be configured to perform either a kernel dump or a minidump and reboot automatically. You can confirm these settings using the Control Panel System and Security System Advanced system settings Startup and recovery.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (Server)

  • Any software components included with the device that is being tested (for example, PSHED plug-ins)

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at 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

  • Itanium

Test Tool Usage

Test Setup (Installation)

X64 platform

  • Copy wheahct.exe and wttlog.dll into a directory.

IA64 platform

  • Copy wheahct.exe, wttlog.dll, installPlugin.bat, and plugin.sys into a directory.

  • Run the driver install by typinginstallPlugin.bat at the command prompt from the directory where plugin.sys is located.

Running the Test

  1. Install the test.

  2. Run the corrected error injection test by typing wheahct.exe /corrected<enter> at the command prompt.

  3. Run the HCT test by typing wheahct.exe /hct<enter> at the command prompt.

  4. "0x124" is the expected error code. If you ss it on the screen or in kd, reset the machine.

  5. After the system restarts, run wheahct.exe /hct <enter> again

  6. After the test is finished, examine Wheahct.xml for results.

Command Option Description

The test tool wheahct.exe runs from a command line window. It accepts the following command line options.

/?

This option prints the tool help page, which contains information about all of the different options and their usages.

/hct

Use this command line option to perform a full WHEA hardware compatibility test. The test includes error injection and restart. The test injects fatal errors, which cause the machine to crash with bugcheck 0x0000124. After the machine automatically reboots, run wheahct /hct <enter> again to generate the test results. The test results are available in the file wheahct.xml

/fatal

Use this command line option to perform the fatal error injection part of the test. A fatal error causes the system to crash with bugcheck 0x0000124. The system crash in response to fatal error is expected, and if the machine is not configured correctly to automatic reboot on crash, you must restart the machine manually.

/validate

Use this command line option to perform validation of the fatal error injection. When invoked with this option, the tool queries the system event log for the fatal error record.

/recoverable

Use this command line option to perform the recoverable error test. In this test, the tool injects the recoverable memory scrubber error or LLC EWB. Note that the /recoverable switch is for either Patrol Scrub error or LLC Explicit Write Back test.

/err2

Use this command line option to run the LLC Explicit Write Back test. This test is specific to the Nehalem platform. See "Additional information on Loadgen" below to cause cache flushes while testing for WHEA functionality.

/corrected

Use this command line option to run the corrected error test. In this test, the tool injects a corrected error. Because this error will be corrected, the error record is received in real time and the test tool will check the compliance of the error record with WHEA platform design guide.

/vf_errsrc

Use this command line option to run the WHEA ACPI tables validation test

/cap

Use this command line option to query the WHEA WMI error injection capabilities.

All of the results are displayed on the Command Prompt window and logged to the Wheahct.xml file.

Note You need to have administrator rights to run the WheaHCT.exe tool.

Additional information on Loadgen

You can download the loadgen tool without network client functionality from the following Microsoft Web site:
http://www.microsoft.com/windowsserver2008/en/us/WS08-R2-CF.aspx

The instructions below are for configuring LoadGen tool installed by the Software Certification Toolkit v2.3 x64 for the Windows Server 2008 R2 Software Logo program.

Note This version of LoadGen will not function on Windows Server 2008.

The primary purpose of LoadGen is to ensure a desired level of stress for the required time period. This stress causes cache flushes, which allow verification of WHEA cache evict functionality.

LoadGen monitors the system and maintains the desired resource level whenever not being met by other processes, such as test harness, automation, or app testing.

Installing LoadGen

  • Always use platform-specific LoadGen.

  • If the machine name is not 14 characters or less, LoadGen will not initialize.

  • Make sure that LoadGen is installed in directories whose path name does not contain embedded spaces

    Examples:

    C:\LoadGen will work.

    C:\Logo Tools\LoadGen will fail.

    C:\Software_Certification_Toolkit\LoadGenR2 is the default installation.

Configuring LoadGen

  • Never run LoadGen on production environment.

  • Use platform-specific LoadGen installed on the local computer.

  • Make sure that the machine is configured with the local administrator account, "Administrator", with a valid password on all machines that will participate in stress.

  • Configure components, accounts, and any domain policies that will run on all machines that will participate in stress.

Starting LoadGen

From a command prompt on each machine where the LoadGen binaries are installed, navigate to the platform directory where LoadGen.exe is stored, and enter the following into an elevated command prompt:

LoadGen.exe -config:LogoStress.xml -NonHCT:0 -NoWTTLog -user:Administrator -pwd:<Password>

Notes

  • Make sure that you use the exact command line provided, or your results and logging will not be valid. Logo Program will only accept properly formatted logs.

  • In the example above, logostress.xml is a configuration file that is provided with the LoadGen binaries.

  • pwd parameters must be replaced with the Administrator password without the <>.

  • The LogoStressLog.log file is generated in the LoadGen directory and must be included with all required logs outlined in the test case.

  • When LoadGen is running; you should see the UI with a countdown of time remaining and plenty of information displayed.

  • After installation, more complete instructions are available in the readme file included with the install.

Test Assertions

Windows Logo Program: SYSFUND-0012 Architectural corrected and uncorrected hardware errors sources on the server are discoverable by the operating system

Additional Information: The server must implement at least one corrected and one uncorrected hardware error sources that are discoverable by the operating system during startup initialization. The minimal set of error sources, if available on the platform, and the mechanisms used for error source discovery are described in the WHEA Platform Design Guide.

Windows Logo Program: SYSFUND-0013 The server persists WHEA hardware error records across server reboot and server power cycle

Additional Information: The server must provide an interface to a persistent store for error records. This persistent store must preserve the error records across server reboots and server power cycle. At a minimum, the platform must provide enough storage space for one uncorrectable error record. Options to implement this interface are described in the WHEA Platform Design Guide.

Windows Logo Program: SYSFUND-0014 Server enables reporting of system hardware errors to the operating system

Additional Information: The server provides mechanisms to report both corrected and uncorrected system hardware errors.

Windows Logo Program: SYSFUND-0015 Server synchronizes firmware-based error handling with WHEA

Additional Information: Windows Server 2008 provides an OSC mechanism to indicate the presence of WHEA in the operating system. The server must honor these mechanisms and enable WHEA flows when the OSC is detected. Optional mechanisms are provided to enable the firmware to process error events from error sources before handing control off to WHEA, and to communicate this firmware-first handling to the operating system. These mechanisms for coordinating the error handling between firmware and the OS are described in the WHEA Platform Design Guide.

Windows Logo Program: SYSFUND-0016 Server supports error-injection mechanisms for WHEA testing

Additional Information: Servers must support WHEA-defined interfaces for software injection of a subset of the supported hardware errors into the platform to enable WHEA validation. Options to provide this interface are described in the WHEA Platform Design Guide.

Interpretation of the Results

The test tool will display the results on the console and in the xml log (wheahct.xml) as PASS--FAIL information.

Troubleshooting

Hard Hang

If the server freezes and is not responding, there is a bug in the error injection instructions as part of the error injection action table. Another possible cause is that the system may be stuck in SMM as part of the persistence actions (if SMM is used for that).

You can use a hardware debugger to help identify the source for this type of error.

Bug check 0x0000124 with no reboot

The fatal error injection is part of the HCT, and a bugcheck 0x0000124 is expected. Review Note 2 above for instructions on how to configure your machine for automatic reboot.

Bug check 0x0000124

This is expected when a fatal error is injected in the system. If the error is not associated with fatal error injection, it indicates a hardware error. Consult Microsoft online documentation for more information.

Bug Check 0x0000122

This bug check indicates that an internal error in the Windows Hardware Error Architecture (WHEA) has occurred. Each stop error has four parameters. The error type is determined by parameter 1, as described in the following table.

Parameter 1 | Parameter 2 | Parameter 3 | Parameter 4 | Description
0x00000001 | Size of memory | Error source count | 0 | Failed to allocate enough memory for all the error sources the HEST
0x00000002 | Number of processors | 0 | 0 | Failed to allocate enough memory for WHEA information block for each processor
0x00000005 | Status | Phase (The initialization phase for the bug check) | 0 | WHEA failed to allocate enough memory for the error sources, or the error source enumeration failed
0x00000006 | Status | Phase | Error source type | Failed to initialize the error source (of type parameter 4) during phase (parameter 3) and the returned error code was (status)
0x00000007 | Status | 0 | 0 | Failed to allocate enough memory
0x00000008 | Number of error sources | 0 | 0 | Failed to allocate enough memory for all the error source descriptors
0x00000009 | Source type | Source ID | 0 | WHEA received an uncorrected error source from an invalid error source
0x0000000A | Source Type | Source ID | 0 | Failed to allocate an error record for an uncorrected error
0x0000000B | Source Type | Source ID | 0 | Failed to populate the error record for an uncorrected error

These errors can result from a bug in the implementation of a vendor supplied PSHED plug-in, the firmware implementation of error records, or the firmware implementation of error injection.

The following table contains a list of possible error types:

0x00 | Machine Check Exception
0x01 | Corrected Machine Check
0x02 | Corrected Platform Error
0x03 | Non-Maskable Interrupt
0x04 | PCI Express Error
0x05 | Other types of error sources/Generic
0x06 | IA64 INIT Error Source
0x07 | BOOT Error Source
0x08 | SCI-based generic error source
0x09 | Itanium Machine Check Abort
0x0a | Itanium Machine check
0x0b | Itanium Corrected Platform Error


WSIT - Responsive and Ready (Manual)

Type: Manual

Overview

Manual scenarios that focuses on the responsiveness and readiness of the integrated system.

Note This test applies to client only.

Details

Responsive and Ready

OS \ Hardware Requirements:

  • Mobile System with Battery

  • Mobile System with closeable lid

Metrics of Interest to Increase Customer Satisfaction:

  • Cold start boot time
    • User presses the power on button. Auto-logon. Desktop is completely painted and Start Menu is responsive.
  • Wireless connection established time
    • User presses the power on button. Auto-logon. Desktop is completely painted and Start Menu is responsive.
  • Application usable after cold start time
    • User presses the power on button. Auto-logon. Desktop is completely painted and Start Menu is responsive. Launch Web Browser and browser screen appears.
  • Home page loads time
    • Starting with cold start and auto-logon. Desktop is completely painted and Start Menu / Apple Menu are responsive. Launch Web Browser. Home page from local network appears.
  • System sleep time
    • System connected to wireless network. Adobe Reader, Web Browser and WMP is running. Using sleep command to trigger sleep. Timing as perceived by the user.
  • Resuming from sleep time
    • Bring the system out of sleep and system's screen lights up.
    • Bring the system out of sleep and system's screen lights up. Switch to the web browser and load the home page. Home page appears.
  • System shutdown time
    • Close all applications on the system before starting the test. Initiate shutdown and wait till the machine completely shuts down (as perceived by the user).

Scenario Steps

Docking Station S3 Sleep Walk Away Resume:

  1. Dock a laptop to the docking station

  2. Connect a video display to the docking station and configure the laptop to output to the video display

  3. Put the System into S3 sleep

  4. Undock the laptop from the docking station

  5. Wake the laptop from S3

  6. Confirm that video is functioning correctly and present

Run Time:
Log File:
System Restart Required: No
Test Category: System Kit

Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: SMTask.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running WSIT - Responsive and Ready (Manual)

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

The test might return SKIP if...

Code Tour

File Manifest

File Location

SMTask.exe | [Testbinroot]\NTTEST\DRIVERSTEST\WDKTools
DockingS3.txt | [Testbinroot]\NTTEST\DRIVERSTEST\Manual


WSIT - Secure by Default - FireWallCheck

Type: Automated

Overview

System Integration test to verify that firewall is enabled by default.

Note This test applies to client only.

Details

WSIT - Secure by Default - FireWallCheck

Automated test to verify the settings of the firewall. It will pass if firewall is turned on in the default settings.

Run Time: 1 min
Log File: firewallcheck.wtl
System Restart Required: No
Test Category: system kit
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program: firewallcheck.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running WSIT - Secure by Default - FireWallCheck

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Code Tour

File Manifest

File | Location
Firewallcheck.exe | [testbinroot]\nttest\driverstest\wdktools\firewallcheck


WSIT - Secure By Default (Manual)

Type: Manual

Overview

System Integration test that focus on the default security settings.

Note This test applies to client only.

Details

Secure By Default

OS \ Hardware Requirements:

  • None

Default configuration must have an Enabled Firewall

Scenario Steps

To verify Windows Firewall Settings:

  1. {Win} -> {r}

  2. {"firewall.cpl"}, {Enter}

  3. [Change Settings]

  4. Confirm that the Windows Firewall is enabled

Note Advanced Firewall settings can be reviewed by:

  1. {Win} -> {r}, {"cmd /k cd \"}, [Enter]

  2. In the command window, {"netsh firewall show config"}

If a 3rd party firewall is installed confirm that it is activated by default and detected by Windows, Data Execution Prevention must be enabled for all programs and services . To verify Data Execution Prevention settings, follow these steps:

  1. {Win} -> {r},

  2. {"control"}, {Enter}

  3. [System and Maintenance] -> [System]-> [Advanced system settings] -> [Advanced] -> Select the [Settings .. ] button in the Performance Pane -> [Date Execution Prevention]

  4. Confirm that radio button is selected indicating that DEP is turned on "for all programs and services except those I select:"

  5. Confirm that no programs are listed as exempt from DEP protection

  6. Press [OK] to apply any changed settings

  7. Press Cancel on the test window.

  8. Reboot the system to apply any DEP setting changes made

  9. Re-run the test. If the system successfully booted, then click Pass in the test window.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running WSIT - Secure By Default (Manual)

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Code Tour

File Manifest

File Location

SMTask.exe | [Testbinroot]\NTTEST\DRIVERSTEST\WDKTools\
DEPCheck.txt | [Testbinroot]\NTTEST\DRIVERSTEST\Manual
FireWallCheck.txt | [Testbinroot]\NTTEST\DRIVERSTEST\Manual


WSIT - WLAN Device Compliance (Manual)

Type:

Overview

System Integration test that focuses on the WLAN Device Compliance.

Note This test applies to client only.

Details

WLAN Device Compliance with WPA and WPA2

OS \ Hardware Requirements:

  • 802.11x WLAN Adapter

  • WLAN Access Point that supports a superset of protocols and security encryption technologies provided by the WLAN Adapter on the System in test

Scenario Steps

Sustained Wireless File I\O Protocol Verification:

  1. Connect a wired (non-WLAN) system to a Wireless Gateway\Switch

  2. Stage the wired system with a 1g + file

  3. Stage the wireless system with a 1g + file

  4. For each wireless protocol supported by the network adapter i.e. 802.11 a,b,g,n,y and Security standard (WPA WPA2 are the minimum required for Logo)
    a. Connect to the wireless access point
    b. Put the WLAN system into S3\Stand by
    c. Wake the WLAN system from S3\Stand by
    d. Confirm that the network connection on the WLAN system has resumed
    e. In parallel, transfer the 1g file from the wired system to the WLAN system & transfer the 1g file from the WLAN system to the wired system
    f. Verify that both files transferred successfully without interruption

Run Time: Log File: System Restart Required: NoTest Category: system kit

Supported operating systems for Logo or Signature testing:

  • Windows 7

Program:smtask.exe

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running WSIT - WLAN Device Compliance (Manual)

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.

Code Tour

File Manifest

File | Location
SMTask.exe | [Testbinroot]\NTTEST\DRIVERSTEST\WDKTools\
WirelessIOProtocol.txt | [Testbinroot]\NTTEST\DRIVERSTEST\Manual
AudioCaptureMonitor.txt | [Testbinroot]\NTTEST\DRIVERSTEST\Manual
DUIDIntegrationDC.txt | [Testbinroot]\NTTEST\DRIVERSTEST\Manual
ExternalDeviceDC.txt | [Testbinroot]\NTTEST\DRIVERSTEST\Manual
ProjectionSimple.txt | [Testbinroot]\NTTEST\DRIVERSTEST\Manual
ProjectionAdvanced1.txt | [Testbinroot]\NTTEST\DRIVERSTEST\Manual
ProjectionAdvanced2.txt | [Testbinroot]\NTTEST\DRIVERSTEST\Manual
ProjectionDesktopExtension.txt | [Testbinroot]\NTTEST\DRIVERSTEST\Manual


XP, Vista, Windows Server 2003 Core Stress Test

Type: Automated Test

Overview

The Core Stress Test exercises memory and disk subsystems of the Microsoft Windows operating system.

Note This test applies to Windows Vista, Windows Server 2003, and Windows XP.

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 test uses the Driver Verifier option to simulate low system resources against specific drivers that you are testing. When the low-resources simulation option is selected, Driver Verifier will cause a random selection of the driver's memory allocations to fail. These failures test the driver's ability to react properly to low memory and other low-resource conditions. The stress tests use an extensible test harness that you can modify to include device-specific stress tests.

System Restart Required: No
Supported operating systems for Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).

  • Software components included with the device that is being tested.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Running XP, Vista, Windows Server 2003 Core Stress Test

Prerequisite Before you can run Core Stress Test and the Core Stress Test with low resources test, install the device and driver on the test client computer. Next, install and configure DTM. For more information about installing DTM, see the DTM Installation topic.

Update instructions to use the Submissions Wizard, and INF option.

To run this test, do the following:

  • Open 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 on.

  • In the Available Jobs pane, select the Core Stress Test and Core Stress Test with low resources jobs.

  • Click Add Selected in the lower-left corner of the Device Console window to add the jobs to the schedule of jobs to run.

  • Click Schedule Jobs.

  • Follow the progress of the Core Stress Test or Core Stress Test with low resources jobs 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.

The Core Stress Test and Core Stress Test with low resources tests use an extensible test harness that you can modify to include device-specific stress tests.

Adding Device Specific Stress Tests

The Core Stress Test and Core Stress Test with low resources tests 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 starts an additional test (or child process), you must also list the additional test (or tests) 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, and so on). The following code example shows the syntax for this section:

[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 executable files, you must list those tests (or children) in the [child_process] section of the configuration file. List all of 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 code example, Test1 returns the value 1 if the test is successfully completed, Test2 takes a command-line argument, and Test3 starts 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, do the following:

  1. Make a copy of the DRS_Ext.ini configuration file. This file is located on the DTM controller in the \\DTMServerName\Tests\cpu\nttest\BaseTest\whdq\DQS\RUNSTRSS directory. DTMServerName is the name of the computer that runs the DTM controller, and cpu is the target processor architecture.

  2. Open the copy of the configuration file and then remove the comment characters that cover any of the tests that are 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.

  3. 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 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

  4. Save the copy of the configuration file.

  5. In the Device Console window of DTM Studio, select and then add the DRS - Stress Test and DRS - Stress Test with low resources stress jobs.

  6. In the Add Selected pane, right-click DRS - Stress Test or DRS - Stress Test with low resources, and click Edit Parameters.

  7. For the ExIniFile parameter, specify the name of the configuration file that you just edited.

  8. Repeat steps 6-7 for the other stress jobs. When you run the tests, the additional device-specific tests are added to the stress run.

  9. Click Save to create a Device Job Schedule file that you can load in the future to avoid having to edit the parameters again.


Terminal Server PNP Redirection Testing

Terminal Server PNP Redirection Testing Overview
Preparing for Terminal Server PNP Redirection Testing
Running Terminal Server PNP Redirection Tests
Troubleshooting Terminal Server PNP Redirection Testing

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Terminal Server PNP Redirection Testing Overview

These procedures test your Windows Portable Device (WPD) over Terminal Server for correct functionality by using the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that 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.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

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 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 Plug and Play (PnP) redirection testing:

  • Two computers that are running 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 must be running Windows Vista, Enterprise Edition or Windows Vista, Ultimate Edition.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Other Device Requirements

The following software is required to run the Terminal Server PNP redirection tests:

Note These tests apply only to Cellular Handsets devices that install third-party (that is, vendor-supplied) WPD drivers. If you are not providing a WPD driver for your Cellular Handset device, you are not required to run these tests for your device, even though the jobs might appear in the Device Console.

  • For cellular handsets, you must have the driver for the Windows Portable Devices (WPD) cellular phone. 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.

  • You need to update your driver .inf file to be able to support TS PNP Device Redirection. Read the "Device Driver INF Changes for Plug and Play Device Redirection on Terminal Server" section located in the link: Device Driver INF Changes for Plug and Play Device Redirection on Terminal Server

Tester Knowledge Requirements

To run the Terminal Server PNP redirection tests, testers must know how to:

  • Plug a device into a USB port of the computer and maintain the connectivity throughout the test run.

  • Provide continuous power to the device throughout the test run.

  • Troubleshoot device installation to make sure that the device is installed successfully by using Device Manager or by looking at the SetupAPI device installation logs.

This section contains the following topics:

Preparing for Terminal Server PNP Redirection Testing

Running the Terminal Server PNP Redirection Tests

Troubleshooting Terminal Server PNP Redirection Testing

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


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 (WDK) 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 automatic logon, see 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. The test creates a tspnpadmusr user who is a member of local admin group on both TS client machine and TS server machine. The test creates a TS session on the TS server with this account and password

  2. Both the TS client and TS server computers should be in the same DTM machine pool.

  3. Make sure that you have updated your inf file to make it TS-redirectable and your TS-redirectable driver is installed on the TS server machine.

  4. Important: Edit the job named TS_PNPRedirection - WDK in Job Explorer, go to LMS section and edit the LMS_Client LMS. In the LMS Constraints tab add "Dimension" field to WTT\FullMachineName, set the "Operator" field to Equals and set the "Value" to be the actual Machine Name of the Client Machine. This step is required so that this job knows which machine to select as the Client Machine.

  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 logo test dimension, and then click Add.
    5. Make sure 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

Running the TS PNP Redirection logo tests for Cellular Phone Device

Logo Program: Windows Vista Client Logo (x86, x64) only

  1. Please refer to "Portable Media Devices Testing" section for details on how to run local non-TS Cellular Phone Logo Tests. Since TS logo jobs will run with the same submission as the non-TS logo jobs, it's imperative that the local non-TS Cellular Phone Logo tests are run first.

    Recommended Setup:
    • TS Server: The same DTM client machine that was used to run the non-TS Cellular Phone Logo Tests should be set up as the TS Server machine. Install the TS-redirectable driver on this machine. Read the "Device Driver INF Changes for Plug and Play Device Redirection on Terminal Server" section located in the link: Device Driver INF Changes for Plug and Play Device Redirection on Terminal Server on how to make the driver TS-redirectable.
    • TS Client: An additional DTM client machine with the same processor architecture (x86 or x64) as the TS Server machine. Connect your device to this machine, and install the (non TS-redirected) driver on this machine.
    • Only 1 device is needed, and it should be connected to the TS Client machine.
      • SettingWhen creating the Logo submission, you will need a device connected to each of the machines, so that the appropriate submission configuration jobs will be scheduled on both machines. This is a crucial step to ensure that the DTM smart scheduler can run the Logo jobs scheduled for the submission ID of each machine.
      • Once you created your submission, and completed the WDK submission hardware and ID configuration jobs, you may now disconnect the device from the TS Server machine, and keep your target device connected to the TS Client machine so that it can be redirected.
  2. Setting up machines for Terminal Server Redirection:
    • The first test to be run on the TS Client machine is the TS_PnpRedirectionPNPREDIRECTION-WDK DTM job that resides in WDK->TerminalServer->Client DTM category. Note: This test is the preparatory ground for launching next set of TS Redirection Logo tests. You can find this in Explorers -> Job Explorer, under the category TerminalServer ->Client.
    • Edit the LMS_Client LMS with correct Client Machine name for WTT\FullMachineName constraint as described in test system configuration section above.
    • After TS_PnpRedirection WDK test is run on TS client machine, schedule the TS_PNPRedirection -WDK job on your machine pool, selecting both machines when you schedule. This will run on TS client machine specified by your LMS_Client setting. It creates a TS session on the TS Server machine. Make sure that you don't close this TS session or terminate the TS client executable i.e. mstsc.exe after this test is done. This session is required to run the next set of tests.
    • 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. Specifically, from Device Console, locate this device in the "Windows Portable Devices" node for the TS server machine on the left hand pane.

  3. When you complete setting up the machines for Terminal Server Redirection testing, you will be required to run the following test cases for the redirected driver on the TS Server machine:

    WPD Compliance Tests (TS Redirection)

    WPD Compliance Stress Tests (TS Redirection)

    1. Select the same submission that you have created previously, and refresh Device Console. You may need to wait a few minutes until the device appears correctly (no stale entries).
    2. Right-click the device, and select "View Device XML," and verify the entries such as DeviceID, DriverDate, DriverVersion, and ImagePath for your driver and device. The DeviceID should begin with the prefix TS_.

  4. Select the TS redirected device and schedule the following "TS Redirection" jobs from the second "Cellular Handsets" category. The other jobs are not required for this test.

    Cellular Handsets

    :
    1. Select the same submission that you have created previously, and refresh Device Console. You may need to wait a few minutes until the device appears correctly (no stale entries).
    2. Right-click the device, and select "View Device XML," and verify the entries such as DeviceID, DriverDate, DriverVersion, and ImagePath for your driver and device. The DeviceID should begin with the prefix TS_.

Since these jobs are run within the same submission as the non TS logo jobs, the logs from these jobs will be bundled together in the same package.


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 - TS_PNPRedirection-WDK

After running the TS_PnpRedirection-WDK job on TS client machine, if the redirected Cellular phone device does not show up in the DTM Device Console UI on the TS server, make sure:

  1. Your device is directly connected to the TS Client machine and installed under "Portable Devices". If not, check that your driver INF file is correctly installed on the TS Client machine.

  2. From the TS Session running on the TS Client machine, you should be able to see the device enumerated in Device Manager under "Portable Devices", and driver details should show it as a TS redirected device. The device hardware ID should begin with the prefix "TS_".

  3. If the device fails to install under "Portable Devices" on the TS Server, check that your TS-redirection driver INF file is correctly installed on the TS Server machine.

  4. Verify that the TS-redirection driver INF file contains the correct TS redirection sections as specified: Device Driver INF Changes for Plug and Play Device Redirection on Terminal Server

  5. Looking at the SetupAPI device installation logs on the TS server will also suggest what went wrong.

  6. Go to the TS client machine and verify that the client machine has launched 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.

  7. Make sure WTT\FullMachineName constraint having Client Machine Name is added to LMS_Client.

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 constraint 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 how to 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.


Transfer Cable Testing

Transfer Cable Testing Overview

Preparing for Transfer Cable Testing

Running the Transfer Cable Tests

Troubleshooting Transfer Cable Testing

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Transfer Cable Testing Overview

The procedures presented in this section outline the process for testing your Transfer Cable for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) 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 Windows logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

Transfer Cable 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 device, see Running the Transfer Cable Tests.

Run time: Approximately 8 hours

Hardware requirements

The following hardware is required for Transfer Cable 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.

  • Three test systems that are connected over TCP/IP

  • Two transfer cable devices

  • One USB 2.0 high-speed hub with four ports to meet the requirements of USB device tests

Software requirements

The following software is required to run the Transfer Cable tests:

  • Current release of the Microsoft Windows Logo Kit (WLK)

Tester knowledge requirements

To run the Transfer Cable tests, testers must know how to accomplish the following tasks:

  • Install the Operating system from the product CD.

  • Launch Windows Easy Transfer and run successful migration with 10 gigabyte of data files.

  • Launch test from the Device Console in DTM studio.


Preparing for Transfer Cable 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 Transfer Cable Testing Overview.

Many of the tests in the Windows Logo 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 your test system for Transfer Cable testing, do the following:

  1. Install the appropriate Microsoft Windows Operating System (Windows Vista or Windows 7) on two machines.

  2. Perform a successful migration between two machines using Windows Easy Transfer.
    • Make sure the source machine contains a minimum of 10 gigabytes data files to transfer.
    • Use "An Easy Transfer Cable" as the transfer method.
  3. Install DTM client on one machine.
    • Modify your DTM client machine power settings to prevent it from going to sleep.
    • Attach two transfer cables to DTM client machine using USB 2.0 high-speed hub.
  4. Configure the machine for testing in DTM studio:
    • Create a machine pool
    • Add DTM client machine into this machine pool


Running the Transfer Cable Tests

To run the transfer cable tests, follow these step:

  1. Create a submission by going to Device Control and dropping down the long horizontal box to select Create new submission on your DTM studio.

  2. Run through the wizard by selecting the following:

    a. If your DTM client is Windows Vista , select Premium if the Transfer cable is at least 8 ft in length, or Basic if it is less than 8 ft in length.

    If your DTM client is Windows 7, select Basic.

    b. Select the machine pool that has the transfer cable configured.
    c. Select No INF.
    d. Expand hardware selection and select Transfer Cable.
    e. Select OK.

  3. Select all of the jobs that appear and add them. Then click Schedule Jobs.

  4. Several command windows appear on the client machine.

  5. If a manual prompt appears on the client machine, manually press Pass or Fail on each of them.

  6. When everything is done, from the device console window, right-click Transfer Cable device, and click Create Submission Package. This creates a CPK file that documents what happened during the testing.


Troubleshooting Transfer Cable Testing

  1. 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.

  2. Modify your DTM client machine power settings to prevent it from going to sleep.

  3. Attach two transfer cables to DTM client machine using USB 2.0 high-speed hub.


Windows Server 2008 R2 System Testing

Windows Server 2008 R2 System Testing Overview

Preparing for Windows Server 2008 R2 System Testing

Running the Windows Server 2008 R2 System Tests

Troubleshooting Windows Server 2008 R2 SystemTesting

Basic Domain Controller Setup for Server System Logo Testing

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Windows Server 2008 R2 Loadgen Stress Testing Overview

The procedures presented in this section outline the process for testing your Windows Server 2008 R2 System for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the system. 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 Windows logo testing.

  • Running: The running topics describe how to run to run the tests for your device or system.

Windows Server 2008 R2 System Tests

The list of tests you need to run depend upon the capabilities of the system being tested. To see the complete list of tests that could be required for your product, see the Windows Server 2008 R2 System Tests.

System Functionality Tests

The System Functionality Tests are individual tests of the capabilities of the system. Some tests are run for every system, and some tests only run if the capability exists in the system.

System Stress Test

System Stress Test consists of several server scenario workloads operating from the user level address space applied to the system to exercise the system hardware, system-specific devices and drivers, network and storage adapters and drivers, and any filter drivers that might be part of the system configuration, such as multipath storage drivers, storage or file system filter drivers, or intermediate layer network drivers.

The workloads applied are:

  • SQL I/O Simulation

  • Local Storage I/O

  • Client-Server Storage I/O

  • Winsock Network Traffic

These workloads will automatically scale to the number of network and storage adapters found in the system that have connected clients or storage devices, respectively. For example, if the test discovers one network adapter and one storage adapter (along with the necessary connected clients or storage devices, respectively), the test will create workload processes for that number of adapters in order to provide the stress workload. If the system has multiple network and storage adapters, test processes are created for each of those adapters, drivers, and connected resources (clients or storage devices) in order to provide the same relative stress workload. Additionally, the network and storage adapters and their respective resources need not be the same type. For example, GigaBit Ethernet and 10GigBit Ethernet adapters could be tested at the same time, as long as network clients were connected to both devices. Similarly, Fibre Channel and iSCSI storage adapters can be tested at the same time, as long as the appropriate storage media is attached. And any HBA units that are attached to the server under test (SUT) must be connected to the appropriate type of storage media.

Additionally, the system test is designed to achieve the same relative amount of stress on the system, regardless of the number or type of processors, amount of memory, or the number of network and storage adapters in the system. The test detects the number of processors/cores in the system, as well as the amount of memory in the system. The test then creates as many processor-specific and memory-specific stress processes as are needed to achieve a predetermined level of processor and memory utilization and will terminate those processes if the utilization level exceeds the predetermined level of stress. Thus, the level of utilization for those resources is always commensurate with the capabilities of the system. A system that only supports a few processors/cores and an appropriate amount of memory for the system will have the same relative levels of stress as a larger system with more processors/cores and a greater amount of memory.

Shutdown/Restart Test

The Server test also includes a shutdown and restart test. This test signals the system to shut down and restart. The test records the event log information related to shutting down and restarting the system, such as vetoes that prevent shutdown, the 'startup event,' and any driver errors received after restarting the system. This test is designed to ensure that all device drivers in the system comply with system shutdown, do not veto, and cleanly restart in the system without conflicting with other drivers. For more information, see I/O Completion Cancellation Guidelines.

There are 3 DTM jobs within System Stress Test kit:

  • Win 7 LoadGen Server Stress - Run First - Set Machine Policies (run time < 30 minutes)

  • Win 7LoadGen Server Stress - Start Test for Server (run time = 24 hours)

  • Win 7 LoadGen Server Stress - Run Last - Reset Machine Policies (run time < 20 minutes)

As the names indicate, you must schedule the "Run First - Set Machine Policies" job before the "Start Test for Server" job. And you must schedule the "Run Last - Reset Machine Policies" job afterwards, when the "Start Test for Server" job has finished.

You need to schedule the Run First and Run Last jobs only once for each submission, but you must schedule and run the "Start Test" job multiple times until it passes. You also need to schedule the "Run Last - Reset Machine Policies" job if you are going to schedule other different jobs on the same machine pool.

Details

LoadGen is a test tool that generates load on a given system under test. The system can be a standalone server (such as a datacenter server or fault-tolerant server) or any solution that consists of multiple computers (such as a multi-node cluster or a dynamic partitioned machine). LoadGen is started on the master client and can use multiple subordinate client computers to generate network load on the system under test.

You can start LoadGen with multiple command line parameters to enable you to control how it behaves. Configuration information is provided in the XML file that is passed through the -config command line parameter. The name of the system under test and subordinate clients (if any) are passed through -sut and -sc respectively. User credentials that start test process underare passed by -user and -pwd or -usellu (for LLU's in a DTM environment). Other command line options are available through LoadGen.exe /?.

After LoadGen starts, it reads the configuration input from the command line parameters and configuration file. This input includes the system requirements, tests to start on the systems, performance counters to monitor, parameter information, and so on. During setup, LoadGen does the following:

  • Copy files to all computers and start a service (named spsrv) that LoadGen uses throughout the test run to launch tests, monitor test processes, gather information, and so on.

  • Check that the systems meet the requirements that are specified in the configuration file.

  • Confirm that the users that is specified on the command line is a local administrator on each and every computer in the setup.

  • Create the parameter tree and parameter table. These items are internal data structures that are used to assign which specific system resources (CPU, memory, disk, network, and so on) that LoadGen targets during the test run and which test processes generate the load on each resource.

When the test starts, it runs through a set of phases. A phase consists of one or more tests that run for a given amount of time. Some test scenarios have only one test phase. At the beginning of each phase, LoadGen starts new tests. And at the end of each phase, LoadGen stops those tests that do not run during the next phase.

Tests that run in a given phase can be one of the following:

  • Tests that stress the resources on the system under test.

  • Processes that test system features.

LoadGen starts and monitors all test processes and reacts accordingly when an instance stops. If a test process is a critical one and it fails, the entire test run is ended by LoadGen. Otherwise, the test continues to run against the system under test.

When a test fails or when the last phase of the test run ends, Loadgen does the following:

  • Stops all test processes that are running on all systems.

  • Collects test logs to a local folder on the master client. This folder is later copied to the DTM log share.

  • Stops the services that it started on the systems.

  • Deletes the files that are distributed at the beginning of the test run.

To start the Server Stress test kit, you must have the following computers that have the operating system installed, that are domain-joined, and that are connected through Ethernet:

  • The system under test (SUT) is the server that you are trying to logo.

  • The master client (MC) is the system that starts, monitors, and finishes the test kit.

  • The subordinate clients (SCs) are the systems that generate the test load for network traffic.

The Server Stress test kit start the following tests on the testing systems:

  1. System functionality tests. These tests start at beginning of the test run and should not stop or fail before the test kit finishes. The test kit reports a failure if any of those tests failed.

  2. SQL Database IO simulation. If there are extra non-system disks that are connected to SUT, this test runs on all the non-system disks. Otherwise, if there is only one system disk on SUT, this test runs on the system disk.

  3. Local File System IO simulation. If there are extra non-system disks that are connected to SUT, this test runs on all of the non-system disks. Otherwise, if there is only one system disk on SUT, this test runs on the system disk.

  4. System resource stress tests: The test kit monitors stress level on SUT from MC and these tests are started or stopped according to the system stress level. Their failure is not considered a failure of the test kit.

  5. Client-Server IO. This test starts on the SCs and sends a large amount of data to the SUT. Then, the data is stored on the disks of the SUT.

  6. Network Stress. This test starts on the SCs and sends network traffic to the SUT.

  7. CPU resource consumption. This test runs on the SUT and consumes a certain percentage of the CPU resource.

  8. Memory resource consumption. This test runs on the SUT and consumes a certain percentage of system memory resource, including physical memory, page file, and non-paged pool.

  9. System reboot test: This test runs on the SUT and restarts the computer while the system is under stress. The system should be able to turn itself off and then turn on in certain period of time. This test and the whole test kit fail if the system cannot shutdown or restart.

The server stress test tries to generate network load for each NIC on the server under test. The desired throughput is 40% of the NIC's capacity. If, with the current client set, the network load cannot reach the targeted level, Loadgen requires additional client to be added in to testing environment. (To add an additional client, click the "client" pane of Loadgen UI, type the name of the client system to add into the box, and click Add. Server stress test has a time-out window of 60 minutes. After it made the request, if no additional client is added after 60 minutes, the test fails and exits.

Additional Qualifications Tests

Server systems might have additional functionality beyond that required for the Windows Server 2008 R2 Logo. The additional qualifications for which a system can test and qualify are:

  • Dynamic Partitioning

  • Fault Tolerance

  • High Availability

  • Enhanced Power Management

These additional qualification tests can be found in the DTM test harness with the tests that are listed for systems. Vendors whose systems can meet the requirements for these additional qualifications must select and run the tests required for each. These tests will not be scheduled or run automatically. The Dynamic Partitioning tests exercise and confirm the hot add, hot replace, and rebalance functionality of the system, devices, and drivers. The Fault Tolerant tests exercise and confirm the ability of a fault tolerant system hardware, devices, and drivers to have a hardware failure and continue to operate without impacting other clients on the network. The Enhanced Power Management tests validate that the systems supports the CPUID feature flag, processor p-states, WMI objects, WS-MAN and SMASH needed for the Windows server operating system to manage the power of the system.

Note that a system can support none, some or all of the above features and Additional Qualifcations, such as both dynamic partitioning and fault tolerance. In order for the vendor to validate that the system meets the requirements for one or more of the Additional Qualifications, one or more of the Additional Qualification tests must be selected and run. Those results are then submitted along with the results of the Server Logo tests. The Additional Qualification test results cannot be submitted separate from Server Logo test results.

For more information about Additional Qualifications, see Additional Qualifications Information.

For more information about dynamic partitioning testing, see Dynamic Partitioning (DP) Simulator and Test.

Run time: Run time will vary depending on whether the system supports dynamic partitioning or fault tolerance. If only the Server Logo test is selected, testing will take approximately two days, with the Loadgen test taking one day to run while the remaining tests run during the second day.

Additionally, if the system being tested includes audio, video or other devices and drivers, those will be exercised as well, and that will increase test time.

Hardware requirements

The following hardware is required for Windows Server 2008 R2 System 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.

The following hardware is required for running the Windows Server 2008 R2 operating system.

Component Requirement

Processor

Minimum: 1.4 GHz (x64 processor)
Recommended: 2 GHz or faster
Note An Intel Itanium 2 processor is required for Windows Server 2008 R2 for Itanium-Based Systems

Note - Server System Logo testing requires that the Server Under Test be populated w/ the maximum number of processors the system supports.

Memory

Minimum: 512 MB RAM
Recommended: 2 GB RAM or greater
Optimal: 2 GB RAM (Full installation) or 1 GB RAM (Server Core installation) or more
Maximum (32-bit systems): 4 GB (Standard) or 64 GB (Enterprise and Datacenter)
Maximum (64-bit systems): 32 GB (Standard) or 2 TB (Enterprise, Datacenter, and Itanium-Based Systems)

Note - Server System Logo testing requires that the Server Under Test be populated w/ the maximum amount of memory the system supports.

Disk space

Minimum: 10 GB
Recommended: 40 GB or greater
Note Computers with more than 16 GB of RAM will require more disk space for paging, hibernation, and dump files

Drive

DVD-ROM drive

The following hardware is required for Windows Server 2008 R2 System testing.

Infrastructure Requirement and Setup for the Server Stress Test

The Server Stress test requires all test machines to be in a network with a domain controller. The machines themselves must be joined to that domain and have a domain user account created. The reliability of the network is critical to the stress test, if your network is not reliable or setup improperly, the test will either fail or won't start. Make sure the test environment is on a stable and reliable network. Use dynamic IP addressing for all machines. All systems used in testing, such as DHCP, DNS, or Active Directory Domain Controller, must be the latest version and service pack of the operating system.

Server System under Test (SUT) Requirements

  • Maximum number of processors that the SUT supports.

  • The maximum memory capacity that the SUT supports.

  • At least one Gigabit network adapter, or additional network adapters, being used for testing.

  • One hard disk drive to be used for installing the operating system. This hard disk drive should have two partitions. Partition 1 should have at least 1.5 GB, and less than 5 GB, of space that is configured as Active, System. Partition 2 should have at least 40 GB of space (or the Windows Server 2008 R2 minimum requirement) that is configured as Boot, Page File, Crash Dump.

  • One Gigabit Ethernet network hub.

Client System Requirements

The system failure of even a single client will cause the entire test to fail. To minimize the likelihood of client system failures, use the following criteria to help you choose computers and other hardware for this test:

  • Make sure that your computers have resources that exceed the minimum CPU and RAM requirements.

  • Make sure that all NICs and device drivers have already been Logo-qualified. The bandwidth of the NICs in the client computers must be equal to the bandwidth of the NIC in the SUT.

  • Plug all client computers into UPS power protection units

  • Connect all client computers with high quality cabling, routers, and switches.

  • Use highly redundant storage and memory components: For example, RAID 1 or RAID 5 memory, MPIO Duplexing for storage, RAID hard disks, Teaming for NICs etc

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software requirements

The following software is required to run the Windows Server 2008 R2 System tests:

  • One of the following operating systems for the SUT:
    • Windows Server 2008 R2 Datacenter Edition to enable all the processors and exercise all possible features in the system being tested. This applies for Logo testing or for any possible Additional Qualification tests such as those for the High Availability, Fault Tolerance, Enhanced Power Management, or Dynamic Partitioning tests.
    • Windows Server 2008 R2 for Itanium-based systems, in order to enable all the processors and exercise all possible features in the system being tested. This applies for Logo testing or for possible Additional Qualification tests such as those for the High Availability, Fault Tolerance, Enhanced Power Management, or Dynamic Partitioning tests.

  • Windows Server 2008 R2, Standard Edition, for x64 platform, for the master client and the client systems

  • Any drivers that are not shipped with the Microsoft Windows operating system

  • The current release of the Driver Test Manager (DTM)

  • The optional Windows Server 2008 R2 BitLocker Drive Encryption component must be installed on the server.

Note The System Tests topic provides more information about the system requirements for the BitLocker Drive Encryption test.

Tester knowledge requirements

To run the Windows Server 2008 R2 System tests, testers must know how to accomplish the following tasks:

  • Create, format, and remove partitions on a hard disk drive

  • Set power management options

  • Install and configure a network

  • Install the operating system from the product DVD

  • Download a service pack for an operating system

  • Install the Active Directory Domain Services Role

  • Create a domain

  • Install and operate the Driver Test Manager and Studio Services

  • Set up the systems to be used in testing at the BIOS/FW/EFI level


Preparing for Windows Server 2008 R2 Loadgen Stress 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 Windows Server 2008 R2 System Testing Overview.

Many of the tests in the Windows Logo 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

We are making the assumption that you have already setup the network domain controller and installed the DTM controller and DTM Studio on a machine (Please see the DTM setup documentation). Also the DTM controller and Studio are on the network.

The Server test requires the following system configuration tasks to prepare the test system for server testing.

The machines setup for the Server Stress test consisted of:

  1. One "Server Under Test" (SUT). This is the machine you are logo-ing

  2. One x64 (This kit does not support ia64 for clients) client machine that will act as the "Remote Test Host" (MC). Please note the restriction for the MC below:

    Note The master client must be included in the Windows Catalog.

    The master client must NOT be set up as follows:

    • As the domain controller for the test systems
    • As the WTT Studio host
    • As the DTM Controller for the systems that are used for testing

    Note You should not do this to the SC or SUT either. It can impact the test in a negative way.

  3. Eight x64 (This kit does not support ia64 for clients) client machines that will act as the "Subordinate Client" (SC)

  4. Do not use "MC" or "SC" or "SUT" or any derivatives in the machine names. As this can cause test to fail.

Important Because some systems might be set to shipping configuration, they might not have all their devices enabled or their drivers loaded. Before testing begins, ensure that all devices in the system are enabled and all drivers related to those devices are loaded per the testing requirements.

Storage and OS Installation

  1. These machines are connected to the network via gigabit HUB or switch with high speed CAT6 or faster cables.

  2. Install Datacenter or Enterprise Server SKU Operating System (OS) into the SUT

  3. Install any Server SKU OS on the MC and SC's

  4. All machines have NTFS format on all disks.

  5. Format the hard disk drive to have at least one partition with 20 GB of free disk space after the OS has been installed. This disk should be configured as Boot, Page File, Crash Dump.

  6. Install the optional Windows Server 2008 R2 BitLocker Drive Encryption component on the server.

Note The System Tests topic provides more information about the system requirements for the BitLocker Drive Encryption test.

Systems Settings for SUT, MC and SCs

  1. Join each machine to the same Domain using the domain user account you created and use dynamic IP addressing.

  2. Logon to each machine using the created domain user account.

  3. Use the following procedure to configure the power options on the SUT master client and the SC Clients:
    1. Click Start, click Control Panel, and then double-click Power Options.
    2. Click the Power Schemes tab.
    3. From the Turn off monitor list, select Never.
    4. From the Turn off hard disks list, select Never.
    5. If there is a System standby list, select Never.
    6. If there is a System hibernates list, select Never.
    7. If there is a Hibernation tab, clear the Enable hibernation check box.

  4. Each machine (MC, SC, SUT) will need at least one gigabit Network Interface Card (NIC) to connect to the network. If machine have more than one NIC, make sure those are also connected to the HUB.

  5. Note IPv4 and IPv6 must both be enabled on the system being tested, the master client, and all clients connected to the system.

Note A network interface adapter that is not connected to a network generates an error, causing the test to fail. Note that network adapters used for iSCSI connectivity to storage do not need to be connected to client systems.

DTM Studio Setup:

  1. Logon to each machine using the created domain user account

  2. Install the DTM client on each machine so they will become visible in DTM Studio under the "Default Pool" in the Job Monitor pane. Here's how:
    1. Click Start then Run on each machine, type the path to the client installation files located on the DTM controller. Example: \\YourDtmController\DTMInstall\Client\setup.exe
    2. Click Enter to run setup.exe and follow the prompts to install the DTM client.
    3. After the DTM Client installation completed successfully, the machine name should appear under the Default Pool branch in the Job Monitor pane in DTM Studio.
    4. Do this for each SC, MC, and SUT

  3. In the Job Monitor pane create a new machine pool and give it a name. Any name you like. The Machine Pool name should be no more than 12 characters without spaces.

  4. Move all the machines (SUT, MC, SC's) from the "Default Pool" to this new machine pool you just created. Drag-n-drop them into the new pool.

  5. Create a new submission through Device Console. In the DTM Studio menu, click Explorers, and then select Device Console.
    1. In the Submission drop-down, select <New Submission>.
    2. Choose the processor-specific version of the OS you are running on the SUT, and click Next.
    3. Select the Category System Submission, and click Next.
    4. Select the Sub-Category Server, and click Next.
    5. Give a name to the Submission, than select the Machine Pool that contains the configured MC, SCs, and the SUT you want to submit for a logo, and click Next.
    6. Select the SUT, and click Next.
    7. Select all relevant Submission Qualifications, and click Next.
    8. After you have reviewed the New Submission information and verified that it is correct, click Next. If not, you can hit Back now to return to any prior step in the process and correct any mistakes.
    9. Verify the Roles for the machines in that machine pool; make certain that the machines intended to be the MC, SC, and SUT all have the correct radio buttons selected, and click Next.
    10. Select the correct answer for High Availability questions, and click Finish.

  6. Return to the Job Monitor, either by clicking the Job Monitor tab at the bottom of DTM Studio menu, or click Explorers, then Job Monitor.

  7. Select the Machine Pool used to create this Submission, and click Refresh to verify that the Prepare for Submission jobs have completed.

The environment is now ready to run tests.

Note When you are not testing in Submission mode, you have to manually set the appropriate HCT\Role dimension for each client computer. Select the value of MC for the master client and the value of Node for the subordinate clients. For more information about how to set a dimension, see the Defining and Viewing Dimensions topic.


Running the Windows Server 2008 R2 System Tests

To run the Server Stress tests for logo submission follow the steps below.

  1. Return to the Device Console, either by clicking the Device Console tab at the bottom of DTM Studio, or clicking Explorers, then Device Console.

  2. If the submission you just created is not shown in the Submission pull-down, select your Submission now.

  3. Select the Win7 Loadgen Server Stress - Run First - Set Machine Policies checkbox. This job will set certain configuration on the computers in your machine pool.

  4. Right click the Win7 Loadgen Server Stress - Run First - Set Machine Policies job, and select Edit Parameters

  5. In the pop up box, type in the Domain Name, Domain User Name and Domain User Password used by the test environment for the parameters DomainName_LLU, UserName_LLU and Password_LLU respectively. Then close the pop up box.

  6. Click the Add Selected button, and then verify that the correct MC, SUT, and one of the SCs are in the validation list. Close the validation list, and click Schedule Jobs.

  7. Return to the Job Monitor to verify that the Win7 Loadgen Server Stress - Run First - Set Machine Policies job has completed successfully. This job needs to pass before the next job will run properly.

  8. Follow the job scheduling procedure to run the Win7 Loadgen Server Stress - Start Test for Server job. This is the Server Stress test. This test runs for approximately 24 hours.

  9. Depending on the "horse power" of your SC clients compare to your SUT, the test may ask for more clients. Make sure you check the MC screen from time to time in the first few hours for a pop-up asking for more clients. Once the first few hours have past, the stress load should stabilize. See troubleshooting section 'Loadgen is asking for more clients' for details.

  10. Return to the Job Monitor to verify that the Win7 Loadgen Server Stress - Start Test for Server job has completed successfully. You'll need to press the refresh button on the tool bar in order to see the updated info. If you need to rerun this job, there is no need to rerun the previous Win7 Loadgen Server Stress - Run First - Set Machine Policies Job.

  11. Follow the job scheduling procedure to run the Win7 Loadgen Server Stress - Run Last - Reset Machine Policies job when the Start Test job is finished. The Run Last job resets the machine policies that were set on the computers in your machine pool. Whether this Job passes or fails is not relevant to the submission; it is simply a clean-up Job.

  12. Return the test results

Notes

  • If you perform multiple logo test runs we highly recommend that you reboot all the machines between logo runs. This will ensure a clean run and eliminate any running process that may have not gotten cleanup properly from the previous run.

  • The Server Stress test will reboot the server under test during the test to verify that the system can recover from a crash or power failure. The reboot can result in an unexpected reboot event in the system log. This will cause a System Event Tracker (SET) pop-up message to appear when you log on locally. The SET popup appears because the system tests cause a STOP error.

The Windows Server 2008 R2 Logo test kit user interface can be monitored on the console session of the master client. Phase 1 of the LoadGen Server Stress test is the setup phase and only takes a few minutes to run. Phase 2 is the server stress portion of the test and runs for 20 hours. Phases 3 through 7 involve a series of reboot sessions on the SUT, and each phase is between 15 and 40 minutes long (depending on how fast the system reboots). During this time, the stress test validates the reboots and checks system logs to monitor progress. Each reboot instance lasts between five and ten minutes. Phase eight is the final one. In this phase the stress test is run again for one hour.

Important Returning the test results saves all of the test log files that are created during a test run to a single cabinet (.cpk) file. Do not return the test results until you successfully complete all of the required tests for a test submission. Even your failed runs will be saved in the cabinet file. You can delete the failed run logs if you wish to reduce the size of the cabinet file.

User Interface Notes

  • Getting to the LoadGen UI: Depending on how the user connects to the master client, the LoadGen user interface may not appear to the user when DTM Studio starts the test run. Users can find which session launches LoadGen by adding the Session ID column to the process list on the Task Manager Processes tab and then connecting to this session ID via the Task Manager Users tab.

  • Logo vs. non-Logo mode: LoadGen can start in logo mode or non logo mode. The LoadGen UI exposes different functionality as described below based on the mode it runs in. LoadGen runs in logo mode when launched from the Device Console within DTM Studio. LoadGen runs in non-logo mode when launched from the Job Monitor or Job Explorer within DTM Studio.

  • Logo vs. non-Logo mode: LoadGen can start in logo mode or non logo mode. The LoadGen UI exposes different functionality as described below based on the mode it runs in. LoadGen runs in logo mode when launched from the Device Console within DTM Studio. LoadGen runs in non-logo mode when launched from the Job Monitor or Job Explorer within DTM Studio.

After LoadGen launches its tests, the user can interact with LoadGen and control several aspects of the test run through its user interface. The upper part of test tool main user interface displays the test status and other important information. The lower half display configuration and monitoring information, and consists of three tabs. Click Exit to end the test run and the test run will be treated as a failure. Depending on the test run configuration and command line parameters, the user interface may display:

  • Test status frame: Located in the top half of the user interface, this frame displays a summary of information about the test run including the amount of time remaining, and a list of messages about test activity. If there is more than one phase for this run, the phase information will also be displayed along with the overall test summary.

  • Configuration and monitoring frame: Located in the bottom half of the user interface, this frame may contain up to 3 tabs which are relevant to the current test run. These tabs are described next.

  • Configuration and monitoring frame: Located in the bottom half of the user interface, this frame may contain up to 3 tabs which are relevant to the current test run. These tabs are described next.

The Tests tab lists the test processes that LoadGen launches. Details for each test process include: process name, test name, machine name, process ID, running time, status and a link to log, if applicable. The user can sort the list by any of the columns. Furthermore, in non logo mode, the user has more control of the tests running. The user can stop running tests or manually start more test instances through the user interface using the buttons on this tab by first selecting one test and then choose one of the buttons below:

Stop - This button can be clicked while test is running. Click this button to stop the test process.

Start - This button can be click while the test is stopped. Click this button to start the test process.

Stop all of this type - Click this button to stop all test processes of the same type.

Start another of this type - Click this button to start a different test process.

Show log - Display test log file (if one exists). The following screen shot shows the Windows Server 2008 R2 Logo Test Kit Tests tab.

Screen shot of the Windows Server 2008 R2 Logo Test Kit Tests tab showing the test status, configuration, and monitoring

The Clients tab lists the clients registered that LoadGen that are used to stress the network resources of the system under test. The status of each client is displayed along with how stressed that client is. At a certain stage, when the client machine is stressed enough, this machine won't be available for LoadGen to start more test processes on. When LoadGen needs to start a new test process on a client and no clients are available, LoadGen will ask the user for more clients. It is not necessary to install DTM Client on these new client computers. However, User Account Control and any firewalls must be disabled on these new clients and they must be joined to a domain. At any time during the test run the user can add or remove clients from the test run using the following buttons on this tab:

To add another client, type client name into text box then click the Add button.

To remove a client, select a client in the client view table and click the Remove button. The following screen shot shows the Windows Server 2008 R2 Logo Test Kit Clients tab.

Note Users can add and remove clients during both logo and manual testing.

Screen shot of the Windows Server 2008 R2 Logo Test Kit Clients tab with a text box for adding clients

The PerformanceCounters tab lists the performance counters monitored and controlled by LoadGen during this test run. Users can select different counter objects sort them in the upper table of the tab. The lower right table displays the information of the selected counter. When the user selects a counter, LoadGen will display a graph showing the recent activity for that counter. The graph also shows the range LoadGen is attempting to keep the counter within. In non-logo mode, the user can change that range by changing the lower or upper bound for individual counters in the Counters tab. After changing the bounds, LoadGen may start/stop test instances affecting this counter to drive it into the desired range. The following screen shot shows The Windows Server 2008 R2 Logo Test Kit Performance Counters tab.

Screen shot of The Windows Server 2008 R2 Logo Test Kit Performance Counters tab displaying various performance values


Running Loadgen in Non-Logo Testing Mode

You can run Loadgen in non-Logo testing mode by scheduling the relevant job in the Job Explorer window instead of in the Device Console. This is useful in the case where you want to run the stress test for non-logo testing.

To run Loadgen in non-logo testing mode

  1. Open DTM Studio and switch to the Job Explorer window.

  2. Browse to \WDK Tests\Server\Win7 Server Systems Kit\Win7 Loadgen Server Stress.

  3. Right-click the Win7 LoadGen Server Stress - Run First - Set Machine Policies job, and then click Schedule.

  4. In the Jobs tab, type in the Domain Name, Domain User Name and Domain User Password used by the test environment for the parameters DomainName_LLU, UserName_LLU and Password_LLU respectively.

  5. Click the Machines tab.

  6. From the Select Machine Pool drop-down list box, click the target machine pool for running the test.

  7. Click Schedule Jobs on any Machines from this Machine Pool.

  8. Click the Job Monitor tab at the bottom left of the DTM Studio window and view the job status.

  9. When the job has completed successfully, click the Job Explorer tab at the bottom left of the DTM Studio window, and then browse to \WDK Tests\Server\Win7 Server Systems Kit\Win7 Loadgen Server Stress.

  10. Right-click the Win7 LoadGen Server Stress - Start Test for Server job, and then click Schedule. Repeat steps 5-8

Once you are done. Make sure you run the last job to clean up the machine policies by scheduling Win7 LoadGen Server Stress - Run Last - Reset Machine Policies job. This is just a cleanup job, whether it passed or failed is not relevant to the test. But you should run it to reset the machines.

Note You can make changes to the test parameters by using the Loadgen user interface on the master client. You can perform following tasks:

  • Start or stop tests in the Test pane

  • Add or remove clients in the Client pane

  • Adjust stress level for each performance counter in the Performance Counters pane

Note You can only adjust stress levels when you run Loadgen in non-logo mode. Additionally, the server stress test must be in Phase 2, with the phase status showing "Running Test." However, if the controls and options in the user interface are grayed out, the test is not in a state where you are allowed to make adjustment to the parameters. This grayed-out state exists before Phase 2 (the stress phase) starts, and again after Phase 2 is completed. The buttons remain grayed out until you select a test in the UI.


Troubleshooting Windows Server 2008 R2 System Testing

The Windows Server 2008 R2 System Logo test includes a significant amount of logging, which makes it easier to troubleshoot failures and problems.

The Test Failed, Why?

If the failure occurs within minutes of launch, it usually means something was not configured properly. Go back and verify the settings.

If the test actually ran, there should be a log file called Srvlog.xml in the DTM controller.

  1. Open Job Monitor

  2. Browse to the machine pool where the teat was scheduled

  3. In the Job Execution Status pane, select Win7 Loadgen Server Stress - Start Test for Server

  4. In the Task Execution Status pane, right click RunJob -Launch Win7 Server Logo Kit and select Child Job Result

  5. Go back to Job Execution Status pane, select Launch Win7 Server Logo Kit

  6. In the Task Execution Status pane, right click Start LogGen task and select View Task Log

  7. The log is parsed from the original Loadgen log and only has errors and passes

  8. To get to the original Loadgen text log, repeat steps 1-5, then click Job Logs on top toolbar or right click Launch Server Logo Kit and select Browse Job Logs

  9. This will open the log share on DTM controller and loadgen log file srv.log will be in the share. If srv.log file does not exist, it means the test never ran. Although the Job was scheduled the stress test did not run.

  10. Drag and drop the srv.log file into notepad.

  11. Scroll to the bottom of the file in Notepad

  12. Search from the bottom up for the string "Error -"

  13. The text in the same line will tell you what failed. If it does not...

  14. Search up again with the same string. You might need to do this a few times but generally the first or second search would tell you.

The information in log file only provided a high level indicator of what failed. It does not provide specifics.

If you're still stuck, create a CPK file and send it to product support when you open a case here:

Help and Support

Loadgen is asking for more clients

The loadgen harness has a feature that will ask for more SC clients if the existing clients cannot generate enough stress against the SUT. This is to accommodate large servers and the possibility of some SC clients going bad in the middle of a run. In general we recommend you start with eight SC clients. This is sufficient for 95% of the cases. The stress level should stabilize in the first three to four hours of the test. In other words, if more clients are needed, you'll see the pop-up in the MC within that time frame. You will have sixty minutes to add a new client or the test will abort and fail.

Note There is a limitation in the Device Console where you cannot add more machines to the machine pool once a submission has started. So if you are starting with less than eight clients, make sure that you have additional clients in the machine pool before starting the submission run.

In the event loadgen is asking for more clients pass the four hour mark, it means something that has gone wrong. Either one or more of the existing clients dropped out for whatever reason, or some network connectivity issues has occurred. Please check to make sure that the primary domain controller is Windows Server 2008 SP2.

We have seen cases where one of two NIC's on a SUT cannot reach the desire stress level no matter how many clients were added. This was an issue with the NIC driver in combination with the network speed. Loadgen does not know that it can never reach the desire stress level, so it continues to ask for more clients. If you encounter this event, something is wrong or has gone wrong. In such a case, we recommend that you rerun the test using a different brand of NIC to confirm or eliminate the NIC driver.


Additional Qualifications Information

Fault-Tolerant Additional Qualification Requirements

If you want the system under test to be additionally qualified for fault tolerance (FT), you must select that option from the DTM Submission Wizard. If the system under test qualifies for FT, it will also be qualified for a Windows Server logo. The tests for the fault tolerant additional qualification are almost identical to those for Server logo tests. The only difference is that for the FT qualification, the Mmtest.exe test is run, which calls, and has a dependency upon, the vendor-provided Oemdll.dll.

Mmtest.exe calls Oemdll.dll functions to create and then destroy mirrored memory images. These functions are stored in a vendor-supplied DLL file. This DLL file translates the Mmtest.exe function requests to the form needed by the vendor-supplied drivers to manage and operate the memory mirror hardware. The DLL file hides the specifics of the vendor's implementation of fault tolerance technology from Mmtest.exe.

When you test for the fault-tolerant additional qualification, you must put the Oemdll.dll in a location and supply that location as the parameter to the DTM test Start Test for Fault Tolerance Server. The location can be either on the local disk of the DTM Controller or a on a network share. If the location is on the network, DTM Controller must be able to access it with the credentials that you supplied when you installed the controller.

For more information, see Fault Tolerant Systems.

Dynamic Partition Testing

The Dynamic Partitioning Additional Qualification test tests the logo requirement of Computer Hardware Systems supporting Dynamic Partitioning. It checks whether the system server correctly supports Hot Add CPU/Memory and Hot Replace CPU/Memory. You can run the test manually after you set up the system. The test can also be run through DTM (shipped with WLK) as part of the Windows Server 2008 Server System test for submission.

For more information, see Dynamic Partition Testing.

Enhanced Power Management Additional Qualification

The Enhanced Power Management tests the requirements for being awarded the Enhanced Power Management Additional Qualification. It does this by checking if the CPUID feature flag reports that the CPU supports p-states, and at least 1 p-state has been exposed to the OS for the first requirement. The second requirement is tested by making a WMI query which returns at least one Win32_PowerMeter object that reports values within permissible ranges for the "CurrentReading" and "ConfiguredBudget" properties.

For more information, see Enhanced Power Management Additional Qualification.


Basic Domain Controller Setup for Server System Logo Testing

Document Purpose

This document details step-by-step how to set up a network infrastructure manually. The content is written for Windows Server 2008 R2. All systems used for Server Logo testing must be the latest version and service pack of the operating system, such as Windows Server R2, Service Pack 1 or later.

The information in this document is provided as-is, no warranty or support are provided or implied. The document was written to provide a beginners guide to creating a working network for the purposes of WLK testing.

Before you Begin

Note: All of the machines you are using to test the Server Under Test (SUT) are on an isolated network, with no connections to any machines that are not used for this test run, as referenced in the diagram below. Depending on which test kit you are using your run may not require all eight Subordinate Clients (SC). The Master Client (MC) is most likely required, depending on the kit you are running. Please refer to the Device Test Manager (DTM) help file for details on DTM usage.

Preparing the Domain Controller

  1. Shut Down all machines being used in the test run except the Domain Controller. All MCs, SCs, SUTs, and the DTM Controller must be Shut Down.

  2. On the machine that is designated for your Domain Controller, click the Start Button, then Right-click Network, then click Properties.

  3. In the Tasks pane on the right, click Manage Network Connections.

  4. Right-Click and Disable all Network Adapters except one.

  5. On the remaining Network Adapter, Right-Click and select Properties.

  6. Select Internet Protocol Version 4, and click Properties.

  7. Select the radio button Use the following IP address, and in the IP address textbox, enter 10.0.0.10

  8. For Subnet Mask, enter 255.255.255.0

  9. Leave the Default Gateway blank and Preferred DNS Server textboxes blank, and click OK

Promoting the Domain Controller

  1. Click the Start Button, then click Run

  2. Type dcpromo, then press Enter

  3. When the Active Directory Services Installation Wizard window appears, click Next twice.

  4. At the Configure Domain Name System Client Settings window, click the checkbox for Automatically correct the problem by installing DNS Server service on this computer, then click Next.

  5. Click Next again, then click Create a New Domain in a new forest, and click Next.

  6. Give your new domain a name (e.g. MyDomain.com), and click Next. (The wizard will verify that the new domain name is not already in use. If so, please verify that these machines are on an isolated network, and retry this step.)

  7. From the drop-down menu, select Windows Server 2008, and click Next.

  8. Verify that the DNS Server, and Global catalog checkboxes are selected, then click Next.

  9. Select Yes at the dialog box that appears.

  10. Make no changes to the Database, Log Files, and SYSVOL directories, then click Next.

  11. Choose a Directory Services Restore Mode Administrator password, enter it into the password textboxes, and click Next. Make certain that the password meets or exceeds the password complexity requirements.

  12. Verify that all the settings you selected are reflected in the Summary screen. If so, click Next.

  13. Select the Reboot on completion checkbox.

Creating the Domain User

  1. On the domain controller, when it has finished rebooting, click Start, then Administrative Tools, then Active Directory Users and Computers.

  2. Expand the domain you created, e.g. MyDomain.com, and right-click Users, then click New, then User.

  3. In the First Name textbox, enter Logonuser, and in the User Logon Name textbox, enter logonuser , then click Next.

  4. Choose a password that meets or exceeds the password complexity requirements, and enter it into the Password and Confirm Password textboxes.

  5. Click the 'Password Never Expires' checkbox, and at the warning dialog, click OK.

  6. Verify that all settings are correct, then click Finish.

  7. Click View, then Advanced Features.

  8. Right-click logonuser, then click Add to a Group

  9. In the textbox, Type Account Operators then click OK.

Setting up the DHCP Service

  1. Click the Start button, then All Programs, Administrative Tools, and Server Manager.

  2. In the left pane, select Roles, then right-click Roles and select Add Roles.

  3. If the Before You Begin wizard page appears, click Next.

  4. Check the DHCP Server checkbox, and click Next, and then Next.

  5. Verify that there is only one Network Connection available, and that it is only type IPv4. If either of these is not true, return to Step 4.

  6. Verify that the IP Address for the remaining network connection is 10.0.0.10, and that its checkbox is selected. If not, return to Step 8. If so, click Next.

  7. At the Specify IPv4 DNS Server Settings window, verify that the parent domain is the domain you created (e.g. MyDomain.com), then click Next.

  8. At the Specify IPv4 WINS Server Settings, change no settings, and click Next.

  9. At the Add or Edit DHCP Scopes window, click Add.

  10. In the Scope Name textbox, type MyDomain

  11. In the Starting IP Address textbox, type 10.0.0.20

  12. In the Ending IP Address textbox, type 10.0.0.200

  13. In the Subnet Mask textbox, type 255.255.255.0

  14. Verify that the Activate This Scope checkbox is checked, then click OK, and then Next.

  15. Select Enable DHCPv6 stateless mode for this server, and click Next.

  16. At the Specify IPv6 DNS Server Settings window, delete all information in all textboxes, and click Next.

  17. Select the Use current credentials radio button, and click Next.

  18. Verify that all your settings are correct, and if so, click Install.

  19. When the installation completes, click Close.

  20. If you require a range of static IPs for the test kit:

    Choose from the range of IPs from 10.0.0.11 through 10.0.0.19, or 10.0.0.2 through 10.0.0.9.

Joining SCs, MC and SUT to the domain

  1. Power on the SC, MC, and SUT.

  2. After the machines have booted into windows, verify that they all have IP Addresses in the range of your DHCP scope. (e.g. 10.0.0.x addresses, not 169.254.x.x addresses). If not, verify that you are on an isolated network, and go back to Step 33.

  3. On the SCs, MC, and SUT, log in as Administrator.

  4. Click Start, right-click Computer, and click Properties

  5. Under Computer name, domain, and workgroup settings, click Change Settings

  6. At the Computer Name/Domain Changes windows, under the Member Of radio box, click Domain, and type the domain you created (e.g. MyDomain.com ) in the textbox, then click OK.

    Note: If you did not name your domain MyDomain.com, please replace every following instance of 'MyDomain.com' and 'MyDomain' with the name of the domain you created.

  7. In the Username textbox, enter MyDomain\logonuser and in the password textbox, enter the domain user password, then click OK.

  8. Add user MyDomain\logonuser to the administrators group by clicking Start, All Programs, Administrative Tools, Server Manager

  9. In Server Manager, expand Configuration, and Local Users and Groups, then click Groups.

  10. Double click the group Administrators

  11. In the object names textbox, type MyDomain\logonuser, and click OK

  12. In the User Name textbox, enter MyDomain\logonuser, and in the password textbox, enter logonuser's password, and click OK.

  13. At the Administrators Properties window, click OK.

  14. Reboot the SCs, MC, and SUT.

  15. After rebooting, log the SCs, MC, and SUT in as user logonuser on the MyDomain domain, using logonuser's password.

  16. Click Start, and Control Panel

  17. Select User Accounts in Control Panel.

  18. Click User Accounts in User Accounts to end up at Control Panel\User Accounts\User Accounts.

  19. Click Change User Account Settings.

  20. Move the slider down to Never notify, and then click OK.

  21. Return to the Control Panel.

  22. Click Check Firewall status.

  23. Click Turn Windows Firewall on or off.

  24. Select all 3 radio buttons to Turn off Windows Firewall, click OK, and then close Windows Firewall.

Joining the DTM Controller to the Domain

  1. Power on the Windows Server 2003 machine to be used for the DTM Controller/DTM Studio.

  2. Click Start, Right-Click My Computer, and Click Properties.

  3. Click the Computer Name tab, and click Change.

  4. Under the Member Of pane, click the Domain radio button, type the name of the domain you created (e.g. MyDomain.com) in the textbox, and click OK.

  5. Click OK at the Welcome to the MyDomain domain dialog.

  6. Click Start, Right-click My Computer, and click Manage.

  7. Expand System Tools and Local Users and Groups, then click Groups.

  8. Double-click Administrators, and click Add.

  9. In the object names textbox, type MyDomain\logonuser and click OK.

  10. Reboot the DTM Controller/DTM Studio machine, and log in as the domain user. (e.g MyDomain\logonuser)

You now have a functional domain.


Windows Server 2008 R2 Tests

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


BitLocker Drive Encryption BIOS Interface Logo Test

For more information, please see BitLocker Drive Encryption BIOS Interface Logo Test.


BitLocker Drive Encryption BIOS USB Logo Test

For more information, please see BitLocker Drive Encryption BIOS USB Logo Test.


CardBus Bridge Register Test

For more information, please see CardBus Bridge Register Test.


Disk Stress

For more information, please see Disk Stress.


GUIMAN GDI w-poly clip (gmvideo6b)

For more information, please see GUIMAN GDI w-poly clip (gmvideo6b).


HAL Test

For more information, please see HAL Test.


Processor Virtualization Support Test

Overview

The Virtualization Detect (DetectVp.EXE) tool is the logo test for checking if the system meets the requirements for Microsoft Virtualization Software. This test checks virtualization support for both Intel and AMD processors.

Details

DetectVp queries the processor features by using CPUID instructions and by reading MSR values of certain registers. The information is collected by the digitally signed DetectVp driver for all of the processors that are present in the system. After the information is collected, DetectVp validates the information and checks if all of the processors in the system are homogenous and whether they support the same set of features.

If the features of the processors in the system match the minimum requirement for running Virtualization, the test passes. If the feature requirement is not met, the test displays which feature requirement is not met and fails. If the test fails, the system cannot run Microsoft Virtualization software.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2008

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x64

Running Processor Virtualization Support Test

DetectVp is designed to run as a fully automated part of Driver Test Manager (DTM) and as a manual test tool from at command prompt. You can duplicate the automated tests by simply running DetectVp without parameters from an elevated Command Prompt window.

Command Syntax

Command option | Description
No command-line parameters |

Test Assertions

Windows Logo Program: SYSFUND-0140 Processors in the server support virtualization hardware assists
Additional Information: To support the Windows Server 2008 Virtualization Role, all processors in the server must support one of the following processor virtualization hardware assist technologies:Intel VT technologyAMD Pacifica technologyDetails on specific requirements for each of these technologies are available in the Windows Server 2008 Virtualization Requirements document. Design and Implementation NoteFor access to the Windows Server 2008 Virtualization Requirements document, e-mail lhvrtreq@microsoft.com.


Signed Driver Check (CheckLogo)

For more information, please see Signed Driver Check (CheckLogo).


SMBIOS HCT

For more information, please see SMBIOS HCT


SQL IO Simulator

Overview

The SQL IO Simulator test stresses the IO subsystem by generating IO patterns similar to the IO activity of the SQL Server. The simulator creates two types of temporary files on the drives to be tested: database data files and database log files. The data files are used to read and write verifiable data pages; the log files are used to simulate the Write Ahead Logging (WAL) protocol.

Details

SQLIOSim.com simulates SQL threads so it has lazywriter, logwriter, checkpoint, grow/shrink, read-ahead, bulk insert, random access, and audit threads (called 'users'). The content of the pages is random, but it can be recreated using the seed value. Every time the page is read from disk, the tool checks whether or not the buffer descriptor for this page is in the buffer pool already (the page has been read/written before). If that is the case, a replica page is created from the seed stored in the descriptor, and the pages are compared; if not, the page is checked for consistency using the checksum from the page header. If validation fails, the dump of the page is saved as SqlSimErrorDumpXXXXX.txt in the current directory, and the error is logged.

Requirements

Software Requirements

The test tool requires the following Windows operating systems:

  • Windows Server 2008 R2

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x64

  • Itanium


System - Common Scenario Stress with IO

For more information, please see System - Common Scenario Stress with IO.


System - Disable Enable with IO

For more information, please see System - Disable Enable with IO.


System - Sleep Stress with IO

For more information, please see System - Sleep Stress with IO.


TCG TPM Integration Test

For more information, TCG TPM Integration Test.


WDDM System Check

For more information, please see WDDM System Check.


WHEAHCT

For more information, please see WHEAHCT.


Unclassified Signature Testing

Unclassified Signature Testing Overview

Preparing for Unclassified Signature Testing

Running the Unclassified Signature Testing Tests

Unclassified Signature Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Unclassified Signature Testing Overview

You can use the Unclassified Signature program to obtain a Microsoft signature for your device drivers and INF files if no Windows logo program exists for your device type. You can also use the Unclassified Signature program to sign your filter drivers and device stacks if no specific device is associated with your driver. You cannot use an Unclassified Signature if a logo program exists for your driver or device type. Unclassified Signature is not a device or system logo program and does not grant you a Windows logo for your driver or device. It is only used to obtain a signature for your driver.

Note You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

The procedures presented in this section outline the process for testing your driver 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 or driver.

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 Windows logo testing.

  • Running: The running topics describe how to run the tests for your device or system.

Driver Reliability Tests

The tests you must 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 Driver Reliability Tests topic.

Note The Driver Reliability tests are required for most logo programs in addition to device-specific tests specified by each logo program. For an Unclassifed Signature, the Driver Reliability tests are sufficient to obtain a signature for your driver.

Run time: approximately 5 hours

Hardware requirements

The Unclassified Signature program requires no special hardware other than the device and driver being tested.

Note Testing a device to obtain a logo for Server Device qualification requires that the system being used to test the device supports four processors and a minimum of 1 GB of RAM. These system capabilities are required for the "Dynamic Partitioning (DP) Simulator and Test" and the "Multiple Processor Group" test to run. You do not need a system that actually supports DP capabilities or has greater than 64 processors to test your device.

If a pool of systems is used to test devices, at least one system in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that system must contain the device and driver being tested. As long as the driver is the same on all systems in the pool, the schedule will be created to run against all systems.

For those tests that do not include a driver to test, such as testing a hard drive, the Driver Test Manager (DTM) scheduler will constrain the DP test to run on the default system. This system should also be manually configured to have multiple processor groups. The default system is the first one listed. Test personnel, in this case, should ensure that this first system meets these minimum hardware requirements.

Note Except for Para-Virtualization drivers (as defined by Logo Requirement Policy-0020), physical devices and their associated drivers being tested for Server Logo or Signature may not be tested in virtual machines using any form of virtualization. This is because not all virtualization products support the underlying functionality needed to pass the tests relating to Multiple Processor Groups, Device Power Management, Device PCI functionality, etc.

Software requirements

The Unclassified Signature program has no software requirements other than the software that is required by the device or driver being tested.

Note Microsoft Windows Server 2008 R2 is supported.

Tester knowledge requirements

To run the Driver Reliability tests, testers must know how to accomplish the following tasks:

  • Complete basic tasks in Driver Test Manager (DTM).

This section includes the following topics:

Preparing for Unclassified Signature Testing

Running the Unclassified Signature Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Preparing for Unclassified Signature Testing

Before running the tests, you must configure at least one client system and install the operating system. This section summarizes the related procedures.

Device and Driver Installation

Install your driver and device on at least one client computer system.

DTM Client Software Installation

Install Driver Test Manager (DTM) client software. After DTM Client is installed, open DTM Studio and locate the new client in the default machine pool.

Create a Machine Pool

If a machine pool has not already been created, perform the following steps to create one.

  1. Right-click the '$' in the left-hand Machine Pool window, and click Add Machine Pool.

  2. In the Add Machine Pool dialog box, type a name for the machine pool, and click OK.

Add the newly installed client to the machine pool by dragging and dropping it from the Default Pool window to the newly created machine pool.

Make the client ready for scheduling

  1. In the machine pool to which you added the newly installed client, right-click the client computer in the Machines windows, click Change Status, then click Reset.

    The Unclassified Master Config Job will automatically schedule and run on the client computer. When the job has completed, the client is ready to begin an Unclassified submission.

  2. Repeat the preceding step for each client in the machine pool.


Running the Unclassified Signature Tests

To run the Unclassified Signature tests, do the following:

  1. Open Driver Test Manager (DTM) Studio.

  2. On the Explorers menu, click Device Console.

  3. Select View By Submission.

  4. From the Submission control, click New Submission. The Create New Submission Wizard appears.

  5. From the Select OS dialog box, click the Windows operating system that is installed on the client, and then click Next.

  6. From the Select Category window, click Unclassified Submission, and then click Next.

  7. Under Logo Type, scroll to the bottom of the list, click Unclassified, and then click Next.

  8. From the Qualification Level window, click Unclassified, and then click Next.

  9. Type a name for the submission, click the machine pool, and then click Next.

  10. Type the path to the INF file and click Load. You can also use the Browse button to find your INF file.

  11. In the Drivers for Submission area, select the driver that you want to submit, and then click Next.

    Note If you select the I am not providing an INF or Driver Package check box, your device will be tested with the system-supplied drivers and the INF file from the operating system. As a result, you will not be able to upload driver files to Winqual. However, you will still receive the Windows Logo Verification Report after you successfully complete the logo tests, and your submission package is approved.

  12. Click Finish.

    The new submission appears on the left side of the Available Devices window in the Device Console.

  13. In Available Jobs, select the Driver Reliability check box, and then expand the Driver Reliability category to show the individual jobs.

To schedule the Unclassified Submission jobs, do the following:

  1. Click Add Selected, and then click Schedule Jobs.

    Note At this point, you can return to the Job Monitor window to monitor the progress of the logo tests that you scheduled.

  2. From the Device Console, click the Status button to launch the Submission Status Tool.

After the submission jobs are complete, create a submission package.

  1. Open Device Console, and in the Available Devices window on the left, right-click the submission name that you created earlier.

  2. Click Create Submission Package.

  3. In the Save File dialog box, type a name for the submission, and then click Save.

    Important This is the file that you will submit to Microsoft along with your driver package.


Unclassified Signature Tests

These test jobs exercise and test devices and drivers that use the Unclassified category. They are listed under the following topics: Device Fundamental, Device Installation, and Kernel Mode Driver Tests.


[PREVIEW] Verify Driver Load Order Group is not WdfLoadGroup

Type: Automated test

Overview

The WdfLoadGroup driver load group can only be used by Windows Driver Framework (WDF). Drivers are expected to not specify this load order group. If the WdfLoadGroup value is used, it prevents the WDF boot start driver installation.

Details

This test checks the load order group value of the device driver. If the driver is using WdfLoadGroup, then the test flags this as an error.

Run time: 5 minutes
System restart required: No
Supported operating systems for logo or signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2008

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.
Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard disk drive with a minimum of 20 GB available on partition C:
Processor
  • x86
  • x64
  • IA64

Running the test

To run this test, follow these steps:

  1. Open DTM Studio.
  2. Open Device Console, and then select the machine pool that contains the computer that you want to run the test on.
  3. In Available Devices, expand the type of device that is associated with your driver, and then select the specific device to run the test on.
  4. In Available Jobs, click the Verify Driver Load Order Group is not WdfLoadGroup job.
  5. To add the job to the schedule of jobs to run, click Add Selected in the lower-left corner of the Device Console window .
  6. Click Schedule Jobs.


Device Installation Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


Run INFTest against a single INF

Overview

The Run INFTest against a single INF test is an automated Driver Test Manager (DTM) test job that runs the ChkINF utility. ChkINF is a set of perl scripts that verify the structure and syntax of setup information (INF) files for drivers that are designed for Microsoft Windows 2000 or later versions of the Windows operating system.

Details

For a full description of ChkINF, see the Driver Development Tools section of the Windows Driver Kit (WDK) documentation.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Running Run INFTest against a single INF

Run INFTest agains a single INF will be automatically run for Unclassified Signature and Logo submissions. For more information, see your logo program documentation.


Kernel-Mode Driver Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


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

PwrTest functionality is separated into scenarios. Currently, PwrTest supports the following scenarios:

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

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.

ES

Displays and records thread execution state changes. Thread execution states allow applications and services to temporarily override power management settings such as the monitor and sleep idle timeouts.

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
  es  for thread execution state changes

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 Microsoft Windows Driver Kit (WDK) tools that use the WTTlog interface.

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 command-line arguments in the following table.

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
/unattend | Indicates the system should wake unattended. PwrTest will not request the display to be enabled between each sleep cycle. | This feature is disabled by default.

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 command-line arguments in the following table.

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 command-line arguments in the following table.

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 command-line arguments in the following table.

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>

The following table describes the Info 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.

Execution State Scenario Information

The PwrTest Execution State scenario is designed to log and display thread execution state change events.

Applications and services may temporarily override power management settings such as the monitor and sleep idle time outs by changing their thread execution state. Execution state for a given thread can be changed through the Microsoft Win32 SetThreadExecutionState() API.

The Execution State scenario will display and log in real-time applications and services that are changing their thread execution state. This can be useful to diagnose applications and services that are preventing the monitor or system from going idle.

For more information about the SetThreadExecutionState() API, see SetThreadExecutionState on the MSDN Web site.

To learn more about the Execution State scenario, type:

  PwrTest /es /?

The PwrTest /es scenario can be exited by pressing the 'q' key.

Note PwrTest is not capable of determining changes to thread execution state before the Execution State scenario is started.

Argument | Description | Default value
(no arguments) | n/a | n/a

Examples

PwrTest /es

PwrTest will display and log changes to thread execution state.

XML Logfile Output

The Execution State scenario generates the following XML elements:

<ExecutionState>
  <EsChange>
  <Time>09:13:47</Time>
  <Process>\Device\HarddiskVolume1\Program Files\Windows Media Player\wmplayer.exe</Process>
  <RawState>0x80000001</RawState>
  <Continuous>TRUE</Continuous>
  <System>TRUE</System>
  <Display>FALSE</Display>
  <AwayMode>FALSE</AwayMode>
  </EsChange>
  <EsChange>
  <Time>09:13:47</Time>
  <Process>\Device\HarddiskVolume1\Program Files\Windows Media Player\wmplayer.exe</Process>
  <RawState>0x80000003</RawState>
  <Continuous>TRUE</Continuous>
  <System>TRUE</System>
  <Display>TRUE</Display>
  <AwayMode>FALSE</AwayMode>
  </EsChange>
  </ExecutionState>

The following table describes the Execution State scenario XML elements in detail.

Element | Description
<ExecutionState> | Contains information related to the execution state scenario. Only one <ExecutionState> element per PwrTest log file.
<EsChange> | Contains information related a single thread execution state change event. There will be one <EsChange> element for each thread execution state change event recorded in the PwrTest log file.
<Time> | Indicates the time when the execution state change event occurred.
<Process> | Indicates the path to the image file for the process that requested the execution state change.
<RawState> | Indicates the request execution state. This state is a 32-bit value of type EXECUTION_STATE (see Windows.h).
<Continuous> | Indicates if the process requested the execution state change to be continuous (ES_CONTINUOUS).
<System> | Indicates if the process requested the system to be available (ES_SYSTEM_REQUIRED).
<Display> | Indicates if the process requested the display to be available (ES_DISPLAY_REQUIRED).
<AwayMode> | Indicates if the process requested away mode to be enabled (ES_AWAYMODE_REQUIRED).

Run Time: 10 minutes
Log File: PwrTestLog.xml
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Software components included with the device that is being tested.

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Running Power Management Test Tool (PwrTest)

Code Tour

File Manifest

File | Location
pwrtest.exe | tools\acpi\pwrtest

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:


Resume From Standby

Overview

The Resume from Standby (Rpat.exe) test tool is a tool that developers, testers, and system integrators can use to discover which drivers are creating a 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 helps system integrators figure out where to focus their efforts to meet the new Vista resume-from-standby requirements.

Details

This tool is located in the \tools\acpi\rpat folder in the Microsoft Windows Driver Kit (WDK). In this documentation, we've used tables to simulate the HTML. There may be minor differences in formatting and table graphics.

Rpat.exe

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 an .etl file generated by Pwrtst.exe. By default, Rpat.exe 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.

Generated by S3 | Resume tool
BIOS Init Time | 2254 ms
Device Resume Time | 636 ms
Resume Time | 666 ms

Device durations

The device durations section describes how long each specific device took to resume from standby. This list is ordered from the slowest device to the fastest.

Device | Duration (ms) |
NVIDIA GeForce FX 5950 Ultra (LDDM) | 274 | ||||||||||||||||||||||||||||||
Texas Instruments OHCI Compliant IEEE 1394 Host... | 209 | |||||||||||||||||||||||||
USB Mass Storage Device | 157 | ||||||||||||||||
Intel 82801EB USB Universal Host Controller | 97 | |||||||||
Intel 82801EB USB Universal Host Controller | 97 | |||||||||
Intel 82801EB USB Universal Host Controller | 97 | |||||||||

You can see here that, as is typical, the graphics controller took the longest to resume.

If you click a device name, you will see a summary of which drivers were using the device, how much time each one took, and the dependencies between them. For example, if you click the "USB Mass Storage Device" link in the previous table, you get:

USB Mass Storage Device
Identification: | USB\VID_10DF&PID_0500\00600000026A
Class: | USB
Manufacturer: | Compatible USB storage device
Location Information: | Port#0008.Hub_#005

Driver | BeginTime - End Time | ms
system32\DRIVERS\USBSTOR.SYS | 67072-67072 | || |
system32\DRIVERS\USBSTOR.SYS | 67072-67072 | || |
system32\DRIVERS\usbhub.sys | 67072-67228 | ||||||||||||||||||||||||||||||||||||| |
system32\DRIVERS\USBSTOR.SYS | 67229-67229 |  | |||
system32\DRIVERS\ubshub.sys | 67229-67229 |  | |||

In the previous table, you can see that the last two operations blocked on Usbhub.sys.

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 table shows the same information as the previous table, 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 previous table.

Device Timeline
The following graph shows the timeline for the devices. Time is in milliseconds (ms).
Device | BeginTime - EndTime |
ACPI x86-based PC | 66539 - 66542 | || |
Microsoft ACPI-Compliant System | 66544 - 66574 | ||||||||||||||||||||||||||||||| |
System board | 66574 - 66574 |  | ||
PCI bus | 66574 - 66574 |  | ||

The previous except shows that the system board device took negligible time to resume from standby but, as expected, blocked on the ACPI-Compliant System. Clicking a hyperlink in the tool 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.

Driver Duration
The following graph shows the cumulative time spent in each driver. Time is in milliseconds (ms).
Driver | Duration (ms) |
Microsoft USB Universal Host Controller miniport driver | 280 | |||||||||||||||||||||||||||||||||||||||
 | 274 | |||||||||||||||||||||||||||||||||||||
Microsoft ACPI driver | 272 | |||||||||||||||||||||||||||||||||||

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 a future release.

Run Time: 5 min
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

Code Tour

File Manifest

File | Location
rpat.exe | \tools\acpi\rpat


Supplemental Tests

Note For logo testing best practices, and tips to avoid common failures, please refer to "Avoiding Test Failures."


BangFS Test (DEPRECATED)

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 Logo or Signature testing:

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium


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".

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

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 |


CopyFourCC Test (DEPRECATED)

Overview

TBD

Details

TBD

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


Dynamic Partition System Testing

Overview

The HDPInterfaceTester tests the logo requirement of Computer Hardware Systems supporting Dynamic Partitioning.

It checks whether the system server supports:

  • Hot Add CPU/Memory

  • Hot Replace CPU/Memory

You can run the test manually after you set up the system. It can also be run through DTM (shipped with WLK).

Note This content does not apply to the "Device Fundamentals" category of tests.

Details

The failure/success to pass the test is by whether the system supports Hot Add of CPU/Memory/IO and Hot Replace of CPU/Memory.

Supported operating systems for Logo or Signature testing:

  • Windows Server 2008 R2 Datacenter

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • OEM wmi provider

Processor

The test tool runs on the following processor architectures:

  • x64

  • Itanium

Running Dynamic Partition System Testing

Requirements

Hardware Requirements

  • Computer (supporting Dynamic Partitioning) to be tested. Let's call this DP System.

  • Secondary Computer that has network access to the above Computer. Let's call this DPSupport system.

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Software Requirements

  • Windows Server 2008 R2 Datacenter on the DP System

  • Windows XP or later on DPSupport System

  • Software components included with the device that is being tested.

  • WMI provider from OEM that will be run on the DP System

  • Software components included with DpInterfaceTester

Setting up the systems in DTM environment

Make sure the 2 machines as described under hardware requirement are put under a machine pool

Name the DPSupport System as "DpSupportSystem"

Running the test through DTM

Run the job named "DP HCT" on the DPSupport System.

Make sure to modify the parameter in the job to specify the name or IP of DP System

Once the job starts running, it will prompt to make sure that the WI providers are installed on the DP system. If not then run the job named "Install DPMonitor on DP System" on the DP System. This is typically done once before doing several runs of the DP HCT test.

It then prompts to make sure the DP system is ready for a Hot Add test. What that means is you should make sure that there is at least one unassigned unit having CPU(s), which can be added to a running partition. You should also make sure that there is at least one unassigned unit having Memory(s), which can be added to a running partition. Instead of having two unassigned units, you can just have one unit that has both CPU and memory.

The job then runs the test for Hot Add scenario for CPU and memory

It then prompts to make sure the DP system is ready for a Hot Replace test. What that means is you should make sure that there is at least one unassigned unit having CPU(s), which can be replaced with a running unit under a running partition. You should also make sure that there is at least one unassigned unit having Memory(s), which can be replaced with a running unit under a running partition. Instead of having two unassigned units, you can just have one unit that has both CPU and memory.

It then runs the test for Hot Replace scenario for CPU and memory

It then prompts to remind you uninstall the WMI providers on the DP System. This is optional as you may not want to do this in case you want to run the test again. If you are not going to run the test again then you can do this by running the job named "Uninstall DPMonitor from DP System"

Troubleshooting

Error: "This application has failed to start because WTTLog.dll was not found".

Resolution: This should not happen if you are using DTM. This can happen if you are running the test manually. In that case either install DTM or copy WTTLog.dll to a folder in the system that is included in the path.

Error: "Failed to connect to the primary machine"

Resolution: This could happen for several reasons-

  • The primary machine (DP System) is unreachable from the machine (DP Support System) that is running the HCT. Make sure that the DP System is on the same network and is reachable by trying a "net use"

  • The username and/or password specified in the command line do not match with the username and/or password on the DP System. In that case rerun the HCT with the correct username and/or password.

  • The WMI subsystem did not find the WMI service for DPInterface. Make sure HDPInterface dll is registered (regsvr32 HDPInterface.dll) and the corresponding mof file is registered (mofcomp HDPIMonitor.mof).

  • The user (corresponding to the username specified in the command line) does not have permission on the folder that houses HDPIMonitor.dll. Make sure you place the mof and dll in a folder that has permissions for the user.

Error: "Connected to machine <0 based machine number> without DPMonitor".

Resolution: This can happen for same reasons as above. Please take similar resolution steps as above for HDPIMonitor.dll and HDPIMonitor.mof

Error: The HCT might spew error information on the console as well as in the log because of failure to execute some methods exposed by the OEM provider (HDPInterface).

Resolution: The error message should have information about the failure. Please find out why HDPInterface was unable to service the request and rerun HCT.

Error: "Hot Add CPU test scenario not found" and/or "Hot Add Memory test scenario not found" and Hot Add test may fail for this reason.

Resolution: Configure the DP System in such a way that there is at least one unassigned unit having CPU(s), which can be added to a running partition. You should also make sure that there is at least one unassigned unit having Memory(s), which can be added to a running partition. Instead of having two unassigned units, you can just have one unit that has both CPU and memory.

Error: "Hot Replace CPU test scenario not found" and/or "Hot Replace Memory test scenario not found" and Hot Add test may fail for this reason.

Resolution: Configure the DP System in such a way that there is at least one unassigned unit having CPU(s), which can be replaced with a running unit under a running partition. You should also make sure that there is at least one unassigned unit having Memory(s), which can be replaced with a running unit under a running partition. Instead of having two unassigned units, you can just have one unit that has both CPU and memory. Note: Boot partition having just one unit may not be replaceable; hence you should make sure if boot partition is a target for replacement test then it should at least have two units.

Other reasons for not able to find a test scenario:

  • If for some reason the spare unit already has an owner partition.

  • If spare unit does not have CPU or Memory.

  • If the target partition (partition where the spare unit is to be added or replaced) is not reported as in running state.

  • Only in case of replace: The target unit (the unit that is going to be replaced with the spare unit) does not have any owner partition.

  • Only in case of replace: The target unit does not have CPU or Memory.

The previous reasons are usually fixable by OEM.

Error: Error while validating the Hot Add operation. Actual DP layout (tree) does not match expected DP layout (tree).

Resolution: In this case hct will print the expected layout. Please compare the actual and expected layout and see if there is something that could be fixed by OEM.

Error: Error while validating the Hot Add operation. "Failed to confirm hot add. DP system reported <n> CPUs and <n> Mem modules added, but DPMonitor noticed <n> CPUs and <n> Mem modules added"

Resolution: This means that the DPMonitor module did not receive the expected number of device arrivals (number of logical CPUs in case of Hot Added CPU) and number of memory modules (in case of Hot Added memory). This could happen if for some reason the system does not detect hot added components. This could also happen if HDPInterface returns too soon before the DP System have received device arrival notification. Please take necessary steps to fix the error condition.

Error: "SimpleIOStress Failed! -> IcmpSendEcho() had too many consecutive timeouts. Win32=1214 - The format of the specified network name is invalid."

Resolution: This failure can be caused by network latency, which can be improved by trying one or more of the following steps:

  • Disable DHCP and use static IP addressing.

  • Place a router or switch directly between the controller and client.

  • For redundant network paths, add an additional NIC connected to the network.

Error: "Replace - ReplacePartitionUnit() failed. GLE = 31”, error code = 0x80004005 , Unspecified error."

Resolution: If this occurs, check to make sure that a Hypervisor or other virtualization method is not hosting the operating system instance under test.


Enhanced Power Management Additional Qualification

Type: Automated Test

Overview

This test examines the system to verify that the system supports the minimum requirements for Windows Server 2008 R2 Enhanced Power Management feature.

Details

This test does not directly perform any specific stress tests. Rather, it examines the system as follows:

  • If the CPUID feature flag reports that the CPU supports p-states, then if at least 1 p-state has been exposed to the OS, then requirement 1 is met.

  • If at least one Win32_PowerMeter object can be found via WMI query, that reports values for the following properties in the given range:

    CurrentReading (25W - 5000W)

    ConfiguredBudget (25W - 5000W)

    then requirement 2 is met.

If a system meets both requirements, then the test passes.

Refer to the following links for more information;

Recommendations for Power Budgeting with Windows Server http://www.microsoft.com/whdc/system/pnppwr/powermgmt/Svr_PowerBudget.mspx

Windows Hardware Developer Central - Power Management
http://www.microsoft.com/whdc/system/pnppwr/
Run Time: 5 minutes
Log File: SvrPwrEnabledTest.wtl
System Restart Required: No
Test Category: System
Supported operating systems for Logo or Signature testing:

  • Windows Server 2008 R2

Program: The test binary is SvrPwrEnabledTest.exe.

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

Hardware Requirements

The test tool requires the following hardware:

  • Systems that expose p-states if their processors support them, OR, systems with processors that do not support p-states.

  • Systems (firmware) that support the Power Meter Interface (PMI). Such systems will present at least one power meter, exposed as a Win32_PowerMeter object.

Additional Requirements

  • At least one power meter (one Win32_PowerMeter object) with the property ConfiguredBudget set to a value between 25W and 5000W. If this property is not writeable, it must be pre-configured at the factory. If it is writeable, it can be set via WMI.

Processor

The test tool runs on the following processor architectures:

  • x64

  • IA64

Running the test

All test cases return PASS or FAIL. Review the test results in the log file for specific details about failures.


Fault Tolerant Systems

Overview

Fault-Tolerant Additional Qualification Requirements

If you want the system under test to be additionally qualified for fault tolerance (FT), you must select that option from the DTM Submission Wizard. If the system under test qualifies for FT, it will also be qualified for a Windows Server logo.

Details

The tests for the fault tolerant additional qualification are almost identical to those for Server logo tests. The only difference is that for the FT qualification, the Mmtest.exe test is run, which calls, and has a dependency upon, the vendor-provided Oemdll.dll.

Mmtest.exe calls Oemdll.dll functions to create and then destroy mirrored memory images. These functions are stored in a vendor-supplied DLL file. This DLL file translates the Mmtest.exe function requests to the form needed by the vendor-supplied drivers to manage and operate the memory mirror hardware. The DLL file hides the specifics of the vendor's implementation of fault tolerance technology from Mmtest.exe.

When you test for the fault-tolerant additional qualification, you must put the Oemdll.dll in a location and supply that location as the parameter to the DTM test Start Test for Fault Tolerance Server. The location can be either on the local disk of the DTM Controller or a on a network share. If the location is on the network, DTM Controller must be able to access it with the credentials that you supplied when you installed the controller.

OEMDLL.DLL Requirements

Scope: This information is for vendors who want to implement a platform-specific DLL that Mmtest.exe will call, in order to validate if the system is hardware fault-tolerant.

Detailed Feature Description and Specification: Physical memory mirroring is a feature that is included in the Enterprise and Datacenter Editions. The underlying fault-tolerant hardware technology is typically proprietary to each vendor. Additionally, there is currently no uniform API to test this functionality.

Because vendors of fault-tolerant computer systems must be able to test memory mirroring functionality, the Mmtest.exe test program was developed to help verify the functionality.

Because Mmtest.exe is a generic test program that has no specific knowledge about these proprietary systems, Mmtest.exe searches a list of DLLs to find the appropriate DLL to use on a particular system.

API and Interfaces

The vendor-provided DLL must enable MMtest.exe to determine how many physical memory images are available on a given platform and methods to enable or disable each image in the physical memory mirror.

The DLL must expose the following three interfaces: MMQuery, MMCrash, and MMSyncVerify. All three functions are called in succession to perform a test cycle on a memory mirror system.

MMQuery

This function confirms that Oemdll.dll is compatible with the operating system and hardware it is running on. Additionally, MMQuery provides the total of number of memory images that are supported by the vendor on the system under test and indicates which images are currently operating redundantly.

MMCrash

This function provides a method to disable a given memory image. The memory image must operate redundantly for the call to MMCrash to succeed. After the MMCrash call has completed, the hardware that creates the memory image must be able to be removed from the system without additional disruption of processing. This state, where the memory image is removed, persists until a new request is received.

MMSyncVerify

This function provides a method to re-enable memory images that were previously disabled with MMCrash. A call to this function does not return until the memory image has returned to a redundant operational state, and (if it is configured) the vendor's device driver and hardware abstraction layer (HAL) have verified the contents of the memory mirror.

DLL Entry Points

MMQuery

DWORD WINAPI MMQuery (

OUT UINT *puBoardsNo )

Description

MMQuery returns information about the number of memory images and their operational state.

Parameters

puBoardsNo - A pointer to a memory address that is provided by the caller. The total number of physical memory images that are supported on the given platform is sent to this address.

Return Value

This function returns a bitmap of all memory images that are operating in a redundant state. The least significant bit represents CPU image 0, bit one represents CPU image one, and so on. If this function is called on different hardware platforms than the one where the DLL was intended to run, MMQuery returns a value of zero.

Note Because MMtest.exe attempts to load all the DLLs from every vendor that has a fault-tolerant system, the function returns zero if the DLL is not running on the vendor's platform.

Only one of the bits is required to be set in the bitmap. If only one memory image is operating during the function call, only that bit is set in the bitmap.

MMCrash

DWORD WINAPI MMCrash (

IN DWORD cpu_brd )

Description

MMCrash signals the vendor's device driver to disable the caller-specified memory image. All other redundant memory images are expected to continue to run normally.

Parameters

cpu_brd - The ordinal number of a memory image to disable. This function does not return until the device driver has completed the disable operation.

Return Value

Either ERROR_SUCCESS or an appropriate failure code from WinError.h.

MMSyncVerify

DWORD WINAPI MMSyncVerify (

VOID )

Description

MMSyncVerify signals the vendor's device driver to re-enable the previously disabled memory image. A call to this function does not return until the memory image has returned to a redundant operational state, and the device driver has verified the physical memory mirror.

Parameters

None.

Return Value

An appropriate value from WinError.h to indicate whether the mirroring operation completed successfully. This call returns ERROR_SEM_TIMEOUT if the mirroring operation did not finish in a timely manner. This time-out interval is vendor-specific.

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Software components included with the device that is being tested.

  • Windows Server 2008 R2

Hardware Requirements

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:


Flip Tests (DEPRECATED)

Overview

TBD

Details

TBD

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


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 Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • 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.


Monitor Configuration API - WDK (DEPRECATED)

Type: Automated Test

Overview

TBD

Details

TBD
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Program:

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

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:


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 opeTest Category:rating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium


Server Virtualization Validation Test

Overview

The procedures presented in this section outline the process for testing your virtualization product for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Logo Kit (WLK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the virtualization product.

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 virtualization product for testing.

Running: The running topics describe how to run to run the tests for your virtualization product.

Virtual Machine Functionality Tests

The Functionality Tests are individual tests of the capabilities of the product's virtual machine implementation.

SVVP System Functionality Tests Overview

The SVVP System Functionality Tests include tests to validate the functionality of the following aspects and components of the virtual machine:

  • Virtual PCI I/O

  • Virtual SMBIOS

  • Virtual Timers

  • Virtual ACPI and PNP functions

  • The correct operation of the storage capabilities of the virtual machine

  • The appropriate signing by Microsoft of all the drivers included

Hypervisor-based virtualization products correctly expose to the instance of the running operating system, the fact that the operating system is running in a virtual environment.

Details

LoadGen is a test tool that generates load on a given system under test. The system can be a standalone server or a virtual machine. LoadGen is started on the master client and can use multiple subordinate client computers to generate network load on the system under test.

You can start LoadGen with multiple command line parameters to enable you to control how it behaves. Configuration information is provided in the XML file that is passed through the -config command line parameter. The name of the system under test and subordinate clients (if any) are passed through -sut and -sc respectively. User credentials that start test process under are passed by -user and -pwd or -usellu (for LLU's in a DTM environment). Other command line options are available through LoadGen.exe /?.

After LoadGen starts, it reads the configuration input from the command line parameters and configuration file. This input includes the system requirements, tests to start on the systems, performance counters to monitor, parameter information, and so on. During setup, LoadGen does the following:

  • Copy files to all computers or virtual machines and starts a service (named spsrv) that LoadGen uses throughout the test run to launch tests, monitor test processes, gather information, and so on.

  • Check that the systems or virtual machines meet the requirements that are specified in the configuration file.

  • Check that the systems or virtual machines meet the requirements that are specified in the configuration file.

  • Create the parameter tree and parameter table. These items are internal data structures that are used to assign which specific system or virtual machine resources (CPU, memory, disk, network, and so on) that LoadGen targets during the test run and which test processes generate the load on each resource.

When the test starts, it runs through a set of phases. A phase consists of one or more tests that run for a given amount of time. Some test scenarios have only one test phase. At the beginning of each phase, LoadGen starts new tests. And at the end of each phase, LoadGen stops those tests that do not run during the next phase.

Tests that run in a given phase can be one of the following:

  • Tests that stress the resources on the system under test.

  • Processes that test system features.

LoadGen starts and monitors all test processes and reacts accordingly when an instance stops. If a test process is a critical one, the entire test run is ended by LoadGen. Otherwise, the test continues to run against the system under test.

When a test fails or when the last phase of the test run ends, Loadgen does the following:

  • Stops all test processes that are running on all systems or virtual machines.

  • Collects test logs to a local folder on the master client. This folder is later copied to the DTM log share.

  • Stops the services that it started on the systems or virtual machines.

  • Deletes the files that are distributed at the beginning of the test run.

To start the Server Virtualization Validation Stress test kit, you must have the following computers that have the operating system installed, that are domain-joined, and that are connected through Ethernet:

  • The virtual machine system under test (SUT) is the virtualization product that you are trying to validate.

  • The master client (MC) is the system or virtual machine that starts, monitors, and finishes the test kit.

  • The subordinate clients (SCs) are the systems or virtual machines that generate the test load for network traffic.

The Server Virtualization Validation Stress test kit start the following tests on the testing systems:

  • Virtual Machine functionality tests. These tests start at beginning of the test run and should not stop or fail before the test kit finishes. The test kit reports a failure if any of those tests failed.

  • System resource stress tests: The test kit monitors stress level on VM SUT from MC and these tests are started or stopped according to the VM system stress level.

  • Client-Server IO. This test starts on the SCs and sends a large amount of data to VM SUT. Then, the data is stored on the disks of the VM SUT.

  • Network Stress. This test starts on the SCs and sends network traffic to the VM SUT.

  • CPU resource consumption. This test runs on the VM SUT and consumes a certain percentage of the CPU resource.

  • Memory resource consumption. This test runs on the VM SUT and consumes a certain percentage of system memory resource, including physical memory, page file, and non-paged pool.

The server virtualization validation stress test tries to generate network load for each NIC on the VM server under test. The desired throughput is 40% of the NIC's capacity. If, with the current client set, the network load cannot reach the targeted level, Loadgen requires additional clients to be added in to testing environment. (To add an additional client, click the "client" pane of Loadgen UI, type the name of the client system to add into the box, and click Add. Server stress test has a time-out window of 60 minutes. After it made the request, if no additional client is added after 60 minutes, the test fails and exits.

Hardware requirements

The following virtual hardware is required for running the Windows Server 2008 R2 operating system.

Component | Requirement
Processor | Minimum: 1.4 GHz Recommended: 2 GHz or faster Note An Intel Itanium 2 processor is required for Windows Server 2008 R2 for Itanium-Based Systems
Memory | Minimum: 512 MB RAM Recommended: 2 GB RAM or greater Optimal: 2 GB RAM (Full installation) or 1 GB RAM (Server Core installation) or more Maximum (64-bit systems): 32 GB (Standard) or 2 TB (Enterprise, Datacenter, and Itanium-Based Systems)
Disk space | Minimum: 10 GB Recommended: 40 GB or greater Note Virtual machines with more than 16 GB of RAM allocated will require more disk space for paging and dump files
Drive | DVD-ROM drive

The following hardware is required for Windows Server 2008 R2 System testing.

Infrastructure Requirement and Setup for the Server Virtualization Validation tress Test

The Server Virtualization Validation Stress test required all test machines to be in a network with a domain controller. The machines themselves will need to be joined to that domain and have a domain user account created. The reliability of the network is critical to the stress test, if your network is not reliable or setup improperly the test will either fail or won't start. Make sure the test environment is on a stable and reliable network. Use dynamic IP addressing for all machines.

For the Win2008 R2 Server Virtualization Validation Stress Test, it's a requirement that both IPV4 and IPV6 be turned on.

Server Virtualization Validation System under Test (SUT) Requirements

  • Maximum number of processors that the VM SUT supports.

  • The maximum memory capacity that the VM SUT supports.

  • At least one Gigabit network adapter/virtual adapter/driver, or additional network adapters, being used for testing.

  • One hard disk drive or virtual disk to be used for installing the operating system. and should have at least 40 GB of space (or the Windows Server 2008 R2 minimum requirement) that is configured as Boot, Page File, Crash Dump.

  • One Gigabit Ethernet network hub.

Client System Requirements

The system failure of even a single client may cause the entire test to fail. To minimize the likelihood of client system failures, use the following criteria to help you choose computers and other hardware for this test:

  • Make sure that your computers or virtual machines have resources that exceed the minimum CPU and RAM requirements.

  • Make sure that all NICs and device drivers have already been logo-qualified or signed. The bandwidth of the NICs in the client computers must be equal to the bandwidth of the NIC in the SUT.

  • Plug all client computers into UPS power protection units

  • Connect all client computers with high quality cabling, routers, and switches.

  • Use highly redundant storage and memory components: For example, RAID 1 or RAID 5 memory, MPIO Duplexing for storage, RAID hard disks, Teaming for NICs etc.

Software requirements

The following software is required to run the Windows Server 2008 R2 System tests:

One of the following operating systems for the VM SUT:

  • Windows Server 2008 R2 Datacenter Edition to enable all the processors and exercise all possible features in the system being tested.

  • Windows Server 2008 R2 Datacenter Edition to enable all the processors and exercise all possible features in the system being tested.

  • Windows Server 2008 R2 for Itanium-based systems, in order to enable all the processors and exercise all possible features in the system being tested.

  • Windows Server 2008 R2, Standard Edition, for x64 platform, for the master client and the client systems

  • Any drivers that are not shipped with the Microsoft Windows operating system

  • The current release of the Driver Test Manager (DTM)

Tester knowledge requirements

To run the Windows Server 2008 R2 Server Virtualization Validation System tests, testers must know how to accomplish the following tasks:

  • Create, format, and remove partitions on a hard disk drive

  • Set power management options

  • Install and configure a network

  • Install the operating system from the product DVD

  • Download a service pack for an operating system

  • Install the Active Directory Domain Services Role

  • Create a domain. To learn how to create a domain read Basic Domain Controller Setup for Server System Logo Testing located under Logo Tests: Device and Driver Technologies -> Windows Server 2008 R2 System Testing.

  • Install and operate the Driver Test Manager and Studio Services

  • Set up the systems or virtual machines to be used in testing at the BIOS/FW/EFI level

Preparing for Windows Server 2008 R2 Server Virtualization Validation 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 Windows Server 2008 R2 System Testing Overview.

Many of the tests in the Windows Logo Kit (WLK) require a test system or virtual machine 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.

Test systems configurations

We are making the assumption that you have already setup the network domain controller and installed the DTM controller and DTM Studio on a machine (Please see the DTM setup documentation). Also the DTM controller and Studio are on the network.

The Server Virtualization Validation test requires the following system configuration tasks to prepare the test VM system for testing.

The machines setup for the Server Virtualization Validation Stress test consisted of:

  • One VM "Server Under Test" (SUT). This is the virtual machine product you are validating

  • One x64 (This kit does not support ia64 for clients) client machine that will act as the "Remote Test Host" (MC). Please note the restriction for the MC below:

    Note The master client must be listed on the Windows Catalog or a VM running on such a system.

    The master client must NOT be set up as follows:

    • As the domain controller for the test systems
    • As the DTM Studio host
    • As the DTM Controller for the systems that are used for testing

    Note You should not do this to the SC or VM SUT either. It can impact the test in a negative way.

  • Eight x64 (This kit does not support ia64 for clients) client machines or virtual machines that will act as the "Subordinate Clients" (SCs)

  • Do not use "MC" or "SC" or "SUT" or any derivatives in the virtual machine system names. As this can cause test to fail.

Important Because some systems might be set to shipping configuration, they might not have all their devices enabled or their drivers loaded. Before testing begins, ensure that all devices in the virtual machine system are enabled and all drivers related to those devices are loaded per the testing requirements.

Storage and OS Installation

  • These machines or virtual machines are connected to the network via gigabit HUB or switch with high speed CAT6 or faster cables.

  • Install Datacenter or Enterprise Server SKU Operating System (OS) into the VM SUT

  • Install any Server SKU OS on the MC and SC's

  • All machines or virtual machines have NTFS format on all disks or virtual disks.

  • Each machine or virtual machine has approximately 40GB of free disk space on drive C:\ after the OS has been installed.

Systems Settings for SUT, MC and SCs, physical or virtual

  • Join each machine to the same Domain using the domain user account you created and use dynamic IP addressing.

  • Logon to each machine using the created domain user account.

  • Use the following procedure to configure the power options on the VM SUT master client and the SC Clients:
    1. Click Start, click Control Panel, and then double-click Power Options.
    2. Click the Power Schemes tab.
    3. From the Turn off monitor list, select Never.
    4. From the Turn off hard disks list, select Never.
    5. If there is a System standby list, select Never.
    6. If there is a System hibernates list, select Never.
    7. If there is a Hibernation tab, clear the Enable hibernation check box.

  • Turn off User Account Control (UAC) and firewall on all the machines and reboot the machines

  • Each machine (MC, SC, SUT) will need at least one gigabit Network Interface Card (NIC) to connect to the network. If machine have more than one NIC, make sure those are also connected to the HUB.

  • Note

    IPv4 and IPv6 must both be enabled on the system being tested, the master client, and all clients connected to the system.
    A network interface adapter that is not connected to a network generates an error, causing the test to fail. Note that network adapters used for iSCSI connectivity to storage do not need to be connected to client systems.

DTM Studio Setup:

  • Logon to each machine using the created domain user account

  • Install the DTM client on each machine so they will become visible in DTM Studio under the "Default Pool" in the Job Monitor pane. Here's how:
    1. Click Start then Run on each machine, type the path to the client installation files located on the DTM controller. Example: \\YourDtmController\DTMInstall\Client\setup.exe
    2. Click Enter to run setup.exe and follow the prompts to install the DTM client.
    3. After the DTM Client installation completed successfully, the machine name should appear under the Default Pool branch in the Job Monitor pane in DTM Studio.
    4. Do this for each SC, MC, and SUT

  • In the Job Monitor pane create a new machine pool and give it a name. Any name you like. The Machine Pool name should be no more than 12 characters without spaces.

  • Move all the machines (SUT, MC, SC's) from the "Default Pool" to this new machine pool you just created. Drag-n-drop them into the new pool.

  • Create a new submission through Device Console. To do this, in the DTM Studio menu click Explorers, and then Device Console.
    1. In the Submission drop-down, select <New Submission>.
    2. Choose the processor-specific version of the OS you are running on the SUT, and click Next.
    3. Select the Category System Submission, and click Next.
    4. Select the Sub-Category Server Virtualization Validation, and click Next.
    5. Give a name to the Submission, then select the Machine Pool that contains the configured MC, SCs, and the SUT you want to submit, and click Next.
    6. Select the VM SUT, and click Next.

  • Return to the Job Monitor, either by clicking the Job Monitor tab at the bottom of DTM Studio menu, or click Explorers, then Job Monitor.

  • Select the Machine Pool used to create this Submission, and click Refresh to verify that the Prepare for Submission jobs have completed.

The environment is now ready to run tests.

Note When you are not testing in Submission mode, you have to manually set the appropriate HCT\Role dimension for each client computer. Select the value of MC for the master client and the value of Node for the subordinate clients. For more information about how to set a dimension, see the Defining and Viewing Dimensions topic.

Running the Windows Server 2008 R2 Server Virtualization Validation Tests for the Maximum VM test case

To run the Serve Virtualization Validation Stress tests for submission follow the steps below. This portion of the SVVP test tests a single virtual machine. This test machine will be the largest virtual machine whose logo test results you want to submit to Microsoft. This virtual machine must have been validated and will be listed by Microsoft. This SVVP test is referred to as the 'Maximum VM' test or 'Max VM' test.

During the Max VM test, the computer that hosts the maximum virtual machine must expose the following:

The maximum amount of RAM that can be supported by the virtual machine. There must be enough physical RAM on the host machine to back this amount.

The maximum number of processors that can be supported by the virtual machine. There must be enough physical CPU cores on the host machine to back this number.

  • Return to the Device Console, either by clicking the Device Console tab at the bottom of DTM Studio, or clicking Explorers, then Device Console.

  • If the submission you just created is not shown in the Submission pull-down, select your Submission now.

  • Select the Win7 Loadgen Server Stress - Run First - Set Machine Policies checkbox. This job will set certain configuration on the computers in your machine pool.

  • Right click the Win7 Loadgen Server Stress - Run First - Set Machine Policies job, and select Edit Parameters

  • In the pop up box, type in the Domain Name, Domain User Name and Domain User Password used by the test environment for the parameters DomainName_LLU, UserName_LLU and Password_LLU respectively. Then close the pop up box.

  • Click the Add Selected button, and then verify that the correct MC, VM SUT, and one of the SCs are in the validation list. Close the validation list, and click Schedule Jobs.

  • Return to the Job Monitor to verify that the Win7 Loadgen Server Stress - Run First - Set Machine Policies job has completed successfully. This job needs to pass before the next job will run properly.

  • Follow the job scheduling procedure to run the Win7 Loadgen Server Stress - Start Test for Server job. This is the Server Stress test. This test runs for approximately 24 hours.

  • Depending on the "horse power" of your SC clients compare to your VM SUT, the test may ask for more clients. Make sure you check the MC screen from time to time in the first few hours for a pop-up asking for more clients. Once the first few hours have past, the stress load should stabilize. See troubleshooting section 'Loadgen is asking for more clients' for details.

  • Return to the Job Monitor to verify that the Win7 Loadgen Server Stress - Start Test for Server job has completed successfully. You'll need to press the refresh button on the tool bar in order to see the updated info. If you need to rerun this job, there is no need to rerun the previous Win7 Loadgen Server Stress - Run First - Set Machine Policies Job.

  • Follow the job scheduling procedure to run the Win7 Loadgen Server Stress - Run Last - Reset Machine Policies job when the Start Test job is finished. The Run Last job resets the machine policies that were set on the computers in your machine pool. Whether this Job passes or fails is not relevant to the submission; it is simply a clean-up Job.

  • After you successfully complete all the jobs, create a submission package for the virtual SUT.

Running the Windows Server 2008 R2 Server Virtualization Validation Tests for the Multiple VM test case

For each virtual SUT created, there must be one set of clients consisting of subordinate clients and one master client. These clients can either be physical or virtual.

In order to test four virtual SUT machines, and depending on the processing power of the clients, eight subordinate clients may or may not be enough. LoadGen might ask for more subordinate clients during the test if the stress level LoadGen tries to achieve cannot be reached with the eight clients

This portion of the SVVP test uses the same set of tests to simultaneously stress four instances of the virtual machine that are all running on the same system. This SVVP test is referred to as the 'Multiple VMs' test. During the Multiple VMs test, the computer hosting the four virtual machines must expose each of the virtual machines to the following:

At least two virtual processors, backed by physical cores

One quarter as much virtual machine memory, backed by physical memory, as was used for the Max VM configuration and tests

You can also use a computer that exceeds these requirements to perform the SVVP test.

  • Return to the Device Console, either by clicking the Device Console tab at the bottom of DTM Studio, or clicking Explorers, then Device Console.

  • If the submission you just created is not shown in the Submission pull-down, select your Submission now.

  • Select the Win7 Loadgen Server Stress - Run First - Set Machine Policies checkbox. This job will set certain configuration on the computers in your machine pool.

  • Right click the Win7 Loadgen Server Stress - Run First - Set Machine Policies job, and select Edit Parameters

  • In the pop up box, type in the Domain Name, Domain User Name and Domain User Password used by the test environment for the parameters DomainName_LLU, UserName_LLU and Password_LLU respectively. Then close the pop up box.

  • Click the Add Selected button, and then verify that the correct MC, VM SUT, and one of the SCs are in the validation list. Close the validation list, and click Schedule Jobs.

  • Return to the Job Monitor to verify that the Win7 Loadgen Server Stress - Run First - Set Machine Policies job has completed successfully. This job needs to pass before the next job will run properly.

  • Follow the job scheduling procedure to run the Win7 Loadgen Server Stress - Start Test for Server job. This is the Server Stress test. This test runs for approximately 24 hours.

  • Depending on the "horse power" of your SC clients compare to your VM SUT, the test may ask for more clients. Make sure you check the MC screen from time to time in the first few hours for a pop-up asking for more clients. Once the first few hours have past, the stress load should stabilize. See troubleshooting section 'Loadgen is asking for more clients' for details.

  • Return to the Job Monitor to verify that the Win7 Loadgen Server Stress - Start Test for Server job has completed successfully. You'll need to press the refresh button on the tool bar in order to see the updated info. If you need to rerun this job, there is no need to rerun the previous Win7 Loadgen Server Stress - Run First - Set Machine Policies Job.

  • Follow the job scheduling procedure to run the Win7 Loadgen Server Stress - Run Last - Reset Machine Policies job when the Start Test job is finished. The Run Last job resets the machine policies that were set on the computers in your machine pool. Whether this Job passes or fails is not relevant to the submission; it is simply a clean-up Job.

  • After you successfully complete all the jobs, create a submission package for each virtual SUT.

Validation Requirements

To qualify for SVVP validation you must meet the following test procedures:

  • The Max VM test must successfully complete all testing

  • All SUT VMs for the Multiple VMs test must run Job 2 in approximately the same time

  • All Job 2 runs for the Multiple VMs scenario must pass within the same time frame for all SUT VMs

Submission Packages

SVVP Submissions must include the following:

  • A results package [CPK] for the 'Max VM' test

  • A results package [CPK] for each of the four virtual SUT machines tested for the 'Multiple VM' test and the results must be for the same hardware architecture for each virtual SUT machine.

    Note These are the possible architectures: Opteron, Xeon and Itanium, and that Opteron and Xeon are tested separately. The results must also have been created using the version of Windows Server 2008 appropriate for the architecture.

Important

  • If you perform multiple test runs we highly recommend that you reboot all the virtual machines or machines between runs. This will ensure a clean run and eliminate any running process that may have not gotten cleanup properly from the previous run.

  • The Server Virtualization Validation Stress test will reboot the virtual machine server under test during the test to verify that the virtual machine system can recover from a crash or power failure. The reboot can result in an unexpected reboot event in the system log. This will cause a System Event Tracker (SET) pop-up message to appear when you log on locally. The SET popup appears because the system tests cause a STOP error.

  • The Windows Server 2008 R2 test kit user interface can be monitored on the console session of the master client.

    Important Returning the test results saves all of the test log files that are created during a test run to a single cabinet (.cpk) file. Do not return the test results until you successfully complete all of the required tests for a test submission. Even your failed runs will be saved in the cabinet file. You can delete the failed run logs if you wish to reduce the size of the cabinet file.

Manual Test Steps:

Running Loadgen in Non-Submission Testing Mode

You can run Loadgen in non-submission testing mode by scheduling the relevant job in the Job Explorer window instead of in the Device Console. This is useful in the case where you want to run the stress test for non-submission testing.

To run Loadgen in non-submission testing mode:

  • Open DTM Studio and switch to the Job Explorer window.

  • Browse to \WDK Tests\Server\Windows Server Systems Kit\Windows Server Test.

  • Right-click the Win7 LoadGen Server Stress - Run First - Set Machine Policies job, and then click Schedule.

  • Click the Machines tab.

  • From the Select Machine Pool drop-down list box, click the target machine pool for running the test.

  • Click Schedule Jobs on any Machines from this Machine Pool.

  • Click the Job Monitor tab at the bottom left of the DTM Studio window and view the job status.

  • When the job has completed successfully, click the Job Explorer tab at the bottom left of the DTM Studio window, and then browse to \WDK Tests\Server\Windows Server Systems Kit\Windows Server Test.

  • You will need to edit the test to get into non-submission mode. Right-click the Win7 LoadGen Server Stress - Start Test for Server job, click Edit, click Parameters tab, under the value column, look for "-nonhct:1" change this to "-nonhct" and save the job.

    Important You will need to change this back before doing a submission test run in Device Console else DTM will detect the change and fail the submission run

    .

  • Right-click the Win7 LoadGen Server Stress - Start Test for Server job, and then click Schedule. Repeat steps 4-7

  • Once you are done. Make sure you run the last job to clean up the machine policies by scheduling Win7 LoadGen Server Stress - Run Last - Reset Machine Policies job. This is just a cleanup job, whether it passed or failed is not relevant to the test. But you should run it to reset the machines.

Note You can make changes to the test parameters by using the Loadgen user interface on the master client. You can perform following tasks:

  1. Start or stop tests in the Test pane

  2. Add or remove clients in the Client pane

  3. Adjust stress level for each performance counter in the Performance Counters pane

Note You can only adjust stress levels when you run Loadgen in non-submission mode. Additionally, the server stress test must be in Phase 2, with the phase status showing "Running Test." However, if the controls and options in the user interface are grayed out, the test is not in a state where you are allowed to make adjustment to the parameters. This grayed-out state exists before Phase 2 (the stress phase) starts, and again after Phase 2 is completed. The buttons remain grayed out until you select a test in the UI.

Troubleshooting Windows Server 2008 R2 Server Virtualization Validation Testing

The Windows Server 2008 R2 Server Virtualization Validation test includes a significant amount of logging, which makes it easier to troubleshoot failures and problems.

The Test Failed, Why?

If the failure occurs within minutes of launch, it usually means something was not configured properly. Go back and verify the settings.

If the test actually ran, there should be a log file called Server.xml in the DTM controller.

  1. Open Job Monitor

  2. Browse to the machine pool where the teat was scheduled

  3. In the Job Execution Status pane, select Win7 Loadgen Server Stress - Start Test for Virtual Server

  4. In the Task Execution Status pane, right click RunJob -Launch Win7 Server Logo Kit and select Child Job Result

  5. Go back to Job Execution Status pane, select Launch Win7 Server Logo Kit

  6. In the Task Execution Status pane, right click Start LogGen task and select View Task Log

  7. The log is parsed from the original Loadgen log and only has errors and passes

  8. To get to the original Loadgen text log, repeat steps 1-5, then click Job Logs on top toolbar or right click Launch Server Logo Kit and select Browse Job Logs

  9. This will open the log share on DTM controller and loadgen log file vm.log will be in the share. If vm.log file does not exist, it means the test never ran. Although the Job was scheduled the stress test did not run.

  10. Drag and drop the vm.log file into notepad.

  11. Scroll to the bottom of the file in Notepad

  12. Search from the bottom up for the string "Error -"

  13. The text in between these markers will tell you what failed. If it does not...

  14. Search up again with the same string. You might need to do this a few times but generally the first or second search would tell you.

The information in vmlog.xml only provided a high level indicator of what failed. It does not provide specifics.

If you're still stuck, create a CPK file and send it to product support when you open a case here:

Help and Support

Vmlog.xml is saying my account is not an Admin when it is

The possible causes for this error are:

The UAC is on. To fix this turn off UAC and reboot that machine.

Loadgen is asking for more clients

The loadgen harness has a feature that will ask for more SC clients if the existing clients cannot generate enough stress against the SUT. This is to accommodate large servers and the possibility of some SC clients going bad in the middle of a run. In general we recommend you start with eight SC clients. This is sufficient for 95% of the cases. The stress level should stabilize in the first three to four hours of the test. In other words, if more clients are needed, you'll see the pop-up in the MC within that time frame. You will have sixty minutes to add a new client or the test will abort and fail.

Note There is a limitation in the Device Console where you cannot add more machines to the machine pool once a submission has started. So if you are starting with less than eight clients make sure you have additional clients in the machine pool before starting the submission run.

In the event loadgen is asking for more clients pass the four hour mark, it means something has gone wrong. Either one or more of the existing clients dropped out for whatever reason or some network connectivity issues has occurred.

Run Time:
Log File:
System Restart Required:
Test Category:

Supported operating systems for Logo or Signature testing:

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool requires the following software:

  • Windows Server 2008 R2

  • Software components included with the device that is being tested

  • Windows Server 2008 R2, Datacenter Edition for X64

  • The virtual machine on the system under test: Windows Server 2008 R2 (any edition). For purposes of SVVP testing, the operating system on the virtual machine must be either Windows Server 2008 R2, x64 DC, or ia64.

  • The master and subordinate clients: You must install Windows Server 2008 R2, Standard or Enterprise Edition on the client computers.

  • All physical and virtual machines must have the firewall and user account control (UAC) turned off. Otherwise the SVVP test will result in test failure.

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Any computer that meets the Windows Server 2008 R2 hardware requirements. See the hardware requirements table in the Windows Server 2008 R2 System Testing Overview topic.

  • At least 8 physical processor cores so that, for the Multiple VMs test, each one of the four virtual machines can be exposed to two virtual processors that can be mapped to two physical processors.

  • At least the maximum memory for which a single virtual machine will be tested. This will also meet the requirements for the Multiple VMs test, which requires one quarter of the maximum single-virtual-machine memory for each of the four virtual machines. This system should also have any additional memory required for the hypervisor or Host operating system and the Virtual Machine Monitor required to host four virtual machines.

Processor

The test tool runs on the following processor architectures:

  • x64

  • Itanium

Running Server Virtualization Validation Test

PCI Tests

The PCI/PCI Express Compliance Test, or PCIHCT, is a test tool that verifies that PCI and PCI-compatible interfaces are implemented in compliance with published specifications by PCI-SIG and Microsoft.

PCIHCT focuses on the software interface of a device (also known as the configuration space). The configuration space contains registers that the software can access. This access makes it possible to expose the device type, device class, capabilities, state, status, and other information to the operating system. The operating system can also configure and control the device through the configuration space registers.

PCIHCT checks the implementations of the configuration space for errors such as:

  • Invalid values specified in the registers

  • Ability to write to Read-only registers

  • Writable registers cannot be written to

  • Registers that are supposed to clear, but fail to do so, when the value of 1 is written to them

  • Registers that are supposed to retain their content after a reset but fail to do so

  • Writing certain values to the registers, causes the device (and in some cases the system) to hang and stop responding.

  • Not all features or capabilities are implemented as required by the specifications.

The PCI Compliance test (PCITest2.exe) determines whether or not a single PCI device or all relevant PCI devices in a system comply with industry standards for PCI devices. The test also checks several specific Microsoft requirements for PCI devices that might exceed requirements in standard PCI related specifications.

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 (for example, base classes 0h, Bh, or Eh). The test also excludes devices with a base class/subclass combination that does not need testing (for example, 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). 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 invoked, when it is running, and when it is stopped. For PCI-Express systems, the test also checks the ACPI table to perform a BIOS-related test for memory configuration space access.

HAL Test

The HAL Test verifies the functionality of the high precision event timer (HPET) and other functions. This test verifies that:

  • The system that you are testing is using an HPET device.

  • The HPET frequency is between 10 MHz and 500 MHz.

  • The timer does not glitch or run backward.

This is done by measuring elapsed times using KeQueryPerformanceCounter, and comparing the results with those obtained from another available time source.

SMBIOS TEST

The SMBIOS HCT test validates the system's SMBIOS data. For information about the Windows Server 2008 R2 Logo requirements, about the information that is checked and about other items, see the SMBIOS Support in Windows page on the WHDC Web site.

SLEEP TEST

The System - Sleep Stress with IO job ensures that the system and its device drivers can be cycled through all the sleep states supported by the system. Additionally, this job ensures that the devices are still functional after these state changes through SimpleIO stress testing.

ENABLE/DISABLE TEST

The System - Disable Enable with IO job disables and then enables every "disableable" device. A "disableable" device is a device that has the Disable option available in Windows Device Manager, and is not part of the "LegacyDriver" class. Additionally, this job tries to ensure that the devices are still functional after the changes in state through SimpleIO stress testing. The System - Disable Enable with IO job also runs the underlying scenario test but it can only target "disableable" devices.

The test tries to do raw writes, bypassing any file system that is mounted on the hard disk if it can. The test attempts raw writes if one of the following occurs:

  • The test can find a raw, unpartitioned disk.

  • The test can find a raw, unformatted volume.

  • The test can find a volume that it can dismount.

If none of the preceding situations is available, the test performs I/O through the file system. This action is more CPU intensive. In the third and most common test mode (the test finds a volume that it can dismount), the test allocates a test file to use and writes only to the extents of that file. This situation ensures that the test never corrupts the file system of the device that it is testing.

The amount of space that the test uses is determined by the free space that is available on the test device(s). To ensure best device performance, you should delete any unnecessary files from the test device and should cleanly format or defragment the device before running the test.

IsVM TEST

To support utility or application software that may need to determine if it is executing in a virtualized environment, the IsVM test determines if virtualization products correctly expose the CPUID information to the virtual instance of Windows or applications. Software in the virtual instance of Windows can determine if it is running within a virtualized environment by executing the CPUID instruction with an input (EAX register) value of 1. When the CPUID instruction is executed by the software and it checks bit 31 of register ECX, the "hypervisor-present" bit should be set by the virtualization product.

CHKLOGO TEST

The Signed Driver Check (CheckLogo) is a test tool that verifies that drivers that are installed in a system submitted for validation, have the correct logo level signature attributes. This validation ensures that drivers meet the criteria in WLP for the Windows Server 2008 logo program, as well as insuring the drivers are in compliance with the Para-Virtualization driver requirement.

These tests are also scheduled by the DTM for the SVVP test, and the results are also recorded. These are the same system-level tests run by physical systems for the Windows Server 2008 Logo. A failure of any of these tests might constitute a failure for the overall SVVP test.

COMMON SCENARIO STRESS WITH IO TEST

The System - Common Scenario Stress with IO job ensures that the system and all of 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. In addition, it ensures that the devices are still functional after these state changes through SimpleIO stress testing.

The underlying scenario can only run disable/enable scenarios on disableable devices. A disableable device is a device that has the Disable menu option available in Windows Device Manager and is not class "LegacyDriver."

These tests are also scheduled by the DTM for the SVVP tests, and the results are recorded. These are the same system-level tests run by physical systems for the Windows Server Logo. A failure of any of these tests may create a failure for the overall SVVP test.

For more information and troubleshooting help, see "System - Common Scenario Stress with IO."

SVVP System Functionality Tests Setup

Starting the SVVP System Functionality tests will require the following systems.

System Under Test - this is the server being validated

No master client or subordinate clients are involved in the SVVP System Functionality tests, but the setup for the SVVP System Stress test (LoadGen) meets all requirements, and does not need to be modified for these tests.

The SVVP Functionality Test kit contains the tests that are explained in the DTM Jobs in the SVVP kit section earlier in this topic.

Virtual Machine Stress Test

The Stress Test consists of several server scenario workloads operating from the user level address space applied to the system to exercise the virtual system "hardware", the virtualization product-specific devices and drivers, network and storage adapters and any other drivers that might be part of the virtual machine system configuration, such as multipath storage drivers, storage or file system filter drivers, or intermediate layer network drivers.

The workloads applied are:

  • Client-Server Storage I/O

  • Winsock Network Traffic

These workloads will automatically scale to the number of virtual network and storage adapters found in the virtual machine system that have connected clients or storage devices, respectively. For example, if the test discovers one virtual network adapter and one storage adapter (along with the necessary connected clients or storage devices, respectively), the test will create workload processes for that number of virtual adapters in order to provide the stress workload. If the system has multiple virtual network and storage adapters, test processes are created for each of those virtual adapters, drivers, and connected resources (clients or storage devices) in order to provide the same relative stress workload. Additionally, the virtual network and storage adapters and their respective resources need not be the same type. For example, GigaBit Ethernet and 10GigaBit Ethernet virtual adapters could be tested at the same time, as long as network clients were connected to both virtual devices. Similarly, Fibre Channel and iSCSI virtual storage adapters can be tested at the same time, as long as the appropriate storage media is attached. Any virtual HBA units that are attached to the server under test (SUT) must be connected to the appropriate type of storage media.

Additionally, the virtual machine system test is designed to achieve the same relative amount of stress on the virtual machine system, regardless of the number or type of exposed logical processors, amount of allocated virtual machine memory, or the number of virtual network and storage adapters in the system. The test detects the number of exposed logical processors/cores in the virtual machine system, as well as the amount of allocated memory in the virtual machine system. The test then creates as many processor-specific and memory-specific stress processes as are needed to achieve a predetermined level of processor and memory utilization and will terminate those processes if the utilization level exceeds the predetermined level of stress. Thus, the level of utilization for those resources is always commensurate with the capabilities of the system. A virtual machine system that only supports a few processors/cores and an appropriate amount of memory for the system will have the same relative levels of stress as a larger virtual machine system with more processors/cores and a greater amount of memory.

There are 3 DTM jobs within Server Virtualization Validation Stress Test kit:

  • Win7 LoadGen Server Stress - Run First - Set Machine Policies (run time < 30 minutes)

  • Win7 LoadGen Server Stress - Start Test for Virtual Server (run time = 24 hours)

  • Win7 LoadGen Server Stress - Run Last - Reset Machine Policies (run time < 20 minutes)

As the names indicate, you must schedule the "Run First - Set Machine Policies" job before the "Start Test for Server" job. And you must schedule the "Run Last - Reset Machine Policies" job afterwards, when the "Start Test for Server" job has finished.

You need to schedule the Run First and Run Last jobs only once for each submission, but you must schedule and run the "Start Test" job multiple times until it passes. You also need to schedule the "Run Last - Reset Machine Policies" job if you are going to schedule other different jobs on the same machine pool.


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 Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium


Syscache Test

Type: Automated Test

Overview

The Syscache 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

The Syscache test attempts to write files using every known combination of write attributes, truncation strategy, file pointer move strategy, and read attributes. The Syscache test opens a series of temporary files and does IO on them. For each type of write file (sequential, non-buffered, mapped IO, async IO, and so on 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 that have opened the file for read operations 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 Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium


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.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Test Assertions

Test Assertion GUID: C07DC21B-15E3-17FA-7AB3-47D9C4


USB Hub Advanced Transfer Test

Type: Automated Test

Overview

A hub is a USB device that connects to a host system and provides additional USB attachment points. The USB hub contains three principal components: the hub repeater, the hub controller, and the transaction translator.

The USB Hub Advanced Transfer Test focuses on the transaction translator and verifies compliance with the Universal Serial Bus Specification Revision 2.0 requirements and the Microsoft Windows Logo Program System and Device Requirements. A USB 2.0 hub provides support for high-speed, full-speed, and low-speed USB peripherals.

The USB High Speed Advance Transfer test consists of a number of individual tests that are based on the USB 2.0 Transaction Translator and Hub Compliance Test Specification that the USB-IF developed.

Details

The USB High Speed Hub Advanced Transfer Test is required only for Universal Serial Bus (USB) revision 2.0 high-speed hubs. The test verifies that the hub correctly handles a variety of transactions types, including interrupt and isochronous IN transactions that occur at microframe boundaries, periodic transactions, and out-of-order complete-split and start-split transactions.

Schmoo pipes

Interrupt IN and Isochronous IN transactions that run behind a transaction translator have special handling rules when the transactions are still in progress at a microframe boundary. The tests, TD-9.30.1.32 and TD-9.30.1.33, use a dummy transaction to shift the location of IN transactions throughout a microframe and across microframe boundaries. This dummy transaction is an isochronous OUT to a non-existent endpoint that is slowly increased one bit at a time by varying the size and number of bitstuffs that the data pattern produces. This dummy transaction pipe will be referred to as a schmoo pipe following the nomenclature that is used in the Enhanced Host Controller Interface Specification for Universal Serial Bus Host Controller document that is available at USB EHCI Specification.

TD-9.30.1.32 Interrupt IN Microframe Boundary Test

The Interrupt IN Microframe Boundary test checks to ensure that the transaction translator correctly handles the case where interrupt IN transactions are still in progress at a microframe boundary. This test uses a schmoo pipe to generate transactions that precede the interrupt IN transaction in the microframe.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support an isochronous OUT endpoint and a loopback pair of interrupt endpoints. The maximum packet size for the interrupt endpoints is set to 64 bytes. The maximum packet size of the isochronous OUT endpoint is set to 1024 bytes.

Using a custom EHCI test stack, the test sets up a schedule to run a series of three transactions within a microframe. The transaction order is:

  1. Interrupt OUT

  2. Schmoo OUT

  3. Interrupt IN

For each fixed Interrupt transaction size and data pattern, the schmoo OUT is varied from 1 to 188 - N bytes, one bit at a time, where N is the current size of the Interrupt transaction. In each case, the data read from the interrupt IN transaction is compared to ensure it is the same as the data written with the interrupt OUT transaction. The transaction descriptor for each completing Interrupt IN transaction is examined to see if it required one or two complete splits to finish. When the transaction first requires two complete splits, the end of the microframe boundary has just been crossed.

The test is repeated for all valid sized interrupt transfers for every possible data pattern.

The procedure is repeated for all possible microframes (that is, when start-splits arrive in microframe 1, 2, 3, and so on).

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if the data returned by any interrupt IN transfer is not identical to the data that was sent with an interrupt OUT transfer.

TD-9.30.1.33 Isochronous IN Microframe Boundary Test

The Isochronous IN Microframe Boundary Test explicitly checks to ensure that the transaction translator correctly handles the case where isochronous IN transactions are still in progress at a microframe boundary. This test uses a schmoo pipe to generate transactions that precede the isochronous IN transaction in the microframe. This situation is also implicitly tested to some extent in the TD-9.29.1.31 Isochronous Transaction Loopback Test with large data sizes. Therefore, this test examines only small transfers.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full speed test device to support an isochronous OUT endpoint and a loopback pair of isochronous endpoints. The maximum packet size for the isochronous loopback endpoints is set to 128 bytes. The maximum packet size of the isochronous OUT endpoint is set to 1024 bytes.

The test uses a custom EHCI test stack to set up a schedule to execute a series of three transactions within a microframe. The transaction order is:

  1. Isochronous OUT (loopback endpoint)

  2. Schmoo OUT

  3. Isochronous IN (loopback endpoint)

For each fixed isochronous transaction size and data pattern, the schmoo OUT is varied from 1 to 188 - N bytes, one bit at a time, where N is the current size of the isochronous loopback transaction. In each case the data read from the isochronous IN loopback transaction is compared to ensure it is the same as the data written with the isochronous loopback OUT transaction. The transaction descriptor for each completing isochronous IN transaction is examined to see if it required one or two complete splits to finish. When the transaction first requires two complete splits, the end of the microframe boundary has just been crossed.

The test is repeated for all valid sized isochronous transfers for every possible data pattern.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if the data returned by any isochronous IN transfer is not identical to the data that was sent with an isochronous OUT transfer.

TD-9.30.1.34 Periodic Abort Rules Test

The Periodic Abort Rules Test verifies that the transaction translator will abort periodic transactions that are still in progress at the end of a classic frame. It also verifies that interrupt transactions that are still in progress at the beginning of the fourth microframe--after the start-split for the transaction arrived--will be aborted.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support an isochronous IN data source endpoint. The maximum packet size for the endpoint is set to 1024 bytes. The isochronous IN source is programmed to respond with 490 bytes of transaction length including bitstuffs, interpacket delay, etc.

The test device is also configured to support an additional pair of isochronous loopback endpoints and a pair of interrupt loopback endpoints with maximum packet sizes of 1024 and 64 respectively.

The test sets up start-splits for an isochronous IN transaction (490) bytes and an interrupt OUT transaction with the start splits sent in the same microframe. Later, an interrupt IN transaction is performed to read back the data sent with the interrupt OUT. The data must match. The order is:

  1. Isochronous IN

  2. Interrupt OUT

  3. Delay

  4. Interrupt IN

This process is repeated with the size of the data that is returned by the isochronous IN source being increased by one bit each iteration (using bitstuffs). At around a size of 500 bytes, the interrupt IN should no longer return data because the interrupt OUT transaction will be running at the beginning of microframe X+4 after the start-split arrival and must be aborted.

The process is repeated using the isochronous loopback endpoints to make sure that the isochronous transactions are not aborted.

This process is repeated is with the start splits for the initial isochronous IN and interrupt OUT transactions that are being sent in microframes Y0-Y4.

The process is repeated will all valid transfer sizes for the transfer being pushed across the abort boundary.

To explicitly exercise the End of Frame abort rule instead of the X+4 abort rule, another run of the test is repeated. In this case, start-splits are sent in microframe Y5. The starting size for the isochronous IN data source is only 300 in this case. It is tested using interrupt and loopback endpoints pairs. The hub must shut down the port when the EOF abort occurs.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • The data read from an isochronous or interrupt loopback endpoint does not match the data written.

  • An interrupt transaction that is in progress at the beginning of the fourth microframe after the start split arrival is not aborted.

  • An isochronous transaction that is in progress at the end of the frame is not aborted.

  • The hub does not shut down (disable) the port in an EOF abort case.

TD-9.30.1.35 Periodic Free Rules Test

The Periodic Free Rules Test verifies that the transaction translator will free start-splits for periodic transactions that have not been started at the end of a classic frame. It also verifies that periodic transactions that are not in progress at the beginning of the fourth microframe-after the start-split for the transaction arrived-will be freed from the start split pipeline.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full speed test device to support an isochronous IN data source endpoint. The maximum packet size for the endpoint is set to 1024 bytes. The isochronous IN source is programmed to respond with 564 bytes of transaction length including bitstuffs, interpacket delay, and so on. The test device is also configured to support an additional pair of isochronous loopback endpoints and a pair of interrupt loopback endpoints with maximum packet sizes of 1024 and 64 respectively.

The test sets up start splits for an isochronous IN transaction (564) bytes and an interrupt OUT transaction with the start splits sent in the same microframe. Later an interrupt IN transaction is performed to read back the data sent with the interrupt OUT. The interrupt IN must not return any data. The transaction order is:

  1. Isochronous OUT

  2. Interrupt OUT

  3. Delay

  4. Interrupt IN

This process is repeated for 100 iterations with the size of the data returned by the isochronous IN source being increased by one bit each iteration. The interrupt IN should never run because of the X+4 microframe free rule. This process is repeated with the start-splits for the initial isochronous IN and interrupt OUT transactions being sent in microframes Y0-Y4. The process is repeated using the isochronous loopback endpoints.

To explicitly exercise the End-of-Frame free rule, instead of the X+4 free rule, the test is repeated. In this case, start-splits are sent in microframe Y5. The starting size for the isochronous IN data source is only 376 in this case. It is tested using interrupt and loopback endpoints pairs. In this case, both types of IN should not return data as the interrupt OUT and isochronous OUT to loopback endpoints should be freed.

The process is repeated for all valid transfer sizes for the transfer that should be freed.

This procedure is repeated for each downstream port on the hub if it uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • Any data is read from an isochronous or interrupt loopback endpoint in a free case.

  • An isochronous or interrupt start-split is not freed from the pipeline at the beginning of the fourth microframe after its arrival.

TD-9.30.1.36 Complete Split Pipeline Free Test

The Complete Split Pipeline Free Test verifies that complete-split information for periodic transactions is freed from the complete-split pipeline if they are still present at the beginning of the second microframe after the associated transactions completed on the full/low speed bus.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full-speed test device to support a pair of isochronous and a pair of interrupt loopback endpoints. The maximum packet size for the isochronous endpoint loopback pair is set to 128 bytes. The maximum packet size of the interrupt endpoint loopback pair is set to 64 bytes. Each endpoint is configured to keep a transaction count.

The test sets up a series of interrupt OUT and IN transaction pairs. The test uses a custom EHCI test stack to allow complete control over the transaction scheduling. The interrupt OUT is scheduled under normal scheduling rules. The interrupt IN is scheduled such that a complete-split is not scheduled for the first microframe it would normally be scheduled in.

This transaction series is set up and run. The complete-splits for the interrupt IN should never complete (NYET). The host should resolve the transaction to an error (the TT will not receive a complete-split in the microframe where the data is really available, causing the TT to free the complete-split at the beginning of the next microframe).

This procedure is repeated for all valid transfer sizes.

The procedure is also repeated for isochronous transactions for all valid transfer sizes.

This procedure is repeated for each downstream port on the hub if it uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if an interrupt or isochronous loopback IN still completes despite the first complete split not being issued.

TD-9.30.1.37 Out Of Order Complete Split Test

The Out of Order Complete Split Test verifies that a TT correctly searches the pipeline for an out of order complete-split and advances the pipeline to the matching entry in the case a match is found. The test also ensures that the TT does not lose information in the complete-split pipelines when it must search for a non-existent entry.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full-speed test device to support as many pairs of interrupt endpoints as possible. A custom EHCI test stack is used to enable complete control over the transaction scheduling.

Transfers are sent to each of the endpoints with the start-splits and complete-splits scheduled in the same microframes. For one endpoint (the bad index/transfer), the start-split is scheduled one microframe earlier. This timing means that its complete split will not be matched. All transfers except the "bad" transfer must complete successfully. The bad transfer must fail.

Next, the process is repeated with interrupt IN transfers. All must complete successfully except the "bad" transfer. The data received must match the data sent with each of the OUT transfers.

This transaction series is set up and run as a one shot run. The periodic list is disabled. The complete transaction sequence is set up. The list is enabled and then immediately disabled once the transactions are run. This procedure is repeated for all valid transaction sizes and a variety of different data patterns. For each test iteration, the data pattern is different for each loopback pair of endpoints.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

The test is also repeated using isochronous transfers. The "bad" isochronous OUT transfer is created by using the wrong begin/middle/all label on the OUT.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • Out of order complete-splits are not completed by the TT.

  • Other transactions that should not be affected by an out of order complete-split are affected.

  • Any IN transactions do not product the data written to the OUT endpoint in the loopback pair for a good endpoint.

TD-9.30.1.38 Out Of Order Start Split Test

The Out of Order Start Split Test verifies that isochronous OUT transactions requiring multiple start-splits are correctly aborted in cases where start-splits are received out of order, or not received at all by the transaction translator.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full speed test device to support a pair of isochronous loopback endpoints and a pair of interrupt loopback endpoints. The maximum packet size for the isochronous endpoint loopback pair is set to 1024 bytes.

The test sets up a series of isochronous OUT and isochronous IN transaction pairs. A custom EHCI test stack is used to allow complete control over the transaction scheduling. The following table shows how the isochronous OUT is scheduled.

Iscohronous OUT scheduling | Description
SS - Begin, SS - Middle1, SS - Middle 2, . . ., SS - Middle 3 | Correct
SS - Middle 1, SS - Middle 2, ... | No SS Begin
SS - Begin, Empty Microframe, SS - Middle 1, ... | Empty Microframe1
SS - Begin, Empty Microframe, SS - End | Empty Microframe2
SS - Begin, SS - Middle1, SS-Middle 2/INT OUT, ... | INT OUT In Middle
SS - End | END Only
SS- Begin, SS - Middle1, . .. (NO SS - END) | Missing END

The isochronous IN and a pair of interrupt OUT/IN transactions are always scheduled later in the correct fashion (except for the INT OUT in Middle case above).

This transaction series is set up and run. The ISO data pattern should only be read back correctly in the case labeled (Correct) in the preceding table. The interrupt data pattern should always be read back correctly.

This procedure is repeated for a variety of transfer sizes. A variety of data patterns are used.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A long Isochronous OUT that skips a microframe or is intermingled with another transaction is not aborted.

  • An aborted Isochronous OUT affects an unrelated Interrupt transaction.

  • The data read back from the interrupt loopback endpoint is not the same as the data written.

TD-9.30.1.39 Non-Periodic Bandwidth Reclamation Test

The Non-Periodic Bandwidth Reclamation Test verifies that the transaction translator will execute a non-periodic transaction when the periodic pipeline becomes empty. This execution must take place if a non-periodic transaction is available and can be run before the current (if any) periodic transactions can be executed.

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full-speed test device to support a pair of isochronous endpoints and a pair of bulk endpoints. Each endpoint is configured for loopback transfers. A series of several frames of transactions are run as part of the test. The transfers occur as follows:

  1. Isochronous OUT to out endpoint of loopback pair.

  2. Stop Periodic List.

  3. Queue isochronous OUT endpoint to dummy endpoint (no real endpoint).

  4. Queue isochronous IN from IN endpoint of loopback pair.

  5. Attempt bulk IN transfer as soon as isochronous transfers start.

This process is repeated with the size of the isochronous OUT transfer (and thus the isochronous IN) increased by one byte each time. This continues until the Bulk transfer no longer executes. If the transfer stops executing before the total size of the isochronous OUT and isochronous IN transfers (streaming) are less than 1370 bytes the test fails.

The test is repeated for Bulk IN transfers.

The procedure is also repeated for BULK transactions of all possible sizes.

Results Interpretation

The test writes all results to a file.

The test fails if:

  • A non-periodic transaction does not occur when the periodic pipeline is empty and there is more than enough time before the end of the frame.

  • The TT stops executing bulk transfers when it still has more than enough time left in the frame to execute them.

TD-9.30.1.40 Mixed Stream Interoperability Test

The Mixed Stream Interoperability Test creates multiple loopback streams of various mixed transfer types.

For this test, you connect the high-speed hub to an EHCI host controller (high-speed capable port). Full-speed and low-speed test devices are connected to a USB 1.1 hub, which is connected to an available downstream port of the high-speed test hub. The test configures the full- and low-speed test devices to support pairs of loopback endpoints for each transaction type. The loopback tests described in the loopback tests for each individual transfer type are run simultaneously. They are run first for the full-speed device only, and then for both devices together. In each case, the period of the periodic loopback streams is varied for each stream at a different rate.

Results Interpretation

The test writes all results to a file.

The test fails if the data read on an IN transfer does not match the data written on an OUT transfer.

Run Time: 45 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • One test USB 2.0 high-speed hub

  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller

  • One Functional Compliance test low-speed device (low-speed USB 2.0 Compliance test board)

  • One Functional Compliance test full-speed device (full-speed USB 2.0 Compliance test board)

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium

Troubleshooting

The following list describes USB High Speed Hub Test Assertions:

Device Enumeration and Port Routing

  • Hub Connected Upstream to High Speed Capable Port
    • 1.1.1 When a hub's upstream port is connected to a high speed capable port, control of a full speed device connected to a downstream port must be routed to the transaction translator by the hub port routing logic.
    • Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
    • 1.1.2 When a hub's upstream port is connected to a high speed capable port, control of a low speed device must be routed to the transaction translator by the hub port routing logic. Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
    • 1.1.3 When a hub's upstream port is connected to a high speed capable port, a USB-IF compliant full speed device must enumerate properly when connected to a downstream port.
    • Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
    • 1.1.4 When a hub's upstream port is connected to a high speed capable port, a USB-IF compliant low speed device must enumerate properly when connected to a downstream port.
    • Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
    • 1.1.5 When a hub's upstream port is connected to a high speed capable port, a USB-IF compliant high speed device must enumerate properly when connected to a downstream port.

  • Hub Connected Upstream to Full/Low Speed Only Capable Port

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.

    • 1.2.1 When a hub's upstream port is connected to a full/low speed only capable port, a USB-IF compliant high speed device must enumerate properly when connected to a downstream port (as a full speed device).
    • Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
    • 1.2.2 When a hub's upstream port is connected to a full/low speed only capable port, a USB-IF compliant full speed device must enumerate properly when connected to a downstream port.
    • Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
    • 1.2.3 When a hub's upstream port is connected to a full/low speed-only capable port, a USB-IF compliant low speed device must enumerate properly when connected to a downstream port.
    • Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
    • 1.2.4 When a hub's upstream port is connected to a full/low speed-only capable port, the transaction translator must be disabled and must not be used. The hub repeater must operate as a full/low speed repeater.

  • General Device Detection

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.

    • 1.3.1 Bit 9 of the Port Status Bits should be set to one If and only if a low speed device is attached to the downstream port of a hub. Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
    • 1.3.2 Bit 10 of the Port Status Bits should be set to one if, and only if, a high speed device is attached to the downstream port of a hub that is operating in a high speed environment. Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
  • Port Indicators. The port indicators are optional for USB 2.0 hubs. However, if they are implemented all of the following assertions must be met.

    • 1.4.1 A hub must accurately indicate whether it supports port indicators through bit D7 of the wHubCharacteristics field of the hub class descriptor.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Sections 11.5.3, 11.23.2.1.

    • 1.4.2 If a high speed capable hub implements port indicators they must be as specified in the Universal Serial Bus Specification, Revision 2.0. Custom port indicators are not allowed.

      Reference document: Universal Serial Bus Specification, Revision 2.0.

    • 1.4.3 When a hub is suspended or not configured all of its port indicators must be off.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Sections 11.5.3, 11.23.2.1.

    • 1.4.4 When a hub makes the transition out of a not configured state, its port indicators must be in Automatic control mode (as defined in section 11.5.3 of the Universal Serial Bus Specification, Revision 2.0) by default.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3

    • 1.4.5 A hub port indictor must be off when it is under automatic control and the port is in the Suspended, Resuming, SendEOR, Restart_E, or Restart_S state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.6 A hub port indictor must be Green when it is under automatic control and the port is in the Enabled, Transmit, or TransmitR state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.7 A hub port indictor for a hub with Port Power Switching must be off when it is under automatic control and the port is in the Disconnected, Disabled, Not Configured, Resetting, or Testing state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.8 The following rule applies to a hub port indictor for a hub without Port Power Switching. It must be off or amber if there is an over-current condition when it is under automatic control and the port is in the Disconnected, Disabled, Not Configured, Resetting, or Testing state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.9 A hub port indictor for a hub with Port Power Switching must be off or amber if there is an over-current condition. This rule applies when it is under automatic control and the port is in the powered-off state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.10 A hub port indictor for a hub without Port Power Switching must be off when it is under automatic control and the port is in the powered-off state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.

    • 1.4.11 Bit 12 of a hub's Port Status bits must accurately indicate whether the port indicator is currently under Automatic or Software control.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.1.

    • 1.4.12 A port indicator must make the transition to manual mode and display amber in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 1.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 1.4.13 A port indicator must make the transition to manual mode and display green in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 2.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 1.4.14 A port indicator must make the transition to manual mode and display off in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 3.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 1.4.15 A port indicator must make the transition to automatic mode in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 0.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.

    • 1.4.16 A hub must respond to a Clear Port Feature command with feature selector PORT_INDICATOR by transitioning the port indicator for that port to Automatic Mode.

      Reference document: Universal Serial Bus Specification, Revision 2.0, 12/07/00 Errata.

  • Number of Transaction Translators. Reporting of Number of Transaction Translator in Implementation.

    • 1.5.1 A hub must implement either one transaction translator or one transaction translator per downstream port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, 11.14.1.3.

    • 1.5.2 A hub operating at full/low speed must set the bDeviceProtocol field of its Device_Qualifer Descriptor to 1 if its implements a single transaction translator or 2 if it implements one transaction translator per port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.5.3 A hub operating at high speed must set the bInterfaceProtocol field of its Interface Descriptor to 0 if its implements a single transaction translator or 1 if it implements one transaction translator per port.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.5.4 A hub operating at high speed that implements one transaction translator per port must provide an alternate setting for its interface with all fields identical to those for the default interface except for bInterfaceProtocol which must be set to 2.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.5.5 By default a hub with multiple transaction translators (1 per port) must only use one transaction translator (single TT mode by default).

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.5.6 A multiple transaction translator capable port (1 per port) must only use more than one transaction translator if its alternate interface setting is set through a SET_INTERFACE request. A hub with multiple transaction translators must support SET_INTERFACE when operating in a high-speed capable environment.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.5.7 A hub with multiple transaction translators (1 per port) must support GET_INTERFACE when operating in a high speed environment.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

  • Descriptors and Commands. Transaction Translator Commands and Transaction Translator Think Time.

    • 1.6.1 A hub must implement its Device, Device Qualifier, Configuration, Interface, Other Speed Configuration, and Endpoint descriptors when connected in a full speed electrical environment as specified in the Universal Serial Bus Specification, Revision 2.0.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.6.2 A hub must implement its Device, Device Qualifier, Configuration, Interface, Other Speed Configuration and Endpoint descriptors when connected in a high speed electrical environment as specified in the Universal Serial Bus Specification, Revision 2.0.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.

    • 1.6.3 A hub must respond to a valid Get_TT_State request with bits 0 to 15 of the TT_Return_Flags field set to zero.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.8.

    • 1.6.4 A transaction translator must return to its initial state after configuration in response to the Reset_TT request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.9.

    • 1.6.5 A transaction translator must halt operation in response to a valid Stop_TT request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.

    • 1.6.6 A transaction translator that has been stopped via a Stop_TT request must only resume operation after being reset through a Reset_TT request or an overall reset of the hub.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.

    • 1.6.7 A transaction translator must clear an asynchronous (non-periodic) buffer associated with the given endpoint in response to a valid Clear TT Buffer request.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.

    • 1.6.8 A transaction translator must treat an otherwise correct Clear_TT_Buffer response that specifies a non-existent transaction as a functional no-op.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.

    • 1.6.9 A transaction translator must accurately indicate its worst case Think Time to advance to the next full/low speed transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.

    • 1.6.10 A multi-TT hub must respond with a Request Error to a Clear TT Buffer, Stop TT, Reset TT, or Get TT State request with an invalid port number. A single TT hub must respond with a Request Error to a Clear TT Buffer or Get TT State request with an invalid port number. A single TT hub may ignore the port number in Stop TT and Reset TT requests.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.

    • 1.6.11 A hub must respond with a Request Error to a Clear TT Buffer, Stop TT, Reset TT, or request with an incorrect wLength field.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.

    • 1.6.12 A hub must support the PING protocol on its control endpoint. This includes the possibility of a host that PINGs before attempting an OUT transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 8.5.1.1.

    • 1.6.13 The bHubContrCurrent field in the hub descriptor must indicate the current draw of the hub circuitry from VBUS. It must not include the current draw of any embedded downstream devices.

      Reference document: WLP# B2.6.4.6. Note: This is currently a proposed erratum to the Universal Serial Bus Specification, Revision 2.0. The current (as of 3/29/02) specification does not clearly define the meaning of this field.

    • 1.6.14 A TT that has been stopped with a Stop TT command must continue to generate SOFs to enabled downstream ports under its control.

  • USB 2.0 Test Modes Assertions

    Reference document: WLP# B2.6.4.6. Note: This is currently a proposed erratum to the Universal Serial Bus Specification, Revision 2.0. The current (as of 3/29/02) specification does not clearly define the meaning of this field.

    • 1.7.1 A hub must place its upstream port in test mode TEST_J in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_J.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.

    • 1.7.2 A hub must place its upstream port in test mode TEST_K in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_K.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.

    • 1.7.3 A hub must place its upstream port in test mode TEST_SEO_NAK in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_SEO_NAK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.

    • 1.7.4 A hub must place its upstream port in test mode TEST_PACKET in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_Packet.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.

    • 1.7.5 A hub must respond with a request error to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_Force_Enable.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.9, 7.1.20.

    • 1.7.6 Once a hub has its upstream port in a test mode it must only exit the test mode if the power is cycled for the hub.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.

    • 1.7.7 A hub must transition a downstream port out of test mode in response to a reset.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.8 A hub with a downstream port in a test mode must still report port disconnects or port resume status changes for all other downstream ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.9 A downstream facing port that has been placed in a test mode may only exit the mode when the hub is reset.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.

    • 1.7.10 A hub must place the designated downstream facing port in test mode TEST_J in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_J.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.11 A hub must place the designated downstream facing port in test mode TEST_K in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_K.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.12 A hub must place the designated downstream facing port in test mode TEST_SEO_NAK in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_SE0_NAK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.13 A hub must place the designated downstream facing port in test mode TEST_PACKET in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_Packet.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.14 A hub must place the designated downstream facing port in test mode TEST_Force_Enable in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_Force_Enable.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.

    • 1.7.15 A downstream port in test mode Test_Force_Enable must still indicate disconnect events.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.

    • 1.7.16 A hub must respond with a request error (STALL) to a CLEAR_FEATURE command with feature selector TEST_MODE.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 9.4.1.

    • 1.7.17 A hub must respond with a request error (STALL) to a CLEAR_PORT_FEATURE command with feature selector PORT_TEST.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.

Miscellaneous

  • Hub and Transaction Translator Requirements

    • 1.8.1 If a transaction translator is receiving a packet at EOF2 of the downstream facing bus it must disable the downstream facing port that is currently transmitting.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.

    • 1.8.2 If the transaction translator is transmitting a packet near EOF1 of the downstream facing bus it must force and abnormal termination sequence as defined in Section 11.3.3 of the Universal Serial Bus Specification, Revision 2.0 and stop transmitting.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.

    • 1.8.3 A port with a high-speed device connected must still indicate high-speed operation through descriptors when it is suspended and the device reverts to full speed terminations.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.5.1.9.

    • 1.8.4 If a hub misses Start-of-Frame (SOF) packets for three consecutive microframes when operating in a high speed environment it also loses synchronization for its full speed timers. Any transaction translators in operation must stop generating full speed SOF packets until synchronization is regained.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.5 Frame timers used by transaction translator units in hubs must maintain synchronization unless the hub microframe timer loses synchronization.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.6 If a hub misses Start-of-Frame (SOF) packets for three consecutive microframes when operating in a high speed environment it loses synchronization for its microframe timer and all related frame timers used by transaction translators.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.7 If a hub loses microframe synchronization its transaction translators must respond to periodic complete splits with results buffered in the periodic complete split pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.8 If a hub loses microframe synchronization its transaction translators must abort any buffered periodic start-split transactions in the periodic start split pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.9 If a hub loses microframe synchronization its high speed handler must ignore any high-speed periodic start splits.

    • 1.8.10 If a hub loses microframe synchronization its transaction translators must stop issuing low speed keep alive on any low speed enabled ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.11 If a hub loses microframe synchronization, its transaction translators must stop issuing full speed SOFs on any full speed enabled downstream ports.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.12 If a hub loses microframe synchronization, its transaction translators must not start issuing any subsequent periodic full/low speed transactions.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.13 If a hub loses microframe synchronization, its high-speed handler must respond to any high speed start splits for bulk/control transactions normally. (NAK if buffers full - place transactions in available non-periodic buffers as it normally would.)

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.14 If a hub loses microframe synchronization it must respond normally to any complete splits for bulk/control transactions.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

    • 1.8.15 If a hub loses microframe synchronization it must not issue any pending bulk/control transactions on the full/low speed bus. It must preserve the buffers for these transactions until synchronization is regained.

    • 1.8.16 A hub must repeat all high speed traffic, including start and complete splits, to all high speed enabled downstream ports. In particular, a hub may not prevent split traffic from reaching a hub further downstream with a full or low speed device connected.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.

Bulk and Control (Non-Periodic) Transfers. The following assertions use the notation described in the Universal Serial Bus Specification, Revision 2.0 to describe the possible states of a buffer for a bulk or control transfer being executed through a transaction translator.

  • General

    • 2.1.1 A transaction translator must have at least two bulk/control transaction buffers. Each one must be capable of holding the Start Split and related data for an OUT or data from the full/low speed bus for an IN.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.

    • 2.1.2 If the transaction translator has an available Non-Periodic buffer (not in the Ready/X or Pending state) the high speed handler must accept the Start Split for a bulk or control transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.

    • 2.1.3 If the transaction translator does not have an available Non-Periodic buffer (not in the Ready/X or Pending state) the high speed handler must NAK the start split for a bulk or control transfer.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.

    • 2.1.4 If the high speed handler for a transaction translator times out or receives a CRC error anywhere in the <Start Split - Token - Data> sequence for a bulk or control transfer it must timeout and not buffer the transaction in one of its non-periodic buffers.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.

    • 2.1.5 If the high speed handler for a transaction translator times out or receives a bad CRC anywhere in the <Complete Split - Token> sequence it must time out and not respond.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.1.6 If a full or low speed non-periodic transaction results in a NAK, STALL, or ACK response the transaction translator must update the transaction buffer to the corresponding status and must not retry the transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.1.7 A full or low speed non periodic transaction that produces a timeout or transaction error must be retried locally by the transaction translator.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.1.8 A full or low speed non-periodic transaction must not be tried more than three times locally by the transaction translator.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.1.9 A full or low speed non periodic transaction that has been tried three times locally by the transaction translator without success must be resolved to a STALL response.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.1.10 The integrity of all data associated with non periodic transactions must be preserved as it is transferred into and out of any of the non-periodic buffer space used by the transaction translator.

  • Control Transactions

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.1 The high-speed handler for a transaction translator receives a Start Split for a control transfer to an endpoint. There is already a control transaction for that endpoint whose non-periodic buffer is in the pending or ready/x state. In this case, the transaction translator must respond with an ACK but disregard the information.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.2 If the high speed handler for a transaction translator receives a Start Split for a control transfer and already has a non-periodic buffer in the old/x state for the same endpoint it must re-use the same buffer for the new transaction.

    • 2.2.3 If the high speed handler for a transaction translator receives a Complete Split for a control transfer and has a non-periodic buffer for the same endpoint in the pending state it must respond with a NYET handshake.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.4 If the high speed handler for a transaction translator receives a complete split for a control transfer and does not have a non-periodic buffer for that endpoint it must respond with a STALL.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.5 The high-speed handler for a transaction translator receives a complete split for a control transfer. If it has a non-periodic buffer for the same endpoint in the ready/STALL state, it must return STALL and transition the buffer to the old/STALL state.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.6 If the high speed handler for a transaction translator receives a complete split for a control transfer and has a non periodic buffer for the same endpoint in the old/STALL state it must return STALL.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.7 The high speed handler for a transaction translator receives a complete split for a control OUT transfer. If it has a non-periodic buffer for the same endpoint in the ready/ACK state it must return ACK and transition the buffer to the old/ACK state.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.8 If the high speed handler for a transaction translator receives a complete split for a control OUT transfer and has a non-periodic buffer for the same endpoint in the old/ACK state it must return ACK.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.9 The high speed handler for a transaction translator receives a complete split for a control IN transfer. If it has a non-periodic buffer for the same endpoint in the ready/DataX state it must return DataX and transition the buffer to the old/DataX state.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.10 If the high speed handler for a transaction translator receives a complete split for a control IN transfer and has a non periodic buffer for the same endpoint in the old/Data state it must return Data.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.11 The high speed handler for a transaction translator receives a complete split for a control transfer. If it has a non-periodic buffer for the same endpoint in the ready/NAK state it must return NAK and transition the buffer to the old/NAK state.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.12 If the high-speed handler for a transaction translator receives a complete split for a control transfer and has a non periodic buffer for the same endpoint in the old/NAK state, it must return NAK.*

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.13 A transaction translator must correctly handle full speed control transfers in both directions of up to 64 bytes.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.2.14 A transaction translator must correctly handle low speed control transfers in both directions of up to 8 bytes.

      Note The USB core specification stipulates that direction should not be checked as part of buffer matching for control endpoints. Some vendors have implemented checking that does not match for Setup/In, Setup/Out, Out/In mismatches. These implementations are also acceptable.

  • Bulk Transactions

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.1 The high speed handler for a transaction translator receives a Start Split for a bulk transfer. If there is already a buffer for that endpoint and direction already in the pending or ready/x state it must respond with an ACK but disregard the information.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.2 The high speed handler for a transaction translator receives a Start Split for a bulk transfer. If it already has a non-periodic buffer for that endpoint and direction in the old/x state it must re-use the same buffer for the new transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.3 The high speed handler for a transaction translator receives a Complete Split for a bulk transfer. If it already has a non-periodic buffer for the same endpoint and direction that is in the pending state it must respond with a NYET handshake.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.4 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it does not have a non-periodic buffer for that endpoint and direction it must respond with a STALL.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.5 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/STALL state it must return STALL and transition the buffer to the old/STALL state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.6 If the high speed handler for a transaction translator receives a complete split for a bulk transfer and has a non periodic buffer for the same endpoint and direction in the old/STALL state it must return STALL.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.7 The high speed handler for a transaction translator receives a complete split for a bulk out transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/ACK state it must return ACK and transition the buffer to the old/ACK state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.8 If the high speed handler for a transaction translator receives a complete split for a bulk out transfer and has a non periodic buffer for the same endpoint and direction in the old/ACK state it must return ACK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.9 I The high speed handler for a transaction translator receives a complete split for a bulk in transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/Data state it must return Data and transition the buffer to the old/Data state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.10 If the high speed handler for a transaction translator receives a complete split for a bulk in transfer and has a non periodic buffer for the same endpoint and direction in the old/DataX state it must return DataX.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.11 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/NAK state it must return NAK and transition the buffer to the old/NAK state.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.12 If the high speed handler for a transaction translator receives a complete split for a bulk transfer and has a non periodic buffer for the same endpoint and direction in the old/NAK state it must return NAK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.

    • 2.3.13 A transaction translator must correctly handle full speed bulk transfers in both directions of up to 64 bytes.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 5, 11.

  • Isochronous and Interrupt (Periodic) Transfers. In the following assertions, the high-speed bus microframes are referenced as follows:

    | Y0 | Y1 | Y2 | Y3 | Y4 | Y5 | Y6 | Y7 |

    Frame X-1 Frame X

    • 3.1.1 A transaction translator must be able to receive and correctly buffer up to 16 start splits for periodic transfers in a single microframe.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.4.

    • 3.1.2 When the high speed handler of a transaction translator receives a valid Start Split for a periodic transaction, it must place the start split into the start split pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.4.

      9.29.1.29 Isochronous Transaction Protocol Test, TD-9.29.1.30 Interrupt Transaction Loopback Test

    • 3.1.3 The high speed handler must accept and handle all valid Start Splits for periodic transfers received in any microframe except during microframe Y6.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.

    • 3.1.4 The transaction translator must not start any periodic transaction on the full/low speed bus during the same microframe the Start Split for that transaction arrived.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.

    • 3.1.5 The transaction translator (high speed handler) must never send any response packet to a periodic start split.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.

    • 3.1.6 The transaction translator (high speed handler) must place periodic start splits in the start split pipeline in the order in which they are received.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.3.

    • 3.1.7 The transaction translator (high speed handler) must execute periodic transactions on the full/low speed bus in the same order as the start splits in the microframe pipeline.

  • Abort Rules - Section 11.18.6.1

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.3.

    • 3.2.1 If a full or low speed periodic transaction is in progress when EOF occurs, it must be aborted by the transaction translator.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.

    • 3.2.2 If an interrupt transaction is in progress and the microframe timer indicates microframe X+4, where X is the microframe in which the start split for the transaction arrived, it must be aborted.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.

    • 3.2.3 If a periodic transaction is aborted it must not have a complete split response in the complete split stage pipeline. This means that the transaction translator will respond with a NYET to any Complete Splits for the transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.

    • 3.2.4 When a transaction translator aborts a periodic IN transaction, it must not issue the handshake packet for the transaction on the full/low speed bus.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.

    • 3.2.5 When a transaction translator aborts an OUT transaction and is in the middle of a DATA packet, it must stop issuing data bytes and force a bit stuffing error on the downstream facing bus.

  • Free Rules - Section 11.18.6.2

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.

    • 3.3.1 If a periodic start split received in microframe X has still not been executed when the microframe timer indicates the X+4 microframe it must be removed from the start split pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.2.

    • 3.3.2 All start splits in the start split pipeline for unexecuted transfers, except those received in microframe Y7 must be removed from the start split pipeline at the beginning of a new full speed frame.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.2.

    • 3.3.3 The entry for a transaction in the periodic Complete Split pipeline must only live for one microframe after the transaction is executed on the full/low speed bus. At the beginning of the second microframe after the execution the buffer space in the complete split transaction pipeline must be freed for re-use.

  • Complete-Split Pipeline Search Rules - Section 11.18.8

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.7.

    • 3.4.1 If the high speed handler for a transaction translator receives a periodic complete split that matches the first entry of the complete split pipeline the handler must respond with the indicated data and/or status.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.2 The high speed handler for a transaction translator receives a periodic complete split that matches the first entry in the complete split pipeline multiple times. In this case it must continue to respond with the indicated data and/or status until it receives a periodic complete split for a different transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.3 If the high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline it must search all other entries in the complete split pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.4 The high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline and does not find a match in the pipeline. In this case it must return the pipeline to its state at the start of the search and return NYET.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.5 If the high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline it must search all other entries. If it finds a match it must advance the pipeline to the matching transaction and free all entries it passes in the advance. It must return the status and/or data for the matching entry.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.6 If the high-speed handler receives a first periodic complete split for a transaction and has not finished searching the periodic complete split pipeline for a match, it must not respond to the complete split and continue to search for the match. It must respond correctly to the next complete split for the transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.

    • 3.4.7 The transaction translator must not start a periodic transaction until it has space available in the complete split pipeline stage to hold the results of the transaction.

  • Interrupt Transactions - Sections 11.20.x

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.3.

    • 3.5.1 A transaction translator must never locally retry an interrupt transfer on the full/low speed bus.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.

    • 3.5.2 If the high speed handler for a transaction translator receives a complete split for an interrupt transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/NAK state it must return NAK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.3 If the high speed handler for a transaction translator receives a complete split for an interrupt transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/STALL state it must return STALL.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.4 The high speed handler for a transaction translator receives a complete split for an interrupt transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/trans_err state it must return ERR.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.5 If the high speed handler for a transaction translator receives a complete split for an interrupt OUT transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/ACK state it must return ACK.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.6 The high speed handler for a transaction translator receives a complete split for an interrupt IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/DATAX state it must return DATAX.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.7 The high speed handler for a transaction translator receives a complete split for an interrupt IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/MDATA state it must return MDATA.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.8 If the full/low speed CRC check fails, an ERR handshake must be returned to the host for the transaction by the transaction translator. No data can be returned for the current microframe.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.9 The full/low speed CRC must not be returned in response to a complete split for an interrupt IN transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.5.10 The full/low speed interrupt IN transaction is still in progress at a microframe boundary and at least 3 data bytes have been received. In this case, the transaction translator must update the appropriate complete split pipeline entry with the current data except the latest two bytes and place the entry in the old/MDATA state. It must not perform a full/low speed CRC check. The transaction translator is allowed to carry forward up to the last 6 bytes in the microframe (2 bytes for the potential CRC plus up to an additional 4 bytes).

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)

    • 3.5.11 The full/low speed interrupt IN transaction is still in progress at a microframe boundary and less than 3 data bytes have been received. In this case the transaction translator must return NYET to the corresponding complete split. The transaction translator may return NYET and carry forward up to the first 6 data bytes.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)

    • 3.5.12 A transaction translator returns MDATA for the complete split for an Interrupt IN. It must return the remaining data with the appropriate DATA0/1 PID or ERR if the CRC check fails in response to the next complete split for that endpoint and direction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4.

    • 3.5.13 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout in the Start Split - IN sequence for an interrupt IN transaction. In this case it must disregard the start split and not place it into the Start Split microframe pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.5.14 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout in the Start Split - OUT - DATA/X sequence for an interrupt OUT transaction. In this case it must disregard the start split and not place it into the Start Split microframe pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.5.15 If the full/low speed transaction completes before the end of a microframe (no matter how close to the end) the transaction translator must return all data in response to the complete split in the next microframe.

  • Isochronous Transactions - Sections 11.21.x

    Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.6.1 A transaction translator must never locally retry an isochronous transfer on the full/low speed bus.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.6.2 The high speed handler for a transaction translator receives a timeout, bit stuffing error, or CRC error in the Start Split-all - OUT - DATA sequence for an isochronous OUT. In this case it must disregard the start split and not attempt the transaction on the full/low speed bus.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.6.3 If the high speed handler for a transaction translator receives a timeout, bit stuffing, or CRC error anywhere in the Start Split-begin - OUT - DATA sequence for an isochronous OUT it must disregard the Start Split and not attempt the transaction on the full/low speed bus.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.4 The high speed handler receives an error or times out in the Start Split-begin - OUT - DATA sequence. In this case it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.5 The transaction translator must generate the full/low speed CRC for all Isochronous OUT transactions that it generates.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.6 If the transaction translator receives a Start Split-begin for an Isochronous OUT transaction it must start the transaction on the full/low speed bus and continue to look for isochronous OUT start splits to the same endpoint in each subsequent microframe.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.7 The transaction translator does not receive a Start Split-middle or Start Split-end in a successive microframe after receiving a Start Split-begin for an isochronous OUT endpoint. In this case, it must force a bit stuff error in full/low speed transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.8 The high speed handler does not receive a Start Split-middle or Start Split-end in an expected microframe. In this case it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.9 The transaction translator receives a Start Split-middle or Start Split-end with a bad CRC in a successive microframe after receiving a Start Split-begin for an isochronous OUT endpoint. In this case it must force a bit stuffing error on the full/low speed transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.10 If the high speed handler receives a Start Split-middle or Start Split-end with an error it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.11 The high speed handler receives a Start Split-middle or Start Split-end for an Isochronous OUT transaction and does not already have a full/low speed transaction pending for that endpoint. In this case, it must disregard that Start Split and any subsequent Start-Split middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.

    • 3.6.12 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout anywhere in the Start Split - IN sequence for an isochronous IN transaction it must disregard the start split and not place it into the Start Split microframe pipeline.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.6.13 The transaction translator must never return the full/low speed CRC as part of the data for an isochronous IN transaction.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.4.

    • 3.6.14 The high speed handler for a transaction translator receives a complete split for an isochronous IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/DATAX state it must return DATAX.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.6.15 The high speed handler for a transaction translator receives a complete split for an isochronous IN transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/Trans_err state. It must return ERR.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.

    • 3.6.17 A full speed isochronous IN transaction is still in progress at a microframe boundary and at least three data bytes have been received. In this case, the transaction translator must update the appropriate complete split pipeline entry with the current data except the latest two bytes and place the entry in the old/MDATA state. It must not perform a full speed CRC check. The transaction translator is allowed to carry forward up to the last 6 bytes in the microframe (2 bytes for the potential CRC plus up to an additional 4 bytes).

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)

    • 3.6.18 A full speed isochronous IN transaction is still in progress at a microframe boundary and less than 3 data bytes have been received. The transaction translator must return NYET to the corresponding complete split. The transaction translator may return NYET and carry forward up to the first 6 data bytes.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)

    • 3.6.19 If the full/low speed transaction completes before the end of a microframe (no matter how close to the end) the transaction translator must return all data in response to the complete split in the next microframe.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.

    • 3.6.20 The TT high-speed handler must return isochronous data with the same data toggle used by the device. Alternately, the TT high speed handler may always use DATA0.

      Reference document: Universal Serial Bus Specification, Revision 2.0, proposed errata as of 3/29/02.

General Transaction Translator (HUB) Data Integrity

  • General Host Controller Interaction Assertions

    • 3.7.1 A USB 2.0 hub must not corrupt data moving from a host system to any USB device.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.

      9.29.1.30 Interrupt Transaction Loopback Test, TD-9.29.1.31 Isochronous Transaction Loopback Test

    • 3.7.2 A USB 2.0 hub must not corrupt data moving from any USB device into the host.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.

      9.29.1.30 Interrupt Transaction Loopback Test, TD-9.29.1.31 Isochronous Transaction Loopback Test

Transaction Translator Full/Low Speed Transaction Scheduling

  • Transaction Scheduling Assertions

    • 3.8.1 The transaction translator full/low speed handler must start executing the next periodic full/low speed transaction for the current microframe whenever it is idle.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.14.2.3.

    • 3.8.2 Whenever the transaction translator full/low speed handler is idle, and there are no periodic transactions available, it must execute an available non-periodic transaction selected in round robin fashion. It must only execute a non-periodic transaction if it can be finished before the end of the current full speed frame. For IN transactions this calculation must be made using the maximum transaction size.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Section 11.14.2.3.

Multiple Stream Interoperability

  • Transaction Scheduling Assertions

    • 3.9.1 The transaction translator must correctly process all valid combinations of periodic and non-periodic transactions running in unison.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.

    • 3.9.2 The transaction translator must correctly process all valid combinations of non-periodic transactions running in unison.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.

    • 3.9.3 The transaction translator must correctly process all valid combinations of periodic transactions running in unison.

      Reference document: Universal Serial Bus Specification, Revision 2.0, Chapter 11.


USB System Port Presence Test

Type: Automated Test

Overview

The USB System Port Presence Test determines whether a system contains one or more USB root hubs or standard hubs. The system must contain at least one USB root hub and a total of two USB ports besides those that are used for a USB pointing device or USB keyboard. The test queries the system for USB root hubs through the USB software stack. The query determines whether there are at least two ports in the system besides the keyboard or pointing device ports and that they conform to the Windows Logo Program basic requirements. For mobile systems, one port is required.

Details

The test program queries each of the USB hubs through the USB software stack to determine how many ports are present in the system. The test software issues a Device GetDescriptor to get the device capabilities of the hubs. The following fields are returned and examined.

Offset | Field | Description
1 | bDescriptorType | 29h indicates a hub descriptor
2 | bNbrPorts | Number of downstream ports that this hub supports
7 | DeviceRemovable | Indicates if a port has a removable device attached

The descriptor value must be 29h (or 09h) to indicate that the device is a hub. The port number and the DeviceRemovable bitmap vector for each hub are used to calculate the total number of removable ports in the system. There must be at least two ports in the system that supports removable devices. For mobile, there must be at least one port that supports removable devices.

The test software then issues a GetPortStatus for each port that supports removable devices on the hubs in the system. The port should show the following bits in the status field.

Field | Value
PORT_CONNECTION | Not Connected
PORT_ENABLE | Not Enabled
PORT_SUSPEND | Not Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | N/A

This state is the normal state for the hub and port to accept new device connections. Every removable port that does meet these requirements is not available and does not count towards the port requirement (2 ports for desktop and 1 for mobile).

After this process is complete, you are asked to connect a device to each port that indicates it is available. If you cannot connect a device to any of these ports, it does not count towards the port requirement (2 ports for desktop and 1 for mobile).

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • USB System Software does not load correctly and enable the host controllers.

  • System does not support at least two (one on mobile) available downstream ports besides those used by USB keyboards and pointing devices. The following advisory information is provided as applicable.
    • Content of each hub descriptor.
    • Content of each port status descriptor.

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested

  • Computer that meets the minimum software requirements

  • Windows keyboard

  • Two-button pointing device

  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz

  • Hard drive with a minimum of 20 GB available on partition C:

  • Two USB devices. Only one USB device is required for mobile testing

  • One USB 2.0 controller PCI adapter, if system does not contain a USB 2.0 controller

Processor

The test tool runs on the following processor architectures:

  • x86

  • x64

  • Itanium


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, and so on).

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

Program:

Requirements

Software Requirements

The test tool requires the following software:

  • Supported operating system (see list above)

  • Software components included with the device that is being tested

Hardware Requirements

The test tool requires the following hardware:

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Processor

The test tool runs on the following processor architectures:

  • 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 list 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 (alphanumeric and underscore)
/and | ASCII only directory names (alphanumeric 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


Video Acceleration - Bad Data (DEPRECATED)

Overview

TBD

Details

TBD

Run Time:
Log File:
System Restart Required:
Test Category:

Supported operating systems for Logo or Signature testing:

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:


YUV Blt 9 Test (DEPRECATED)

Overview

TBD

Details

TBD

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Test Assertions

Test Assertion GUID:
Windows Logo Program: GRAPHICS-0032 Display WDDM driver supports the DirectX VA 2.0 Video Processor DDI
Additional Information:


YUV Blt Test (DEPRECATED)

Overview

Details

Run Time:
Log File:
System Restart Required:
Test Category:
Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Server 2008 R2

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:

  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements
  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

Test Assertions

Test Assertion GUID:
Windows Logo Program: GRAPHICS-0032 Display WDDM driver supports the DirectX VA 2.0 Video Processor DDI
Test Assertion GUID:
Windows Logo Program: GRAPHICS-0012 Display WDDM driver supports the DirectX VA 2.0 Video Processor DDI


Glossary

Send comments about this topic to Microsoft

Build date: 2/10/2011

© 2011 Microsoft Corporation. All rights reserved.


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. 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

See also execution agent (EA).

execution agent (EA)

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.


Topic Not Found

The requested topic was not found. The following are possible causes and solutions.

  • Cause: The topic has a bad link.

    Solution: Send feedback about the topic. To provide feedback for a topic on the MSDN site, go to the page and click "Click to Rate and Give Feedback". To provide feedback for an offline topic, go to the page and click "Contact Us".

  • Cause: You are using a local installation of the MSDN Library, but you did not install the component that contains the topic.

    Solution: Install the complete SDK documentation using the latest MSDN CD.

  • Cause: You are using a local installation of the SDK, but you did not install the component that contains the topic.

    Solution: Install the complete SDK documentation from the latest SDK.

Note that you can also download the latest SDK documentation from the Microsoft Download Center or view the SDK online on MSDN.