Dispositivo USB desconhecido: entenda a falha no descritor no Windows 11

Falha na solicitação de descritor de dispositivo USB no Windows 11 mostrando enumeração, VID, PID, driver e diagnóstico com USBView
A falha na solicitação de descritor pode acontecer durante a enumeração USB, antes que o Windows consiga identificar corretamente o dispositivo e associá-lo ao driver adequado.
74 / 100 Pontuação de SEO

Você conecta um pendrive, webcam, impressora, adaptador USB, controle, leitor de cartão ou outro periférico ao computador. O Windows 11 reproduz o som de conexão, mas o equipamento não funciona.

Ao abrir o Gerenciador de Dispositivos, aparece algo semelhante a:

Dispositivo USB desconhecido (Falha na solicitação de descritor de dispositivo)

Em inglês, a mensagem pode aparecer como:

Unknown USB Device (Device Descriptor Request Failed)

Muitos usuários interpretam esse erro imediatamente como:

“Está faltando o driver.”

Essa é uma possibilidade que precisa ser analisada dentro do contexto, mas existe um detalhe fundamental: a falha na solicitação do descritor pode acontecer antes de o Windows conseguir identificar normalmente o dispositivo para então associá-lo ao driver apropriado.

O computador precisa primeiro estabelecer comunicação básica com o periférico.

Uma representação simplificada é:

dispositivo conectado

detecção física/elétrica

reset e comunicação USB

enumeração

leitura dos descritores

identificação do dispositivo

Plug and Play

associação/carregamento de drivers

dispositivo pronto

Se a comunicação falha nas primeiras etapas, simplesmente reinstalar o software do fabricante pode não resolver.

Para entender o problema corretamente, precisamos conhecer algo chamado:

enumeração USB.


O que significa “descritor de dispositivo”?

Um equipamento USB precisa fornecer ao host informações estruturadas sobre si mesmo.

Essas informações fazem parte dos chamados:

USB descriptors.

Um dos principais é:

Device Descriptor.

Ele fornece informações fundamentais necessárias para que o host compreenda características básicas daquele dispositivo USB.


O Windows não adivinha o que você conectou

Quando você conecta um dispositivo, o Windows não olha fisicamente para ele e pensa:

“Isso parece uma webcam Logitech.”

A identificação acontece através do protocolo USB.

O dispositivo precisa responder corretamente às solicitações feitas pelo host.


Antes do driver existe comunicação USB básica

Esse é um conceito essencial para diagnosticar esse erro.

Imagine:

Windows

USB Host Controller

Root Hub / Hub

porta

cabo/conector

dispositivo USB

Antes de um driver específico controlar plenamente o equipamento, essa cadeia precisa funcionar o suficiente para que o dispositivo seja detectado e identificado.


O que acontece quando conectamos um USB?

A sequência real possui muitos detalhes e varia conforme a geração e arquitetura USB, mas podemos construir uma representação didática.

Quando um periférico é conectado, existe uma sequência semelhante a:

  1. conexão física;
  2. detecção do dispositivo;
  3. inicialização/reset apropriado;
  4. comunicação pelo endpoint de controle;
  5. obtenção dos descritores;
  6. atribuição/configuração necessária;
  7. identificação;
  8. Plug and Play;
  9. associação com drivers.

Essa sequência ajuda a localizar o erro.


O que é enumeração USB?

Enumeração é o processo pelo qual o host descobre e configura um dispositivo USB conectado.

Durante esse processo, o host obtém informações necessárias para saber com que tipo de equipamento está se comunicando.


O dispositivo precisa responder

Não basta estar recebendo energia.

Ele precisa responder corretamente às solicitações do host.

Essa diferença explica um sintoma muito comum:

“A luz acende, mas o Windows não reconhece.”


Receber energia não significa transmitir dados

Uma porta USB transporta energia e comunicação, conforme o padrão e a implementação.

Um equipamento pode:

  • acender LED;
  • carregar bateria;
  • ligar motor;
  • energizar circuito;

e ainda assim falhar na comunicação de dados.

Portanto:

LED aceso ≠ comunicação USB funcionando.


E celular carregando também não prova que o cabo transmite dados

Existem cabos e situações em que alimentação funciona, mas comunicação não.

Além disso, um cabo danificado pode manter determinados condutores funcionando enquanto outros apresentam problema.


O que é Device Descriptor?

O Device Descriptor contém campos que ajudam o host a compreender o dispositivo.

Entre as informações relacionadas à identificação USB estão valores como:

  • Vendor ID;
  • Product ID;
  • versão USB;
  • classe, quando aplicável;
  • informações relacionadas a configurações e outros descritores.

O que é VID?

VID significa:

Vendor ID.

É um identificador associado ao fornecedor/fabricante dentro do ecossistema USB.

Em Hardware IDs podemos encontrar algo semelhante a:

VID_1234


O que é PID?

PID significa:

Product ID.

É utilizado juntamente com outras informações para identificar determinado produto ou família de dispositivos daquele fornecedor.

Exemplo conceitual:

VID_1234&PID_5678


Por que VID e PID são importantes?

O Windows utiliza informações de identificação do dispositivo durante o processo Plug and Play e associação com drivers.

Um Hardware ID pode assumir uma estrutura semelhante a:

USB\VID_1234&PID_5678

Esse exemplo é fictício.


Mas e se o Windows não consegue ler corretamente o descritor?

Aí temos o ponto central deste artigo.

Se a comunicação necessária para obter as informações básicas falha, o Windows pode não conseguir chegar a uma identificação normal do periférico.

O resultado pode aparecer como:

Dispositivo USB desconhecido

e, especificamente:

Falha na solicitação de descritor de dispositivo.


O erro não significa simplesmente “driver errado”

Essa distinção é extremamente importante.

Compare dois cenários.

Cenário A — Dispositivo identificado

O Windows consegue determinar informações como fabricante/produto e cria a instância correspondente, mas existe problema com o driver.

Cenário B — Device Descriptor Request Failed

A comunicação inicial necessária para identificar corretamente o dispositivo já apresentou falha.

No cenário B, procurar imediatamente um driver específico pode não atacar a origem.


Por que a solicitação do descritor pode falhar?

Existem várias possibilidades:

  • dispositivo com defeito;
  • cabo com problema;
  • conector danificado;
  • porta USB problemática;
  • hub defeituoso;
  • alimentação inadequada;
  • mau contato;
  • firmware do periférico;
  • problema no controlador/hub USB;
  • determinadas condições de energia;
  • incompatibilidade específica.

Precisamos separar essas hipóteses através de testes.


Não existe uma única causa para o Código 43

Em algumas situações, esse problema aparece associado ao:

Código 43

no Gerenciador de Dispositivos.

O Código 43, por si só, não identifica automaticamente qual componente físico está defeituoso.

É necessário observar a mensagem e o contexto.


Primeiro teste: desconecte e conecte novamente

Parece básico, mas faz sentido.

Ao reconectar o dispositivo, você força uma nova tentativa de detecção e enumeração.

Observe se:

  • sempre falha;
  • funciona ocasionalmente;
  • muda conforme a posição do conector.

Se mexer no cabo muda o problema, atenção

Isso aumenta a suspeita sobre:

  • cabo;
  • conector;
  • porta;
  • solda.

Não é uma prova definitiva, mas é uma pista importante.


Segundo teste: use outra porta USB

Este é um dos testes mais valiosos.

Se temos:

porta A → falha

porta B → funciona

o dispositivo demonstrou que consegue enumerar em pelo menos outra condição.

Agora devemos investigar a diferença entre os caminhos.


Mas “outra porta” pode significar mais do que parece

Duas portas externas podem pertencer a:

  • hubs internos diferentes;
  • controladores diferentes;
  • gerações USB diferentes;
  • caminhos físicos diferentes.

Por isso, trocar de porta é um teste diagnóstico real.


Teste portas traseiras do desktop

Em computadores de mesa, portas traseiras da placa-mãe podem fornecer um caminho mais direto que determinadas portas frontais.

As portas frontais dependem de:

  • cabo interno;
  • header USB;
  • painel frontal;
  • conectores adicionais.

Se funciona atrás e falha na frente

Investigue:

dispositivo

porta frontal

cabo interno

header da placa-mãe

O problema pode não estar no Windows.


Terceiro teste: elimine hubs

Se o dispositivo está conectado através de:

  • hub USB;
  • dock;
  • monitor com hub;
  • teclado com USB integrado;
  • extensor;

conecte-o diretamente ao computador.


Por que hub pode causar problema?

Porque ele adiciona outra camada:

host

root hub

hub externo

dispositivo

Além da comunicação, existe a questão de alimentação.


Hub sem fonte pode dividir recursos de alimentação

Um hub alimentado pelo próprio barramento precisa trabalhar dentro das condições de energia disponíveis.

Dispositivos mais exigentes podem apresentar problemas dependendo da configuração.


Hub com fonte também pode dar defeito

Ter alimentação externa não garante que:

  • fonte está boa;
  • controlador está bom;
  • cabo upstream está bom.

Teste direto continua importante.


Quarto teste: troque o cabo

Quando o dispositivo possui cabo removível, esse teste deveria estar entre os primeiros.

Use um cabo:

  • compatível;
  • conhecido como funcional;
  • adequado à aplicação.

Cabo que carrega não necessariamente transfere dados corretamente

Esse ponto merece repetição.

A alimentação funcionar não prova integridade das linhas de comunicação.


Comprimento também pode importar

Cabos excessivamente longos ou de qualidade inadequada podem degradar a integridade do sinal.

O efeito depende da velocidade e da implementação USB.


Quinto teste: outro computador

Este é um dos testes mais fortes.

Temos:

Dispositivo A → PC 1 → falha

Agora:

Dispositivo A → PC 2 → ?


Se falha em dois computadores diferentes

A suspeita aumenta sobre:

  • dispositivo;
  • cabo;
  • firmware do equipamento.

Se funciona perfeitamente no segundo computador

A investigação volta para o primeiro PC:

  • portas;
  • controlador;
  • hub;
  • energia;
  • firmware;
  • Windows.

