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:
- conexão física;
- detecção do dispositivo;
- inicialização/reset apropriado;
- comunicação pelo endpoint de controle;
- obtenção dos descritores;
- atribuição/configuração necessária;
- identificação;
- Plug and Play;
- 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
| Teste | Resultado |
|---|---|
| dispositivo A + porta 1 | falha |
| dispositivo A + porta 2 | falha |
| dispositivo A + outro PC | falha |
| dispositivo B + PC original | funciona |
Essa combinação aumenta bastante a suspeita sobre o dispositivo A ou seu cabo.
Agora inverta
| Teste | Resultado |
|---|---|
| dispositivo A + porta 1 | falha |
| dispositivo A + porta 2 | funciona |
| outros dispositivos + porta 1 | també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:
- identifique corretamente o dispositivo problemático;
- escolha desinstalar/remover o dispositivo quando apropriado;
- reinicie ou faça nova detecção;
- 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
| Teste | Resultado |
|---|---|
| porta original | falha |
| segunda porta | falha |
| cabo B | funciona |
| cabo original novamente | falha |
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:
- desconecte o dispositivo;
- conecte novamente;
- teste outra porta;
- elimine hubs e docks;
- troque o cabo, quando possível;
- 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:
- anote
14:32; - conecte o USB;
- deixe o erro acontecer;
- abra o log;
- 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:
- desconecte o USB;
- remova apenas a instância problemática;
- reinicie;
- conecte novamente;
- 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.
| Dispositivo | Cabo | Porta | PC | Resultado |
|---|---|---|---|---|
| A | 1 | traseira 1 | PC 1 | falha |
| A | 1 | traseira 2 | PC 1 | falha |
| A | 2 | traseira 1 | PC 1 | funciona |
| A | 1 | PC 2 | PC 2 | falha |
Nesse exemplo, o cabo 1 ganha muita força como causa.
Outro exemplo
| Dispositivo | Porta | PC | Resultado |
|---|---|---|---|
| A | frontal | PC 1 | falha |
| A | traseira | PC 1 | funciona |
| B | frontal | PC 1 | falha |
| B | traseira | PC 1 | funciona |
Agora o caminho frontal merece investigação.
Terceiro exemplo
| Dispositivo | PC | Resultado |
|---|---|---|
| A | PC 1 | falha |
| A | PC 2 | falha |
| A | PC 3 | falha |
| B | PC 1 | funciona |
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
| Sintoma | Camada mais provável |
|---|---|
| Device Descriptor Request Failed | enumeração USB |
| VID/PID aparecem, mas driver não instala | Plug and Play/driver |
| Code 28 | driver ausente |
| Code 10 | inicialização de driver/dispositivo |
| unidade RAW | sistema de arquivos/volume |
| unidade sem letra | montagem/volume |
| impressora aparece mas não imprime | driver/spooler/fila/rede ou interface |
| webcam aparece mas aplicativo não acessa | aplicativo/permissão/driver |
| dispositivo nem recebe energia | hardware/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.
Faça um comentário