일반적인 디바이스 기본 사항 안정성 테스트 실패 검토

  • 아티클

이 항목에서는 Windows HLK(Windows Hardware Lab Kit) 디바이스 기본 사항 안정성 테스트를 실행할 때 발생할 수 있는 일반적인 테스트 실패에 대해 설명합니다.

테스트가 HLK Studio에서 실패한 것으로 표시되지만 te.wtl 로그에는 통과 결과만 표시됨

테스트가 HLK Studio에서 실패한 것으로 표시되지만 te.wtl 로그에는 통과 결과만 표시되는 경우 다음 단계를 실행하여 실패의 원인이 된 오류를 가져올 수 있습니다.

  1. 마우스 오른쪽 단추로 빨간색 테스트 실행 아이콘을 클릭합니다.
  2. 오류를 선택합니다.

발생한 오류에 대한 설명이 포함된 대화 상자가 표시됩니다.

테스트 중 예기치 않은 다시 부팅이 발생하여 테스트에 실패함

오류 텍스트에 예기치 않은 다시 부팅이 발생했다고 나타나면 디바이스에서 운영 체제를 예기치 않게 다시 부팅(BSOD)했다는 의미일 수 있습니다. 이 실패를 진단하려면 디버거를 연결하거나 전체 메모리 덤프를 자동으로 생성하도록 테스트 머신을 구성하고 버그 확인을 조사합니다. 테스트 실패의 커널 디버깅을 시작하려면 커널 디버깅을 사용하여 디바이스 기본 사항 안정성 테스트 실패 디버그를 참조하세요.

설치하는 동안 디바이스 상태 확인 작업이 실패함

테스트가 시작되기 전에 디바이스가 미디어 또는 연결을 사용하여 제대로 설정되지 않았기 때문에 디바이스 상태 확인 작업이 실패하는 경우가 많습니다. 테스트를 위해 디바이스를 올바르게 구성하는 방법에 대한 자세한 내용은 Device.Fundamentals 안정성 테스트 필수 구성 요소를 참조하세요.

디바이스 상태 확인 작업은 모든 디바이스 기본 사항 안정성 테스트 작업의 설정 단계에 포함됩니다. DUT(테스트 대상 디바이스)가 작동 중 상태인지 확인할 수 있는 도구를 실행합니다. 실패하면 디바이스 문제를 나타내는 로그가 만들어집니다.

예를 들어 Bluetooth 디바이스의 경우 다음 오류가 발생할 수 있습니다.

PerformIO(Example ) Failed : Streaming error capturing audio HRESULT=0x8445001F Count 1

이 오류 메시지는 테스트하기 전에 오디오 제어판을 사용하여 Bluetooth 디바이스에 연결해야 함을 나타낼 수 있습니다.

다음 예제에서는 테스트 디바이스에서 문제 코드 A - CM_PROB_FAILED_START 상태를 보고합니다. 문제 코드 0(문제 없음)을 보고해야 합니다.

WDTF_TARGETS          : INFO  : - Query("IsPhantom=False AND (DeviceID='USB\VID_0BDB&PID_1917&CDC_0D&MI_06\6&2A131B9E&1&0006')")
WDTF_TARGETS          : INFO  : Target: F5321 gw Mobile Broadband Network Adapter USB\VID_0BDB&PID_1917&CDC_0D&MI_06\6&2A131B9E&1&0006 
WDTF_TEST             : ERROR : Found a device that has a non-zero problem code or is phantom. Logging device info.
WDTF_TEST             : INFO  : DeviceID:     USB\VID_0BDB&PID_1917&CDC_0D&MI_06\6&2A131B9E&1&0006
WDTF_TEST             : INFO  : DisplayName:  F5321 gw Mobile Broadband Network Adapter
WDTF_TEST             : INFO  : Status:       Status Flags=0x1802400 (DN_HAS_PROBLEM DN_DISABLEABLE DN_NT_ENUMERATOR DN_NT_DRIVER) Problem Code=a (CM_PROB_FAILED_START)
WDTF_TEST             : INFO  : IsPhantom:    False

"테스트 스레드가 시간 제한을 초과했습니다. 스레드를 종료하는 중입니다." 오류로 인해 디바이스 경로 연습기가 실패함