O teste cruzado é melhor que reinstalar tudo

Um bom diagnóstico procura alterar uma variável de cada vez.


Matriz simples

TesteResultado
dispositivo A + porta 1falha
dispositivo A + porta 2falha
dispositivo A + outro PCfalha
dispositivo B + PC originalfunciona

Essa combinação aumenta bastante a suspeita sobre o dispositivo A ou seu cabo.


Agora inverta

TesteResultado
dispositivo A + porta 1falha
dispositivo A + porta 2funciona
outros dispositivos + porta 1também falham

Agora a porta ou seu caminho ganha força como hipótese.


O diagnóstico USB deve seguir evidências

Evite começar com:

  • formatar Windows;
  • instalar programas aleatórios;
  • alterar Registro;
  • comprar outro computador.

Primeiro faça os testes físicos e cruzados.


Como verificar o erro no Gerenciador de Dispositivos

Pressione:

Win + X

Abra:

Gerenciador de Dispositivos

Procure:

Controladores USB (barramento serial universal)

Você pode encontrar:

Dispositivo USB desconhecido (Falha na solicitação de descritor de dispositivo)


Abra Propriedades

Clique com o botão direito:

Propriedades

Observe:

  • Geral;
  • Detalhes;
  • Eventos;
  • Driver.

A guia Eventos pode ajudar

Ela mostra eventos relacionados à instalação/configuração do dispositivo.

Isso ajuda a construir uma linha do tempo.


Hardware IDs podem estar incompletos

Quando a enumeração falha cedo, talvez você não obtenha os mesmos identificadores que apareciam quando o dispositivo funcionava corretamente.

Isso faz sentido.

O host não conseguiu obter todas as informações necessárias.


Não procure VID/PID inexistente como se fosse um driver

Se o dispositivo não forneceu corretamente sua identificação, o problema pode estar antes da associação normal do driver.


O que é endpoint 0?

Todo dispositivo USB possui um endpoint de controle padrão, frequentemente chamado de:

Endpoint 0.

Ele participa das transferências de controle necessárias à enumeração.


Control transfers são fundamentais

Durante a enumeração, o host utiliza transferências de controle para solicitar informações e configurar o dispositivo.

Se essa comunicação básica falha, a enumeração pode parar.


O que são USB descriptors?

Existem diferentes tipos de descritores.

Entre eles podemos encontrar:

  • Device Descriptor;
  • Configuration Descriptor;
  • Interface Descriptor;
  • Endpoint Descriptor;
  • String Descriptors.

Eles descrevem diferentes aspectos do dispositivo.


Device Descriptor não contém “tudo”

Outro cuidado técnico importante.

Não devemos imaginar um único pacote dizendo absolutamente tudo sobre o periférico.

A arquitetura usa vários descritores relacionados.


Configuration Descriptor

Ajuda a descrever configurações e estruturas associadas ao dispositivo.


Interface Descriptor

Descreve interfaces oferecidas dentro de uma configuração.

Um único dispositivo físico pode possuir várias interfaces.


Exemplo: dispositivo USB composto

Uma webcam pode oferecer diferentes funções.

Outro exemplo é um headset USB que pode envolver:

  • áudio;
  • controles;
  • outras interfaces.

O Windows pode lidar com várias interfaces pertencentes ao mesmo dispositivo físico.


O que é USB Composite Device?

É um dispositivo USB que apresenta múltiplas interfaces/funções sob o mesmo dispositivo.

No Gerenciador de Dispositivos, você pode encontrar referências a:

USB Composite Device.


Um periférico pode carregar vários drivers

Por isso:

“qual é o driver desse USB?”

pode ter uma resposta mais complexa.


Classes USB

Muitos equipamentos seguem classes padronizadas.

Exemplos incluem:

  • HID;
  • Mass Storage;
  • Audio;
  • Video.

HID

Human Interface Device.

Inclui muitos:

  • teclados;
  • mouses;
  • controles.

O Windows possui suporte de classe para diversos dispositivos desse tipo.


Mass Storage

Pendrives e determinados dispositivos de armazenamento podem utilizar a classe de armazenamento USB.


UVC

USB Video Class é importante para muitas webcams.

Uma webcam compatível pode utilizar suporte de classe sem exigir um enorme pacote proprietário apenas para funcionar de forma básica.


Por isso nem todo USB precisa de driver baixado do fabricante

O Windows possui vários drivers de classe.


E isso reforça o ponto deste artigo

Se a enumeração básica falhou, baixar 15 pacotes de driver pode ser completamente irrelevante.


A alimentação USB pode causar falha de enumeração?

Sim.

Se o dispositivo não recebe condições elétricas adequadas para inicializar e comunicar corretamente, a enumeração pode falhar.


Mas não use “falta energia” como explicação para tudo

É apenas uma hipótese.

Precisamos testá-la.


Dispositivos que podem exigir atenção especial

Por exemplo:

  • HDs externos;
  • interfaces de áudio;
  • placas de captura;
  • webcams;
  • determinados adaptadores.

HD externo que fica ligando e desligando

Se ouvimos ciclos de inicialização ou observamos conexão/desconexão repetida, alimentação e cabo merecem investigação.


Mas cuidado com HD mecânico

Ruídos anormais podem indicar problema físico no próprio disco.

Nesse caso, se existem dados importantes, evite insistir em testes agressivos.


“Falha no descritor” pode aparecer após suspensão?

Pode.

Se o problema ocorre especificamente após:

  • suspensão;
  • hibernação;
  • retomada;

a investigação muda.


Agora gerenciamento de energia entra na lista

Windows e hardware podem colocar componentes USB em estados de economia de energia.

Em determinadas combinações de hardware, firmware e driver, a retomada pode apresentar problemas.


USB Selective Suspend

O Windows possui mecanismos de suspensão seletiva USB.

Eles permitem economizar energia sem desligar necessariamente toda a árvore USB.


Isso é especialmente importante em notebooks

Economia de energia influencia autonomia.


Não desative tudo como primeiro teste

Muitos tutoriais recomendam imediatamente:

“Desative a economia de energia de todos os USB Root Hubs.”

Isso não deveria ser o primeiro passo.


Primeiro prove que o problema está relacionado à energia

Compare:

  • boot limpo;
  • após suspensão;
  • conectado à tomada;
  • outra porta;
  • outro dispositivo.

Se só acontece depois de suspensão

Agora temos uma evidência relevante para investigar energia e retomada.


Fast Startup também pode confundir testes

O Windows pode utilizar Inicialização Rápida em determinadas configurações.

Isso significa que:

Desligar

e:

Reiniciar

não devem ser tratados como operações idênticas para todo diagnóstico.


Faça um Reiniciar real

Se o problema desaparece após:

Reiniciar

mas volta depois de determinado ciclo de energia/suspensão, registre isso.


Por que remover o dispositivo no Gerenciador pode ajudar?

Em determinadas situações, remover a instância e permitir nova detecção pode corrigir problemas de configuração do Windows.

Mas isso faz sentido principalmente quando existe evidência de problema lógico.


Como fazer um teste controlado

No Gerenciador de Dispositivos:

  1. identifique corretamente o dispositivo problemático;
  2. escolha desinstalar/remover o dispositivo quando apropriado;
  3. reinicie ou faça nova detecção;
  4. conecte novamente.

Não remova controladores aleatoriamente em computador remoto

Se você estiver prestando suporte remoto, desativar ou remover controladores USB indiscriminadamente pode derrubar:

  • teclado;
  • mouse;
  • rede USB.

Isso pode encerrar sua capacidade de controlar o computador.


USB Root Hub não é simplesmente uma “porta”

Essa confusão é comum.

Um Root Hub faz parte da topologia USB apresentada pelo host controller.

Várias portas físicas podem aparecer organizadas sob diferentes hubs/controladores.


O Gerenciador de Dispositivos não mostra a topologia da maneira mais intuitiva

Para diagnóstico avançado, ferramentas específicas podem ajudar.


USBView

A Microsoft disponibiliza o USBView como ferramenta para visualizar informações e a árvore de dispositivos USB.

Ela é especialmente útil para técnicos.


O que podemos observar?

Dependendo do dispositivo e de quanto da enumeração funcionou:

  • controladores;
  • hubs;
  • portas;
  • descriptors;
  • VID/PID;
  • configurações;
  • velocidade.

USBView não conserta o dispositivo

Ele é uma ferramenta de observação.

Seu valor está em responder:

“O que o host realmente conseguiu enxergar?”


Exemplo de diagnóstico

Temos uma webcam.

Porta traseira USB 3.x

Device Descriptor Request Failed

Outra porta

webcam funciona.

Outro computador

webcam funciona.

Isso reduz bastante a probabilidade de a webcam estar completamente defeituosa.


Agora testamos outro dispositivo na primeira porta

Se ele também falha:

porta/caminho USB ganha força como hipótese.


Outro exemplo

Pendrive:

PC A

falha em todas as portas.

PC B

falha.

PC C

falha.

Outros pendrives funcionam nos três PCs.

Agora a evidência aponta fortemente para o próprio pendrive.


Não formate o pendrive para resolver falha de descritor

Se o host nem consegue enumerar corretamente o dispositivo, formatação não é a etapa inicial apropriada.


Sistema de arquivos vem depois

Para formatar FAT32, exFAT ou NTFS, o Windows primeiro precisa enxergar o dispositivo de armazenamento adequadamente.


Falha de descritor acontece antes disso

Essa distinção elimina muita tentativa inútil.


“Meu pendrive está RAW” é outro problema

Se aparece como RAW, o dispositivo já foi reconhecido suficientemente para o Windows enxergar armazenamento, mas existe problema em outra camada.


Compare

Device Descriptor Request Failed

Problema muito cedo na comunicação/enumeração.

Unidade RAW

Dispositivo reconhecido, mas estrutura do volume/sistema de arquivos apresenta problema.

São diagnósticos completamente diferentes.


“Letra da unidade sumiu” também é diferente

Se o dispositivo aparece no Gerenciamento de Disco, mas não recebe letra, a enumeração USB provavelmente já avançou muito além do ponto discutido neste artigo.


