Когда флешка или внешний диск «отваливается» без видимой причины, первое, что стоит проверить, — USB log, то есть журнал событий шины USB: в нём фиксируются подключения, отключения, ошибки дескрипторов и сбои питания порта. Фраза «usb at usb log» обычно означает поиск записи о конкретном устройстве в таком журнале — например, строки вида usb 1-2: new high-speed USB device в выводе dmesg на Linux или события перечисления устройства в журнале Windows.
В этой статье разберём, где операционная система хранит логи USB, как их включить и прочитать, какие записи указывают на аппаратную проблему, а какие — на сбой драйвера. Материал подходит для диагностики на уровне пользователя и не требует специального оборудования.
Что такое USB log и зачем он нужен
USB log — это хронологическая запись событий, которые происходят на шине USB: обнаружение устройства, запрос дескрипторов, назначение адреса, загрузка драйвера, ошибки передачи данных. Операционная система ведёт такой журнал постоянно (как dmesg в Linux) либо позволяет включить расширенную трассировку при необходимости (как Event Tracing for Windows).
По журналу можно отличить три принципиально разные ситуации: устройство вообще не обнаруживается шиной (проблема кабеля, порта или самого гаджета), устройство видно, но не назначается драйвер (проблема ПО), либо соединение рвётся уже после успешного подключения (питание, помехи, нестабильный контакт). Без лога эти случаи внешне выглядят одинаково — «флешка не работает».
USB log — главный инструмент, позволяющий отличить аппаратную неисправность от программного сбоя без разборки устройства.
Просмотр USB-лога в Linux: dmesg и journalctl
Самый быстрый способ увидеть события USB в Linux — команда dmesg. Подключите устройство и сразу выполните в терминале:
dmesg | grep -i usbВ выводе ищите строки вида usb 1-2: new high-speed USB device number 5 using xhci_hcd — это успешное обнаружение. Если после неё следует device descriptor read/64, error -71 или unable to enumerate USB device, шина видит «что-то» на порту, но не может прочитать дескриптор — типичный признак проблемы с кабелем, питанием или самим устройством.
Для наблюдения за событиями в реальном времени удобен режим слежения:
sudo dmesg -wВ системах с systemd те же события доступны через journalctl -k -f. Обе команды читают кольцевой буфер ядра, поэтому старые записи со временем вытесняются новыми — если сбой произошёл давно, лог мог уже перезаписаться.
- 🔌
usb X-Y: new ... device— устройство обнаружено, шина работает; - 📛
device not accepting address— устройство не отвечает на назначение адреса, часто аппаратная причина; - 🔁
USB disconnectсразу после подключения — вероятны проблемы с питанием порта или контактом; - ⚡
over-current condition— превышение тока на порту, порт может быть отключён защитой.
Низкоуровневая трассировка: usbmon
Когда записей dmesg недостаточно — например, нужно увидеть сами пакеты, которыми обмениваются хост и устройство, — в Linux используется механизм usbmon. Он предоставляет доступ к трафику шины через интерфейс в debugfs и обычно требует прав root.
Типовой порядок действий: загрузить модуль sudo modprobe usbmon, затем читать поток событий из /sys/kernel/debug/usb/usbmon/0u (все шины) или из файла конкретной шины. Сырой формат удобнее разбирать через Wireshark, который умеет захватывать интерфейсы usbmon и показывать запросы в человекочитаемом виде.
sudo modprobe usbmon
sudo cat /sys/kernel/debug/usb/usbmon/0u
⚠️ Внимание: захват usbmon фиксирует весь трафик шины, включая данные, которые вы вводите с USB-клавиатуры. Не оставляйте захват включённым постоянно и не передавайте файлы трассировки третьим лицам без проверки содержимого.
Формат строки usbmon
Каждая строка содержит адрес URB, метку времени, тип события (S — submit, C — callback, E — error), тип передачи (control, bulk, interrupt, isochronous), адрес устройства и конечной точки, статус и длину данных. Полный формат описан в документации ядра Linux (файл Documentation/usb/usbmon.txt в исходниках ядра).
USB-лог в Windows: Просмотр событий и трассировка
В Windows базовые сведения о подключениях видны в Просмотре событий: откройте eventvwr.msc и посмотрите журналы Система (источники вроде Kernel-Power, USBHUB) и журналы приложений и служб в разделе Microsoft → Windows, где есть подразделы, связанные с USB. Точный набор журналов зависит от версии Windows, поэтому ориентируйтесь на поиск по слову «USB» внутри дерева журналов.
Для глубокой диагностики Microsoft предусмотрела трассировку событий (ETW) для USB-стека, а также сведения об устройстве в Диспетчере устройств: вкладка «События» в свойствах устройства показывает историю — когда оно было настроено, запущено или удалено. Это удобный способ понять, дошло ли перечисление до стадии загрузки драйвера.
Ещё один практичный инструмент — бесплатная утилита USBLogView от NirSoft, которая ведёт непрерывный журнал подключений и отключений USB-устройств с указанием времени, типа устройства и идентификаторов VID/PID. Она подходит для длительного наблюдения, когда сбой плавающий и поймать его вручную сложно.
- 🖥️ Диспетчер устройств → Свойства → События — история конкретного устройства;
- 📋 Просмотр событий — системные ошибки USB-хабов и питания;
- 🛰️ USBLogView — непрерывный мониторинг подключений/отключений;
- 🔬 ETW-трассировка — глубокий разбор для разработчиков драйверов.
Типовые записи в логе и их расшифровка
Чтение лога сводится к сопоставлению записи с этапом подключения. Сначала шина обнаруживает устройство, затем читает дескрипторы, назначает адрес, выбирает конфигурацию, и только потом загружается драйвер. Сбой на каждом этапе оставляет характерный след.
| Запись в логе | Этап | Вероятная причина |
|---|---|---|
| new high-speed USB device | Обнаружение | Норма, шина и порт исправны |
| device descriptor read/64, error | Чтение дескриптора | Кабель, питание, неисправность устройства |
| device not accepting address | Назначение адреса | Аппаратный сбой устройства или порта |
| over-current condition | Питание | Превышение тока, КЗ в устройстве или кабеле |
| USB disconnect, повторяется циклично | Эксплуатация | Нестабильный контакт, энергосбережение порта |
Обратите внимание: одинаковые сообщения могут иметь разные причины на разных машинах. Запись об ошибке дескриптора сама по себе не доказывает неисправность флешки — сначала проверьте устройство на другом порту и другом компьютере, чтобы локализовать источник.
Всегда сравнивайте поведение минимум на двух портах и, если возможно, на двух компьютерах. Если ошибка в логе «переезжает» вместе с устройством — виновато устройство или кабель; если остаётся на порту — проблема в порте или контроллере.
Пошаговая диагностика по журналу
Работайте от простого к сложному, фиксируя каждый шаг. Сначала очистите контекст: выполните sudo dmesg -C (очистка буфера, требует root) или просто запомните время, затем подключите устройство и сразу снимите лог.
Далее определите этап сбоя по таблице выше и проверьте обратимые причины: другой кабель, другой порт, порт без промежуточного хаба, отключение энергосбережения USB (в Linux — параметр autosuspend, в Windows — настройки схемы электропитания и свойства корневого USB-концентратора). Только после этого имеет смысл грешить на драйвер или само устройство.
☑️ Диагностика USB по логу
⚠️ Внимание: сообщение over-current condition означает, что защита порта сработала из-за превышения тока. Повторное подключение того же устройства в тот же порт без выяснения причины может повредить контроллер — сначала проверьте кабель и само устройство на короткое замыкание.
Когда лог чист, а устройство не работает
Иногда в журнале нет вообще никаких записей при подключении — шина «молчит». Это тоже диагностический признак: чаще всего он означает, что до перечисления дело не дошло физически. Возможные причины: кабель только для зарядки (без линий данных — очень частая ситуация с кабелями USB-C и Micro-USB), полностью неисправный порт, отключённый контроллер в BIOS/UEFI или мёртвое устройство.
Проверка проста: подключите в тот же порт заведомо исправное устройство. Если и оно не появляется в логе — проблема на стороне компьютера (порт, контроллер, настройки). Если появляется — ищите причину в кабеле или в самом диагностируемом устройстве. Отсутствие записей в логе — это тоже запись: она почти всегда указывает на физический уровень, а не на драйверы.
⚠️ Внимание: если порт не видит ни одно устройство, проверьте настройки BIOS/UEFI — на некоторых платах USB-контроллеры или отдельные порты можно отключить. Названия пунктов меню различаются у разных производителей, поэтому сверяйтесь с документацией на вашу материнскую плату или ноутбук.
Порядок диагностики всегда один: сначала лог, затем кабель и порт, затем второй компьютер — и только в конце драйверы и само устройство.
FAQ: частые вопросы о USB-логах
Что означает запись «usb 1-2: device descriptor read/64, error -71»?
Хост не смог прочитать дескриптор устройства — базовую информацию, без которой перечисление невозможно. Наиболее частые причины: повреждённый или «зарядочный» кабель, недостаточное питание, неисправность самого устройства. Начните с замены кабеля и порта.
Как посмотреть историю USB-подключений за прошлые дни в Windows?
Штатно — через Просмотр событий и вкладку «События» в свойствах устройства, однако глубина истории ограничена настройками журналов. Сторонние утилиты вроде USBDeview показывают реестр когда-либо подключённых устройств, но это справочная информация, а не полноценный лог ошибок.
Опасно ли включать usbmon на рабочей системе?
Сама трассировка безопасна, но захват содержит данные всех USB-устройств, включая ввод с клавиатуры. Включайте захват только на время диагностики и не передавайте дампы посторонним.
В логе устройство появляется и исчезает по кругу — что делать?
Циклические connect/disconnect обычно указывают на нестабильный контакт, недостаточное питание или агрессивное энергосбережение порта. Проверьте другой кабель, подключение без хаба и отключите autosuspend для USB.
Почему в dmesg нет никаких записей при подключении флешки?
Шина вообще не видит подключение — это почти всегда физический уровень: кабель без линий данных, неисправный порт, отключённый контроллер или нерабочее устройство. Проверьте порт заведомо исправным устройством, чтобы определить сторону отказа.