Просмотрите распространенные сбои тестов надежности устройств

Статья
06/20/2023

В этом разделе описываются распространенные сбои тестов, которые могут возникнуть при запуске тестов надежности оборудования Windows (Windows HLK).

Тест помечен как сбой в HLK Studio, но в журнале te.wtl отображаются только результаты передачи

Если тест помечен как неудачный в HLK Studio, но в журнале te.wtl отображаются только результаты передачи, можно получить ошибку, которая вызвала сбой, выполнив следующие действия:

Щелкните правой кнопкой мыши значок красного теста запуска
Выбор ошибки

Откроется диалоговое окно, содержащее описание ошибки, которая произошла.

Сбой теста, так как во время тестирования произошла непредвиденная перезагрузка

Если текст ошибки указывает, что произошла непредвиденная перезагрузка, скорее всего, это означает, что устройство привело к неожиданной перезагрузке операционной системы (BSOD). Чтобы диагностировать этот сбой, подключите отладчик или настройте тестовый компьютер для автоматического создания дампов полной памяти и исследования ошибки проверка. Чтобы приступить к отладке ядра при сбоях теста, см. раздел "Использование отладки ядра" для отладки сбоев тестов надежности устройств.

Задача проверки состояния устройства завершается сбоем во время установки

Задачи проверки состояния устройства часто завершаются ошибкой, так как устройство неправильно настроено с помощью носителя или подключения перед началом тестирования. Сведения о том, как правильно настроить устройство для тестирования, см. в предварительных требованиях для проверки надежности device.Basics.

Задача проверки состояния устройства включена в этап установки каждого тестового задания "Основы устройства". Он запускает средство для проверки того, что устройство под тестом (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_REMOVE_DEVICE после получения сообщения об ошибке IRP_MN_SURPRISE_REMOVAL"

DF - PNP Surprise Remove Device Test может завершиться ошибкой со следующим сообщением об ошибке, если диспетчер PnP не отправляет IRP в стек тестового устройства после отправки неожиданного удаления IRP:

"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 до закрытия всех незавершенных дескрипторов файлов на устройство. То есть диспетчер PnP не отправляет запрос IRP_MN_REMOVE_DEVICE до тех пор, пока число ссылок PDO не достигнет нуля. Сведения о том, как правильно обрабатывать запрос IRP_MN_SURPRISE_REMOVAL, см. в разделе "Обработка запроса IRP_MN_SURPRISE_REMOVAL".

Чтобы помочь отладить этот тестовый сбой, необходимо определить, как количество ссылок для изменения объекта физического устройства (PDO). Определите процесс изменения счетчика ссылок и проверьте, как выглядит стек вызовов при изменении количества ссылок. Для отладки этого сбоя можно использовать следующие шаги:

Если это еще не сделано, подключите отладчик ядра к тестовом компьютеру. См. сведения о настройке компьютера для развертывания, тестирования и отладки драйверов.
Установите точку останова ba (Break on Access) в расположении, где хранится количество ссылок тестового устройства. Дополнительные сведения о точках останова доступа см. в статьях "Точки останова процессора" (точки останова ba). В следующем примере команда отладчика ядра !devnode получает сведения о devnode для драйвера USBvideo. Адрес PDO для этого devnode 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)
```

Используйте команду !devobj в PDO, чтобы отобразить сведения о счетчике ссылок (RefCount) PDO.

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

Проверьте объект устройства PDO с помощью команды отладчика ядра dt (display Type ). ReferenceCount показывает количество открытых дескрипторов для устройства, связанного с объектом устройства.
```
0: kd> dt nt!_DEVICE_OBJECT 849e9648  
…
   +0x002 Size             : 0x398
   +0x004 ReferenceCount   : 0n0
   +0x008 DriverObject     : 0x8727e120 _DRIVER_OBJECT