디바이스 경로 연습기 테스트 중에 테스트에서 테스트 스레드가 시간 제한을 초과했습니다. 스레드를 종료하는 중입니다. 오류를 기록하면 테스트에서 수행한 마지막 작업도 기록됩니다. 드라이버 개발자는 마지막으로 기록한 작업으로 인해 테스트가 중단되는 이유를 확인해야 합니다. 예:

WDTF_FUZZTEST : Test thread exceeded timeout limit. Terminating thread
WDTF_FUZZTEST : Last logged operation: ZwDeviceIoControlFile, CtrlCode=0x2b0020, InBuf=0xfffffc00, 0 OutBuf=0xfffffc00, 0

"IRP_MN_SURPRISE_REMOVAL을 받은 후에 IRP_MN_REMOVE_DEVICE를 받지 못했습니다."라는 오류 메시지와 함께 예기치 않은 제거 테스트가 실패함

PnP 관리자에서 예기치 않은 제거 IRP를 보낸 후에 제거 IRP를 테스트 디바이스 스택에 보내지 않으면 DF - PNP 예기치 않은 디바이스 제거 테스트가 다음 오류 메시지와 함께 실패할 수 있습니다.

"Failed to receive IRP_MN_REMOVE_DEVICE after receiving IRP_MN_SURPRISE_REMOVAL. Ensure that there are no open handles or references to the test device (in user mode or in kernel mode) preventing IRP_MN_REMOVE_DEVICE from being sent. You may need to terminate any processes or services that may have open user mode handles to this device."

디바이스에 대한 모든 미해결 파일 핸들이 닫힐 때까지 PnP 관리자는 IRP_MN_REMOVE_DEVICE 요청을 보내지 않습니다. 즉, PDO의 참조 수가 0에 도달할 때까지 PnP 관리자에서 IRP_MN_REMOVE_DEVICE 요청을 보내지 않습니다. IRP_MN_SURPRISE_REMOVAL 요청을 올바르게 처리하는 방법에 대한 내용은 IRP_MN_SURPRISE_REMOVAL 요청 처리를 참조하세요.

이 테스트 실패를 디버그하는 데 도움이 되도록 PDO(물리적 디바이스 개체)의 참조 수가 변경되는 방식을 확인해야 합니다. 참조 수를 변경하는 프로세스를 식별하고, 참조 수가 변경되면 나타나는 호출 스택의 상태를 검사합니다. 이 실패를 디버그하는 데 사용할 수 있는 단계는 다음과 같습니다.

  1. 아직 연결하지 않은 경우 커널 디버거를 테스트 컴퓨터에 연결합니다. 드라이버 배포를 위한 컴퓨터 구성, 테스트 및 디버깅을 참조하세요.

  2. ba(액세스 중단) 중단점을 테스트 디바이스의 PDO 참조 수가 저장된 위치에 설정합니다. 액세스 중단점에 대한 자세한 내용은 프로세서 중단점(ba 중단점)을 참조하세요. 다음 예제에서 !devnode 커널 디버거 명령은 USBvideo 드라이버의 devnode에 대한 정보를 가져옵니다. 이 devnode의 PDO 주소는 0x849e9648입니다.

    0: kd> !devnode 0 1 usbvideo
Dumping IopRootDeviceNode (= 0x848fadd8)
DevNode 0x849e9448 for PDO 0x849e9648
  InstancePath is "USB\VID_045E&PID_076D&MI_00\7&1243e0b7&0&0000"
  ServiceName is "usbvideo"
  State = DeviceNodeStarted (0x308)
  Previous State = DeviceNodeEnumerateCompletion (0x30d)

  3. PDO에서 !devobj 명령을 사용하여 PDO의 참조 수(RefCount)에 대한 정보를 표시합니다.

    0: kd> !devobj 0x849e9648
Device object (849e9648) is for:
 0000004e \Driver\usbccgp DriverObject 8727e120
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00003040
Dacl 82910320 DevExt 849e9700 DevObjExt 849e99e0 DevNode 849e9448 
ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000180)  FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) 88310588 \Driver\usbvideo
Device queue is not busy

  4. dt(표시 유형) 커널 디버거 명령을 사용하여 PDO 디바이스 개체를 검사합니다. ReferenceCount는 디바이스 개체와 연결된 디바이스의 열린 핸들 수를 보여 줍니다.

    0: kd> dt nt!_DEVICE_OBJECT 849e9648  
…
   +0x002 Size             : 0x398
   +0x004 ReferenceCount   : 0n0
   +0x008 DriverObject     : 0x8727e120 _DRIVER_OBJECT