Isso mostra a importância de localizar a camada

Pergunte sempre:

em qual etapa a cadeia parou?


Cadeia completa

porta

comunicação USB

enumeração

descritores

identificação

PnP

driver

dispositivo lógico

volume/aplicativo

Quanto mais precisamente encontramos a etapa da falha, menos precisamos “tentar coisas”.


Atualização de BIOS/UEFI pode ajudar?

Em alguns casos específicos, fabricantes corrigem problemas relacionados a:

  • USB;
  • controladores;
  • compatibilidade;
  • gerenciamento de energia.

Mas atualizar BIOS não deve ser resposta automática.


Consulte o histórico da versão

Se a documentação menciona correção relacionada ao seu problema, a atualização passa a ter justificativa melhor.


Driver de chipset também merece atenção

Drivers e componentes de plataforma podem influenciar o comportamento do controlador USB.

Use fontes oficiais do fabricante do computador, placa-mãe ou plataforma quando apropriado.


Evite sites aleatórios de “driver updater”

Eles podem:

  • instalar driver incorreto;
  • adicionar software indesejado;
  • dificultar o diagnóstico.

Windows Update também fornece drivers

Em muitos sistemas, drivers adequados chegam pelo próprio Windows Update.


Mas novamente: driver não é sempre o primeiro suspeito

Se:

dispositivo falha em três computadores

um driver específico do primeiro Windows dificilmente explica todo o comportamento.


O poder do teste cruzado

Esse princípio vale para quase qualquer diagnóstico de hardware:

mude uma variável por vez.


Não troque cabo, porta, driver e Windows ao mesmo tempo

Se funcionar depois, você não saberá o que resolveu.


Crie uma pequena tabela

TesteResultado
porta originalfalha
segunda portafalha
cabo Bfunciona
cabo original novamentefalha

Isso praticamente transforma uma suspeita vaga em evidência reproduzível.


E se funciona depois de alguns minutos?

Investigue:

  • contato;
  • temperatura;
  • alimentação;
  • estado de energia;
  • firmware.

Comportamento intermitente é informação, não “azar”.


E se só funciona após reiniciar?

Investigue o estado lógico da pilha USB e gerenciamento de energia.


E se só funciona depois de desligar completamente?

Isso pode indicar diferença entre reset de software e ciclo completo de energia.

É uma pista útil para controladores e dispositivos que ficam em estados problemáticos.


Não confunda correlação com causa

Se desligar por dez minutos resolveu uma vez, isso não prova automaticamente:

“era energia residual.”

Repita o teste antes de concluir.


Um bom diagnóstico precisa ser reproduzível

Quanto mais conseguimos repetir:

condição X → falha

condição Y → funciona

mais perto estamos da causa.


O principal aprendizado

A mensagem:

Dispositivo USB desconhecido (Falha na solicitação de descritor de dispositivo)

não deve ser interpretada simplesmente como:

“instale o driver.”

Ela indica que precisamos olhar para uma etapa muito anterior da cadeia USB.

A pergunta correta passa a ser:

por que o host não conseguiu obter corretamente as informações necessárias durante a enumeração do dispositivo?

A partir daí, porta, cabo, alimentação, hub, dispositivo, controlador, firmware e software podem ser testados de forma organizada.

Device Descriptor, VID, PID, endpoints e como o Windows identifica um dispositivo USB

Na primeira parte vimos que a mensagem:

Dispositivo USB desconhecido (Falha na solicitação de descritor de dispositivo)

não deve ser interpretada automaticamente como simples ausência de driver.

Agora precisamos aprofundar exatamente o que o Windows tenta descobrir quando um dispositivo USB é conectado.

Essa etapa é importante porque existe uma diferença enorme entre:

Windows identificou o dispositivo, mas o driver falhou

e:

Windows nem conseguiu identificar corretamente o dispositivo

Para entender essa diferença, precisamos entrar nos USB Descriptors.


O que são USB Descriptors?

Descriptors são estruturas padronizadas usadas para fornecer informações sobre um dispositivo USB.

Podemos pensar neles como uma espécie de conjunto estruturado de informações que permite ao host compreender:

  • características do dispositivo;
  • configurações disponíveis;
  • interfaces;
  • endpoints;
  • identificadores;
  • informações textuais.

Não existe apenas um descritor.

Existem vários.

Entre os mais importantes:

  • Device Descriptor;
  • Configuration Descriptor;
  • Interface Descriptor;
  • Endpoint Descriptor;
  • String Descriptor.

A hierarquia dos descriptors

Uma representação conceitual é:

Device

Configuration

Interface

Endpoint

Isso ajuda a entender a arquitetura.

Um dispositivo pode possuir:

  • uma ou mais configurações;
  • uma configuração com várias interfaces;
  • interfaces com vários endpoints.

O Device Descriptor fica no topo

Ele fornece informações básicas sobre o dispositivo.

Entre seus campos encontramos conceitos como:

  • versão USB;
  • classe;
  • identificador do fabricante;
  • identificador do produto;
  • versão do dispositivo;
  • quantidade de configurações.

bLength

Descriptors começam com informações que permitem ao host interpretar sua estrutura.

Um dos campos é:

bLength

Ele informa o tamanho daquele descriptor.


bDescriptorType

Outro campo identifica qual tipo de descriptor está sendo apresentado.

Isso permite ao host saber se está interpretando:

  • Device;
  • Configuration;
  • Interface;
  • Endpoint;
  • String;

ou outro tipo definido pela especificação correspondente.


bcdUSB

Um campo bastante interessante é:

bcdUSB

Ele indica a versão da especificação USB com a qual o dispositivo declara conformidade naquele contexto.


Não confunda isso com velocidade negociada

Encontrar uma determinada versão declarada não significa automaticamente que o dispositivo esteja naquele instante transferindo dados na velocidade máxima associada popularmente àquela geração.

Versão, capacidades e velocidade efetivamente negociada precisam ser interpretadas corretamente.


bDeviceClass

Esse campo pode indicar uma classe associada ao dispositivo.

Mas existe uma nuance importante.

Nem todo equipamento declara sua classe principal diretamente no Device Descriptor.


A classe também pode aparecer na interface

Em muitos dispositivos, as informações de classe relevantes ficam nos:

Interface Descriptors.

Por isso, interpretar apenas um campo isolado pode gerar conclusão errada.


bDeviceSubClass e bDeviceProtocol

Esses campos complementam informações de classe e protocolo quando aplicáveis.

Eles ajudam o host a compreender como tratar o dispositivo dentro da arquitetura de classes USB.


idVendor

Agora chegamos ao conhecido:

VID — Vendor ID.

No Device Descriptor existe o campo:

idVendor

Ele identifica o fornecedor dentro do sistema de identificação USB.


idProduct

Temos também:

idProduct

que corresponde ao:

PID — Product ID.


VID + PID ajudam a identificar o equipamento

Conceitualmente:

VID_1234

PID_5678

produto do fabricante

Esses valores aparecem frequentemente nos Hardware IDs do Windows.


Exemplo fictício

Podemos encontrar algo como:

USB\VID_1234&PID_5678

Não use esse exemplo para procurar um equipamento real; ele serve apenas para mostrar a estrutura.


bcdDevice

Outro campo pode indicar uma revisão do dispositivo.

Isso pode ajudar a diferenciar revisões de hardware ou firmware conforme a implementação do fabricante.


iManufacturer

O Device Descriptor pode apontar para um String Descriptor contendo o nome do fabricante.


iProduct

Pode apontar para uma string relacionada ao nome do produto.


iSerialNumber

Pode apontar para um número de série USB.

Esse campo é especialmente interessante para entender por que o Windows consegue distinguir algumas unidades físicas idênticas.


Número de série USB é muito importante

Imagine dois dispositivos:

VID = igual

PID = igual

Se cada um possui um número de série único, o sistema pode distingui-los de maneira mais consistente.


E se não existe serial único?

O Windows pode precisar utilizar outras informações, incluindo a topologia/localização da conexão, para construir a identidade da instância.


Isso ajuda a explicar outro comportamento

Você troca um equipamento USB de porta e o Windows parece:

“instalar novamente.”

Isso pode acontecer porque a identidade da instância pode depender de mais informações que simplesmente VID e PID.


Device Instance ID

O Windows mantém uma identificação para a instância específica do dispositivo.

Não devemos confundir:

Hardware ID

com:

Device Instance ID.


Hardware ID

Ajuda a descrever o tipo/modelo de hardware para fins de correspondência.


Device Instance ID

Identifica uma instância específica dentro da árvore Plug and Play.


Por que isso importa para impressoras?

Quem trabalha com impressoras USB pode já ter visto:

  • impressora;
  • impressora (Cópia 1);
  • impressora (Cópia 2).

Existem várias causas possíveis para duplicações, mas mudanças de instância e conexão podem participar de determinados cenários.


Não culpe o USB sozinho por toda impressora duplicada

Fila de impressão, driver, software do fabricante e histórico de instalação também podem participar.

Precisamos analisar o caso.


Configuration Descriptor

Depois das informações gerais do dispositivo, temos a descrição de configurações.

Uma configuração descreve como determinadas interfaces e recursos estão organizados.


Um dispositivo pode oferecer mais de uma configuração

A especificação permite isso, embora muitos dispositivos comuns trabalhem normalmente com uma configuração principal.


bNumInterfaces

Dentro da configuração podemos encontrar informações sobre a quantidade de interfaces.


O que é uma interface USB?

Uma interface representa uma função lógica oferecida pelo dispositivo.

Isso é fundamental para equipamentos compostos.


Exemplo: headset USB

Um headset pode precisar oferecer diferentes funcionalidades.

Conceitualmente:

dispositivo físico

interface de áudio

interface de controle

outras interfaces

O Windows pode associar diferentes componentes de driver a essas funções.


Outro exemplo: webcam com microfone

Fisicamente é um único equipamento.

Mas logicamente podemos ter:

vídeo

áudio

Cada função pode aparecer de forma distinta no Windows.


Por isso um USB pode funcionar parcialmente

Imagine uma webcam:

  • microfone funciona;
  • câmera não funciona.

