My first post concerns NDIS testing with the new "Driver Test Manager" (DTM), soon to be replaced with the new and improved "Windows Logo Kit". I have been spending more time than I would like re-imaging DTM Clients and sitting in front of the DTM Studio console.
Here are a few tips that may be obvious to many of you, but you may overlook in haste to get a test submitted:
Update Your DTM Client BIOS
When you purchased your DTM Client machine it may have been setting on the shelf for a while and your "brand new" machine may have a BIOS that is out of date. If the machine has been around for a while after you acquired it the BIOS may have gotten even further out of date.
In addition, if there is a new major operating system release (e.g., Windows Vista…) there may be BIOS fixes that are needed specifically to support the new OS.
Updating the BIOS may or may not really make any difference, but it is good insurance.
Finally, if you ask for support for problems related to PnP and power the support representative will often suggest that your problem is a BIOS problem. That still could be the case, but at least you can say that you are testing with the latest BIOS.
Remove Unnecessary Devices
Use minimal devices on your DTM Client machine. Install just what you need and nothing more. It's really frustrating to encounter a crash in an unrelated driver in the middle of a three hour test run. It ruins you day unnecessarily.
Use Windows Update on Your DTM Client
Examine "All Available Updates" and get the most recent drivers for your system. Insure that there are no banged-out devices in the Device Manager.
Review Network Settings
If your DTM Client is multi-homed (i.e., multiple network adapters) carefully examine your network settings. My experience has shown that if your DTM Client/DTM Controller network topology is not robust DTM may make a bad routing choice.
The effect that I saw when I overlooked this step was that DTM seemed to "run like molasses". Some tests would appear to run very slowly while others would be cancelled by the DTM because of timeout.
An operation like Preparing DTM Client for Submission would take almost an hour if network settings are messed up and only minutes if settings are OK.
Use a Debugger
With the current DTM it is often difficult to identify the actual cause of a test failure. Sometimes you can see the actual problem in the debugger much more easily than you can in the DTM Studio.
In addition, for some tests involving sleep transitions the debugger gives helpful insight into the state of the system.
Use Reimaging Tools
It is almost certain that tests will fail and you will have to start over. (And over, and over…)
So take a snapshot of your DTM Client image using a tool that can save a complete disk partition as a file.
You will probably have to re-image more often than you hope…
Some Advice from WHQL
The July 16, 2007 issue of the WHQL and Windows Logo Program Newsletter includes some advice on avoiding test failures. The newsletter can be found at the URL:
http://www.microsoft.com/whdc/whql/resources/news/WHQLNews_071607.htm
As of this date (July, 2007) there is no WHQL/WLK test for NDIS 5 Intermediate drivers. If you want to get a WHQL signature for a NDIS 5 IM driver you must use the "Unclassified" test from the WLK.Testing NDIS 5 Intermediate Drivers
No comments:
Post a Comment