USB 2.0 & 3.0 SCSI Compliance test for UAS on EHCI (LOGO)
This test verifies Small Computer System Interface (SCSI) Command Descriptor Blocks (CDBs) sent to the Universal Serial Bus (USB) UAS device.
Test details
| Specifications |
|
| Platforms |
|
| Supported Releases |
|
| Expected run time (in minutes) | 5 |
| Category | Compatibility |
| Timeout (in minutes) | 300 |
| Requires reboot | false |
| Requires special configuration | false |
| Type | automatic |
Additional documentation
Tests in this feature area might have additional documentation, including prerequisites, setup, and troubleshooting information, that can be found in the following topic(s):
Running the test
Before you run the test, complete the test setup as described in the test requirements: Hard Disk Drive Testing Prerequisites.
In addition this test requires a UAS device connected to a USB 2.0 Controller.
Troubleshooting
For generic troubleshooting of HLK test failures, see Troubleshooting Windows HLK Test Failures.
For troubleshooting information, see Troubleshooting Device.Storage Testing.
Also, the test writes the results to the log files Scsicompliance.wtl and Scsicompliance.wtl.txt. You can 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.
Note
Errors from this test occur via issues identified in the log file and in bugchecks produced through stressing the driver under test.
During the test, if you are having trouble removing a LUN that is failing or are unable to create a LUN from the storage controller, follow these steps:
Prior to running this test, verify that the storage device works properly. Open diskmgmt.msc, select the disk, and make sure that you can put the device Online and in Initialized state.
Restart the Windows HLK test computer.
Select and rerun the SCSI Compliance Test 2.0. Do not run any test before it.
Run the SCSI Compliance Test (not the SCSI Compliance Test 2.0 (LOGO)) on the same test client and same test storage device. If the test fails again, verify that the storage device is working properly.If the test fails during steps 3 and 4, run the individual failing command data blocks (cdbs) one at a time with the logging verbosity level set to 4 (the highest level of test logging). This will show what data was sent and what data was returned. A test can fail after several cdbs are completed but pass standalone. If this occurs, there is a problem in the firmware or the test.
If you have a device reset that results in the device falling off the bus and subsequent commands to fail, follow these steps:
Copy the test binary (Scsicompliance.exe) from the Windows HLK controller. This file is located at \\controllername\tests\[processorarchitectureofyourclient]\NTTEST\DriversTest\storage\wdk\
Copy the wttlog.dll file from the Windows HLK controller. This file is located at \\<controllername>\Tests\<processorarchitectureofyourclient>\wtt
Place both of these files on the test computer in a separate folder.
From a command prompt, from the directory containing the test binary, type the following command: Scsicompliance.exe /device <deviceID> /verbosity 4 /operation test /scenario <scenario> /CDB <failingcdbname>
Note
DeviceID and scenario values can be found by checking the repro line within the test log. The failingcdbname can be found by running the test binary with the /?option (scsicompliance.exe /?).
Go back to the same directory and review the results to see if you can determine the reason for the test failure.
If you need additional help, collect the txt and wtl logs and share the logs with Microsoft Customer Support.
More information
Run the test as an HLK Manager job.
Command syntax
| Command option | Description |
|---|---|
Scsicompliance.exe |
The options for the test are listed below |
/device |
The device which test is to run on Example: /Device <physical device path> |
/operation |
The operation to runExample: /Operation Test |
/scenario |
The feature to be tested forExample: /Scenario Common |
/version |
Device's USB Version numberExample: /version 3 |
/protocol |
Device's USB protocolExample: /protocol UAS |
/verbosity |
The level of logging verbosity. Larger values cause more verbose output.Example: /Verbosity 4 |
Note
For command-line help for this test binary, type /?.
File list
| File | Location |
|---|---|
Scsicompliance.exe |
<[testbinroot]>\nttest\driverstest\storage\wdk\nttest\ |
Parameters
| Parameter name | Parameter description |
|---|---|
| DiskDeviceObjLink | Device path of disk to test EX: \\.\disk0 |
| WDKDeviceID | Instance path of device to test |
| LoggingVerbosity | LoggingVerbosity: Detail of logging. Levels are cumulative. 0 = Assertions and results. 1 = Details (default). 2 = CDBs , data, and sense info. 3 = Debug and detailed Mode page information. 4 = Memory usage |
| ScenarioId | Scenario test name: Possible values: USBDisk, USBCardReader |
| Options | Options |
| ScsiComplianceDevice | Device path |
| LLU_NetAccessOnly | User account for accessing test fileshare. |
| LLU_LclAdminUsr | User account for running the test. |
| OperationId | Operation to run |
| Version | USB Version: Possible values: 2, 3 |
| Protocol | USB Protocol: Possible values: BOT, UAS |
| QueryIsUsb3 | |
| QueryUAS | |
| QueryRMB | |
| Destructive | (0,1) 0=Passive, 1=Destructive |
| QueryUFDRotationalMedia | Queries gatherer to retrieve property |
| QueryWTGDevice | Queries gatherer to retrieve property |
| RM | Rotational media: 0 or 1 |