Isso significa que o dispositivo não está simplesmente “100% reconhecido” ou “100% desconhecido”.

Uma interface pode estar funcionando enquanto outra apresenta problema.


Isso é diferente de Device Descriptor Request Failed

Se o host falha muito cedo na identificação básica do dispositivo, podemos nem chegar normalmente à etapa de configurar essas interfaces.


Interface Descriptor

O Interface Descriptor descreve determinada interface.

Entre as informações importantes estão:

  • número da interface;
  • classe;
  • subclasse;
  • protocolo;
  • quantidade de endpoints.

bInterfaceClass

Esse campo ajuda a identificar a classe da interface.


Classes padronizadas são muito importantes

Elas permitem que diferentes fabricantes criem dispositivos seguindo um modelo comum.


Exemplo: HID

HID significa:

Human Interface Device.

Muitos:

  • teclados;
  • mouses;
  • controles;

utilizam essa classe.


Por isso mouse simples funciona sem baixar pacote enorme

O Windows possui drivers de classe capazes de atender muitos dispositivos padronizados.


USB Mass Storage

Outra classe conhecida está relacionada a armazenamento USB.

Pendrives e outros dispositivos podem utilizar drivers de classe.


USB Audio

Interfaces de áudio também podem seguir classes USB padronizadas.


USB Video Class

UVC permite que muitas webcams funcionem com drivers de classe compatíveis.


Driver genérico não significa driver ruim

Um driver fornecido pelo Windows para uma classe padronizada pode ser exatamente a solução correta.


Software do fabricante pode adicionar recursos

Por exemplo:

  • configurações;
  • efeitos;
  • atualização de firmware;
  • controles adicionais.

Mas isso não significa que o driver básico seja necessariamente proprietário.


Endpoint Descriptor

Agora chegamos aos endpoints.

Um endpoint é uma origem ou destino lógico de comunicação dentro de um dispositivo USB.


Endpoint não é porta física

Esse é um erro comum.

Quando falamos:

Endpoint 1

não estamos falando da:

porta USB número 1 do computador.

São conceitos completamente diferentes.


Endpoint 0 é especial

Todo dispositivo USB possui o endpoint de controle padrão:

Endpoint 0.

Ele participa das transferências de controle fundamentais para configuração e enumeração.


Por isso EP0 é crítico

Antes de o Windows utilizar normalmente as funções específicas do periférico, precisa existir comunicação de controle adequada.


Control Transfer

Transferências de controle são usadas para tarefas como:

  • obter descriptors;
  • definir endereço;
  • configurar dispositivo.

GET_DESCRIPTOR

Durante a enumeração, o host pode realizar solicitações para obter descriptors.

Conceitualmente:

Host

GET_DESCRIPTOR

Dispositivo

resposta

Se essa troca falha, a enumeração pode parar.


É aqui que a mensagem do artigo começa a fazer sentido

Device Descriptor Request Failed

significa que a tentativa necessária de obter corretamente informações do dispositivo não foi concluída como esperado.


Por que o dispositivo não respondeu?

As causas podem estar em várias camadas.


Possibilidade 1 — Dispositivo não inicializou corretamente

O circuito recebeu energia, mas seu firmware ou controlador não entrou no estado esperado.


Possibilidade 2 — Comunicação elétrica problemática

Cabo, conector ou porta podem degradar o sinal.


Possibilidade 3 — Alimentação instável

O dispositivo pode iniciar parcialmente e depois falhar.


Possibilidade 4 — Firmware travado

Um microcontrolador interno pode não responder corretamente.


Possibilidade 5 — Hub intermediário

Um hub pode introduzir problema de:

  • comunicação;
  • alimentação;
  • compatibilidade.

Possibilidade 6 — Estado problemático do controlador

Em determinadas situações, a pilha/controlador USB do computador pode entrar em condição anormal.


Mas como saber qual delas?

Com:

teste cruzado.

Não com adivinhação.


String Descriptors

Além dos descritores estruturais, dispositivos podem fornecer strings.

Exemplos:

  • fabricante;
  • produto;
  • número de série.

String Descriptor é obrigatório para tudo?

Não devemos assumir que todo dispositivo terá todas as strings possíveis.

Existem campos opcionais e implementações diferentes.


Por isso ausência de nome bonito não significa necessariamente defeito

Alguns dispositivos apresentam descrições genéricas.


O que o Windows faz com VID e PID?

Esses identificadores podem participar da construção dos Hardware IDs utilizados pelo Plug and Play.


Como visualizar Hardware IDs no Windows 11

Abra:

Gerenciador de Dispositivos

Propriedades

Detalhes

IDs de Hardware

Dependendo do dispositivo, aparecerão entradas correspondentes.


Exemplo conceitual

USB\VID_1234&PID_5678&REV_0100

USB\VID_1234&PID_5678

O Windows pode utilizar diferentes níveis de especificidade durante a correspondência.


Compatible IDs

Além de Hardware IDs, o Windows pode trabalhar com:

Compatible IDs.

Eles ajudam na associação com drivers compatíveis, especialmente para classes padronizadas.


Plug and Play procura correspondências

Depois que o dispositivo foi identificado adequadamente, o Windows pode procurar um pacote de driver apropriado.


INF entra aqui

Arquivos INF descrevem informações necessárias para instalação e associação de drivers.


O INF pode conter IDs compatíveis com o hardware

O Windows compara informações do dispositivo com os pacotes disponíveis.


Driver Store

O Windows mantém pacotes de drivers no:

Driver Store.

Isso permite instalar drivers previamente disponibilizados no sistema.


Windows Update pode fornecer outro pacote

Se necessário e permitido pela configuração, o Windows pode obter drivers através do Windows Update.


Mas observe a ordem

descritor

identificação

Hardware IDs

PnP

driver

Isso explica por que uma falha no descritor não é equivalente a:

“Windows encontrou a webcam e não tem driver.”


Como seria um problema típico de driver?

O dispositivo poderia aparecer com seu nome ou IDs adequados, mas apresentar:

  • erro ao iniciar;
  • driver ausente;
  • conflito;
  • código de erro.

Nesse cenário, investigar driver faz muito mais sentido.


Como seria falha de enumeração?

Você encontra:

Unknown USB Device

e o Windows não consegue obter adequadamente a identificação esperada.

Agora cabo, porta, dispositivo, alimentação e controlador ganham prioridade.


Por que Código 43 aparece?

Código 43 é uma indicação de que o Windows interrompeu o dispositivo porque foi informado/detectou que ele apresentou problema.

Mas o contexto e a mensagem específica importam.


Código 43 não é diagnóstico final

Nunca escreva:

Código 43 = dispositivo queimado.

Isso seria simplificação excessiva.


Código 10 é outra coisa

This device cannot start — Code 10

é um cenário diferente.

Nesse caso, o dispositivo pode ter avançado mais no processo e o problema ocorrer durante inicialização do driver/dispositivo.


Código 28 também é diferente

Código 28 geralmente está relacionado à ausência de driver instalado para o dispositivo.

Novamente:

não confunda com falha na solicitação do Device Descriptor.


Diferenciar códigos economiza tempo

Temos:

Device Descriptor Request Failed

Olhar primeiro para enumeração/comunicação.

Code 28

Olhar fortemente para driver ausente.

Code 10

Investigar inicialização do dispositivo/driver.

Code 43

Investigar contexto específico da falha.


USBView pode mostrar os descriptors

Para técnicos, USBView é extremamente útil.

Quando o dispositivo consegue enumerar suficientemente, podemos visualizar informações detalhadas.


O que procurar?

Entre outras coisas:

  • árvore USB;
  • porta;
  • velocidade;
  • Device Descriptor;
  • Configuration Descriptor;
  • interfaces;
  • endpoints;
  • VID/PID.

Quando a enumeração falha cedo

USBView também pode mostrar que determinadas informações não puderam ser obtidas.

Isso é informação diagnóstica.


Como usar USBView conceitualmente

Primeiro observe um dispositivo funcionando.

Depois observe o problemático.

Compare.


Exemplo — Pendrive funcionando

Podemos obter:

Device Descriptor

VID/PID

Configuration

Interface

Endpoints


Pendrive problemático

Talvez apareça apenas uma entrada incompleta ou erro na leitura dos descriptors.

Isso confirma que o problema acontece antes do volume FAT32/NTFS/exFAT.


Gerenciamento de Disco não é primeira ferramenta nesse caso

Se o dispositivo nem enumera, diskmgmt.msc não consegue resolver a comunicação USB.


DiskPart também não

Comandos como:

diskpart

list disk

só ajudam se o armazenamento já estiver sendo apresentado adequadamente ao Windows.


CHKDSK também não

chkdsk trabalha com volumes/sistemas de arquivos.

Ele não repara Device Descriptor.


Isso evita três erros comuns

Quando um pendrive apresenta falha de descritor, não comece com:

diskpart

chkdsk

format

Essas ferramentas atuam em outra camada.


O mesmo vale para impressora

Se uma impressora USB não enumera corretamente, reinstalar a fila de impressão pode não resolver.


Primeiro o USB precisa existir

A cadeia seria:

USB reconhecido

interface de impressão

driver

spooler

fila

Se falhou no primeiro estágio, mexer no spooler pode ser irrelevante.


Webcam segue a mesma lógica

USB

UVC/interface

driver

aplicativo

Se Device Descriptor falha, redefinir permissões da câmera no Windows provavelmente não resolve a causa.


Áudio USB também

USB

interface de áudio

driver

Windows Audio

aplicativo

Precisamos saber em qual camada ocorre a falha.


A topologia USB importa

Uma porta física não existe isoladamente.

Podemos ter:

Host Controller

Root Hub

Hub interno

porta física

Hub externo

dispositivo


Notebook pode possuir hubs internos invisíveis

Webcam interna, Bluetooth, leitor e outros componentes podem utilizar internamente interfaces USB mesmo sem cabo externo visível.


Isso explica dispositivos USB “internos”

O Gerenciador de Dispositivos pode mostrar USB mesmo quando você não conectou nada externamente.


Bluetooth interno frequentemente pode estar ligado via USB