..
…

  5. 테스트를 시작하기 전에 참조 수가 0보다 큰 경우 다음을 수행합니다.

    • PDO가 만들어지는 중단점을 설정합니다.

    • PDO가 만들어지면 ba(액세스 중단) 중단점을 PDO의 참조 수가 저장된 위치에 설정합니다.

      예를 들어 다음 명령은 ba(액세스 중단) 중단점을 디바이스 개체(0x849e9648)에 설정합니다. 중단점은 크기가 4바이트(ReferenceCount 크기)인 ReferenceCount(4 이상 오프셋)에 대한 쓰기 액세스에 설정됩니다.

      0: kd> ba w 4 849e9648+4

    • 테스트를 시작하기 전에 PDO의 참조 수가 0과 같으면 테스트에서 예기치 않은 디바이스 제거를 수행할 때 테스트 실행으로 인해 PDO의 참조 수가 0보다 클 수 있습니다. 이는 일반적으로 핸들 누수를 나타냅니다. 명령 프롬프트 창 또는 Visual Studio에서 PNP 예기치 않은 디바이스 제거 테스트를 실행하여 실패를 재현하고 문제를 해결하는 데 필요한 정보를 캡처합니다.

    참고

    DoConcurrentIO 매개 변수를 TRUE로 설정하면 테스트에서 PDO에 대한 수백 개의 파일 핸들이 열립니다. 이 실패를 재현하는 경우 이 매개 변수를 FALSE로 설정하는 것이 좋습니다.

  6. ba(액세스 중단) 중단점이 발생하면 !thread 및 k(스택 역추적 표시) 커널 디버거 명령을 사용하여 오류를 디버그할 수 있습니다. 테스트를 실행하는 동안 참조 수가 여러 번 변경될 수 있으므로 필요에 따라 ba(액세스 중단) 디버거 명령의 commandString 매개 변수를 사용하여 참조 수에 대한 각 변경에 필요한 정보를 가져올 수 있으며 계속 테스트할 수 있습니다.

    예를 들어 다음 액세스 중단 명령에서 commandString은 참조 수가 변경되는 프로세스를 식별하는 !thread 명령, 호출 스택을 식별하는 .reload ; k 100 명령, 각 변경에 대한 참조 수를 출력하는 !devobj 명령 및 중단점 이후에 계속 진행하는 g 명령으로 구성됩니다.

    0: kd> ba w 4 849e9648+4 "!thread; .thread /p /r; .reload; k 100; !devobj 849e9648; g"

예:

다음 예제에서는 cscript.exe에서 실행되는 스레드의 CreateFile 함수를 호출하면 참조 수가 증가합니다. 테스트를 실행하는 동안 참조 수가 변경되는 모든 인스턴스를 캡처하고 이러한 호출 스택을 분석하면 핸들 누수를 식별하는 데 도움이 될 수 있습니다.

THREAD 87eb3d40  Cid 1094.1490  Teb: 7f5a8000 Win32Thread: 82da2210 RUNNING on processor 3
Not impersonating
DeviceMap                 a71b3228
Owning Process            88199cc0       Image:         cscript.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      1232688        Ticks: 0
Context Switch Count      18             IdealProcessor: 2             
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address ntdll!TppWorkerThread (0x7710704d)
Stack Init a6ebfde0 Current a6ebfa6c Base a6ec0000 Limit a6ebd000 Call 0
Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
ChildEBP RetAddr  Args to Child              
a6ebfa50 814a73fe f81771f8 814a72e5 8281000e nt!IopCheckDeviceAndDriver+0x61 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 182]
a6ebfb70 8149fb76 849e9648 848f9200 87164008 nt!IopParseDevice+0x11d (FPO: [Non-Fpo]) (CONV: stdcall) [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 1634]
…
…
0236f874 7710689d ffffffff 77195ae2 00000000 ntdll!__RtlUserThreadStart+0x4a (FPO: [SEH]) (CONV: stdcall) [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 1021]
0236f884 00000000 7710704d 0031c540 00000000 ntdll!_RtlUserThreadStart+0x1c (FPO: [Non-Fpo]) (CONV: stdcall) [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 939]

