Falha em device descriptor request no Windows: como depurar o Code 43 com evidência de barramento

"Unknown USB Device (Device Descriptor Request Failed)" é um dos erros de USB mais comuns no Windows. O Gerenciador de Dispositivos pode mostrar Code 43. O dispositivo pode aparecer como desconhecido, falhar logo depois de conectado, ou funcionar em uma máquina e não em outra. Buscas como "USB Device Descriptor Request Failed", "Windows Code 43 USB", "device descriptor request failed fix" e "USB enumeration failed" acontecem porque o Windows dá um rótulo para o usuário, não a razão no nível do barramento.

A requisição de descritor é uma das primeiras etapas da enumeração USB. Se ela falha, o host nem consegue descobrir o que é o dispositivo. Isso significa que drivers de classe, software de aplicação, portas seriais, relatórios HID e protocolos vendor não são o primeiro lugar para depurar. A falha aconteceu antes do sistema operacional ter informação suficiente para vincular o driver normal.

O Bus Scope ajuda nesse tipo de problema porque a evidência importante está nas primeiras control transfers depois do attach.

O que o Windows está tentando fazer

Quando um dispositivo USB é conectado, o host detecta o attach, reseta a porta e pede o device descriptor. O device descriptor contém identidade e capacidade básicas:

• versão de USB
• classe, subclasse e protocolo do dispositivo
• max packet size do endpoint zero
• Vendor ID
• Product ID
• release number do dispositivo
• índice de string do fabricante
• índice de string do produto
• índice de string do serial number
• número de configurações

Se o Windows não consegue ler esse descritor de forma confiável, ele pode reportar "Device Descriptor Request Failed".

O que a falha pode significar

Esse erro pode ser causado por:

• Firmware do dispositivo não respondendo no endpoint zero
• Cabo USB ruim ou instável
• Energia insuficiente
• Reset do dispositivo durante a enumeração
• Conteúdo do descritor malformado ou inconsistente
• Problema de max packet size do endpoint zero
• Problema de timing na recuperação do reset
• Incompatibilidade de hub ou porta
• Problema de negociação USB 2.0 versus USB 3.x
• Dano elétrico ou defeito de hardware
• Problema de driver de host controller

O mesmo rótulo do Windows cobre muitas causas raiz diferentes. Por isso a evidência de pacote importa.

Sequência inicial de enumeração

Uma enumeração inicial saudável costuma ser:

Port attach
Port reset
GET_DESCRIPTOR(Device, primeiros 8 bytes)
SET_ADDRESS
GET_DESCRIPTOR(Device, completo)
GET_DESCRIPTOR(Configuration)
SET_CONFIGURATION

Host controllers e versões de Windows podem variar, mas o padrão é parecido. Se o primeiro GET_DESCRIPTOR falha, o host nunca chega à configuração normal do dispositivo.

Os primeiros 8 bytes importam

Hosts geralmente leem os primeiros 8 bytes do device descriptor primeiro para descobrir o packet size do endpoint zero. Se essa requisição falha ou devolve dados inconsistentes, a enumeração pode parar.

Desenvolvedores de firmware às vezes testam só a resposta completa do descritor e esquecem da requisição inicial curta. Um dispositivo pode funcionar em um host e falhar em outro porque o timing e o length da requisição são diferentes.

Procure por:

• Nenhuma resposta para a primeira requisição de descritor
• Short packet onde se esperava uma resposta válida
• Stall no endpoint zero
• Timeout seguido de reset
• Tamanho do descritor que não bate com a estrutura esperada
• Dados do descritor mudando entre tentativas

Energia e loops de reset

Se o dispositivo liga devagar ou consome corrente demais, ele pode resetar durante a enumeração. O Windows tenta de novo. O resultado pode ser um loop:

Attach
Reset
GET_DESCRIPTOR
Timeout
Reset
GET_DESCRIPTOR
Timeout
Unknown USB Device

Usuários podem achar que é problema de driver porque o erro aparece no Gerenciador de Dispositivos. Mas se o descritor nunca foi lido, o driver normal ainda não entrou em jogo.

Tente cabo curto e direto, outra porta, hub com fonte e outro host, mas preserve a captura. O trace mostra se o dispositivo falhou antes ou depois da resposta do descritor.

Descritores malformados

Se o dispositivo devolve bytes de descritor, mas eles são inválidos, o Windows pode rejeitar o dispositivo. Exemplos:

• bLength errado
• Tipo de descritor errado
• Mismatch no comprimento total da configuração
• Descritor de endpoint faltando
• Mismatch na contagem de interfaces
• Max packet size inválido
• Mismatch no length do string descriptor
• Versão de USB declarada e não suportada

Descritores malformados são especialmente comuns em firmware custom, placas de desenvolvimento, cores USB em FPGA e dispositivos com stacks USB escritos à mão.

O Bus Scope ajuda a inspecionar o conteúdo do descritor diretamente, em vez de depender de um erro genérico do Gerenciador de Dispositivos.

Por que funciona no Linux e não no Windows

Alguns dispositivos enumeram no Linux, mas falham no Windows, porque os hosts não são igualmente tolerantes. O Windows pode validar a consistência dos descritores de forma diferente. O Linux pode retentar de um jeito que esconde problemas de timing. Um dispositivo também pode depender de um comportamento de driver de classe que difere entre sistemas.

Não conclua que o Windows está errado nem que o dispositivo está bom. Compare os traces de enumeração. A diferença costuma aparecer na ordem das requisições, no timing, no length do descritor ou no comportamento de reset.

Checklist de depuração

Use este processo:

1. Capture antes de conectar.
2. Identifique se a primeira requisição de device descriptor recebe alguma resposta.
3. Confira se o endpoint zero trava ou dá timeout.
4. Inspecione os bytes do descritor para conferir length e type.
5. Confira se há port resets repetidos.
6. Compare porta direta versus hub.
7. Compare portas USB 2.0 e USB 3.x.
8. Compare outro cabo.
9. Compare traces de enumeração no Windows e no Linux.
10. Se o firmware for custom, teste leituras curtas de descritor explicitamente.

O que incluir em um bug report

Um relatório útil inclui:

• Texto do erro no Windows e Code 43, se houver
• VID/PID do dispositivo, se chegou a ser lido
• Se a primeira requisição de 8 bytes do descritor teve sucesso
• Última requisição USB bem-sucedida antes da falha
• Se os resets se repetem
• Detalhes de cabo, hub e porta
• Captura em torno da conexão, não só depois da falha

Isso dá evidência acionável para as equipes de firmware e driver.

Diagnóstico final

"USB Device Descriptor Request Failed" significa que o host falhou bem cedo na enumeração. A causa raiz pode ser firmware, estrutura do descritor, timing, comportamento do endpoint zero, energia, cabo, hub ou compatibilidade com o host. Em geral, é cedo demais para culpar a aplicação.

O Bus Scope apoia o fluxo certo: inspecionar as primeiras control transfers, preservar a sequência de enumeração e diagnosticar a falha a partir do barramento USB, em vez de um rótulo genérico do Windows.