Dependendo da plataforma, parte de um módulo sem fio pode utilizar internamente uma interface USB.


Se Bluetooth desaparece após problema USB

Não conclua imediatamente que o rádio morreu.

Pode existir relação com a topologia/controlador.


Visualizar por conexão ajuda

No Gerenciador de Dispositivos, diferentes modos de exibição podem ajudar a compreender relações entre dispositivos.


Mas USBView é melhor para topologia USB detalhada

Ele foi feito especificamente para esse tipo de inspeção.


O que é velocidade negociada?

Um dispositivo pode suportar determinada geração, mas operar em uma velocidade inferior dependendo de:

  • porta;
  • cabo;
  • hub;
  • negociação.

USB 3.x pode cair para USB 2.0?

Sim, dependendo da conexão e das capacidades disponíveis.


Isso pode acontecer sem desaparecer completamente

Esse é outro ponto importante.

Falha nas linhas SuperSpeed não significa necessariamente falha total da comunicação USB 2.0 em determinadas arquiteturas/conexões.


Por isso porta USB 3.x pode parecer “funcionar devagar”

Ela pode estar operando em uma condição inferior à esperada.


Mas isso é diferente de Device Descriptor Request Failed

Uma conexão funcionando em velocidade menor ainda conseguiu estabelecer comunicação.


Novamente: identifique a camada

Funciona, mas lento

Investigue velocidade/interface.

Não identifica e mostra Unknown USB Device

Investigue enumeração.


Cabo USB-C torna tudo ainda mais complexo

USB-C descreve o conector, não uma única velocidade universal.

Cabos USB-C podem suportar capacidades diferentes.


Nem todo USB-C possui as mesmas funções

Dependendo da implementação, podem variar:

  • velocidade de dados;
  • potência;
  • modos alternativos.

Por isso “o conector encaixa” não prova compatibilidade completa

Esse tema merece um artigo próprio.


USB Descriptor não é EDID

Como acabamos trabalhando com vídeo, vale separar conceitos.

USB Descriptor descreve dispositivos USB.

EDID é utilizado no contexto de displays para informar capacidades do monitor.

São mecanismos diferentes.


O princípio abstrato é parecido

Em ambos os casos, existe uma fase de descoberta de capacidades.

Mas não devemos misturar os protocolos.


O que acontece se VID/PID estiver corrompido?

Se firmware ou comunicação fornecer dados incorretos, o Windows pode identificar o dispositivo de maneira errada ou não conseguir completar a enumeração.


Firmware de periférico pode causar isso?

Sim.

Alguns equipamentos possuem firmware atualizável.

Uma falha pode impedir inicialização normal.


Atualizar firmware quando o dispositivo nem enumera?

Depende do produto.

Alguns possuem:

  • modo de recuperação;
  • bootloader;
  • procedimento específico.

Não tente firmware aleatório.


Use apenas firmware do modelo exato

Uma atualização incorreta pode inutilizar o dispositivo.


E se VID/PID aparecer como zero ou valores estranhos?

Não conclua imediatamente que “a EEPROM queimou”.

Primeiro descarte:

  • ferramenta interpretando errado;
  • cabo;
  • porta;
  • comunicação incompleta.

Diagnóstico precisa ser conservador

Quanto mais baixo o nível do problema, mais importante evitar conclusões sem evidência.


Teste A/B continua sendo a melhor ferramenta

Exemplo:

Cabo A

Device Descriptor falha.

Cabo B

VID/PID aparecem corretamente.

Cabo A novamente

falha.

Agora temos uma evidência forte contra o cabo A.


Outro exemplo

Porta A

falha.

Porta B

funciona.

Outro dispositivo na porta A

também falha.

Porta/caminho A ganha força.


Outro exemplo

PC A

falha.

PC B

falha.

Cabo novo

falha.

Outros dispositivos

funcionam nos dois PCs.

Agora o próprio periférico ganha força.


Isso é diagnóstico técnico

Não é:

“tente dez soluções até funcionar.”

É:

“mude uma variável, registre o resultado e elimine hipóteses.”

Diagnóstico avançado no Windows 11: USBView, eventos, SetupAPI, energia, controladores e testes que realmente ajudam

Nas duas primeiras partes, vimos que a mensagem:

Dispositivo USB desconhecido (Falha na solicitação de descritor de dispositivo)

aponta para uma falha muito cedo na cadeia USB.

Também vimos que o Windows precisa passar por etapas como:

conexão

detecção

enumeração

Device Descriptor

VID/PID

Plug and Play

driver

A partir daqui, podemos montar um diagnóstico mais técnico.

O objetivo não é sair modificando configurações aleatoriamente.

É descobrir:

em qual camada a comunicação está falhando?


Comece pelo teste físico mais simples

Antes de abrir qualquer ferramenta do Windows:

  1. desconecte o dispositivo;
  2. conecte novamente;
  3. teste outra porta;
  4. elimine hubs e docks;
  5. troque o cabo, quando possível;
  6. teste outro computador.

Esses testes continuam sendo mais importantes que muitas alterações de software.


Por que começar pelo hardware?

Porque uma falha de descritor pode surgir quando o host nem consegue completar corretamente a comunicação básica com o periférico.

Se o mesmo dispositivo falha em três computadores diferentes, reinstalar o Windows do primeiro PC não faz sentido como primeira ação.


Teste portas de controladores diferentes

Em desktops, procure comparar:

  • portas traseiras da placa-mãe;
  • portas frontais;
  • USB 2.0;
  • USB 3.x;
  • USB-C, quando disponível.

O objetivo não é afirmar que uma geração é “melhor”.

É verificar se o comportamento muda conforme o caminho físico.


Exemplo

USB frontal → Device Descriptor Request Failed

USB traseira → funciona

Agora precisamos investigar:

  • painel frontal;
  • cabo interno;
  • header;
  • alimentação;
  • integridade da porta.

Se só uma porta falha, não culpe o Windows inteiro

Essa distinção parece óbvia, mas evita muita formatação desnecessária.


Abra o Gerenciador de Dispositivos

Use:

Win + X

Gerenciador de Dispositivos

Expanda:

Controladores USB (barramento serial universal)

Procure a entrada problemática.


Observe o nome exato

Pode aparecer:

Dispositivo USB desconhecido (Falha na solicitação de descritor de dispositivo)

ou outro erro USB.

O texto importa.


Abra Propriedades → Geral

Observe:

  • status;
  • código de erro;
  • mensagem apresentada.

Não trate todos os Códigos 43 como iguais.


Abra Propriedades → Detalhes

Experimente propriedades como:

  • IDs de Hardware;
  • IDs Compatíveis;
  • Caminho da instância do dispositivo;
  • ID da instância do dispositivo;
  • Localização;
  • Caminhos de localização.

Quando a enumeração falha cedo, algumas informações podem estar incompletas ou genéricas.

Isso é uma pista.


Compare com o mesmo dispositivo funcionando

Esse teste é excelente.

Se o periférico funciona em outro PC, abra as propriedades lá e compare:

  • VID;
  • PID;
  • descrição;
  • instância;
  • fabricante.

Quando funciona, VID/PID aparecem corretamente

Quando falha no descritor, a identificação pode não chegar ao mesmo estágio.

Essa diferença ajuda a confirmar que estamos investigando enumeração e não simplesmente um driver ausente.


Exibição por conexão

No Gerenciador de Dispositivos, altere a visualização para:

Dispositivos por conexão

Isso ajuda a visualizar em qual controlador ou hub determinado dispositivo está conectado.


A árvore pode revelar um padrão

Imagine:

Controlador A

→ vários dispositivos funcionando

→ dispositivo problemático

Agora compare com:

Controlador B

→ dispositivo funciona

Isso ajuda a separar caminhos.


USBView entra aqui

Para análise mais detalhada, o USBView é uma ferramenta muito útil.

Ela mostra a topologia USB com mais profundidade.


O que você pode encontrar no USBView?

Dependendo de quanto o dispositivo conseguiu enumerar:

  • Host Controller;
  • Root Hub;
  • porta;
  • Device Descriptor;
  • Configuration Descriptor;
  • Interface Descriptor;
  • Endpoint Descriptor;
  • VID;
  • PID;
  • velocidade.

Compare dispositivo bom e ruim

Esse método é mais útil que simplesmente olhar números isolados.

Estado funcionando

Pode mostrar:

VID/PID válidos

configuração

interfaces

endpoints

Estado problemático

Pode mostrar:

descritor incompleto

erro

ou ausência de várias informações.


Isso revela em que ponto o processo parou

Se o host nem conseguiu obter Device Descriptor adequadamente, você já sabe que o problema acontece antes de:

  • volume;
  • aplicativo;
  • fila de impressão;
  • software do fabricante.

SetupAPI.dev.log

O Windows mantém logs relacionados à instalação e configuração Plug and Play.

Um arquivo particularmente útil é:

C:\Windows\INF\setupapi.dev.log

Esse arquivo pode conter informações valiosas quando o Windows cria ou configura instâncias de dispositivos.


O que procurar?

Não abra o arquivo e leia tudo do começo ao fim.

Ele pode ser grande.

Use:

  • horário aproximado;
  • ID de instância;
  • VID/PID, quando disponíveis;
  • nome do dispositivo.

Faça um teste com horário controlado

Por exemplo:

  1. anote 14:32;
  2. conecte o USB;
  3. deixe o erro acontecer;
  4. abra o log;
  5. procure registros próximos daquele horário.

Isso reduz muito o ruído.


SetupAPI não substitui USBView

Eles respondem perguntas diferentes.

USBView

Mostra o que a camada USB conseguiu enxergar.

SetupAPI

Ajuda a entender o que o Plug and Play fez com a instância.


Se a enumeração falha cedo, o SetupAPI pode ter pouca informação útil

Isso também é significativo.

Não force uma interpretação de driver quando o dispositivo nunca chegou a uma identificação normal.


Visualizador de Eventos

Abra:

eventvwr.msc

Vá para:

Logs do Windows → Sistema

Procure eventos próximos ao momento em que o dispositivo foi conectado.