Implicit thread is now 87eb3d40
Connected to Windows 8 9200 x86 compatible target at (Wed Sep 19 21:04:27.601 2012 (UTC - 7:00)), ptr64 FALSE
Loading Kernel Symbols
...............................................................
................................................................
...............
Loading User Symbols
................................................................
...........................
Loading unloaded module list
.....................
ChildEBP RetAddr  
a6ebfa50 814a73fe nt!IopCheckDeviceAndDriver+0x61 [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 182]
a6ebfb70 8149fb76 nt!IopParseDevice+0x11d [d:\w8rtm\minkernel\ntos\io\iomgr\parse.c @ 1634]
…
…
0236f2d4 6970274e KERNELBASE!CreateFileW+0x61 [d:\w8rtm\minkernel\kernelbase\fileopcr.c @ 1194]
0236f31c 6b6ce0e1 deviceaccess!CDeviceBroker::OpenDeviceFromInterfacePath+0x178 [d:\w8rtm\base\devices\broker\dll\broker.cpp @ 177]
0236f34c 6b6cc5c0 MFCORE!CDevProxy::CreateKsFilter+0x46 [d:\w8rtm\avcore\mf\core\transforms\devproxy\devproxy.cpp @ 2263]
…
…
0236f874 7710689d ntdll!__RtlUserThreadStart+0x4a [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 1021]
0236f884 00000000 ntdll!_RtlUserThreadStart+0x1c [d:\w8rtm\minkernel\ntdll\rtlstrt.c @ 939]

Device object (849e9648) is for:
 0000004e \Driver\usbccgp DriverObject 8727e120
Current Irp 00000000 RefCount 1 Type 00000022 Flags 00003040
Dacl 82910320 DevExt 849e9700 DevObjExt 849e99e0 DevNode 849e9448 
ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000180)  FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) 88310588 \Driver\usbvideo
Device queue is not busy.

SimpleIO 플러그 인 로그 실패

디바이스 기본 사항 안정성 테스트는 제공된 WDTF 단순 I/O 플러그 인을 사용하여 디바이스의 I/O를 테스트합니다. SimpleIO 플러그 인은 디바이스별 제네릭 I/O 기능을 테스트하는 WDTF 확장입니다. 테스트 중인 디바이스 유형에 대한 WDTF 플러그 인이 있는 경우 테스트는 IWDTFSimpleIOStressAction2 인터페이스를 사용하여 디바이스의 I/O를 테스트합니다.

WDTF SimpleIO 플러그 인에서 기록한 오류는 TestTextLog.log 파일의 WDTF_SIMPLE_IO 태그를 사용합니다(WDTF 개체 이름 태그 참조). 오류 메시지는 항상 테스트 대상 디바이스와 특정 실패 이유를 식별합니다.

예:

다음 예제에서 무선 SimpleIO 플러그 인은 802.11n USB 무선 LAN 카드 디바이스를 테스트하는 동안 I/O 오류가 발생했다는 오류를 기록했습니다. 특히 SimpleIO 플러그 인은 IcmpSendEcho 함수를 사용하여 게이트웨이 주소를 ping했습니다. 이 경우 11010 오류가 반환됩니다. 이 오류는 리소스 부족으로 인한 오류로 변환됩니다.

WDTF_SIMPLE_IO            : ERROR :  - PerformIO(802.11n USB Wireless LAN Card USB\VID_XXXX&PID_XXXX\X&XXXXXXX&X&X ) Failed : WirelessPlugin: TestPingGateway() - IcmpSendEcho() call failed several times. The error reported is for the last failure instance Win32=11010 - Error due to lack of resources.

특정 디바이스에서 테스트 I/O가 영구적으로 중단되고 결국 시간 제한으로 인해 테스트가 실패함

디바이스 기본 사항 안정성 테스트는 시나리오 기반 테스트이며 I/O 테스트를 PNP 및 전원 테스트 시나리오와 결합합니다. 테스트는 일반적으로 시나리오 전후 2분 동안 I/O를 테스트합니다. 예를 들어 DF - 전후에 IO를 사용하여 절전 모드 테스트는 다음을 수행합니다.

For each sleep state supported on the system (CS, S1, S2, S3, S4)

Test I/O on devices with I/O plugins in parallel (one thread per device) for 2 minutes

Enter sleep state & exit after 2 minutes

Next

테스트는 실행될 때 디바이스의 I/O 테스트를 여러 번(각 절전 모드 상태에 대해 한 번씩) 종료합니다. 로그 파일에서 이를 확인하는 방법에 대한 자세한 내용은 로그 파일 검토를 참조하세요.