..
…
```
Если число ссылок больше 0 перед запуском теста:
- Задайте точку останова, в которой создается PDO.
- После создания PDO задайте точку останова для доступа (ba) в расположении, где хранится число ссылок PDO.
  
  Например, следующая команда задает точку останова ba (Break on Access) на объекте устройства (0x849e9648). Точка останова устанавливается для доступа на запись к ReferenceCount (+4 смещения) размером 4 байта (размер ReferenceCount).
```
0: kd> ba w 4 849e9648+4 
```
- Если число ссылок PDO равно 0 перед запуском теста, скорее всего, выполнение теста приводит к тому, что число ссылок PDO будет больше нуля во время выполнения теста неожиданного удаления устройства. Обычно это означает утечку дескриптора. Запустите тест PNP Surprise Remove Device из окна командной строки или Из Visual Studio, чтобы воспроизвести сбой и записать сведения, необходимые для устранения проблемы.
Примечание.

Если для параметра DoConcurrentIO задано значение TRUE, тест открывает сотни дескрипторов файлов для PDO. Рекомендуется задать для этого параметра значение FALSE при воспроизведении этого сбоя.
При возникновении точки останова на доступе (ba) можно использовать команды отладчика ядра !thread и k (Display Stack Backtrace) для отладки сбоя. Так как количество ссылок может изменяться несколько раз во время выполнения теста, в качестве параметра можно использовать параметр commandString команды отладчика ba (Break on Access), чтобы получить сведения, необходимые для каждого изменения счетчика ссылок, и по-прежнему продолжать тестировать.

Например, в следующем разрыве команды доступа команда commandString состоит из команды !thread , которая будет определять процесс, вызывающий изменение счетчика ссылок, и reload; k 100 команд, которые будут определять стек вызовов, команду !devobj для печати счетчика ссылок при каждом изменении, и g , чтобы продолжить после точки останова.
```
0: kd> ba w 4 849e9648+4 "!thread; .thread /p /r; .reload; k 100; !devobj 849e9648; g"
```

Пример:

В следующем примере вызов функции CreateFile из потока, выполняющегося в cscript.exe, приводит к добавочному количеству ссылок. Захват всех экземпляров, в которых количество ссылок изменяется при выполнении теста и анализе этих стеков вызовов, может помочь определить утечки дескриптора.

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.

Сбои журналов простых подключаемых модулей

Тесты надежности устройств используют подключаемые модули простого ввода-вывода WDTF для тестирования операций ввода-вывода на устройствах. Подключаемые модули SimpleIO — это расширения WDTF, которые проверяют функциональные возможности универсального ввода-вывода для конкретного устройства. Если подключаемый модуль WDTF существует для типа протестированного устройства, то тест использует интерфейс IWDTFSimpleIOStressAction2 для тестирования ввода-вывода на устройстве.

Ошибки, зарегистрированные подключаемыми модулями WDTF SimpleIO, используют тег WDTF_SIMPLE_IO в файле TestTextLog.log (см . теги имен объектов WDTF. Сообщение об ошибке всегда идентифицирует устройство под тестом и конкретную причину сбоя.

Пример:

В этом примере подключаемый модуль Wireless SimpleIO зарегистрировал сбой, который произошел во время тестирования устройства беспроводной локальной локальной сети USB 802.11n. В частности, подключаемый модуль SimpleIO pinged адрес шлюза с помощью функции IcmpSendEcho, которая вернула ошибку 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.

Тестирование ввода-вывода на определенном устройстве постоянно зависает и в конечном итоге приводит к сбою теста из-за времени ожидания

Тесты надежности устройств — это тесты на основе сценариев и объединение тестирования ввода-вывода с сценариями PNP и power test. Обычно тесты тестируют ввод-вывод в течение двух минут до и после сценария. Например, DF — спящий режим с операцией ввода-вывода до и после теста выполняет следующие действия:

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

Тест заканчивается тестированием ввода-вывода на устройствах несколько раз (один раз для каждого состояния сна) при запуске. Дополнительные сведения о том, как это увидеть в файлах журнала, см. в разделе "Просмотр файлов журналов".

Одним из распространенных сбоев при тестировании ввода-вывода является то, что тестирование ввода-вывода на определенном устройстве может постоянно зависать. Это приводит к сбою теста после периода времени ожидания теста (обычно это часы). Сведения о выявлении сбоев, вызванных временем ожидания, см. в статье об устранении неполадок с проверкой подлинности Windows HLK .

Примечание.

Windows HLK завершит процесс зависание после периода ожидания. Вместо того, чтобы ждать, пока тест завершится сбоем из-за постоянного зависания, рекомендуется исследовать зависание, пока процесс зависания по-прежнему работает в системе. Сведения об устранении неполадок с зависанием тестов см. в разделе "Устранение неполадок с основами надежности устройств" с помощью раздела Windows HLK.

В зависимости от количества устройств, на которых выполняется тестирование ввода-вывода, можно определить зависающее устройство следующим образом:

Если количество устройств, которые тест тестирует ввод-вывод, является одним, вы не увидите ход выполнения в командном окне более десяти минут. Последняя запись журнала в окне командной строки будет иметь тег WDTF_SIMPLE_IO или WDTF_SIMPLEIO_STRESS , и он определит зависающее устройство. Дополнительные сведения о том, как считывать файлы журналов тестирования, см. в разделе "Просмотр файлов журнала".
Если количество устройств, на которых тест тестирует операции ввода-вывода, больше одного, в командном окне отображается постоянное повторение счетчика performIO(<Device Name>) ... сообщений в течение более десяти минут. Тест пытается остановить тестирование ввода-вывода на одном устройстве через две минуты тестирования ввода-вывода на них. Если операция остановки выполнена успешно для конкретного устройства, в журналах появится сообщение "Остановить", за которым следует сообщение "Закрыть" для устройства. Если отображается сообщение "Остановить", но соответствующее сообщение "Закрыть" не отображается для устройства, то это означает, что тестирование ввода-вывода на это устройство зависло.

Пример:

В следующем случае мобильное широкополосное устройство является устройством проблемы, так как имеется сообщение "Остановить", но соответствующее сообщение "Закрыть" отсутствует. С другой стороны, устройство I2C HID имеет как сообщение "Остановить", так и сообщение "Закрыть", что означает, что тест смог остановить ввод-вывод на устройстве без каких-либо проблем. Тест никогда не имел возможности прекратить тестирование операций ввода-вывода на устройствах Системы, совместимых с Microsoft Basic Render Driver и Microsoft ACPI- совместимых систем; Таким образом, сообщения "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
…
…

Следующим шагом является проверка трассировок стека потоков в тестовом процессе, чтобы определить, почему тестирование ввода-вывода на мобильное широкополосное устройство зависает. Вы увидите, что один из потоков в тестовом процессе используется для конкретного тестирования ввода-вывода на мобильном широкополосном устройстве. Дополнительные сведения об устранении неполадок см. в статье "Использование отладки отладочного теста основы надежности устройства".

Тесты не возобновляют работу со спящего режима

Тесты надежности устройств основаны на системных таймерах пробуждения для пробуждения системы от состояний сна во время тестирования управления питанием. Неисправные таймеры пробуждения могут предотвратить автоматическое пробуждение тестовой системы во время тестового запуска. Если тестовая система не автоматически просыпается от сна, может потребоваться обратиться к поставщику BIOS, чтобы они выпустили исправление BIOS для решения проблем таймера пробуждения, или выполните тесты в другой системе, где таймеры пробуждения работают должным образом.

Система также может постоянно зависать во время питания или выключения из-за ошибок драйвера. В этом случае необходимо повторно запустить тест с помощью тестовой системы, подключенной к отладчику ядра, и выполнить отладку системы с отладчиком ядра.

Сведения о настройке отладчика ядра см . в разделе "Настройка отладки в режиме ядра" вручную . Сведения об устранении неполадок с ошибками тестов Windows HLK см. в общих рекомендациях по устранению неполадок системы при выполнении тестов Windows HLK.

WirelessPlugin: Подключение ToTestProfile() — не удалось подключиться к профилю тестирования. Строка причины: сообщение об ошибке "Конкретная сеть недоступна".

Тесты основы устройства завершаются ошибкой, если правильные значения для параметров Wpa2PskAesSid и Wpa2PskPassword не предоставляются тесту во время тестирования. Тесты требуют предоставления сведений о подключении (SSID и пароля) тестовой беспроводной сети, если один из устройств, на которых выполняется тестирование, является адаптером Wi-Fi. Дополнительные сведения об этих параметрах см. в разделе параметров страницы документации по сбою теста.

WDTFSensorsPlugin: Open() - ДАТЧИК GPS не пошел в готовое состояние

Для тестов надежности устройств требуется, чтобы системы с датчиком GPS проверялись в среде, где есть сильный GPS-сигнал (чтобы тесты могли тестировать ввода-вывода на устройстве датчика GPS). Эта ошибка означает, что датчик GPS в тестовой системе не может получить исправление GPS. Пожалуйста, рассмотрите возможность выполнения тестов в расположении, где тестовая система может получить сильный сигнал GPS.

Сообщение журнала тестирования: количество устройств, найденных после перезагрузки (1), не совпадает с количеством устройств перед перезагрузкой (2); Просмотрите журналы, чтобы найти отсутствующие устройства

Это сообщение указывает, что один из устройств не вернулся после перезагрузки. Чтобы исследовать этот сбой, создайте и проанализируйте подробные журналы Setupapi для переустановки, перезапуска и перезагрузки тестов, выполнив следующие действия.

Чтобы создать подробные журналы setupapi, задайте раздел реестра KEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup! LogLevel для 0x2000ffff
Повторите проблему, а затем просмотрите журналы Setupapi по адресу %windir%\inf\setupapi*
Чтобы устранить проблемы с установкой устройства, ознакомьтесь с разделом "Устранение неполадок с помощью файла Setupapi.log"

Если журнал содержит ошибку, указывающую, что устройство отсутствует или не запущено, запустите !pnptriage из отладчика и просмотрите выходные данные. Дополнительные сведения об отладке тестовых сбоев см. в разделе "Использование отладки отладочного ядра" для отладки сбоев тестов надежности устройств.

Устранение неполадок с проверкой надежности основных устройств с помощью Windows HLK

Поделиться через

Просмотрите распространенные сбои тестов надежности устройств

Тест помечен как сбой в HLK Studio, но в журнале te.wtl отображаются только результаты передачи

Сбой теста, так как во время тестирования произошла непредвиденная перезагрузка

Задача проверки состояния устройства завершается сбоем во время установки

Упражнение пути к устройству завершается сбоем с сообщением "Превышено ограничение времени ожидания потока тестирования. Ошибка прекращения потока

Сбой теста "Не удалось получить IRP_MN_REMOVE_DEVICE после получения сообщения об ошибке IRP_MN_SURPRISE_REMOVAL"

Сбои журналов простых подключаемых модулей

Тестирование ввода-вывода на определенном устройстве постоянно зависает и в конечном итоге приводит к сбою теста из-за времени ожидания

Тесты не возобновляют работу со спящего режима

WirelessPlugin: Подключение ToTestProfile() — не удалось подключиться к профилю тестирования. Строка причины: сообщение об ошибке "Конкретная сеть недоступна".

WDTFSensorsPlugin: Open() - ДАТЧИК GPS не пошел в готовое состояние

Дополнительные ресурсы

Поделиться через

Просмотрите распространенные сбои тестов надежности устройств

Тест помечен как сбой в HLK Studio, но в журнале te.wtl отображаются только результаты передачи

Сбой теста, так как во время тестирования произошла непредвиденная перезагрузка

Задача проверки состояния устройства завершается сбоем во время установки

Упражнение пути к устройству завершается сбоем с сообщением "Превышено ограничение времени ожидания потока тестирования. Ошибка прекращения потока

Сбой теста "Не удалось получить IRP_MN_REMOVE_DEVICE после получения сообщения об ошибке IRP_MN_SURPRISE_REMOVAL"

Сбои журналов простых подключаемых модулей

Тестирование ввода-вывода на определенном устройстве постоянно зависает и в конечном итоге приводит к сбою теста из-за времени ожидания

Тесты не возобновляют работу со спящего режима

WirelessPlugin: Подключение ToTestProfile() — не удалось подключиться к профилю тестирования. Строка причины: сообщение об ошибке "Конкретная сеть недоступна".

WDTFSensorsPlugin: Open() - ДАТЧИК GPS не пошел в готовое состояние

Связанные темы

Дополнительные ресурсы