Um dispositivo USB parou de funcionar.
A placa de rede apresenta comportamento estranho.
O Bluetooth desapareceu.
Uma webcam não é reconhecida corretamente.
Um componente interno do notebook deixou de funcionar depois de uma atualização.
A primeira reação costuma ser abrir o Gerenciador de Dispositivos.
Você procura aquele conhecido triângulo amarelo.
Nada.
Passa pelas categorias.
Nada parece obviamente errado.
Então surge a conclusão:
“Se não existe alerta no Gerenciador de Dispositivos, o Windows não encontrou nenhum problema de hardware ou driver.”
Essa conclusão pode ser precipitada.
O Windows mantém uma estrutura muito mais detalhada sobre dispositivos Plug and Play do que aquela que normalmente observamos navegando manualmente pelo Gerenciador de Dispositivos.
Uma das ferramentas nativas mais interessantes para investigar essa estrutura é:
PnPUtil.exe
E existe um comando especialmente útil:
pnputil /enum-devices /problem
Em vez de abrir categoria por categoria procurando algum sinal visual, podemos perguntar diretamente ao subsistema Plug and Play:
Quais dispositivos estão atualmente associados a algum estado de problema?
A partir daí podemos obter informações como:
- instância do dispositivo;
- descrição;
- classe;
- fabricante;
- estado;
- código de problema, quando disponível.
Mas o PnPUtil também exige interpretação.
Encontrar um dispositivo na lista não significa automaticamente:
hardware queimado.
O problema pode estar relacionado a:
- driver;
- inicialização;
- configuração;
- dependência;
- dispositivo desabilitado;
- identificação;
- estado PnP;
- hardware.
Neste guia vamos aprender a separar essas possibilidades.
O que é PnP?
PnP significa:
Plug and Play.
O conceito existe para permitir que o sistema operacional detecte e configure dispositivos de forma muito mais automatizada.
Quando você conecta um dispositivo USB, por exemplo, existe muito mais acontecendo nos bastidores do que simplesmente:
“Windows encontrou USB.”
O sistema precisa identificar o dispositivo e determinar como lidar com ele.
Dependendo do hardware, isso envolve:
- identificação;
- enumeração;
- associação a uma classe;
- localização de driver;
- criação de uma instância;
- carregamento de componentes necessários;
- configuração do dispositivo.
Por isso, quando alguma dessas etapas apresenta problema, o sintoma final pode ser apenas:
“O dispositivo não funciona.”
O que é o PnPUtil?
O PnPUtil.exe é uma ferramenta de linha de comando nativa do Windows voltada à administração e diagnóstico de componentes Plug and Play e pacotes de drivers.
Ela existe há bastante tempo, mas suas possibilidades evoluíram ao longo das versões do Windows.
No Windows 11, ela pode ser muito útil para administradores e técnicos que precisam investigar dispositivos sem depender exclusivamente da interface gráfica.
Para verificar a ajuda disponível na própria versão instalada do Windows, abra o Terminal ou Prompt de Comando e execute:
pnputil /?
Essa etapa é importante.
Nem todo parâmetro encontrado em um tutorial antigo ou recente deve ser presumido como disponível da mesma forma em todas as versões do Windows.
A ajuda local mostra o que aquela instalação reconhece.
PnPUtil não é apenas uma ferramenta para instalar drivers
Muitos técnicos conhecem o PnPUtil por comandos relacionados ao Driver Store.
Por exemplo, administração de pacotes .inf.
Mas a ferramenta também consegue enumerar dispositivos.
É essa capacidade que vamos explorar.
Um dos comandos mais úteis para nosso cenário é:
pnputil /enum-devices /problem
A palavra:
enum
vem de:
enumerate — enumerar.
Em termos simples:
liste os dispositivos que atendem à condição solicitada.
E /problem restringe a consulta aos dispositivos associados a problemas.
Abra o Terminal como Administrador?
Para começar a investigação, você pode abrir o Terminal do Windows ou o Prompt de Comando.
Para algumas operações administrativas do PnPUtil, privilégios elevados são necessários.
Como nosso objetivo é diagnóstico técnico e podemos avançar posteriormente para outras consultas, faz sentido abrir:
Terminal → Executar como administrador
ou:
Prompt de Comando → Executar como administrador.
Mas existe uma regra importante:
abrir o terminal como Administrador não significa que devemos sair removendo drivers ou dispositivos.
Nesta etapa estamos consultando informações.
Primeiro comando: veja a ajuda
Execute:
pnputil /?
Não pule essa etapa se você estiver documentando um problema real.
Observe as opções apresentadas pela sua versão.
Isso também evita copiar comandos de artigos antigos que podem não corresponder exatamente ao Windows utilizado.
Agora procure dispositivos com problema
Execute:
pnputil /enum-devices /problem
O Windows fará uma consulta aos dispositivos PnP que correspondem ao filtro de problema.
Se existirem dispositivos nessa condição, a saída pode apresentar informações úteis para identificá-los.
O formato exato pode variar conforme a versão e o dispositivo.
Por isso, concentre-se nos conceitos.
O que procurar na saída?
Algumas informações são especialmente importantes:
Instance ID
Device Description
Class Name
Manufacturer Name
Status
Problem Code
Os nomes e detalhes apresentados podem variar, mas esses campos ajudam a transformar:
“alguma coisa está com problema”
em:
“esta instância específica deste dispositivo apresenta determinado estado.”
Instance ID: uma das informações mais importantes
Imagine algo conceitualmente parecido com:
PCI\VEN_XXXX&DEV_YYYY&SUBSYS_...
ou:
USB\VID_XXXX&PID_YYYY\...
Essas sequências parecem confusas.
Mas são extremamente úteis.
Elas ajudam o Windows a identificar uma instância específica de dispositivo.
Isso é muito diferente de simplesmente saber:
“é uma placa de rede.”
Por que o Instance ID importa?
Imagine um computador com:
- Wi-Fi;
- Ethernet;
- Bluetooth;
- adaptador USB;
- interfaces virtuais.
Dizer:
“o adaptador de rede está com problema”
é pouco preciso.
O Instance ID ajuda a determinar exatamente qual dispositivo está sendo analisado.
Ele também pode ajudar a correlacionar informações entre:
- PnPUtil;
- Gerenciador de Dispositivos;
- PowerShell;
- logs;
- outras ferramentas administrativas.
USB: VID e PID
Em dispositivos USB, é comum encontrar identificadores contendo estruturas como:
VID_XXXX
e:
PID_YYYY
De forma simplificada:
VID está relacionado à identificação do fornecedor.
PID identifica o produto dentro daquele contexto.
Isso pode ajudar bastante quando o Windows apresenta uma descrição genérica.
PCI: VEN e DEV
Em dispositivos PCI/PCI Express, podemos encontrar:
VEN_XXXX
e:
DEV_YYYY
Em termos práticos:
VEN identifica o fornecedor.
DEV identifica o dispositivo.
Esses identificadores são extremamente úteis quando precisamos descobrir qual hardware corresponde a uma entrada pouco amigável.
Não baixe driver do primeiro site que aparece
Esse é um cuidado fundamental.
Ao pesquisar um Hardware ID ou identificador de dispositivo na Internet, podem aparecer inúmeros sites oferecendo:
“Download Driver.”
Evite transformar a identificação do dispositivo em licença para baixar executáveis de fontes desconhecidas.
Depois de identificar o hardware, procure drivers preferencialmente por:
- Windows Update;
- fabricante do computador;
- fabricante do dispositivo;
- canais oficiais do fornecedor.
Identificar corretamente vem antes de instalar qualquer coisa.
Device Description
Esse campo pode apresentar um nome amigável.
Por exemplo, dependendo do hardware:
- controlador;
- adaptador;
- dispositivo USB;
- componente de áudio;
- dispositivo de sistema.
Nem sempre a descrição será suficientemente clara.
Por isso, combine:
Description
Instance ID
Class
Manufacturer.
Class Name
O Windows organiza dispositivos em classes.
Você pode encontrar classes relacionadas a:
- rede;
- USB;
- áudio;
- vídeo;
- Bluetooth;
- armazenamento;
- sistema.
A classe ajuda a descobrir a função geral do componente.
Isso é especialmente útil quando o nome do dispositivo não parece familiar.
Manufacturer Name
O fabricante também fornece contexto.
Mas tome cuidado.
O nome mostrado nem sempre corresponde à marca estampada no notebook.
Um notebook de determinada fabricante pode conter componentes produzidos por outras empresas.
Isso é perfeitamente normal.
Um único computador pode reunir componentes de diversos fornecedores.
Status
O estado ajuda a entender como o Windows está enxergando aquela instância.
Não interprete simplesmente:
Status diferente do esperado = hardware quebrado.
O estado pode refletir diversas situações.
Precisamos combiná-lo com o código de problema e o contexto.
Problem Code
Aqui chegamos a uma informação muito interessante.
O Windows Plug and Play trabalha com códigos de problema associados a determinadas condições dos dispositivos.
Esses códigos ajudam a classificar o motivo pelo qual o dispositivo não está funcionando normalmente.
Eles são relacionados àqueles conhecidos códigos que podemos encontrar nas propriedades de um dispositivo no Gerenciador de Dispositivos.
Por exemplo, usuários podem se deparar com códigos como:
Código 10
Código 28
Código 31
Código 43
entre outros.
Cada um possui significado diferente.
Código 10 não significa simplesmente “driver errado”
Esse é um exemplo clássico de simplificação.
Quando alguém encontra:
Código 10
pesquisa rapidamente e recebe a recomendação:
“reinstale o driver.”
Isso pode funcionar em alguns casos.
Mas um código de problema deve ser interpretado junto com:
- dispositivo;
- driver;
- histórico;
- mudanças recentes;
- hardware;
- dependências.
O código direciona o diagnóstico.
Ele não necessariamente fornece sozinho a causa raiz.
Código 28
Esse código é frequentemente associado à ausência de driver adequado para o dispositivo.
É um cenário muito interessante depois de:
- instalação limpa do Windows;
- troca de hardware;
- reinstalação;
- falha de identificação de driver.
Imagine formatar um notebook e perceber que:
- Wi-Fi funciona;
- áudio funciona;
- vídeo funciona.
O Gerenciador de Dispositivos parece quase normal.
Mas o PnPUtil encontra uma instância problemática.
Talvez exista um componente menos evidente sem o driver correspondente.
Código 31
Esse tipo de código direciona a investigação para uma situação em que o Windows não consegue carregar adequadamente os drivers necessários para o dispositivo.
Novamente:
não significa automaticamente hardware defeituoso.
Precisamos investigar o pacote de driver e o histórico do dispositivo.
Código 43
Esse é um dos códigos que mais gera conclusões precipitadas.
O usuário encontra:
Código 43
e imediatamente pensa:
“A placa queimou.”
Não necessariamente.
Esse código está relacionado a uma situação em que o Windows interrompe o dispositivo porque recebeu indicação de problema.
As causas podem variar conforme o hardware.
Precisamos considerar:
- driver;
- firmware;
- comunicação;
- energia;
- dispositivo;
- hardware.
O código é o começo da investigação
A metodologia correta é:
dispositivo problemático
↓
Instance ID
↓
classe
↓
fabricante
↓
Problem Code
↓
driver associado
↓
histórico
↓
teste.
Não:
Problem Code → instalar driver aleatório.
Compare com o Gerenciador de Dispositivos
Depois de encontrar uma entrada problemática pelo PnPUtil, abra:
devmgmt.msc
Agora procure especificamente pelo componente identificado.
Isso muda completamente a experiência.
Antes você estava procurando:
“alguma coisa errada.”
Agora procura:
uma instância específica.
Veja as propriedades do dispositivo
Abra:
Propriedades
e observe abas como:
Geral
Driver
Detalhes
Eventos
quando disponíveis.
Essas informações complementam o PnPUtil.
A guia Detalhes é extremamente útil
Na guia:
Detalhes
existe uma lista de propriedades.
Dependendo do dispositivo, podemos consultar informações como:
- IDs de Hardware;
- caminho da instância;
- classe;
- identificadores;
- outras propriedades PnP.
É uma ótima forma de confirmar que o item encontrado no PnPUtil corresponde ao componente que estamos analisando na interface gráfica.
Compare o Instance ID
O objetivo é conseguir dizer:
“Esta entrada do PnPUtil corresponde exatamente a este dispositivo no Gerenciador de Dispositivos.”
Essa correlação evita investigar o hardware errado.
Gerenciador de Dispositivos “normal” pode ser uma impressão visual
Aqui está uma distinção importante.
Às vezes o usuário diz:
“Meu Gerenciador de Dispositivos está normal.”
Mas o que ele realmente quer dizer é:
“Eu abri a tela e não vi imediatamente um triângulo amarelo.”
São coisas diferentes.
Existem muitas categorias.
Alguns componentes têm nomes pouco intuitivos.
Outros ficam dentro de grupos que o usuário nem abre.
A consulta por linha de comando elimina boa parte dessa procura manual.
Dispositivo desabilitado também merece atenção
Existe outra condição importante.
Um dispositivo pode não estar funcionando porque está:
desabilitado.
Isso não é exatamente a mesma coisa que um driver com falha.
O PnPUtil possui recursos de enumeração que podem ajudar a filtrar dispositivos por diferentes estados, dependendo da versão instalada.
Por isso voltamos ao comando:
pnputil /?
Veja quais filtros sua versão suporta.
Enumere todos os dispositivos
Outra consulta útil é:
pnputil /enum-devices
Agora a lista pode ser muito maior.
Isso permite visualizar dispositivos PnP registrados e depois aplicar filtros mais específicos.
Não é necessariamente a melhor primeira consulta porque produz bastante informação.
Para nosso problema, começar com:
pnputil /enum-devices /problem
é muito mais eficiente.
Filtrar é melhor do que procurar visualmente
Esse é um princípio importante em diagnóstico.
Imagine um sistema com centenas de instâncias PnP.
Procurar manualmente significa:
abrir categoria
↓
olhar
↓
abrir outra
↓
olhar novamente.
Com uma consulta filtrada, fazemos:
mostre apenas dispositivos associados a problemas.
Isso reduz o ruído.
PowerShell também pode ajudar
O Windows possui cmdlets relacionados a dispositivos PnP.
Um exemplo importante é:
Get-PnpDevice
Ele permite consultar dispositivos pelo PowerShell.
Por exemplo:
Get-PnpDevice
pode retornar uma grande quantidade de entradas.
Assim como no PnPUtil, o valor real aparece quando começamos a trabalhar com filtros e propriedades.
PnPUtil ou PowerShell?
Não precisamos escolher apenas um.
Eles se complementam.
O PnPUtil é excelente para:
- administração PnP;
- enumeração;
- drivers;
- operações nativas específicas.
O PowerShell é excelente para:
- filtrar;
- ordenar;
- automatizar;
- cruzar resultados;
- exportar informações.
Uma investigação mais avançada pode usar ambos.
Não remova dispositivos ainda
Depois de encontrar uma entrada problemática, existe uma tentação:
“Vou desinstalar e deixar o Windows instalar novamente.”
Isso pode ser um teste válido em situações específicas.
Mas ainda não chegamos lá.
Primeiro precisamos responder:
Qual dispositivo é?
Qual o código?
Qual driver ele utiliza?
Quando o problema começou?
O dispositivo está presente fisicamente?
Ele já funcionou anteriormente?
Houve atualização?
Só depois decidimos a ação.
Descubra quando o problema começou
Pergunte:
- funcionava ontem?
- começou após Windows Update?
- começou após atualização de driver?
- aconteceu depois de conectar outro dispositivo?
- ocorreu depois de formatar?
- começou após atualização de BIOS/firmware?
- apareceu depois de mover um dispositivo USB para outra porta?
A linha do tempo reduz enormemente as possibilidades.
Um dispositivo que nunca funcionou é diferente de um que parou
Considere:
Cenário A
Instalação limpa do Windows.
O dispositivo nunca funcionou.
Isso aumenta a importância de investigar:
- identificação;
- driver ausente;
- pacote correto;
- suporte da versão do Windows.
Cenário B
Funcionava normalmente há meses e parou ontem.
Agora investigamos:
- atualização;
- driver;
- configuração;
- falha;
- energia;
- hardware.
Mesmo sintoma.
Diagnósticos diferentes.
Dispositivo presente ou não presente?
O Windows pode manter informações sobre dispositivos que foram conectados anteriormente, mesmo quando não estão fisicamente conectados naquele momento.
Isso é particularmente comum com:
- USB;
- adaptadores;
- impressoras;
- dispositivos Bluetooth;
- interfaces de rede.
Por isso, ao encontrar uma entrada, pergunte:
Esse dispositivo deveria estar presente agora?
Essa pergunta evita perder tempo com uma entrada histórica enquanto o problema real está em outro componente.
Primeira árvore de diagnóstico
Execute:
pnputil /enum-devices /problem
Nenhum dispositivo aparece
Isso significa que a consulta não encontrou dispositivos correspondentes àquele filtro naquele momento.
Mas não prova que:
todo hardware está perfeito.
Seu problema pode estar em outra camada.
Exemplos:
- aplicativo;
- serviço;
- rede;
- configuração;
- firmware;
- hardware que não está sendo enumerado da maneira esperada.
Um dispositivo aparece
Identifique:
- Instance ID;
- descrição;
- classe;
- fabricante;
- status;
- Problem Code.
Depois correlacione com:
devmgmt.msc
Vários dispositivos aparecem
Não tente corrigir todos simultaneamente.
Pergunte:
Quais deles têm relação com o sintoma?
Se o Bluetooth não funciona, uma entrada relacionada ao controlador Bluetooth merece prioridade sobre um componente histórico sem relação aparente.
Não transforme PnPUtil em ferramenta de “limpeza”
Esse é um cuidado importante.
Dispositivos registrados no Windows não são lixo simplesmente porque seus nomes parecem estranhos.
Não use PnPUtil com a mentalidade:
“Vou apagar tudo que não reconheço.”
Você pode remover configurações ou componentes necessários.
Nosso objetivo é:
diagnosticar.
Não:
limpar por limpar.
Primeira metodologia VMIA para PnPUtil
Quando um dispositivo não funciona, siga inicialmente:
1. Defina o sintoma
O dispositivo desapareceu?
Não inicia?
Perde conexão?
Nunca funcionou?
2. Abra um terminal administrativo
3. Consulte a ajuda
pnputil /?
4. Procure dispositivos problemáticos
pnputil /enum-devices /problem
5. Registre o resultado
Principalmente:
- Instance ID;
- descrição;
- classe;
- fabricante;
- status;
- Problem Code.
6. Abra o Gerenciador de Dispositivos
devmgmt.msc
7. Correlacione a instância
Confirme que está analisando o mesmo componente.
8. Consulte propriedades e IDs de hardware
9. Descubra quando o problema começou
10. Só então escolha a correção
Esse processo é muito mais seguro do que começar reinstalando drivers aleatoriamente.
como descobrir o driver, interpretar códigos de problema e cruzar informações com PowerShell
Na primeira parte executamos:
pnputil /enum-devices /problem
Esse comando nos permitiu fazer algo extremamente útil:
pedir ao Windows uma lista de dispositivos associados a estados de problema.
Agora imagine que encontramos uma entrada.
O próximo passo não deveria ser:
“Vou remover o dispositivo.”
Nem:
“Vou baixar outro driver.”
Primeiro precisamos responder:
Qual dispositivo é esse?
Ele está fisicamente presente?
Qual driver está associado a ele?
Qual código de problema foi registrado?
O problema começou depois de alguma mudança?
É isso que vamos investigar agora.
Salve a saída antes de alterar qualquer coisa
Antes de fazer modificações, registre o estado atual.
Uma forma simples é executar:
pnputil /enum-devices /problem > "%USERPROFILE%\Desktop\dispositivos-problema.txt"
No Prompt de Comando, isso cria um arquivo de texto na Área de Trabalho com o resultado atual.
Por que isso é útil?
Porque depois de:
- atualizar driver;
- reiniciar;
- remover dispositivo;
- alterar configuração;
você poderá comparar o estado anterior com o novo.
Esse princípio aparece frequentemente em diagnóstico:
registre antes de corrigir.
Comece pelo Instance ID
Vamos imaginar uma entrada contendo algo conceitualmente semelhante a:
USB\VID_1234&PID_5678\...
ou:
PCI\VEN_1234&DEV_5678&SUBSYS_...
Não se preocupe em memorizar toda a sequência.
Copie o Instance ID.
Ele funciona como uma excelente chave para continuar a investigação.
Consulte uma instância específica
O PnPUtil permite trabalhar com identificadores específicos em operações compatíveis com a versão instalada.
Antes de usar parâmetros encontrados na Internet, confirme:
pnputil /?
Se a sintaxe da sua versão permitir consulta direcionada por Instance ID, utilize o identificador exatamente como foi apresentado.
Quando existirem espaços ou caracteres que possam ser interpretados pelo terminal, aspas ajudam a preservar o argumento:
"INSTANCE_ID"
A ideia é sair de:
todos os dispositivos
para:
este dispositivo específico.
Por que isso melhora tanto o diagnóstico?
Imagine encontrar três dispositivos problemáticos:
- controlador desconhecido;
- dispositivo Bluetooth antigo;
- webcam atual.
Seu problema é:
“A webcam parou de funcionar.”
Não faz sentido começar corrigindo todos os três.
Priorize a instância relacionada ao sintoma.
Agora descubra o driver
Uma das perguntas mais importantes é:
Qual pacote de driver o Windows está usando para esse hardware?
Isso ajuda a diferenciar situações como:
- driver ausente;
- driver carregado incorretamente;
- pacote antigo;
- atualização recente;
- pacote genérico;
- driver fornecido pelo fabricante.
O Gerenciador de Dispositivos continua sendo muito útil aqui.
Execute:
devmgmt.msc
Localize o dispositivo identificado e abra:
Propriedades → Driver.
Observe informações como:
- fornecedor do driver;
- data;
- versão;
- detalhes do driver.
Não confunda fabricante do dispositivo com fornecedor do driver
Essa diferença é importante.
O dispositivo pode ser produzido por uma empresa, enquanto o pacote instalado pode aparecer associado a outra organização ou à própria Microsoft.
Isso não significa automaticamente que o driver está errado.
O Windows pode usar drivers fornecidos pelo próprio sistema para diversas classes de dispositivos.
Driver genérico pode estar perfeitamente correto
Outro mito comum:
“Se o driver é da Microsoft, preciso substituir pelo driver do fabricante.”
Não necessariamente.
Algumas classes de hardware funcionam justamente com drivers genéricos fornecidos pelo Windows.
A necessidade de um driver específico depende do dispositivo e das funcionalidades esperadas.
Portanto:
Microsoft como fornecedor ≠ driver errado.
Driver recente também não significa driver melhor
Imagine:
Driver antigo:
funcionava perfeitamente.
Depois de uma atualização:
dispositivo apresenta falha.
Nesse caso, instalar “o mais novo” novamente não necessariamente ajuda.
Precisamos investigar:
- quando a versão mudou;
- de onde veio a atualização;
- se existe versão posterior;
- se o fabricante recomenda outra versão;
- se a reversão é apropriada.
Use a guia Eventos do dispositivo
Em muitos dispositivos, a janela de propriedades oferece:
Eventos.
Ela pode ajudar a reconstruir parte do histórico relacionado à instalação e configuração daquele dispositivo.
Isso é particularmente interessante quando o usuário diz:
“Funcionava até ontem.”
Procure acontecimentos próximos da data do problema.
Compare com o Windows Update
Abra:
Configurações → Windows Update → Histórico de atualizações
Dependendo da situação, alterações de driver podem aparecer no histórico.
Não conclua automaticamente:
“A atualização causou.”
Use a data apenas como correlação inicial.
A linha do tempo novamente
Imagine:
Segunda-feira
Webcam funcionando.
Terça-feira
Driver atualizado.
Quarta-feira
Webcam apresenta Código 10.
Quinta-feira
O mesmo problema continua.
Agora temos uma hipótese forte:
a mudança de driver pode estar relacionada.
Ainda precisamos testar.
Quando “Reverter Driver” faz sentido?
No Gerenciador de Dispositivos existe, em determinados casos, a opção:
Reverter Driver.
Ela pode ser útil quando:
- o dispositivo funcionava antes;
- uma atualização ocorreu;
- o problema começou imediatamente depois;
- existe uma versão anterior disponível para reversão.
Mas nem sempre o botão estará disponível.
E nem sempre a versão anterior é necessariamente a solução.
Não use reversão como ritual
Faça a pergunta:
Existe evidência de que o problema começou com essa mudança?
Se sim, a reversão pode funcionar como teste A/B.
Estado A:
driver anterior → funciona.
Estado B:
driver novo → falha.
Retorno ao Estado A:
volta a funcionar.
Isso fornece evidência muito mais convincente.
Vamos falar dos códigos de problema
O código é uma das informações que mais ajudam a classificar o diagnóstico.
Mas precisamos evitar interpretações simplistas.
Vamos analisar alguns casos frequentes.
Código 10 — dispositivo não consegue iniciar
Quando encontramos um Código 10, sabemos que existe um problema no processo necessário para o dispositivo iniciar corretamente.
A pergunta não deve ser apenas:
“Qual driver eu instalo?”
Pergunte também:
- funcionava anteriormente?
- começou após atualização?
- acontece em outra porta?
- existe problema de energia?
- o firmware está envolvido?
- o hardware responde?
- existe outro erro relacionado?
Exemplo: adaptador Wi-Fi com Código 10
Imagine que o Wi-Fi desapareceu.
O PnPUtil aponta o adaptador.
No Gerenciador de Dispositivos encontramos Código 10.
Podemos investigar:
- histórico de driver;
- atualização recente;
- versão recomendada pelo fabricante;
- reinicialização completa;
- firmware/BIOS quando aplicável;
- comportamento persistente após reinstalação adequada;
- possibilidade de falha física.
O código reduz o espaço de investigação, mas não escolhe sozinho a resposta.
Código 28 — driver não instalado
Esse cenário é especialmente interessante após uma instalação limpa.
Imagine formatar um notebook.
Tudo parece funcionar.
Mas:
pnputil /enum-devices /problem
mostra um dispositivo.
O código indica ausência de driver.
Agora precisamos identificar o hardware.
Use os IDs de Hardware
No Gerenciador de Dispositivos:
Propriedades → Detalhes
Procure uma propriedade relacionada a:
IDs de Hardware.
Você pode encontrar algo semelhante a:
PCI\VEN_XXXX&DEV_YYYY...
Copie o identificador.
Agora descubra qual componente existe naquele modelo de computador.
Prefira a página de suporte do fabricante do computador
Em notebooks e computadores de marca, comece pelo fabricante do equipamento.
Procure pelo:
- modelo exato;
- número de produto quando necessário;
- versão do Windows;
- categoria correspondente.
Isso reduz a chance de instalar pacote inadequado.
Controlador desconhecido depois da formatação
Esse é um caso clássico.
Depois de reinstalar Windows, aparecem componentes pouco intuitivos:
- controlador;
- dispositivo PCI;
- dispositivo de sistema;
- sensor;
- interface.
O computador aparentemente funciona.
Mas alguma função pode estar ausente.
O PnPUtil ajuda a revelar essas pendências.
Código 31 — Windows não consegue carregar os drivers necessários
Aqui precisamos prestar atenção ao conjunto de drivers e à configuração do dispositivo.
Investigue:
- pacote atualmente instalado;
- atualizações;
- filtros de software;
- alterações recentes;
- integridade do driver;
- dependências.
Não conclua:
Código 31 = hardware queimado.
Código 43 — o dispositivo relatou um problema
Esse código aparece em diferentes classes de hardware e exige contexto.
Podemos encontrá-lo em situações envolvendo:
- USB;
- vídeo;
- dispositivos externos;
- outros componentes.
A interpretação precisa considerar o tipo de hardware.
Código 43 em USB
Se um dispositivo USB apresenta problema, investigue:
- outra porta;
- conexão direta em vez de hub;
- cabo, quando houver;
- alimentação;
- outro computador;
- driver;
- dispositivo.
Esse conjunto de testes ajuda a separar:
problema do Windows
de:
problema físico do periférico.
Testar em outro computador é extremamente útil
Imagine:
Dispositivo A falha no PC 1.
Você testa no PC 2.
Falha da mesma maneira.
Isso aumenta a suspeita sobre:
- dispositivo;
- cabo;
- firmware próprio.
Agora imagine:
No PC 2 funciona perfeitamente.
A investigação volta para:
- driver;
- porta;
- sistema;
- energia;
- configuração do PC 1.
Mas não existe teste universal
Uma placa Wi-Fi interna não pode ser testada com a mesma facilidade que um pendrive.
Cada classe de dispositivo exige testes adequados.
O princípio continua:
isole variáveis.
PowerShell entra na investigação
Agora vamos complementar o PnPUtil.
Abra o PowerShell ou Terminal e execute:
Get-PnpDevice
O resultado pode ser grande.
Você verá diversas instâncias PnP.
O PowerShell permite trabalhar com essas informações de forma muito flexível.
Veja dispositivos cujo status não seja OK
Uma consulta útil para investigação é:
Get-PnpDevice | Where-Object Status -ne "OK"
Isso pode destacar entradas cujo status retornado pelo cmdlet não seja OK.
Mas existe uma ressalva importante.
Essa consulta não é necessariamente equivalente a:
pnputil /enum-devices /problem
Os dois mecanismos podem apresentar informações sob perspectivas diferentes.
Por isso, use-os como ferramentas complementares.
Mostre apenas algumas colunas
Para tornar a saída mais legível:
Get-PnpDevice | Select-Object Status, Class, FriendlyName, InstanceId
Agora temos uma tabela com:
- status;
- classe;
- nome amigável;
- Instance ID.
Isso facilita bastante a leitura.
Procure uma instância específica
Se você já possui o Instance ID, pode filtrar os resultados no PowerShell.
Uma abordagem é trabalhar com a propriedade:
InstanceId
para localizar exatamente a entrada desejada.
O objetivo é correlacionar:
PnPUtil
↔
PowerShell
↔
Gerenciador de Dispositivos.
Quando as três ferramentas apontam para a mesma instância, o diagnóstico fica muito mais organizado.
PowerShell é excelente para exportar inventário
Você também pode gerar uma lista para comparação.
Por exemplo:
Get-PnpDevice | Select-Object Status,Class,FriendlyName,InstanceId | Export-Csv "$env:USERPROFILE\Desktop\dispositivos.csv" -NoTypeInformation
Agora você possui um inventário em CSV.
Isso pode ser útil antes e depois de uma intervenção.
Compare antes e depois
Antes da correção:
- dispositivo aparece com problema;
- código registrado;
- driver X.
Depois:
- status normal;
- dispositivo não aparece mais no filtro de problemas;
- funcionalidade restaurada.
Isso cria uma confirmação técnica.
O dispositivo desapareceu completamente?
Agora temos outro cenário.
O usuário diz:
“Meu Bluetooth sumiu.”
Você executa:
pnputil /enum-devices /problem
e não encontra o adaptador esperado.
O Gerenciador de Dispositivos também não mostra claramente o componente.
Isso muda a investigação.
Talvez o problema não seja:
dispositivo presente com erro.
Pode ser:
dispositivo não enumerado naquele momento.
Ausência também é informação
Se o hardware deveria estar presente, mas não aparece entre os dispositivos esperados, considere:
- firmware;
- BIOS/UEFI;
- energia;
- conexão física;
- controlador;
- hardware;
- enumeração.
Isso é diferente de encontrar:
Código 10.
Reiniciar pode fazer o dispositivo reaparecer
Se ele reaparece depois de reiniciar, pergunte:
Por que deixou de ser enumerado antes?
Não aceite apenas:
“Reiniciar resolveu.”
Se o problema retorna, existe algo intermitente.
Investigue:
- energia;
- driver;
- suspensão;
- firmware;
- hardware.
Dispositivo desconectado versus dispositivo com problema
Essa diferença é fundamental.
Um dispositivo que foi conectado anteriormente pode continuar registrado no Windows mesmo quando não está presente.
Portanto, não confunda:
registro existente
com:
hardware atualmente conectado e operacional.
Por que aparecem dispositivos antigos?
O Windows mantém informações de dispositivos por vários motivos.
Isso permite reconhecer novamente um periférico quando ele retorna.
É comum encontrar histórico de:
- pendrives;
- placas de rede;
- Bluetooth;
- monitores;
- impressoras;
- adaptadores USB.
Isso não significa que o Windows esteja “cheio de lixo”.
Não remova dispositivos antigos apenas para limpar a lista
Essa prática pode criar mais problemas do que benefícios.
Só considere remoção quando houver:
- motivo técnico;
- identificação correta;
- entendimento do impacto.
“Não reconheço o nome” não é motivo suficiente.
Dispositivo desabilitado
Existe ainda o cenário em que o hardware está registrado e funcional do ponto de vista de driver, mas foi desabilitado.
Isso pode acontecer:
- manualmente;
- por configuração;
- por alguma ação administrativa.
Dependendo da versão do PnPUtil, existem operações relacionadas a habilitar e desabilitar dispositivos.
Antes de qualquer ação:
pnputil /?
confirme a sintaxe suportada.
Não habilite tudo automaticamente
Se encontrar um dispositivo desabilitado, pergunte:
Por que ele foi desabilitado?
Talvez tenha sido proposital.
Exemplos:
- dispositivo não utilizado;
- hardware com defeito;
- política corporativa;
- teste anterior.
Ativar sem contexto pode reintroduzir um problema.
Wi-Fi desapareceu: roteiro de diagnóstico
Vamos juntar tudo.
Etapa 1
Execute:
pnputil /enum-devices /problem
Etapa 2
Procure o adaptador Wi-Fi.
Situação A — aparece com código
Investigue:
- Instance ID;
- driver;
- histórico;
- código.
Situação B — não aparece no filtro
Execute uma enumeração mais ampla e consulte:
Get-PnpDevice
Situação C — adaptador não aparece em lugar nenhum
Aumenta a importância de investigar:
- BIOS/UEFI;
- hardware;
- energia;
- conexão;
- enumeração.
Bluetooth desapareceu: mesma lógica
Wi-Fi e Bluetooth podem até coexistir no mesmo módulo físico em muitos computadores, mas o Windows os trata como funções e dispositivos distintos.
Se ambos falham simultaneamente, essa coincidência é relevante.
Se apenas Bluetooth falha e Wi-Fi permanece normal, a hipótese muda.
Procure sempre padrões.
Webcam não funciona
Pergunte primeiro:
O Windows enxerga a webcam como dispositivo?
Se sim:
qual estado?
Se existe código:
qual?
Depois investigue driver e permissões do sistema.
Porque uma webcam pode estar perfeitamente enumerada e ainda não funcionar em determinado aplicativo devido a:
- permissão de câmera;
- aplicativo;
- conflito de uso.
PnPUtil não diagnostica todas essas camadas.
Esse ponto é crucial
Imagine:
pnputil /enum-devices /problem
não retorna problema para a webcam.
Ela aparece normalmente no Gerenciador de Dispositivos.
Mas o Teams não consegue utilizá-la.
Nesse caso, continuar reinstalando driver pode ser perda de tempo.
Investigue:
- Configurações de Privacidade da câmera;
- aplicativo;
- câmera selecionada;
- uso simultâneo;
- serviço relacionado.
Áudio também possui várias camadas
“Sem som” não significa automaticamente dispositivo PnP com problema.
Pode existir:
- dispositivo errado selecionado;
- volume;
- aplicativo;
- serviço de áudio;
- saída HDMI;
- Bluetooth;
- driver.
PnPUtil ajuda quando existe um problema na camada do dispositivo.
Ele não substitui o restante do diagnóstico.
A pergunta certa é: em qual camada está a falha?
Podemos pensar assim:
Hardware físico
↓
Enumeração PnP
↓
Driver
↓
Serviços
↓
Configuração do Windows
↓
Aplicativo
Se o PnPUtil mostra o dispositivo saudável, talvez precisemos subir para outra camada.
Se nem existe enumeração, talvez precisemos descer em direção a firmware e hardware.
Quando reinstalar o driver faz sentido?
A reinstalação passa a ser uma hipótese razoável quando existem evidências como:
- pacote ausente;
- driver corrompido;
- atualização problemática;
- código relacionado ao carregamento;
- versão incompatível;
- fabricante recomenda pacote específico.
Mesmo assim, use a fonte correta.
Quando reinstalar driver provavelmente não é a primeira solução?
Quando:
- dispositivo está saudável;
- problema existe apenas em um aplicativo;
- configuração está incorreta;
- hardware nem é enumerado;
- problema é claramente físico;
- serviço necessário está parado.
Reinstalar driver repetidamente não resolve todas as camadas.
Segunda metodologia VMIA
Depois de encontrar um dispositivo com problema:
1. Salve a saída
pnputil /enum-devices /problem
2. Copie o Instance ID
3. Identifique classe e fabricante
4. Abra
devmgmt.msc
5. Consulte
Propriedades → Driver
6. Consulte
Propriedades → Detalhes → IDs de Hardware
7. Veja o histórico disponível
8. Compare com Windows Update
9. Use PowerShell
Get-PnpDevice
10. Determine a camada da falha
Hardware?
Enumeração?
Driver?
Serviço?
Configuração?
Aplicativo?
Só depois escolha a correção.
casos reais, árvore completa de diagnóstico e quando o problema não é o driver
Agora vamos fechar o diagnóstico com situações práticas em que o dispositivo falha, desaparece, reaparece ou apresenta códigos de problema mesmo depois de uma tentativa de reinstalação.
A ideia é responder à pergunta mais importante:
Quando o problema está realmente no driver e quando o PnPUtil está apenas mostrando o efeito de algo que acontece em outra camada?
Esse é o ponto em que o diagnóstico deixa de ser tentativa e erro e passa a seguir uma lógica técnica.
Cenário 1: dispositivo USB aparece como desconhecido
Você conecta um dispositivo USB e o Windows não consegue identificá-lo corretamente.
O primeiro passo pode ser:
pnputil /enum-devices /problem
Se aparecer uma entrada correspondente ao dispositivo, registre:
- Instance ID;
- descrição;
- classe;
- fabricante;
- Problem Code.
Depois abra:
devmgmt.msc
e procure o mesmo dispositivo.
Se a descrição for genérica, consulte:
Propriedades → Detalhes → IDs de Hardware
O que pode causar um USB desconhecido?
Entre as possibilidades estão:
- driver ausente;
- dispositivo que não respondeu corretamente durante enumeração;
- cabo inadequado;
- porta com problema;
- hub;
- alimentação insuficiente;
- firmware do próprio dispositivo;
- falha física.
Por isso, simplesmente instalar um pacote de driver qualquer pode não resolver.
Faça um teste simples de isolamento
Se possível:
Porta USB A
↓
teste.
Depois:
Porta USB B
↓
teste.
Se houver hub:
conecte diretamente ao computador.
Se existir cabo removível:
teste outro cabo compatível.
O objetivo é descobrir se o problema acompanha:
o dispositivo
ou:
a porta/conexão.
Testar em outro computador pode separar software de hardware
Se o mesmo dispositivo falhar em outro computador, a suspeita sobre o próprio periférico aumenta.
Se funcionar normalmente em outra máquina, volte a investigar:
- controlador USB;
- driver;
- energia;
- sistema;
- porta.
Essa é uma das técnicas mais simples e valiosas de diagnóstico.
Cenário 2: Wi-Fi desaparece depois da suspensão
Imagine:
O computador inicia normalmente.
Wi-Fi funciona.
Você fecha a tampa.
O notebook entra em suspensão.
Depois volta.
O Wi-Fi desapareceu.
Agora execute:
pnputil /enum-devices /problem
Se o adaptador aparecer com problema, temos uma informação importante.
Se não aparecer, consulte:
Get-PnpDevice
e procure o adaptador.
A pergunta passa a ser:
O dispositivo continua enumerado ou desapareceu do sistema?
Se o adaptador continua presente
Investigue:
- estado;
- código;
- driver;
- eventos;
- energia.
Isso pode apontar para um problema de retomada do dispositivo.
Se o adaptador desapareceu
A investigação muda.
Considere:
- firmware;
- gerenciamento de energia;
- driver;
- BIOS/UEFI;
- próprio módulo;
- falha intermitente.
Esse tipo de problema pode não ser resolvido simplesmente atualizando o driver de rede.
Reiniciar “resolve”, mas isso não encerra o diagnóstico
Se reiniciar faz o Wi-Fi voltar, existe uma tentação de concluir:
“Era só reiniciar.”
Mas se o problema retorna depois de nova suspensão, você tem um padrão reproduzível.
E padrão reproduzível é excelente para diagnosticar.
Monte um teste A/B
Estado A
Inicialização normal.
Wi-Fi funciona.
Estado B
Suspensão e retorno.
Wi-Fi desaparece.
Estado C
Reinicialização.
Wi-Fi volta.
Agora a relação com o ciclo de energia/suspensão fica muito mais forte.
Cenário 3: Bluetooth some aleatoriamente
Esse problema pode ser particularmente interessante em notebooks que utilizam módulos combinados de Wi-Fi e Bluetooth.
Pergunte:
- Wi-Fi também desapareceu?
- só Bluetooth falhou?
- ocorreu após suspensão?
- apareceu código no PnPUtil?
- o dispositivo ainda aparece no PowerShell?
Se Wi-Fi e Bluetooth falham juntos, pode existir uma causa compartilhada.
Se apenas Bluetooth falha, a hipótese muda.
Cenário 4: webcam aparece normal, mas não funciona
Esse é um exemplo perfeito de limite do PnPUtil.
Imagine:
pnputil /enum-devices /problem
não retorna a webcam.
No Gerenciador de Dispositivos:
status normal.
Mesmo assim, o aplicativo não consegue usar a câmera.
Nesse caso, o problema pode estar acima da camada PnP.
Investigue:
- permissões de câmera;
- aplicativo selecionado;
- câmera correta;
- outro programa usando o dispositivo;
- configurações de privacidade;
- serviço relacionado.
PnPUtil não deve ser usado para forçar toda falha de câmera a se tornar “problema de driver”.
Cenário 5: Código 43 continua depois de reinstalar o driver
Esse é um cenário importante.
O usuário encontra Código 43.
Desinstala.
Instala novamente.
Reinicia.
O mesmo código volta.
Agora a pergunta é:
O que a reinstalação efetivamente testou?
Ela testou apenas uma parte da hipótese.
Se o problema persiste, considere:
- hardware;
- cabo;
- alimentação;
- firmware;
- controlador;
- comunicação;
- incompatibilidade.
Reinstalar o mesmo pacote repetidamente não adiciona novas evidências.
Faça o dispositivo mudar de ambiente
Quando possível, mude uma variável.
Por exemplo:
- outra porta;
- outro cabo;
- outro computador;
- outra alimentação;
- outro hub;
- outra versão de driver suportada.
Cada teste ajuda a excluir possibilidades.
Cenário 6: vários dispositivos apresentam problema ao mesmo tempo
Imagine que:
pnputil /enum-devices /problem
retorne:
- áudio;
- Bluetooth;
- webcam;
- USB;
- dispositivo de sistema.
Cinco falhas independentes simultâneas são possíveis.
Mas antes de tratar cada uma como caso separado, procure uma causa comum.
Pode existir:
- controlador;
- driver base;
- chipset;
- atualização;
- energia;
- firmware;
- problema de barramento.
Um erro em cascata pode criar vários sintomas
Imagine um controlador com problema.
Vários dispositivos dependentes dele podem aparecer como problemáticos.
Se você tentar corrigir os dispositivos filhos um por um, pode desperdiçar tempo.
Procure relações entre:
- classe;
- Instance ID;
- controlador;
- momento da falha.
Cenário 7: dispositivo antigo continua aparecendo mesmo desconectado
Isso não significa necessariamente erro.
O Windows pode manter registros de dispositivos previamente conectados.
Isso é normal em várias situações.
Portanto:
entrada antiga ≠ lixo.
Antes de remover qualquer coisa, confirme se existe impacto real.
Dispositivo fantasma é diferente de dispositivo com problema atual
Um dispositivo não presente pode simplesmente representar um hardware que foi conectado anteriormente.
Já um dispositivo atualmente problemático pode estar fisicamente presente e não funcionar.
Essas situações exigem tratamentos diferentes.
Cenário 8: depois de formatar o Windows, vários dispositivos ficam sem driver
Esse caso costuma ser mais simples de interpretar.
Execute:
pnputil /enum-devices /problem
Se houver códigos relacionados à ausência de driver, identifique os Hardware IDs.
Depois procure o suporte oficial do fabricante do computador.
Em notebooks, normalmente vale começar por:
- chipset;
- componentes de sistema;
- rede;
- áudio;
- vídeo;
- Bluetooth.
Mas não instale pacotes indiscriminadamente.
Identifique primeiro cada dispositivo.
Chipset não é “um driver só”
Esse é outro ponto importante.
O termo “driver de chipset” muitas vezes é usado de forma genérica.
Na prática, um pacote do fabricante pode configurar ou instalar suporte para vários componentes de sistema.
Por isso, depois de uma instalação limpa, alguns “dispositivos desconhecidos” podem estar ligados a componentes da plataforma.
Cenário 9: o dispositivo funciona, mas aparece com comportamento estranho
Nem toda falha PnP significa que o dispositivo está completamente morto.
Um dispositivo pode:
- funcionar parcialmente;
- desconectar;
- reiniciar;
- perder função específica;
- falhar após suspensão.
Esses sintomas intermitentes exigem observação temporal.
Consulte também os eventos do dispositivo
No Gerenciador de Dispositivos:
Propriedades → Eventos
pode ajudar a correlacionar:
- instalação;
- configuração;
- inicialização;
- mudanças.
Isso é especialmente útil se o problema começou após atualização.
Quando usar “Verificar se há alterações de hardware”
O Gerenciador de Dispositivos possui a opção de procurar novamente alterações de hardware.
Ela pode ser útil quando um dispositivo deveria estar presente, mas não aparece.
Mas isso não é uma correção universal.
Se o hardware não responde por causa de energia, firmware ou falha física, uma nova enumeração pode não resolver.
Reiniciar o dispositivo pelo PnPUtil
Versões recentes do PnPUtil oferecem operações adicionais para dispositivos.
Antes de tentar qualquer comando de reinicialização, habilitação ou desabilitação, consulte:
pnputil /?
Isso confirma a sintaxe disponível na sua instalação.
E há uma regra importante:
não reinicie ou desabilite um dispositivo crítico apenas para experimentar.
Placa de vídeo, armazenamento, controladores e dispositivos de sistema exigem cuidado.
Quando desabilitar e habilitar pode ser um teste válido?
Quando:
- dispositivo foi corretamente identificado;
- não é crítico para manter o sistema operacional funcionando;
- existe hipótese relacionada ao estado do dispositivo;
- você entende o impacto.
Mesmo assim, documente antes e depois.
Não use PnPUtil como “reset geral”
Esse é outro erro possível.
PnPUtil é uma ferramenta administrativa poderosa.
Ela não deve ser usada para:
“resetar todos os drivers.”
Esse tipo de abordagem pode transformar um problema pequeno em vários.
Como saber se a correção funcionou?
Depois de uma alteração legítima, execute novamente:
pnputil /enum-devices /problem
Compare com o resultado anterior.
Se o dispositivo deixou de aparecer e voltou a funcionar, temos uma boa evidência de melhoria.
Mas confira também o comportamento real.
Sumir da lista não é suficiente
Imagine:
o dispositivo não aparece mais como problemático.
Mas a função continua sem funcionar.
Então o problema pode ter migrado para outra camada.
Por exemplo:
- aplicativo;
- serviço;
- permissão;
- configuração.
A validação deve combinar:
estado PnP
funcionalidade real.
Exemplo de validação completa
Antes:
- Código 10;
- Wi-Fi não funciona;
- PnPUtil lista adaptador.
Depois de uma correção:
- PnPUtil não lista mais o adaptador como problemático;
- Gerenciador mostra status normal;
- Wi-Fi conecta;
- conexão permanece estável após reiniciar.
Essa é uma validação muito mais forte.
Quando desconfiar de hardware
A suspeita aumenta quando:
- problema persiste com driver correto;
- ocorre em outro sistema;
- ocorre em outra instalação;
- dispositivo falha em outro computador;
- existem desconexões físicas;
- firmware não detecta o componente;
- comportamento piora progressivamente.
Nenhum desses sinais sozinho é absoluto.
Mas vários juntos fortalecem a hipótese.
Quando desconfiar do driver
A suspeita aumenta quando:
- problema começou após atualização;
- versão anterior funcionava;
- reversão restaura a função;
- fabricante reconhece a versão correta;
- código está ligado ao carregamento;
- hardware funciona em outro sistema.
Quando desconfiar de configuração
Considere configuração quando:
- dispositivo está saudável no PnP;
- problema afeta apenas uma aplicação;
- função foi desabilitada;
- permissões impedem acesso;
- saída ou entrada errada está selecionada.
Quando desconfiar de firmware
Considere firmware quando:
- dispositivo some da enumeração;
- problema ocorre antes do Windows;
- BIOS/UEFI não detecta corretamente;
- falha acontece após suspensão ou energia;
- fabricante fornece atualização relacionada.
Firmware exige ainda mais cuidado.
Não atualize BIOS/firmware sem necessidade ou sem seguir a documentação oficial.
Quando PnPUtil não encontra nada
Essa situação também é útil.
Se o comando:
pnputil /enum-devices /problem
não retorna nenhum dispositivo relacionado ao sintoma, então pergunte:
Será que estou investigando a camada errada?
Por exemplo:
Wi-Fi conectado, mas sem Internet.
PnPUtil normal.
Talvez o problema esteja em:
- DHCP;
- DNS;
- gateway;
- roteador;
- firewall;
- rede.
Nesse caso, o dispositivo pode estar perfeitamente saudável.
Outro exemplo: impressora não imprime
A impressora pode estar instalada normalmente no Windows.
PnPUtil pode não indicar problema algum.
A falha pode estar em:
- spooler;
- porta;
- WSD;
- TCP/IP;
- comunicação;
- fila.
Novamente:
dispositivo normal não significa serviço funcional.
A camada PnP é apenas uma parte
Uma boa forma de pensar é:
Hardware
↓
Firmware
↓
Enumeração PnP
↓
Driver
↓
Serviço
↓
Configuração
↓
Aplicativo
↓
Rede ou recurso externo
PnPUtil atua principalmente em uma parte desse caminho.
Por isso ele é tão útil quando usado no lugar certo.
Árvore completa de diagnóstico
1. Defina o sintoma
O dispositivo:
- desapareceu?
- está com erro?
- funciona parcialmente?
- falha após suspensão?
- nunca funcionou?
2. Execute
pnputil /enum-devices /problem
3. Algum dispositivo relacionado aparece?
Sim
Registre:
- Instance ID;
- descrição;
- classe;
- fabricante;
- código.
Não
Consulte:
Get-PnpDevice
e o Gerenciador de Dispositivos.
4. O dispositivo deveria estar presente agora?
Sim, mas não aparece
Investigue:
- firmware;
- energia;
- conexão;
- hardware;
- enumeração.
Sim e aparece com problema
Investigue:
- código;
- driver;
- histórico;
- dependências.
5. Funcionava anteriormente?
Sim
Procure:
- atualização;
- driver;
- Windows Update;
- suspensão;
- mudança de hardware.
Não
Investigue:
- driver ausente;
- compatibilidade;
- identificação;
- suporte do fabricante.
6. O problema persiste em outro ambiente?
Se possível, teste:
- outra porta;
- outro cabo;
- outro computador.
7. Faça uma mudança por vez
Não troque tudo simultaneamente.
8. Reinicie
9. Execute novamente
pnputil /enum-devices /problem
10. Confirme a funcionalidade real
Erros que devem ser evitados
Baixar driver de qualquer site
Prefira fontes oficiais.
Desinstalar todos os dispositivos problemáticos
Cada entrada deve ser entendida antes.
Remover dispositivos antigos para “limpar”
Ausência física não significa lixo.
Atualizar todos os drivers ao mesmo tempo
Isso destrói sua capacidade de saber qual mudança resolveu.
Assumir que Código 43 significa hardware queimado
O código precisa de contexto.
Assumir que código de problema sempre significa driver
Hardware, firmware e energia também podem participar.
Reinstalar o mesmo driver repetidamente
Se nada muda, o teste não adiciona evidência.
Ignorar Instance ID
Sem identificar a instância corretamente, você pode investigar o dispositivo errado.
Checklist rápido
Antes de concluir o diagnóstico, confirme:
- executei
pnputil /enum-devices /problem; - salvei o resultado inicial;
- identifiquei o Instance ID;
- consultei o código de problema;
- comparei com o Gerenciador de Dispositivos;
- consultei IDs de Hardware;
- identifiquei o driver;
- verifiquei quando o problema começou;
- considerei atualização recente;
- testei outra porta ou ambiente quando possível;
- fiz apenas uma mudança por vez;
- executei novamente o PnPUtil;
- confirmei que o dispositivo realmente voltou a funcionar.
Conclusão
O Gerenciador de Dispositivos continua sendo uma ferramenta fundamental do Windows 11.
Mas ele não precisa ser a única forma de investigar hardware e drivers.
Quando um dispositivo deixa de funcionar e a interface gráfica não torna o problema evidente, o comando:
pnputil /enum-devices /problem
oferece uma forma extremamente útil de perguntar diretamente ao Windows:
quais dispositivos estão associados a um estado de problema?
A partir daí, informações como:
- Instance ID;
- classe;
- fabricante;
- estado;
- Problem Code;
permitem transformar um sintoma genérico em uma investigação muito mais precisa.
O ponto mais importante, porém, não é o comando.
É a metodologia.
Não use:
erro → reinstalar qualquer driver.
Use:
sintoma
↓
identificação
↓
estado PnP
↓
código
↓
driver
↓
histórico
↓
hipótese
↓
teste
↓
confirmação.
Essa sequência evita boa parte das tentativas aleatórias que acabam criando mais problemas do que soluções.
FAQ — PnPUtil e dispositivos problemáticos no Windows 11
O que é PnPUtil?
É uma ferramenta nativa do Windows para administração e diagnóstico de dispositivos Plug and Play e pacotes de drivers.
Como listar dispositivos com problema?
Use:
pnputil /enum-devices /problem
Preciso executar o PnPUtil como Administrador?
Algumas operações exigem privilégios administrativos. Para diagnóstico técnico mais amplo, abrir o Terminal como Administrador costuma ser adequado.
Se o PnPUtil não mostrar nada, o hardware está perfeito?
Não. Isso apenas significa que a consulta não encontrou dispositivos correspondentes àquele filtro naquele momento.
O que é Instance ID?
É um identificador associado a uma instância específica de dispositivo PnP.
Qual a diferença entre Instance ID e Hardware ID?
O Hardware ID identifica características do hardware e auxilia na correspondência com drivers. O Instance ID identifica uma instância específica daquele dispositivo no sistema.
O que significa Código 10?
Indica que o dispositivo não conseguiu iniciar corretamente. A causa precisa ser investigada.
O que significa Código 28?
É normalmente relacionado à ausência dos drivers necessários para o dispositivo.
O que significa Código 31?
Indica problema para carregar adequadamente os drivers necessários ao dispositivo.
Código 43 significa hardware queimado?
Não necessariamente. O dispositivo relatou um problema, mas a causa pode envolver driver, firmware, comunicação, energia ou hardware.
PnPUtil substitui o Gerenciador de Dispositivos?
Não. As ferramentas se complementam.
Posso usar PowerShell junto?
Sim. Get-PnpDevice é especialmente útil para consultar, filtrar e exportar informações sobre dispositivos PnP.
Posso remover qualquer dispositivo que apareça com problema?
Não. Primeiro identifique a função e a causa provável.
Um dispositivo antigo registrado no Windows é lixo?
Não necessariamente. O Windows pode manter informações de dispositivos usados anteriormente.
Se a webcam aparece saudável no PnPUtil, por que não funciona?
A falha pode estar em outra camada, como permissões, aplicativo, serviço ou configuração.
Reinstalar o driver sempre resolve?
Não. Só ajuda quando a causa realmente envolve o driver ou sua configuração.
Dispositivo não funciona e você não sabe se o problema é driver ou hardware?
A VMIA – Manutenção e Configuração pode ajudar a diagnosticar dispositivos USB, Wi-Fi, Bluetooth, webcam, áudio, impressoras, drivers e componentes do Windows 11.
O diagnóstico pode incluir análise de:
- PnPUtil;
- Gerenciador de Dispositivos;
- drivers;
- códigos de problema;
- eventos;
- atualizações;
- hardware.
O atendimento pode ser feito por acesso remoto ou visita técnica agendada, dependendo do tipo de problema.
VMIA – Manutenção e Configuração
Telefone e WhatsApp: (11) 99779-7772
Site: https://vmia.site
Blog: https://vmia.com.br
WhatsApp: https://whats.vmia.com.br
Antes de instalar drivers aleatórios ou formatar o computador, vale descobrir qual dispositivo está realmente apresentando problema e em qual camada a falha acontece.
Faça um comentário