I/O를 테스트할 때 발생하는 일반적인 실패 중 하나는 특정 디바이스에서 I/O 테스트가 영구적으로 중단될 수 있다는 것입니다. 이로 인해 테스트 시간 제한 기간(일반적으로 몇 시간)이 지나면 결국 테스트가 실패합니다. 시간 제한으로 인한 실패를 식별하는 방법에 대한 내용은 Windows HLK 테스트 실패 문제 해결을 참조하세요.

참고

Windows HLK는 시간 제한 기간 후에 중단된 프로세스를 종료합니다. 영구 중단으로 인해 결국 테스트가 실패할 때까지 기다리는 대신 시스템에서 중단된 프로세스가 계속 실행되는 동안 중단을 조사하는 것이 좋습니다. 테스트 중단 문제를 해결하는 방법에 대한 내용은 Windows HLK를 사용하여 디바이스 기본 사항 안정성 테스트 문제 해결 항목의 테스트 중단 섹션을 참조하세요.

I/O가 테스트되는 디바이스의 수에 따라 중단된 디바이스는 다음과 같이 식별할 수 있습니다.

  1. 테스트에서 I/O를 테스트하는 디바이스의 수가 1인 경우 명령 창에 10분 넘게 진행 상황이 표시되지 않습니다. 명령 창의 마지막 로그 항목에는 WDTF_SIMPLE_IO 또는 WDTF_SIMPLEIO_STRESS 태그가 있으며 중단된 디바이스를 식별합니다. 테스트 로그 파일을 읽는 방법에 대한 자세한 내용은 로그 파일 검토를 참조하세요.

  2. 테스트에서 I/O를 테스트하는 디바이스의 수가 1보다 크면 명령 창에서 PerformIO(<디바이스 이름>) Count … 메시지가 10분 넘게 지속적으로 반복되는 것을 볼 수 있습니다. 테스트는 I/O를 2분 동안 테스트한 후 한 번에 하나의 디바이스에서 I/O 테스트를 중지하려고 합니다. 특정 디바이스에 대한 중지 작업이 성공하면 로그에서 디바이스에 대한 "중지" 메시지 뒤에 "닫기" 메시지가 표시됩니다. 디바이스에 "중지" 메시지가 표시되지만 해당 "닫기" 메시지가 표시되지 않으면 이 디바이스에 대한 테스트 I/O가 중단된 것을 의미합니다.

예:

다음의 경우 "중지" 메시지가 있지만 해당 "닫기" 메시지가 없으므로 모바일 광대역 디바이스는 문제 디바이스입니다. 반면에 I2C HID 디바이스에는 "중지" 메시지와 "닫기" 메시지가 모두 있습니다. 이는 테스트에서 아무 문제 없이 디바이스에서 I/O를 중지할 수 있음을 의미합니다. 이 테스트에서는 Microsoft 기본 렌더링 드라이버 및 Microsoft ACPI 규격 시스템 디바이스에서 I/O 테스트를 중단할 기회가 없었습니다. 따라서 이러한 디바이스에 대해 "PerformIO" 메시지가 계속 표시됩니다.

WDTF_SIMPLEIO_STRESS      : INFO  :  - Stop(I2C HID Device ACPI\STMQ7017\2&DABA3FF&3 )
WDTF_SIMPLE_IO            : INFO  :  - Close(I2C HID Device ACPI\STMQ7017\2&DABA3FF&3 )
WDTF_SIMPLEIO_STRESS      : INFO  :  - Stop(XYZ Mobile Broadband Device USB\VEN_XXX&PID_XXX\X&XXXXXX&X&X)
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
…
…
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft Basic Render Driver ROOT\BASICRENDER\0000 ) Count 119
WDTF_SIMPLE_IO            : INFO  :  - PerformIO(Microsoft ACPI-Compliant System ACPI_HAL\PNP0C08\0 ) Count 119
…
…

다음 단계는 테스트 프로세스에서 스레드의 스택 추적을 검사하여 모바일 광대역 디바이스에 대한 테스트 I/O가 중단된 이유를 확인하는 것입니다. 테스트 프로세스의 스레드 중 하나가 모바일 광대역 디바이스에서 I/O를 구체적으로 테스트하는 데 사용되는 것을 확인할 수 있습니다. 추가 문제 해결 정보는 커널 디버깅을 사용하여 디바이스 기본 사항 안정성 테스트 실패 디버그를 참조하세요.

