当您在DTM测试中遇到测试失败的Job时，如何定位DTM故障，并进行DTM故障排除，以下我们将给出一些指导信息，这些将有助于您完成并通过在Windows Logo Kit (WLK)的DTM测试，这是为您解决DTM测试失败的故障排除指导。
DTM故障分析：错误项重新运行
大多数的DTM测试都是自动运行一次的，再次测试可以帮助您专注于测试Job本身，有助于检查Job测试的整个过程。一些测试失败的原因可能是由意外引起。您可以尝试多运行几次，只要通过一次，即被视为测试项通过。
一个典型的DTM测试Job包括以下的测试步骤：
- 拷贝测试二进制文件到DTM Client
- 执行测试二进制文件或者进行其他测试Job
- 收集测试日志并且拷贝它们到DTM Controller
- 清理DTM Client（删除在DTM Client上的二进制文件和日志）
在JOB Monitor窗口下，从Job Pool中选出失败的测试，然后定位到Task pool。检查失败的Task Execution Type。对于“Regular”task,您可以查看task日志，或右键单击task图标查看该Job的child jobs。
在查看Child Job的时候，您可以右击task图标查看child job的任务日志。
如果该次测试没有测试日志，它可能发生过一次蓝屏故障。此时您可以在Startup and Recovery对话框禁用automatically restart选项，在Control Panel -> System Properties -> Advanced选项卡对该项进行设置。对蓝屏故障进行深入的了解，请参阅使用WinDBG工具调试驱动问题。
当您再次测试时，您可以从中得到更多的信息来帮助您分析失败的根本原因，以及解决办法。
其他DTM故障排除方式: 手动验证
对于一些测试，如果知道测试的目的和内容，您可以进行手动测试。例如，Sleep stress测试，进行一系列的待机测试，唤醒，休眠和唤醒的周期，用来去验证休眠功能。您可以打开Start menu -> Shutdown -> Stand by或Hibernate然后机器就会进行手动验证。如果在休眠功能的测试上出了问题，您可以从中找出失败的详细原因。
对于一些测试，您可以从DTM Controller拷贝一些二进制文件到DTM Client，尝试用其它的命令行运行这些二进制文件，这将有助于您找出失败的根本原因。
如果您使用的是DTM的默认安装路径，所有的测试任务都会位于DTM Controller下的“C:\Program Files\Microsoft Driver Test Manager\Tests”。 一些测试二进制代码在很大程度上依赖于其它组件，所以您必须拷贝所有相关的文件到测试机上。您可以查看测试任务以理解测试文件之间的依赖关系。
要查看任务的详细情况，请点击在DTM Studio下的Explorer -> Job Explorer。
- DTM故障分析排除指导要排除设备影响
一些测试依赖于某些特定的硬件和软件。在您进行一项新的测试之前，阅读DTM的帮助文件可以帮助您知道测试过程中对硬件和软件的要求。
例如，大多数的USB设备测试，需要把测试的USB设备连接到一个USB 2.0 Hi-speed Hub上，然后将USB 2.0 Hi-speed Hub连接到DTM Client进行测试。在音频测试时，您必须使用音频回路线。所以您可以尝试更换USB Hub，音频线，网线或网络交换机，以消除可能造成的设备故障，然后再次进行测试。进行设备的测试时，您可以尝试更换另外一台有Windows徽标的PC。
在菜单上点击help -> Contents，您就可以阅读在DTM Studio的帮助文件。此外，如果您使用的是DTM Studio的默认安装路径，您还可以在DTM Studio上的“C:\Program Files\Microsoft Driver Test Manager\Studio\Docs”路径下获得帮助文件wtt.chm。
使用WinDBG工具调试驱动程序
如果您进行驱动的可靠性测试时，发现不能找到测试日志，例如 Device path Exerciser, Disable Enable with IO, Plug and Play Driver Test,和 Common Scenario Stress with IO, 此时您需要确认，当驱动可靠性测试运行时是否发生过蓝屏。
如果系统停留在蓝屏页面，需要您在测试机的系统属性里禁用了自动重启选项。当出现蓝屏时，您可以从蓝屏中看到一个以" 0x "为前缀的错误代码和一个模块名称，大多时候，这个模块的名称就是所测试的驱动的名称。
WinDBG是运行在Windows系统下有强大调试功能的图像界面驱动调试工具，可以有效的解决调试驱动的问题。WinDBG有x86和x64平台的不同版本。WinDBG可以帮助您查看源代码，设置断点，查看变量（包括C++对象），堆栈，和内存。
在Microsoft的网站上您可以免费下载到最新版本的WinDBG。下载页面是：http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
对于kernel-mode程序的调试， WinDBG通常需要两台电脑（主机和客户端），Debug串口调制线， IEEE 1394或USB连接线。通过USB设备进行的调试只能在Windows Vista下使用。
WinDBG使用的是 Microsoft Visual Studio 对符号文件进行源码级的调试。它可以访问任何公共函数名和变量所暴露出来的模块，它被编译为Codeview (.pdb)符号文件。所以在您调试之前必须准备相关符号文件与驱动程序二进制文件。在unclassified提交过程中，符号文件是必须的。
想进一步了解WinDBG ，请访问下面的网址：
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
- 同类别的不同设备的比较如果您有一台已经通过DTM测试的设备，您可以比较一下测试失败的设备和通过测试的设备之间有什么不同。两个设备之间的不同之处可能就是测试失败的原因。
WHQL DTM故障分析排除指导扩展阅读：
问：我需要对一款USB产品做WHQL DTM测试。但是我按照安装步骤在windows2003上面装好，在需要认证的系统上也装好了clint ~但是开始测试的时候，我将状态选成reset之后，它状态不会变化成running，最后测试也失败了~请教一下高手，希望能不吝赐教！
答：配合Windows 7进行系统徽标测试的WLK1.4新增了2个音频相关的测试，Round Trip Test和Class Driver Round Trip Test。
这2个新的测试项目替代了Windows 7之前徽标测试工具中的Full Duplex Test。
Round Trip Test和Class Driver Trip Test的差异是后者使用Windows操作系统内置驱动程序进行测试，前者使用被测试系统实际安装的音频驱动程序进行测试。如果被测试系统未安装第三方音频驱动程序的话，实际上二者的测试是一模一样的。
Round Trip测试由2个主要部分组成，一个是回路检测，另一个是空口测试。
该测试工具的最初版本有一些问题，最好在测试过程中，将所有的音频端口都接上音频插头，以避免测试工具错误地判断音频端口的工作状态。这个问题也有相应的Errata Filter和QFE升级包来解决。