Não procure apenas pela palavra USB

Eventos relevantes podem vir de diferentes componentes.

O melhor é:

  • reproduzir o erro;
  • anotar horário;
  • filtrar a janela temporal.

Linha do tempo vale mais que uma lista de erros antigos

Um computador pode ter milhares de eventos acumulados.

O fato de existir um erro de meses atrás não significa que ele esteja ligado ao problema atual.


Reliability Monitor pode ajudar?

Em problemas USB puros, ele não é a primeira ferramenta.

Mas, se a conexão do dispositivo provoca:

  • travamento de aplicativo;
  • falha de driver;
  • reinicialização;

o Monitor de Confiabilidade pode fornecer contexto adicional.

Execute:

perfmon /rel


Agora vamos separar energia de comunicação

Muitos tutoriais começam desativando economia de energia.

Faça isso somente depois de observar padrão compatível.


Pergunta 1

O erro acontece:

imediatamente após ligar o computador?

Se sim, suspensão seletiva não é a primeira hipótese.


Pergunta 2

O dispositivo funciona após boot, mas falha depois de suspensão?

Agora gerenciamento de energia ganha força.


Pergunta 3

O dispositivo some depois de horas em idle?

Também vale investigar energia.


USB Selective Suspend

O Windows pode suspender partes da árvore USB para economizar energia.

Isso é especialmente útil em notebooks.


Suspensão seletiva não significa “desligar todas as portas”

A ideia é permitir que determinados dispositivos entrem em estados de baixo consumo sem derrubar toda a controladora.


Por que isso pode dar problema?

Combinações específicas de:

  • hardware;
  • firmware;
  • driver;
  • hub;

podem falhar durante a retomada.


Teste controlado de energia

Não desligue tudo de uma vez.

Compare:

Teste A

Boot novo → dispositivo funciona.

Teste B

Suspensão → retorna → falha.

Teste C

Reiniciar → volta a funcionar.

Agora existe um padrão forte envolvendo retomada.


Propriedades de USB Root Hub

Alguns dispositivos/hubs apresentam a aba:

Gerenciamento de Energia

com a opção semelhante a:

Permitir que o computador desligue este dispositivo para economizar energia

Modificar isso pode ser útil como teste em um problema de retomada já comprovado.


Não faça isso indiscriminadamente

Pode:

  • aumentar consumo;
  • reduzir autonomia;
  • esconder o mecanismo real.

E em suporte remoto existe outro risco

Se você desativar o controlador errado, pode perder:

  • teclado;
  • mouse;
  • rede USB.

Evite alterações agressivas sem acesso local.


Fast Startup

Inicialização Rápida também pode interferir na forma como alguns estados são preservados entre desligamentos.

Por isso, compare:

Reiniciar

com:

Desligar e ligar.


Se Reiniciar resolve, mas Desligar/Ligar não

Registre essa diferença.

Ela pode apontar para estado de driver, firmware ou energia.


Power cycle completo

Em alguns problemas de hardware, remover completamente a alimentação por um período curto pode fazer um dispositivo sair de estado travado.

Mas isso precisa ser testado com cuidado.


Não transforme “energia residual” em explicação universal

Se funcionou uma vez depois de desligar, isso ainda não prova a causa.

Repita o comportamento.


Notebook exige atenção à bateria interna

Mesmo desligado, determinados circuitos continuam alimentados.

Em alguns modelos, existem procedimentos específicos de reset elétrico.

Siga apenas documentação do fabricante.


BIOS/UEFI pode influenciar USB

Firmware de placa-mãe controla aspectos importantes da inicialização da plataforma.

Atualizações podem corrigir:

  • compatibilidade;
  • estabilidade;
  • controladores;
  • problemas de energia.

Atualize BIOS somente com justificativa

Antes de atualizar:

  • confirme o modelo exato;
  • leia notas da versão;
  • faça backup quando apropriado;
  • siga instruções oficiais.

Não use atualização de BIOS como “solução número 1”

Uma porta com conector quebrado não será reparada por firmware.


Drivers de chipset

Em determinadas plataformas, manter os componentes de chipset corretos e atualizados pode ser importante.

Prefira:

  • fabricante do computador;
  • fabricante da placa-mãe;
  • fornecedor oficial da plataforma.

Evite programas genéricos de atualização de driver

Eles podem instalar pacotes incompatíveis ou desnecessários.


Reinstalar USB Root Hub resolve?

Às vezes, remover uma instância e permitir que o Windows a detecte novamente pode corrigir uma configuração problemática.

Mas não é uma solução universal.


Antes de remover qualquer controlador

Tenha certeza de:

  • qual dispositivo está selecionado;
  • se teclado/mouse dependem dele;
  • se você tem acesso local.

Procedimento mais seguro para dispositivo problemático

Quando apropriado:

  1. desconecte o USB;
  2. remova apenas a instância problemática;
  3. reinicie;
  4. conecte novamente;
  5. observe a nova enumeração.

“Excluir driver” é outra decisão

Durante algumas desinstalações, o Windows pode oferecer opção de remover pacote de driver.

Não marque isso automaticamente.

Se o problema não está no driver, você pode apenas criar trabalho adicional.


Driver Store não precisa ser limpo por causa de Device Descriptor Request Failed

Esse é outro conselho exagerado encontrado na internet.

Se o host não consegue nem identificar o equipamento, limpar pacotes de driver não é a primeira ação lógica.


SFC e DISM ajudam?

Comandos como:

SFC /scannow

e:

DISM

são úteis em cenários específicos de integridade do Windows.

Mas não devem ser usados como resposta automática para um erro USB de enumeração.


SFC não repara cabo

Parece óbvio, mas essa é a lógica.

Se:

dispositivo falha em dois PCs

um reparo de arquivos do Windows do PC 1 não resolverá a causa.


CHKDSK também não repara USB Descriptor

CHKDSK trabalha com sistema de arquivos.

Ele não corrige enumeração.


DiskPart também não

DiskPart só é útil depois que o dispositivo de armazenamento já aparece corretamente ao sistema.


Formatação também não

Se o Windows nem sabe qual dispositivo está conectado, FAT32, exFAT ou NTFS ainda nem são o problema principal.


Outra “solução” comum: alterar Registro aleatoriamente

Evite copiar valores de Registro de vídeos sem entender:

  • qual chave;
  • qual componente;
  • qual efeito;
  • como reverter.

Registro não deve substituir diagnóstico físico

Uma porta quebrada continuará quebrada.


Outro conselho perigoso: aumentar alimentação USB por software

O sistema operacional não transforma uma porta fisicamente limitada em uma fonte de alimentação arbitrariamente mais potente.


USB possui regras elétricas e negociação próprias

Não existe um “hack” seguro no Registro para tornar qualquer porta capaz de fornecer qualquer corrente.


Hubs alimentados podem ajudar em alguns casos

Se existe evidência de limitação de alimentação e o dispositivo é adequado para uso via hub, um hub com fonte própria pode ser um bom teste.


Mas ele precisa ser de boa qualidade

Fonte ruim ou controlador ruim adiciona outro problema.


Dispositivo funciona somente via hub alimentado

Isso é uma pista relevante.

Compare:

direto no PC → falha

hub alimentado → funciona

Agora alimentação ou comportamento elétrico merece investigação.


Dispositivo funciona direto, mas falha no hub

Agora o hub é suspeito.


Não ignore o cabo upstream do hub

Ele também faz parte da cadeia.


USB-C merece testes próprios

Em USB-C, precisamos considerar:

  • cabo;
  • orientação/conector;
  • capacidade de dados;
  • negociação;
  • geração USB.

Um cabo USB-C pode carregar e ainda limitar dados

Novamente:

carga ≠ comunicação de dados garantida.


Docks aumentam a complexidade

Um dock pode integrar:

  • USB hub;
  • vídeo;
  • Ethernet;
  • áudio;
  • Power Delivery.

Se um único periférico falha, tente removê-lo da cadeia.


Se tudo no dock falha

Agora investigue:

  • dock;
  • cabo upstream;
  • fonte;
  • porta do notebook;
  • firmware.

Impressoras USB

Em impressoras, existe uma armadilha comum:

usuário vê impressora offline e começa mexendo no spooler.

Antes disso, verifique se o dispositivo USB está enumerando corretamente.


Se aparece como Unknown USB Device

O problema está abaixo da fila de impressão.


Se aparece corretamente como impressora USB

Agora spooler, driver e fila passam a fazer sentido.


Webcams

Se a câmera aparece normalmente no Gerenciador de Dispositivos, mas o aplicativo mostra tela preta, isso é outro diagnóstico.


Device Descriptor Request Failed é anterior

Não misture:

  • enumeração;
  • permissão da câmera;
  • aplicativo.

Áudio USB

Se uma interface aparece em:

Controladores de som

mas não toca áudio, o problema avançou muito além do Device Descriptor.


Armazenamento USB

Se o pendrive aparece em:

diskmgmt.msc

mas sem letra:

enumeração já ocorreu.


Se aparece RAW

Também já ocorreu.

O problema agora está em outra camada.


Se não aparece nem como armazenamento

E existe falha de descritor:

volte para USB físico/enumeração.


Teste cruzado completo

Um diagnóstico organizado pode usar esta matriz.

DispositivoCaboPortaPCResultado
A1traseira 1PC 1falha
A1traseira 2PC 1falha
A2traseira 1PC 1funciona
A1PC 2PC 2falha

Nesse exemplo, o cabo 1 ganha muita força como causa.


Outro exemplo

DispositivoPortaPCResultado
AfrontalPC 1falha
AtraseiraPC 1funciona
BfrontalPC 1falha
BtraseiraPC 1funciona

Agora o caminho frontal merece investigação.


Terceiro exemplo

DispositivoPCResultado
APC 1falha
APC 2falha
APC 3falha
BPC 1funciona

O dispositivo A é fortemente suspeito.


E se o defeito for intermitente?

Intermitência é mais difícil, mas ainda pode ser documentada.

Registre:

  • temperatura;
  • tempo desde o boot;
  • posição do cabo;
  • porta;
  • suspensão;
  • alimentação.