테스트가 절전 모드에서 다시 시작되지 않음

디바이스 기본 사항 안정성 테스트는 시스템 절전 모드 해제 타이머를 사용하여 전원 관리 테스트 중에 테스트 시스템의 절전 모드 상태를 해제합니다. 잘못된 절전 모드 해제 타이머는 테스트 실행 중에 테스트 시스템의 절전 모드 상태를 자동으로 해제하지 못하도록 방지할 수 있습니다. 테스트 시스템의 절전 모드 상태가 자동으로 해제되지 않는 경우 BIOS 공급업체에 문의하여 절전 모드 해제 타이머 문제를 해결하기 위한 BIOS 수정을 릴리스하도록 하거나 절전 모드 해제 타이머가 예상대로 작동하는 다른 시스템에서 테스트를 실행하도록 해야 할 수 있습니다.

또한 드라이버 버그로 인해 전원이 켜지거나 전원이 끊기는 동안 시스템이 영구적으로 중단될 수 있습니다. 이 경우 커널 디버거에 연결된 테스트 시스템을 사용하여 테스트를 다시 실행하고 커널 디버거에서 시스템 중단을 디버그해야 합니다.

커널 디버거를 설정하는 방법에 대한 내용은 수동으로 커널 모드 디버깅 설정을 참조하세요. Windows HLK 테스트 실행 중에 발생하는 시스템 중단 문제를 해결하는 방법에 대한 일반적인 지침은 Windows HLK 테스트 실패 문제 해결을 참조하세요.

WirelessPlugin: ConnectToTestProfile() - 테스트 프로필에 연결하지 못했습니다. 이유 문자열: "특정 네트워크를 사용할 수 없습니다." 오류 메시지

테스트 일정 시간에 Wpa2PskAesSsid 및 Wpa2PskPassword 매개 변수에 대한 올바른 값이 테스트에 제공되지 않으면 디바이스 기본 사항 테스트가 이 오류 메시지와 함께 실패합니다. 테스트 대상 디바이스 중 하나가 WiFi 어댑터인 경우 테스트에서 테스트 무선 네트워크의 연결 정보(SSID 및 암호)를 제공해야 합니다. 이러한 테스트 매개 변수에 대한 자세한 내용은 실패한 테스트 설명서 페이지의 매개 변수 섹션을 참조하세요.

WDTFSensorsPlugin: Open() - GPS 센서가 준비 상태로 전환되지 않음

디바이스 기본 사항 안정성 테스트에서는 GPS 센서가 있는 시스템을 강력한 GPS 신호가 있는 환경에서 테스트해야 합니다(테스트에서 GPS 센서 디바이스에 대한 I/O를 테스트할 수 있도록). 이 오류는 테스트 시스템의 GPS 센서에서 GPS 수정을 가져올 수 없음을 나타냅니다. 테스트 시스템이 강력한 GPS 신호를 받을 수 있는 위치에서 테스트를 실행하는 것이 좋습니다.

테스트 로그 메시지: 다시 부팅한 후에 찾은 디바이스 수(1)가 다시 부팅 전(2)과 다릅니다. 누락된 디바이스를 찾으려면 로그를 검토하세요.

이 메시지는 다시 부팅한 후 디바이스 중 하나가 돌아오지 않았음을 나타냅니다. 이 실패를 조사하려면 다음 단계를 실행하여 다시 설치, 다시 시작 및 다시 부팅 테스트에 대한 자세한 Setupapi 로그를 생성하고 분석합니다.

  1. 자세한 setupapi 로그를 생성하려면 KEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup!LogLevel 레지스트리 키를 0x2000ffff로 설정합니다.
  2. 문제를 재현한 다음, %windir%\inf\setupapi*에서 Setupapi 로그를 검토합니다.
  3. 디바이스 설치 문제의 근본 원인을 알아보려면 Setupapi.log 파일을 사용하여 문제 해결을 참조하세요.

로그에 디바이스가 없거나 시작되지 않았다는 오류가 포함된 경우 디버거에서 !pnptriage를 실행하고 출력을 검토합니다. 테스트 실패 디버깅에 대한 자세한 내용은 커널 디버깅을 사용하여 디바이스 기본 사항 안정성 테스트 실패 디버그를 참조하세요.

Windows HLK를 사용하여 디바이스 기본 사항 안정성 테스트 문제 해결