Crie condições reproduzíveis

Exemplo:

sempre falha após 20 minutos

é muito mais útil que:

às vezes para.


Quando suspeitar de conector físico?

Pistas:

  • funciona ao pressionar;
  • desconecta ao mexer;
  • conector folgado;
  • falha em determinado ângulo.

Evite continuar movimentando dispositivo com dados importantes

Em discos externos, conexões repetidamente instáveis podem interromper gravações.

Faça backup assim que conseguir acesso confiável.


Quando suspeitar de firmware do periférico?

Pistas:

  • falha em vários computadores;
  • hardware aparentemente íntegro;
  • fabricante documenta problema conhecido;
  • existe procedimento oficial de recuperação.

Quando suspeitar de controlador do PC?

Pistas:

  • vários dispositivos falham no mesmo grupo de portas;
  • outra controladora funciona;
  • problema segue determinada árvore USB.

Quando suspeitar do Windows?

Pistas:

  • dispositivo funciona no mesmo PC com outro sistema;
  • problema começou após alteração específica;
  • hardware funciona em outras máquinas;
  • reinstância/reconfiguração corrige de forma reproduzível.

Mesmo assim, isso precisa ser comprovado.


Não formate antes de fazer teste cruzado

Um teste em outro PC demora pouco e pode evitar uma reinstalação completamente desnecessária.


Quando uma reinstalação do Windows faz sentido?

Somente depois de evidências fortes de corrupção/configuração sistêmica e após excluir causas físicas mais simples.


Procedimento VMIA de diagnóstico USB

Etapa 1 — Registrar mensagem exata

Não anote apenas:

USB não funciona.

Anote:

Device Descriptor Request Failed

e o código exibido.


Etapa 2 — Trocar porta

Comece com caminho físico diferente.


Etapa 3 — Remover intermediários

Hub, dock e extensor devem sair temporariamente do teste.


Etapa 4 — Trocar cabo

Quando possível.


Etapa 5 — Testar outro PC

Essencial para separar periférico de host.


Etapa 6 — Ver Gerenciador de Dispositivos

Confira o estágio em que a identificação chegou.


Etapa 7 — Inspecionar topologia

Use visualização por conexão e, quando necessário, USBView.


Etapa 8 — Correlacionar logs

Use horário da falha em:

SetupAPI.dev.log

e:

Visualizador de Eventos.


Etapa 9 — Investigar energia apenas se houver padrão

Especialmente após suspensão/retomada.


Etapa 10 — Verificar firmware e drivers oficiais

Chipset, BIOS/UEFI e firmware do periférico quando houver justificativa.


Etapa 11 — Repetir teste

A causa precisa ser reproduzível sempre que possível.


O objetivo é transformar “tentativa e erro” em isolamento de falha

No fim, precisamos conseguir dizer algo como:

O dispositivo funciona em dois computadores quando usamos o cabo B, mas falha em ambos com o cabo A.

Isso é diagnóstico.

Muito melhor que:

reinstalei cinco drivers e agora parece funcionar.

Agora podemos fechar o diagnóstico com uma visão organizada do problema.

A mensagem:

Dispositivo USB desconhecido (Falha na solicitação de descritor de dispositivo)

deve ser interpretada como um problema que pode acontecer muito cedo na comunicação USB.

Isso muda completamente a ordem dos testes.

Em vez de começar com:

  • formatar Windows;
  • reinstalar pacote de impressora;
  • executar CHKDSK;
  • alterar o Registro;
  • baixar driver de site aleatório;

o melhor caminho é descobrir em qual camada a comunicação parou.


Fluxo lógico do USB no Windows 11

Podemos resumir o caminho desta forma:

conexão física

alimentação

detecção da conexão

comunicação USB

enumeração

Device Descriptor

VID/PID

Configuration / Interfaces / Endpoints

Plug and Play

driver

função do dispositivo

aplicativo

Quanto mais cedo a falha acontece, menos sentido faz mexer nas camadas superiores.


Fluxograma de diagnóstico

1. O dispositivo recebe energia?

Observe:

  • LED;
  • display;
  • motor;
  • sinal sonoro;
  • indicação de carga.

Se não recebe energia alguma, investigue primeiro:

  • porta;
  • cabo;
  • fonte;
  • hub;
  • dispositivo.

Se recebe energia, continue

Não conclua:

“A porta está boa.”

Energia não garante dados.


2. O Windows reproduz som de conexão?

Se sim, existe pelo menos alguma detecção de evento.

Mas isso ainda não significa enumeração completa.


3. O dispositivo aparece no Gerenciador de Dispositivos?

Se não aparece de forma alguma, investigue:

  • conexão física;
  • porta;
  • cabo;
  • alimentação;
  • controlador.

4. Aparece como Unknown USB Device?

Agora leia a mensagem exata.

Se aparece:

Falha na solicitação de descritor de dispositivo

o diagnóstico deve se concentrar inicialmente em:

  • enumeração;
  • comunicação;
  • dispositivo;
  • cabo;
  • porta;
  • hub;
  • energia;
  • controlador.

5. O mesmo dispositivo funciona em outra porta?

Sim

A porta/caminho original ganha força como suspeito.

Não

Continue.


6. Funciona com outro cabo?

Sim

O cabo original ganha força.

Não

Continue.


7. Funciona em outro computador?

Sim

Investigue o PC original.

Não

O próprio dispositivo ou seu cabo ganha força como causa.


8. Outros dispositivos funcionam na mesma porta?

Sim

O problema pode ser específico daquele periférico.

Não

A porta, hub ou controlador ganha força.


9. O problema aparece somente depois de suspensão?

Sim

Investigue:

  • USB Selective Suspend;
  • energia;
  • retomada;
  • driver;
  • firmware.

Não

Suspensão perde prioridade.


10. O dispositivo aparece corretamente, mas não funciona?

Agora você provavelmente saiu da etapa de falha de descritor.

Passe a investigar:

  • driver;
  • serviço;
  • aplicativo;
  • configuração específica do equipamento.

Uma tabela útil para separar problemas

SintomaCamada mais provável
Device Descriptor Request Failedenumeração USB
VID/PID aparecem, mas driver não instalaPlug and Play/driver
Code 28driver ausente
Code 10inicialização de driver/dispositivo
unidade RAWsistema de arquivos/volume
unidade sem letramontagem/volume
impressora aparece mas não imprimedriver/spooler/fila/rede ou interface
webcam aparece mas aplicativo não acessaaplicativo/permissão/driver
dispositivo nem recebe energiahardware/alimentação

Code 43 não significa sempre a mesma coisa

Código 43 é uma indicação genérica de problema do dispositivo.

O texto adicional é extremamente importante.

Por isso, não pesquise apenas:

Código 43 USB

Pesquise a condição completa.


Code 10

Code 10 normalmente indica que o dispositivo não conseguiu iniciar adequadamente.

Nesse caso, o Windows pode já ter identificado mais informações do hardware.


Code 28

Code 28 normalmente aponta para falta de driver instalado.

Esse cenário é muito mais diretamente relacionado ao driver do que:

Device Descriptor Request Failed.


RAW

Se uma unidade aparece como RAW, ela já foi identificada como dispositivo de armazenamento.

O problema está depois da enumeração USB.


Unidade sem letra

Se aparece no Gerenciamento de Disco, o USB já passou por várias etapas com sucesso.

Agora verifique:

  • partição;
  • letra;
  • volume;
  • política de montagem.

Cenário 1 — Pendrive com Device Descriptor Request Failed

Imagine:

  • LED acende;
  • Windows faz som;
  • Gerenciador mostra Unknown USB Device;
  • não aparece no Gerenciamento de Disco.

Não comece por:

  • DiskPart;
  • CHKDSK;
  • formato.

Primeiro teste:

  • outra porta;
  • outro computador;
  • outro cabo, se aplicável.

Se falha em vários computadores

Existe forte suspeita de defeito no próprio pendrive.


Dados importantes?

Evite:

  • conectar/desconectar dezenas de vezes;
  • formatar;
  • usar programas de recuperação agressivos.

Se o controlador do pendrive não enumera corretamente, recuperação lógica comum pode nem ser possível.


Cenário 2 — HD externo USB

Sintomas:

  • disco tenta ligar;
  • conexão aparece;
  • desconecta;
  • volta;
  • Device Descriptor Request Failed.

Investigue:

  • cabo;
  • alimentação;
  • case USB;
  • bridge USB-SATA;
  • disco interno.

Não confunda case com disco

Em um HD externo, temos:

USB

bridge USB-SATA

disco

O defeito pode estar na bridge, não necessariamente no HD.


Se existem dados importantes

Evite insistir em ciclos repetidos de energia.

Especialmente se houver:

  • ruídos anormais;
  • dificuldade mecânica;
  • travamentos severos.

Cenário 3 — Impressora USB

Se a impressora aparece como:

Unknown USB Device

não comece pelo spooler.

Primeiro resolva a identificação USB.


Depois que o USB aparece corretamente

Agora podemos investigar:

  • driver;
  • fila;
  • spooler;
  • porta USB da impressora;
  • software do fabricante.

Cenário 4 — Webcam

Se aparece como Unknown USB Device:

investigue USB.

Se aparece corretamente como câmera, mas não funciona no Teams/Zoom/navegador:

agora investigue:

  • permissões;
  • aplicativo;
  • driver;
  • exclusividade;
  • câmera já em uso.

Cenário 5 — Interface de áudio USB

Se nem enumera:

  • cabo;
  • porta;
  • alimentação;
  • firmware.

Se enumera corretamente, mas não há som:

  • endpoint de áudio;
  • driver;
  • dispositivo padrão;
  • taxa de amostragem;
  • modo exclusivo.

São problemas diferentes.


Cenário 6 — Dock USB-C

Se apenas um dispositivo conectado ao dock falha:

teste esse dispositivo direto no computador.

Se tudo falha:

investigue:

  • dock;
  • cabo USB-C;
  • fonte;
  • firmware;
  • porta do notebook.

Cenário 7 — Controle de videogame USB

Se aparece como Unknown USB Device:

não culpe imediatamente o jogo.

O jogo só entra na cadeia muito depois.


Cenário 8 — Leitor de cartão

Precisamos separar:

  • leitor USB;
  • cartão inserido.

Se o leitor nem enumera, o cartão não é o primeiro suspeito.


Cenário 9 — Bluetooth interno desapareceu

Alguns módulos internos utilizam USB para determinadas funções.

Se Bluetooth some junto com erro USB:

  • reinicie;
  • observe controlador;
  • veja topologia;
  • investigue energia e firmware.

Cenário 10 — Dispositivo funciona somente após reiniciar

Isso sugere investigar:

  • estado do controlador;
  • energia;
  • firmware;
  • retomada.

Cenário 11 — Funciona após remover totalmente a energia

Pode indicar estado interno travado.

Mas repita o teste antes de concluir.


Cenário 12 — Funciona em USB 2.0 mas não em USB 3.x

Isso é uma pista importante.

Investigue:

  • cabo;
  • porta;
  • sinal;
  • controlador;
  • geração negociada.

Cenário 13 — Funciona na traseira e falha na frente

Investigue:

  • painel frontal;
  • cabo interno;
  • header USB;
  • montagem física.

Cenário 14 — Funciona direto, mas falha em hub

Suspeite de:

  • hub;
  • alimentação;
  • cabo upstream;
  • compatibilidade.

Cenário 15 — Funciona no hub alimentado, mas não direto

Agora alimentação ou comportamento elétrico merece atenção especial.


Cenário 16 — Falha somente após várias horas

Registre:

  • temperatura;
  • estado de energia;
  • tempo de uso;
  • carga.

Cenário 17 — Falha apenas quando mexe no cabo

Isso é forte pista física.


Cenário 18 — Funciona depois de reinstalar dispositivo no Gerenciador

Pode haver problema lógico de instância/configuração.

Mas repita o teste.

Uma correção única não prova a causa.


Cenário 19 — Aparece VID/PID incorreto ou estranho

Compare em:

  • outra porta;
  • outro PC;
  • USBView.

Não conclua imediatamente que firmware está corrompido.


Cenário 20 — Funciona em outro Windows no mesmo hardware

Isso aumenta a suspeita de:

  • driver;
  • configuração;
  • estado do sistema.

O que não fazer como primeira solução

Não formate o Windows

É medida extrema e frequentemente inútil para esse tipo de falha.


Não use “driver updater” genérico

Prefira sempre fontes oficiais.


Não altere Registro aleatoriamente

Sem entender exatamente o mecanismo.


Não apague Driver Store inteiro

Isso pode criar problemas novos.


Não desative todos os hubs USB

Especialmente em suporte remoto.


Não atualize BIOS sem motivo

Leia a documentação primeiro.


Não force o dispositivo fisicamente

Portas e conectores podem quebrar.


FAQ — Perguntas frequentes

1. O que significa “Falha na solicitação de descritor de dispositivo”?

Significa que o host não conseguiu obter corretamente informações necessárias do dispositivo durante a comunicação/enumeração USB.


2. Isso é sempre problema de driver?

Não.

A falha pode acontecer antes da associação normal do driver específico.


3. Cabo ruim pode causar esse erro?

Sim.

Principalmente se houver problema nas linhas de dados ou integridade do sinal.


4. Uma porta USB com energia pode estar defeituosa?

Sim.

Ela pode fornecer alimentação e falhar na comunicação.


5. Se o LED acende, o USB está funcionando?

Não necessariamente.

LED prova apenas algum nível de alimentação/atividade.


6. Trocar de porta realmente ajuda no diagnóstico?

Sim.

Pode alterar o hub/controlador/caminho físico.


7. Preciso formatar o pendrive?

Não por causa de falha de descritor.

A enumeração vem antes do sistema de arquivos.


8. CHKDSK resolve?

Não diretamente.

CHKDSK trabalha com sistema de arquivos.


9. DiskPart resolve?

Somente se o dispositivo já aparece como armazenamento.


10. Código 43 significa hardware queimado?

Não necessariamente.

É preciso analisar a mensagem completa.


11. Code 28 é a mesma coisa?

Não.

Code 28 costuma estar ligado à ausência de driver.


12. USBView é seguro?

Como ferramenta de visualização, sim.

Ela ajuda a inspecionar topologia e descriptors.


13. Preciso instalar driver do fabricante?

Depende do dispositivo.

Muitos usam drivers de classe do próprio Windows.


14. Windows Update pode resolver?

Pode fornecer drivers e correções em determinados casos.

Mas não corrige cabo quebrado.


15. Atualizar BIOS pode resolver?

Em casos específicos documentados pelo fabricante.

Não como primeira tentativa.


16. Suspensão seletiva USB pode causar problema?

Pode contribuir em determinados cenários de retomada.


17. Devo desativar suspensão seletiva?

Somente como teste quando houver evidência relacionada a energia/retomada.


18. Um hub USB pode causar falha?

Sim.

Por comunicação, alimentação ou defeito próprio.


19. Hub com fonte resolve sempre?

Não.

É apenas uma variável de teste.


20. USB-C garante alta velocidade?

Não.

USB-C descreve o conector; as capacidades variam.


21. Cabo USB-C que carrega transfere dados?

Nem sempre da forma esperada.


22. Posso usar qualquer cabo?

Não.

Use cabo compatível e de qualidade adequada.


23. Por que funciona em outra porta?

Pode haver diferença de controlador, hub ou caminho físico.


24. Por que funciona em outro computador?

Isso indica que o periférico consegue funcionar em outra condição.


25. Se falha em vários PCs, o dispositivo está defeituoso?

A suspeita aumenta bastante, mas teste o cabo e outras variáveis.


26. O erro pode ser causado por firmware?

Sim.


27. Posso atualizar firmware com o dispositivo falhando?

Somente se o fabricante fornecer procedimento específico.


28. O Device Descriptor contém VID e PID?

Sim, entre outras informações fundamentais.


29. VID significa fabricante?

VID significa Vendor ID.


30. PID significa produto?

PID significa Product ID.


31. VID/PID são suficientes para identificar uma unidade física única?

Nem sempre.

Número de série e identidade da instância também podem importar.


32. O que é Endpoint 0?

É o endpoint de controle padrão utilizado em operações essenciais da enumeração.


33. Endpoint é uma porta USB física?

Não.

É uma entidade lógica de comunicação no dispositivo.


34. O que é enumeração USB?

É o processo de descoberta/configuração do dispositivo pelo host.


35. O que é Plug and Play?

É o sistema que gerencia descoberta, configuração e associação de dispositivos/driver no Windows.


36. Device Descriptor Request Failed acontece antes do driver?

Pode acontecer antes da associação normal do driver específico.


37. Posso remover o dispositivo pelo Gerenciador?

Em alguns casos, sim, como teste controlado.


38. Posso remover todos os controladores USB?

Não é recomendado como primeira abordagem.


39. USB frontal é pior que traseiro?

Não necessariamente.

Mas possui outro caminho físico e pode ajudar no teste.


40. USB 2.0 pode funcionar quando USB 3.x falha?

Sim, dependendo da causa.


41. Meu pendrive aparece RAW. É o mesmo erro?

Não.

RAW significa que ele já foi detectado como armazenamento.


42. O pendrive aparece sem letra. É falha de descritor?

Normalmente não.

Se aparece no Gerenciamento de Disco, enumeração já aconteceu.


43. Impressora offline é falha USB?

Pode ser, mas existem muitas outras causas.

Verifique se ela aparece corretamente no Gerenciador.


44. Webcam sem imagem é Device Descriptor Request Failed?

Somente se o Windows realmente mostrar esse erro.


45. Bluetooth pode usar USB internamente?

Sim, dependendo da arquitetura do módulo.


46. Reiniciar ajuda?

Pode resetar estados de software/controladores e fornecer informação diagnóstica.


47. Desligar é igual a Reiniciar?

Nem sempre, especialmente por causa de mecanismos como Inicialização Rápida.


48. Fast Startup pode influenciar?

Pode em determinados problemas de estado.


49. Como saber se o problema é cabo?

Teste outro cabo conhecido como funcional e repita o comportamento.


50. Qual é o melhor método?

Trocar uma variável por vez e registrar os resultados.


Conclusão

A mensagem:

Dispositivo USB desconhecido (Falha na solicitação de descritor de dispositivo)

parece simples, mas envolve uma parte fundamental do funcionamento do USB.

O Windows precisa primeiro estabelecer comunicação com o periférico, enumerá-lo e obter informações básicas antes de conseguir identificar corretamente o hardware e associá-lo aos componentes de driver adequados.

Por isso, o melhor diagnóstico não começa necessariamente por driver.

Começa por perguntas simples:

  • o dispositivo recebe energia?
  • funciona em outra porta?
  • funciona com outro cabo?
  • funciona em outro computador?
  • outros dispositivos funcionam naquela mesma porta?
  • o problema aparece depois de suspensão?
  • o Windows consegue ler VID/PID?
  • o USBView mostra descriptors completos?

Com essas respostas, podemos sair do “tente isso” e chegar a um diagnóstico reproduzível.

Em muitos casos, uma simples matriz de testes consegue indicar se a falha está em:

  • cabo;
  • porta;
  • hub;
  • controlador;
  • dispositivo;
  • alimentação;
  • firmware;
  • Windows.

Esse processo evita reinstalações desnecessárias, reduz tempo de diagnóstico e diminui o risco de alterar configurações que não têm relação com o problema.

Precisa de ajuda com USB, Windows 11 ou periféricos?

A VMIA – Manutenção e Configuração realiza diagnóstico de computadores, notebooks, impressoras, redes e periféricos USB, com atendimento técnico e orientação clara.

WhatsApp: (11) 99779-7772
Site: https://vmia.site
Blog: https://vmia.com.br
Avaliações: https://avaliacao.vmia.com.br

O atendimento pode ser feito por visita técnica ou acesso remoto, conforme o tipo de problema e a possibilidade de diagnóstico à distância.

Seja o primeiro a comentar

Faça um comentário

Seu e-mail não será publicado.


*