Dispositivo desconhecido no Windows 11: como identificar pelo Hardware ID

setembro 5, 2026 admin Hardware, Sistema Operacional, Windows 11 0

Dispositivo desconhecido no Windows 11 sendo identificado pelo Hardware ID com VEN, DEV, VID, PID, PnPUtil, arquivo INF e setupapi.dev.log
Diagnóstico de dispositivo desconhecido no Windows 11 usando Hardware IDs, PnPUtil, arquivos INF, Driver Store e setupapi.dev.log para localizar o driver correto.
68 / 100
Desenvolvido por Rank Math SEO
Pontuação de SEO

Você abre o Gerenciador de Dispositivos do Windows 11 e encontra um item que não deveria estar ali:

Outros dispositivos
└── Dispositivo desconhecido

Em alguns computadores, o nome pode ser um pouco mais específico:

Controlador de rede
Controlador PCI
Controlador de comunicação PCI simples
Dispositivo PCI
Controlador multimídia
Dispositivo USB desconhecido

O ícone amarelo chama atenção, mas o verdadeiro problema é outro:

qual driver está faltando?

Pesquisar simplesmente por:

driver dispositivo desconhecido Windows 11

não resolve a questão.

O Windows pode saber que existe um dispositivo conectado ao computador e, ao mesmo tempo, não possuir um driver adequado para associar a ele.

Precisamos descobrir quem é o hardware.

Uma das pistas mais importantes está dentro das propriedades do próprio dispositivo:

IDs de Hardware

É ali que podemos encontrar identificadores semelhantes a:

PCI\VEN_XXXX&DEV_XXXX

ou:

USB\VID_XXXX&PID_XXXX

Esses códigos permitem sair de:

“Existe algum dispositivo desconhecido.”

para algo muito mais útil:

“Este dispositivo pertence a determinado fabricante e possui determinado identificador de produto/dispositivo.”

A partir daí, podemos procurar o driver correto de maneira muito mais segura.

Neste guia, vamos seguir todo o caminho:

Dispositivo desconhecido
        ↓
Hardware ID
        ↓
identificação
        ↓
fabricante
        ↓
driver correspondente
        ↓
arquivo INF
        ↓
Driver Store
        ↓
PnPUtil
        ↓
SetupAPI.dev.log

O objetivo não é simplesmente fazer o ícone amarelo desaparecer.

O objetivo é descobrir qual hardware está com problema, qual driver o Windows está tentando utilizar e por que a associação entre dispositivo e driver não aconteceu corretamente.

O que significa “Dispositivo desconhecido” no Windows 11?

O Windows utiliza o sistema Plug and Play (PnP) para detectar e configurar hardware.

Quando um dispositivo é detectado, o sistema precisa encontrar um pacote de driver compatível.

De forma simplificada:

Windows detecta hardware
        ↓
obtém identificadores
        ↓
procura drivers compatíveis
        ↓
seleciona um pacote
        ↓
instala/configura dispositivo

Quando essa cadeia não termina corretamente, podemos encontrar um dispositivo problemático no Gerenciador de Dispositivos.

Mas isso não significa automaticamente que:

hardware está queimado

Também pode significar que o Windows não encontrou uma correspondência adequada de driver, que a instalação falhou ou que existe outro problema na enumeração/configuração do dispositivo.

Dispositivo desconhecido não significa necessariamente hardware desconhecido fisicamente

Imagine um notebook.

Você consegue identificar facilmente:

  • tela;
  • teclado;
  • touchpad;
  • webcam;
  • Wi-Fi;
  • Bluetooth.

Mas internamente podem existir vários componentes menos óbvios:

controladores
sensores
interfaces ACPI
chipset
leitor de cartão
controlador de armazenamento
componentes de gerenciamento
dispositivos USB internos

Quando um deles perde o driver, o usuário pode não saber sequer qual componente deixou de funcionar.

Por isso o nome:

Dispositivo desconhecido

sozinho fornece pouca informação.

Precisamos dos identificadores.

Antes de procurar drivers, descubra o modelo exato do computador

Essa etapa evita muitos erros.

Em notebooks e computadores de fabricantes como Dell, Lenovo, HP, Acer e ASUS, dois equipamentos visualmente parecidos podem utilizar componentes diferentes.

O mesmo modelo comercial pode até possuir variantes de hardware.

Portanto, registre:

fabricante
modelo
versão do Windows
arquitetura

Como descobrir fabricante e modelo pelo Windows

Pressione:

Win + R

Digite:

msinfo32

Procure campos como:

Fabricante do sistema
Modelo do sistema

Você também pode utilizar PowerShell.

Por exemplo:

Get-CimInstance Win32_ComputerSystem |
Select-Object Manufacturer, Model

Isso pode retornar algo semelhante a:

Manufacturer     Model
------------     -----
Fabricante       ModeloXYZ

Agora temos uma informação essencial para a busca do driver oficial.

Descubra a versão do Windows 11

Execute:

winver

Além disso, você pode consultar:

Configurações → Sistema → Sobre

Observe principalmente:

Windows 11
arquitetura de 64 bits

e informações de versão/build quando forem relevantes para o pacote disponibilizado pelo fabricante.

Abra o Gerenciador de Dispositivos

Pressione:

Win + R

Digite:

devmgmt.msc

Procure categorias como:

Outros dispositivos

ou qualquer item com símbolo de alerta.

Não comece clicando em “Atualizar driver”

Primeiro colete informações.

Clique com o botão direito no dispositivo e abra:

Propriedades

Observe a guia:

Geral

Ela pode mostrar uma mensagem e um código de problema.

Registre essa informação.

Depois vá para:

Detalhes

É aqui que começa a parte mais importante.

Selecione “IDs de Hardware”

No campo Propriedade, procure:

IDs de Hardware

Você poderá encontrar várias linhas.

Um dispositivo PCI pode apresentar algo conceitualmente semelhante a:

PCI\VEN_1234&DEV_5678&SUBSYS_00000000&REV_01
PCI\VEN_1234&DEV_5678&SUBSYS_00000000
PCI\VEN_1234&DEV_5678

Não use esses números fictícios para procurar um driver.

Eles servem apenas para entender a estrutura.

O que significa VEN?

Em um identificador PCI:

VEN

vem de Vendor.

Ou seja, identifica o fornecedor/fabricante associado ao ID PCI.

Exemplo estrutural:

PCI\VEN_XXXX

O valor hexadecimal depois de VEN_ representa o Vendor ID.

O que significa DEV?

DEV

representa o identificador do dispositivo.

Estrutura:

PCI\VEN_XXXX&DEV_YYYY

Temos então:

VEN_XXXX
→ fornecedor

e:

DEV_YYYY
→ dispositivo

A combinação é muito mais útil do que pesquisar apenas:

Controlador PCI

E o que significa SUBSYS?

Um Hardware ID PCI pode possuir:

SUBSYS

Esse campo ajuda a identificar informações do subsistema.

Isso é importante porque o mesmo componente-base pode aparecer em implementações diferentes de fabricantes de computadores ou placas.

Por isso, duas máquinas podem compartilhar:

VEN
DEV

mas apresentar diferenças em:

SUBSYS

REV indica revisão

Você também pode encontrar:

REV

associado à revisão do dispositivo.

Quanto mais completo o identificador, mais específica pode ser a correspondência.

Por que aparecem vários Hardware IDs?

Isso é normal.

Imagine:

PCI\VEN_1234&DEV_5678&SUBSYS_ABCD0001&REV_01
PCI\VEN_1234&DEV_5678&SUBSYS_ABCD0001
PCI\VEN_1234&DEV_5678&CC_XXXXXX
PCI\VEN_1234&DEV_5678

Os identificadores representam diferentes níveis de especificidade que podem ser utilizados durante a correspondência com pacotes de driver.

Não significa que existem quatro dispositivos.

USB usa uma estrutura diferente

Em dispositivos USB, podemos encontrar:

USB\VID_XXXX&PID_YYYY

Nesse caso:

VID

significa Vendor ID.

E:

PID

significa Product ID.

Portanto:

USB
↓
VID
↓
fabricante

e:

USB
↓
PID
↓
produto/dispositivo

Exemplo estrutural de USB

Um identificador pode aparecer como:

USB\VID_1234&PID_5678

Novamente, os números são apenas ilustrativos.

O importante é compreender:

VID_1234
+
PID_5678

como uma combinação usada para identificar o dispositivo USB.

Não confunda PID com Process ID

No Gerenciador de Tarefas, PID costuma significar:

Process ID

Mas dentro de:

USB\VID_XXXX&PID_YYYY

estamos falando do identificador de produto do dispositivo USB.

O contexto muda completamente.

Hardware IDs também podem ter outras estruturas

Nem todo dispositivo será PCI ou USB.

Você pode encontrar identificadores relacionados a outras tecnologias e enumeradores.

Por exemplo:

ACPI\...

ou outros formatos.

Por isso não devemos tentar encaixar todos os dispositivos na regra:

VEN + DEV

Ela é especialmente relevante para PCI.

Da mesma maneira:

VID + PID

é típica da identificação USB.

Hardware ID e Compatible ID não são exatamente a mesma coisa

Na guia Detalhes, você também pode encontrar:

IDs compatíveis

Eles podem ajudar o Windows a encontrar drivers compatíveis em níveis menos específicos.

Mas, para começar a identificar o dispositivo, normalmente queremos observar primeiro:

IDs de Hardware

Por que o Hardware ID é tão importante para drivers?

Porque um pacote de driver possui informações que dizem ao Windows quais dispositivos ele suporta.

Um arquivo INF pode conter identificadores correspondentes ao hardware.

De forma conceitual:

Hardware
↓
possui ID ABC

e:

Driver
↓
INF declara suporte ao ID ABC

Se houver correspondência válida:

Windows pode considerar
o pacote candidato

É por isso que “baixei o driver do fabricante do chip” nem sempre basta

Imagine que você identificou o fabricante do componente.

Isso ajuda bastante.

Mas ainda precisamos considerar:

modelo do computador
subsistema
versão do Windows
arquitetura
pacote personalizado pelo fabricante
dependências

Em notebooks, principalmente, o fabricante do computador pode fornecer um pacote específico para aquela implementação.

Ordem recomendada para procurar o driver

Depois de identificar o dispositivo, prefira:

1. fabricante do computador
2. fabricante da placa-mãe, quando aplicável
3. fabricante oficial do componente
4. Windows Update / atualizações opcionais, quando apropriado

Evite começar por sites aleatórios de download de drivers.

Por que sites genéricos de drivers são um risco?

Porque você pode encontrar:

pacote antigo
pacote modificado
modelo parecido
versão incompatível
instalador de terceiros

Além do risco de segurança, um driver incorreto pode criar um problema mais difícil do que o dispositivo desconhecido original.

Evite programas que prometem atualizar “todos os drivers”

Um computador funcionando corretamente não precisa necessariamente possuir a versão numericamente mais alta de cada driver existente na Internet.

Drivers dependem de:

hardware
OEM
Windows
firmware
compatibilidade

O objetivo deve ser:

instalar o pacote correto para o dispositivo correto.

Não:

atualizar tudo porque existe um número maior.

Copie o Hardware ID

No Gerenciador de Dispositivos:

Propriedades
↓
Detalhes
↓
IDs de Hardware

Clique com o botão direito sobre a linha e copie.

Guarde em um arquivo de texto.

Por exemplo:

Computador:
Fabricante:
Modelo:

Dispositivo:
Nome mostrado pelo Windows:

Código de erro:

Hardware ID:
PCI\VEN_....&DEV_....

Isso cria um registro útil antes de qualquer alteração.

Como pesquisar corretamente pelo identificador

Em vez de pesquisar a linha completa logo de início, você pode trabalhar com os elementos principais.

Para PCI:

VEN_xxxx DEV_xxxx

Para USB:

VID_xxxx PID_xxxx

Mas não pare no primeiro resultado encontrado.

Confirme em fontes confiáveis e, principalmente, relacione o componente ao modelo real do computador.

Um resultado de pesquisa não é prova de compatibilidade do driver

Suponha que a busca indique que o Hardware ID provavelmente pertence a um determinado componente.

Isso responde:

“O que este dispositivo provavelmente é?”

Ainda precisamos responder:

“Qual pacote de driver devo instalar neste computador?”

São perguntas diferentes.

Exemplo de raciocínio correto

Dispositivo desconhecido
↓
PCI Hardware ID
↓
VEN identifica fornecedor
↓
DEV identifica dispositivo
↓
SUBSYS ajuda a contextualizar implementação
↓
modelo do notebook confirmado
↓
site oficial do fabricante
↓
driver correspondente

Esse caminho reduz bastante a chance de instalar um pacote inadequado.

Como saber se o driver baixado realmente contém suporte ao dispositivo?

Aqui entramos em uma etapa mais técnica.

Muitos pacotes de driver contêm arquivos:

.inf
.sys
.cat
.dll

O arquivo:

INF

é especialmente importante para a instalação e associação do pacote.

O INF pode revelar os dispositivos suportados

Depois de extrair um pacote de driver legítimo, é possível encontrar referências a Hardware IDs dentro dos arquivos INF.

Imagine que seu dispositivo possua:

PCI\VEN_1234&DEV_5678

e um INF contenha uma entrada correspondente.

Isso fornece uma evidência muito mais forte de que o pacote conhece aquele hardware.

Mas não edite o INF para “forçar compatibilidade”

Essa é uma prática ruim para diagnóstico comum.

Alterar o INF pode interferir com:

assinatura
integridade
instalação
compatibilidade

Se o pacote oficial não declara suporte ao dispositivo, precisamos descobrir por quê.

Não devemos simplesmente inserir o Hardware ID manualmente.

Como o Windows escolhe entre vários drivers?

Essa pergunta é muito importante.

Pode existir mais de um pacote capaz de atender um dispositivo.

O Windows precisa selecionar entre candidatos.

Entram em cena fatores relacionados à correspondência do dispositivo e ao pacote de driver.

É por isso que:

“tenho um driver instalado”

não significa necessariamente:

“o Windows está usando o pacote que eu imaginava”

O Gerenciador de Dispositivos pode mostrar informações do driver atual

Quando o dispositivo possui um driver associado:

Propriedades
↓
Driver

Observe:

Fornecedor do driver
Data do driver
Versão do driver

Também existe:

Detalhes do Driver

Isso ajuda a descobrir quais arquivos estão associados ao dispositivo.

Mas nosso dispositivo está desconhecido

Quando não existe associação adequada, essas informações podem ser limitadas.

Então precisamos de ferramentas adicionais.

Uma delas é:

PnPUtil

PnPUtil no Windows 11

O PnPUtil é uma ferramenta nativa do Windows para trabalhar com dispositivos e pacotes de driver.

Abra Terminal ou Prompt de Comando com os privilégios necessários para a operação que pretende executar.

Para começar, podemos simplesmente consultar.

Encontrando dispositivos com problema

Um comando particularmente útil é:

pnputil /enum-devices /problem

Ele ajuda a enumerar dispositivos que apresentam códigos de problema.

Isso é muito interessante quando o Gerenciador de Dispositivos parece confuso ou quando existem vários itens problemáticos.

Não use o comando apenas para copiar e colar uma solução

Leia o resultado.

Procure informações como:

Instance ID
Device Description
Class Name
Problem Code

A saída disponível pode variar conforme dispositivo e versão do Windows.

Device Instance ID

O Instance ID é outro identificador importante.

Ele identifica uma instância específica do dispositivo dentro do sistema PnP.

Não é exatamente a mesma coisa que dizer:

Hardware ID

Essa diferença será importante quando começarmos a consultar um dispositivo específico.

Get-PnpDevice no PowerShell

O PowerShell também oferece uma forma útil de visualizar dispositivos.

Experimente:

Get-PnpDevice

A saída pode ser grande.

Para observar dispositivos que não estão em estado normal:

Get-PnpDevice |
Where-Object Status -ne "OK"

Isso ajuda a encontrar itens que merecem investigação.

Consulte um dispositivo específico

Se você já conhece o Instance ID, podemos trabalhar de maneira muito mais direcionada.

Por enquanto, apenas registre:

FriendlyName
InstanceId
Status
Class

quando estiverem disponíveis.

A diferença entre nome amigável e identidade real

O Windows pode mostrar:

Dispositivo PCI

como nome.

Isso é apenas uma descrição genérica.

O identificador:

PCI\VEN_XXXX&DEV_YYYY...

é muito mais útil para descobrir o que realmente existe ali.

“Controlador PCI” não é o nome do driver que você deve pesquisar

Esse é um erro muito comum.

Pesquisar:

driver controlador PCI Windows 11

pode trazer resultados para inúmeros componentes completamente diferentes.

Primeiro descubra:

VEN
DEV
SUBSYS

quando presentes.

O mesmo vale para “Controlador de rede”

Um controlador de rede desconhecido pode ser:

Wi-Fi
Ethernet
outro adaptador

e cada computador pode utilizar fabricante e modelo diferentes.

Pesquisar apenas:

driver controlador de rede

é insuficiente.

Como saber se o problema apareceu depois de formatar?

Esse é um cenário muito comum.

Antes:

Windows funcionando
↓
todos os drivers instalados

Depois:

formatação
↓
Windows 11 limpo
↓
Dispositivo desconhecido

Isso aumenta a suspeita de que algum driver específico do equipamento não veio automaticamente com o Windows.

Chipset merece atenção

Depois de uma instalação limpa, componentes relacionados ao chipset e dispositivos da plataforma podem precisar de pacotes fornecidos pelo fabricante.

Mas não instale “qualquer driver de chipset”.

Primeiro confirme:

modelo
plataforma
Hardware IDs

O Windows Update pode encontrar drivers

O Windows Update também distribui drivers.

Portanto, antes de buscar pacotes obscuros, vale verificar as opções oficiais disponíveis no próprio Windows.

Dependendo da situação, drivers podem aparecer em atualizações opcionais.

Ainda assim, depois da instalação, confirme o resultado no Gerenciador de Dispositivos.

Como confirmar que o problema realmente foi resolvido?

Não basta o instalador mostrar:

Instalação concluída

Volte ao:

devmgmt.msc

e confirme:

o dispositivo desconhecido desapareceu?

Depois procure o componente em sua categoria correta.

Por exemplo:

Adaptadores de rede
Controladores USB
Controladores de som
Dispositivos do sistema

Confira o status

Abra:

Propriedades
↓
Geral

O ideal é que o dispositivo esteja funcionando normalmente, sem código de problema.

Confira o driver associado

Na guia:

Driver

observe:

Fornecedor
Data
Versão

Isso ajuda a confirmar o pacote que entrou em uso.

E se o instalador disser que funcionou, mas o dispositivo continuar desconhecido?

Agora o diagnóstico muda.

Temos:

driver aparentemente instalado
↓
Dispositivo desconhecido continua

Precisamos perguntar:

o pacote entrou no Driver Store?
o INF contém o Hardware ID?
o Windows considerou o pacote compatível?
a instalação encontrou erro?

É aqui que ferramentas como PnPUtil e os logs do SetupAPI se tornam extremamente importantes.

Driver Store: o driver pode existir no computador sem estar associado ao dispositivo

Esse conceito é fundamental.

Um pacote de driver pode estar presente no sistema e, ainda assim, determinado dispositivo não estar utilizando esse pacote.

Portanto:

driver presente

não é igual a:

driver associado corretamente ao dispositivo

Essa diferença explica um problema clássico

Usuário:

“Mas eu já instalei o driver.”

Gerenciador de Dispositivos:

Dispositivo desconhecido

Os dois fatos podem coexistir.

O instalador pode ter colocado arquivos no computador, mas o Windows ainda não encontrou uma correspondência válida para aquele dispositivo.

Precisamos então responder três perguntas

Pergunta 1

Qual é o Hardware ID real?

Pergunta 2

O pacote instalado declara suporte a esse Hardware ID?

Pergunta 3

O Windows tentou associar esse pacote e, se tentou, o que aconteceu?

A terceira pergunta nos leva a uma das fontes de diagnóstico mais interessantes deste artigo:

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

O que é o setupapi.dev.log?

O Windows mantém registros relacionados às operações de instalação de dispositivos.

O arquivo:

setupapi.dev.log

pode fornecer informações valiosas sobre o que ocorreu quando o Windows tentou instalar ou configurar determinado hardware.

Em vez de vermos apenas:

driver não instalou

podemos começar a procurar:

qual dispositivo?
qual pacote?
qual INF?
qual etapa?
qual resultado?

Esse será um dos pontos centrais da próxima parte.

Checklist da Parte 1

Antes de instalar qualquer driver para um dispositivo desconhecido:

[ ] Identifiquei fabricante do computador
[ ] Identifiquei modelo exato
[ ] Confirmei versão do Windows 11
[ ] Abri o Gerenciador de Dispositivos
[ ] Registrei o código de problema
[ ] Abri a guia Detalhes
[ ] Copiei os IDs de Hardware
[ ] Diferenciei PCI de USB
[ ] Identifiquei VEN/DEV quando PCI
[ ] Identifiquei VID/PID quando USB
[ ] Registrei SUBSYS quando disponível
[ ] Evitei sites aleatórios de drivers
[ ] Consultei primeiro fontes oficiais
[ ] Verifiquei se o pacote corresponde ao modelo
[ ] Confirmei o resultado no Gerenciador de Dispositivos
[ ] Usei PnPUtil para localizar dispositivos problemáticos
[ ] Registrei o Instance ID

Resumo do diagnóstico até aqui

Nosso método não é:

Dispositivo desconhecido
↓
Google
↓
baixar primeiro driver encontrado
↓
instalar

O método correto é:

Dispositivo desconhecido
↓
coletar Hardware ID
↓
identificar barramento
↓
interpretar VEN/DEV ou VID/PID
↓
confirmar modelo do computador
↓
localizar pacote oficial
↓
confirmar compatibilidade
↓
instalar
↓
verificar associação

E, se isso falhar:

PnPUtil
↓
Driver Store
↓
INF
↓
SetupAPI.dev.log

Essa segunda camada é justamente o que transforma uma tentativa de instalação de driver em um diagnóstico técnico.

Hardware ID, Instance ID, INF, Driver Store e PnPUtil: como provar que o driver realmente corresponde ao dispositivo

Na Parte 1, chegamos a um ponto fundamental: descobrir o provável fabricante do hardware não significa que já encontramos o driver correto.

Agora precisamos responder:

Como o Windows relaciona aquele dispositivo físico a um pacote de driver específico?

O caminho envolve vários elementos:

Dispositivo
↓
Hardware IDs
↓
Compatible IDs
↓
arquivo INF
↓
pacote de driver
↓
Driver Store
↓
seleção do driver
↓
instalação do dispositivo

Quando entendemos essa cadeia, fica muito mais fácil diagnosticar situações como:

“Eu instalei o driver,
mas o dispositivo continua desconhecido.”

Hardware ID, Compatible ID e Instance ID não são a mesma coisa

Esses três conceitos aparecem frequentemente durante o diagnóstico.

Vamos separá-los.

Hardware ID

É um identificador que descreve o hardware de maneira que o Windows possa procurar drivers correspondentes.

Um dispositivo PCI pode apresentar algo estruturalmente semelhante a:

PCI\VEN_1234&DEV_5678&SUBSYS_ABCD0001&REV_01

E também versões menos específicas:

PCI\VEN_1234&DEV_5678&SUBSYS_ABCD0001
PCI\VEN_1234&DEV_5678

Esses números são ilustrativos.

Compatible ID

O Windows também pode utilizar identificadores compatíveis.

Eles normalmente descrevem o dispositivo de forma menos específica.

Conceitualmente:

Hardware ID
→ correspondência mais específica

enquanto:

Compatible ID
→ correspondência mais genérica

Isso permite que um driver compatível com uma classe ou implementação mais ampla possa ser considerado em determinadas situações.

Instance ID

Já o Device Instance ID identifica uma instância específica daquele dispositivo no sistema.

Pense assim:

Hardware ID
=
“que tipo de hardware sou?”

e:

Instance ID
=
“qual é minha instância dentro deste Windows?”

Essa simplificação ajuda a entender por que os dois identificadores aparecem em contextos diferentes.

Por que o Instance ID é importante?

Porque ferramentas como PnPUtil podem utilizar o identificador da instância para consultar ou atuar sobre um dispositivo específico.

Imagine que existam vários dispositivos semelhantes.

Você não quer investigar genericamente:

todos os dispositivos USB

Você quer:

esta instância específica

Como copiar o Instance ID pelo Gerenciador de Dispositivos

Abra:

devmgmt.msc

Depois:

Dispositivo
↓
Propriedades
↓
Detalhes

No campo Propriedade, procure:

Caminho da instância do dispositivo

ou a propriedade equivalente apresentada pelo Windows.

Copie o valor.

Get-PnpDevice também mostra InstanceId

No PowerShell:

Get-PnpDevice

Podemos selecionar campos úteis:

Get-PnpDevice |
Select-Object Status, Class, FriendlyName, InstanceId

Isso cria uma visão muito mais prática.

Procure apenas dispositivos problemáticos

Get-PnpDevice |
Where-Object Status -ne "OK" |
Select-Object Status, Class, FriendlyName, InstanceId

Isso ajuda a reduzir o volume de informações.

Get-PnpDeviceProperty aprofunda a investigação

Quando você conhece o Instance ID, pode consultar propriedades PnP.

Por exemplo:

Get-PnpDeviceProperty -InstanceId "INSTANCE_ID"

Substitua:

INSTANCE_ID

pelo identificador real copiado do seu computador.

Não copie Instance IDs de tutoriais

Cada dispositivo e instalação pode apresentar identificadores próprios.

Use sempre os dados do equipamento que está sendo diagnosticado.

PnPUtil pode consultar dispositivos problemáticos

Como vimos:

pnputil /enum-devices /problem

Essa é uma excelente primeira triagem.

Enumerando dispositivos conectados

Outra consulta útil em versões atuais do Windows que suportam essa opção é:

pnputil /enum-devices /connected

Agora podemos comparar:

dispositivo conectado

com:

dispositivo apresentando problema

Consulte uma instância específica

Com o Instance ID em mãos, as opções disponíveis do PnPUtil permitem direcionar a consulta ao dispositivo.

O ponto importante é:

Gerenciador de Dispositivos
↓
Instance ID
↓
PnPUtil
↓
mesmo dispositivo

Isso evita investigar o hardware errado.

Agora precisamos entender o pacote de driver

Um driver do Windows normalmente não é apenas:

arquivo.sys

O pacote pode conter vários arquivos.

Exemplo:

driver.inf
driver.sys
driver.cat
DLLs
outros arquivos

O arquivo INF é essencial

O INF fornece instruções e informações utilizadas durante a instalação do dispositivo.

Ele pode definir:

  • dispositivos suportados;
  • arquivos necessários;
  • serviços;
  • informações do fabricante;
  • seções específicas;
  • configurações necessárias.

Para nossa investigação, um ponto é especialmente importante:

O INF declara suporte ao Hardware ID do dispositivo?

Exemplo conceitual

Hardware:

PCI\VEN_1234&DEV_5678

Dentro de um INF podemos encontrar uma referência correspondente.

Conceitualmente:

%DeviceName%=InstallSection,PCI\VEN_1234&DEV_5678

Se o identificador aparece em uma seção aplicável, temos evidência de que o pacote conhece aquele dispositivo.

Isso é melhor do que confiar apenas no nome do instalador

Imagine um arquivo:

Chipset_Driver_W11_x64.exe

O nome parece correto.

Mas isso não prova que o pacote contém suporte ao componente desconhecido.

Ao extrair o pacote e examinar os INFs, podemos verificar a correspondência real.

Pesquise o Hardware ID dentro dos INFs

Se você possui uma pasta com drivers oficiais extraídos, pode pesquisar pelo identificador.

Por exemplo, usando PowerShell:

Get-ChildItem "C:\Drivers" -Filter *.inf -Recurse |
Select-String -Pattern "VEN_1234&DEV_5678"

Troque o identificador pelo seu.

O resultado pode apontar para um INF

Algo conceitualmente semelhante a:

C:\Drivers\Chipset\driver.inf

Agora temos uma ligação:

Hardware ID
↓
aparece no INF
↓
pacote possui correspondência

Isso é muito mais sólido do que escolher pelo nome.

Pesquisar somente VEN pode gerar resultados demais

Se você procurar:

VEN_1234

poderá encontrar dezenas de dispositivos do mesmo fornecedor.

Prefira inicialmente a combinação:

VEN_1234&DEV_5678

E, quando necessário, considere também o SUBSYS.

Para USB, use VID e PID

Exemplo:

Get-ChildItem "C:\Drivers" -Filter *.inf -Recurse |
Select-String -Pattern "VID_1234&PID_5678"

Novamente, substitua pelos valores reais.

E se o INF não contiver o Hardware ID?

Isso é uma pista importante.

Talvez:

driver errado

ou:

pacote para outra variante

ou ainda:

driver usa correspondência diferente

Não force instalação imediatamente.

Não edite o INF para adicionar o ID

Pode parecer tentador fazer:

copiar linha
↓
trocar Hardware ID
↓
salvar INF

Mas isso pode quebrar a assinatura e não cria compatibilidade real.

O fato de dois dispositivos parecerem semelhantes não significa que utilizam exatamente o mesmo driver.

O catálogo também importa

Pacotes de drivers normalmente trabalham com mecanismos de assinatura e integridade.

Arquivos .cat fazem parte desse ecossistema.

Modificar o INF pode invalidar a relação esperada entre os componentes assinados do pacote.

O Driver Store

Agora chegamos a outro conceito fundamental.

O Windows mantém pacotes de drivers em um repositório chamado Driver Store.

De forma simplificada:

pacote validado
↓
Driver Store
↓
dispositivo pode utilizar o pacote

Um driver no Driver Store não significa que está em uso

Esse ponto merece repetição.

Podemos ter:

Pacote A
→ presente no Driver Store

mas:

Dispositivo X
→ não usa Pacote A

Portanto, quando alguém diz:

“O driver já está instalado.”

precisamos perguntar:

Instalado onde e associado a qual dispositivo?

Liste os pacotes de terceiros com PnPUtil

Execute:

pnputil /enum-drivers

Você poderá encontrar informações como:

Published Name
Original Name
Provider Name
Class Name
Driver Version
Signer Name

Published Name e Original Name

Um pacote pode ter originalmente um nome como:

fabricante.inf

mas aparecer publicado no Driver Store como:

oem42.inf

Isso é normal.

Por que oem42.inf aparece?

O Windows atribui nomes publicados como:

oem0.inf
oem1.inf
oem42.inf

a pacotes de terceiros adicionados ao Driver Store.

Por isso:

oem42.inf

não informa sozinho qual fabricante criou o driver.

Precisamos olhar os demais campos.

Exemplo conceitual

Published Name : oem42.inf
Original Name  : fabricante.inf
Provider Name  : Fabricante
Class Name     : System
Driver Version : ...

Agora temos contexto.

Procure o nome original

Se você sabe que o pacote baixado possui:

abcdriver.inf

pode verificar se ele aparece entre os pacotes enumerados.

Isso ajuda a responder:

O pacote realmente entrou no Driver Store?

Mas ainda não prova que o dispositivo está usando esse pacote

Precisamos relacionar:

Dispositivo

a:

Driver

Esse é o próximo passo.

O Gerenciador de Dispositivos pode revelar o INF em uso

Para um dispositivo que já possui driver:

Propriedades
↓
Driver
↓
Detalhes do Driver

pode mostrar arquivos relacionados.

Outras propriedades e ferramentas também ajudam a identificar o pacote associado.

PnPUtil pode fornecer informações mais detalhadas do dispositivo

Em versões atuais do Windows, o PnPUtil possui opções de enumeração que podem fornecer informações adicionais conforme os parâmetros suportados.

Antes de copiar comandos avançados de um tutorial antigo, consulte:

pnputil /?

Isso é importante porque o PnPUtil evoluiu ao longo das versões do Windows.

Esse cuidado também vale para este artigo

O Windows 11 recebe atualizações.

Portanto:

pnputil /?

é a referência local mais segura para confirmar quais opções existem naquele computador.

Por que um pacote compatível pode não ser escolhido?

Agora entramos em uma questão interessante.

Imagine:

Pacote A
→ contém ID compatível

Pacote B
→ também contém ID compatível

Qual deles o Windows escolhe?

A seleção de drivers não depende simplesmente de:

“qual tem data mais nova”

O Windows utiliza critérios de correspondência e classificação de drivers.

A especificidade da correspondência importa

Conceitualmente:

correspondência específica

pode ser preferível a:

correspondência genérica

Isso ajuda a entender a importância dos diferentes IDs apresentados pelo dispositivo.

Data e versão não contam toda a história

Outro erro frequente:

versão 10.5

é automaticamente melhor do que:

versão 10.4

Não necessariamente para aquele dispositivo específico.

Compatibilidade e seleção do pacote importam.

O driver do fabricante do notebook pode ser mais adequado

Em notebooks, um componente pode ter personalizações específicas do OEM.

Por isso, dependendo do hardware:

driver OEM

pode ser a escolha correta mesmo quando o fabricante do chip oferece um pacote numericamente mais recente.

Não use “Atualizar driver” como prova definitiva

O Gerenciador de Dispositivos pode informar algo como:

O melhor driver para o dispositivo já está instalado.

Isso não significa:

hardware está funcionando perfeitamente

A mensagem se refere ao processo de seleção dentro das opções disponíveis ao Windows naquele contexto.

Se o dispositivo continua apresentando erro, precisamos investigar o código e os logs.

Cenário: pacote está no Driver Store, mas dispositivo continua desconhecido

Temos:

Hardware ID identificado
↓
pacote oficial baixado
↓
INF contém o Hardware ID
↓
pacote aparece no Driver Store
↓
dispositivo continua problemático

Agora o diagnóstico ficou muito interessante.

Precisamos descobrir:

O que aconteceu durante a tentativa de instalação?

É aqui que o SetupAPI.dev.log ganha importância

O arquivo:

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

mantém registros relacionados à instalação de dispositivos.

Ele pode mostrar uma sequência muito mais detalhada do que a mensagem simplificada do Gerenciador de Dispositivos.

Antes de abrir o log, obtenha o Instance ID

Isso facilitará muito a busca.

Imagine que o dispositivo tenha um identificador semelhante a:

PCI\VEN_1234&DEV_5678&SUBSYS_...

e um Instance ID completo.

Copie-o.

Depois podemos procurar trechos desse identificador no log.

Abra o setupapi.dev.log

O caminho padrão é:

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

Você pode abri-lo em um editor de texto adequado.

Não altere o arquivo.

Use-o como fonte de diagnóstico.

O arquivo pode ser grande

Não tente ler do início ao fim.

Pesquise:

VEN_XXXX

ou:

VID_XXXX

ou uma parte suficientemente específica do Instance ID.

Exemplo

Se o Hardware ID contém:

VEN_1234&DEV_5678

pesquise:

VEN_1234&DEV_5678

Isso pode levar à seção referente à tentativa de instalação daquele dispositivo.

Procure o início da seção

O log costuma organizar operações em blocos.

Quando localizar o dispositivo, observe algumas linhas anteriores para entender:

quando começou
qual operação estava ocorrendo
qual dispositivo estava envolvido

Depois siga até o final da operação

Queremos reconstruir:

início
↓
busca de driver
↓
seleção
↓
instalação
↓
resultado

Não leia apenas a última linha

O erro final pode ser consequência de algo ocorrido anteriormente.

Assim como no Process Monitor, procure a primeira divergência relevante.

Compare uma instalação bem-sucedida quando possível

Se houver outro dispositivo semelhante funcionando, o log pode ajudar a entender como uma operação normal se parece.

Isso não significa que os dois dispositivos sejam idênticos.

A comparação serve para entender a estrutura do processo.

O SetupAPI ajuda a responder perguntas que o Gerenciador não responde claramente

Por exemplo:

O Windows encontrou algum driver?
Qual INF foi considerado?
A instalação chegou a iniciar?
Em qual etapa ocorreu problema?

Essas perguntas transformam o diagnóstico.

Não procure apenas a palavra ERROR

Um log técnico pode possuir mensagens que parecem alarmantes, mas não representam a causa final.

O contexto é essencial.

Horário também é importante

Se você acabou de tentar instalar o driver às:

14:32

procure a seção correspondente àquela tentativa.

Isso reduz a chance de analisar uma instalação antiga.

Crie uma tentativa controlada

Uma estratégia útil é:

anotar horário
↓
executar ação de instalação
↓
anotar resultado
↓
abrir setupapi.dev.log
↓
procurar evento daquele horário/dispositivo

Agora você sabe exatamente qual tentativa analisar.

Não fique repetindo instalação dezenas de vezes

Cada tentativa pode aumentar o ruído.

Faça:

uma tentativa
↓
analisar
↓
formular hipótese
↓
próximo teste

O INF encontrado no log pode ser relacionado ao Driver Store

Se o log mencionar algo como:

oem42.inf

podemos voltar ao:

pnputil /enum-drivers

e descobrir:

Original Name
Provider
Class
Version
Signer

Agora relacionamos:

tentativa de instalação
↓
oem42.inf
↓
pacote específico

Esse cruzamento é extremamente útil

Temos três lados:

Hardware ID
Device Instance
INF / pacote

Quando os três são relacionados, deixamos de adivinhar.

Exemplo completo de raciocínio

Imagine:

Gerenciador:
Dispositivo PCI desconhecido

Hardware ID:

PCI\VEN_1234&DEV_5678

Encontramos no pacote oficial:

driverabc.inf

O pacote aparece no Driver Store como:

oem42.inf

O SetupAPI registra tentativa envolvendo:

oem42.inf

Agora podemos investigar por que a instalação não terminou corretamente.

Isso é muito diferente de “instale o driver de chipset”

A recomendação genérica seria:

instale chipset
↓
reinicie

Nosso diagnóstico é:

qual dispositivo?
↓
qual Hardware ID?
↓
qual INF?
↓
qual pacote?
↓
qual tentativa?
↓
qual resultado?

Quando o driver está instalado, mas o dispositivo ainda mostra código de erro

Nesse cenário, não estamos mais necessariamente diante de:

driver ausente

Pode haver:

driver carregado
+
dispositivo não iniciou corretamente

Isso muda completamente a investigação.

Código 28 é diferente de Código 10 ou Código 43

De forma geral, códigos diferentes representam situações diferentes.

Portanto, registre exatamente o código exibido em:

Propriedades
↓
Geral
↓
Status do dispositivo

Não pesquise apenas:

ícone amarelo Windows 11

Código 28 merece atenção quando falta driver

Um cenário em que o Windows informa ausência de drivers para o dispositivo aponta fortemente para a etapa de seleção/instalação do pacote.

Nesse caso:

Hardware ID
+
INF
+
Driver Store
+
SetupAPI

são especialmente úteis.

Código 10 muda a pergunta

Se existe driver associado, mas o dispositivo não consegue iniciar corretamente, a investigação já pode envolver:

driver
firmware
dependências
dispositivo
hardware

O problema não é simplesmente “baixar o driver”.

Código 43 também não deve ser traduzido automaticamente como hardware queimado

O Windows está reportando um problema associado ao dispositivo/driver.

A causa precisa ser investigada.

Não condene o hardware apenas pelo número.

E “Dispositivo USB desconhecido”?

USB merece cuidado especial.

Alguns problemas acontecem antes mesmo de o Windows conseguir obter corretamente informações suficientes do dispositivo.

Nesse caso, podemos ter questões relacionadas a:

porta
cabo
energia
hub
dispositivo
controlador USB

Não é sempre um simples “driver faltando”.

Hardware ID ausente ou estranho é uma pista

Se o Windows não consegue fornecer os identificadores esperados, talvez o problema esteja ocorrendo em uma etapa anterior à seleção normal do driver.

Isso muda o caminho do diagnóstico.

Não force PnPUtil sem saber o pacote

O PnPUtil pode realizar operações de instalação e gerenciamento.

Esses recursos são poderosos.

Mas nosso princípio permanece:

identificar
↓
confirmar
↓
instalar

e não:

forçar todos os INFs encontrados

Cuidado com instalação recursiva de pastas enormes de drivers

É tecnicamente possível trabalhar com múltiplos pacotes em operações administrativas, mas instalar indiscriminadamente uma coleção inteira de drivers não é o objetivo deste diagnóstico.

Queremos o pacote certo.

Checklist avançado da Parte 2

Antes de avançar para uma instalação forçada ou concluir que o hardware está com defeito:

[ ] Copiei o Hardware ID
[ ] Copiei o Instance ID
[ ] Diferenciei Hardware ID de Instance ID
[ ] Consultei Compatible IDs
[ ] Usei Get-PnpDevice
[ ] Consultei propriedades PnP
[ ] Usei pnputil /enum-devices /problem
[ ] Identifiquei o pacote oficial
[ ] Extraí o pacote quando necessário
[ ] Pesquisei VEN/DEV nos arquivos INF
[ ] Pesquisei VID/PID quando USB
[ ] Verifiquei SUBSYS quando relevante
[ ] Não editei o INF
[ ] Consultei pnputil /enum-drivers
[ ] Identifiquei Published Name
[ ] Identifiquei Original Name
[ ] Identifiquei Provider
[ ] Confirmei se o pacote está no Driver Store
[ ] Diferenciei pacote presente de pacote em uso
[ ] Registrei o código do dispositivo
[ ] Abri setupapi.dev.log
[ ] Pesquisei o Hardware/Instance ID
[ ] Relacionei horário da tentativa
[ ] Identifiquei o INF citado no log

O principal aprendizado desta parte

Quando um dispositivo aparece como desconhecido, não precisamos trabalhar por tentativa.

Podemos construir uma cadeia de evidências:

Hardware físico
↓
Hardware ID
↓
Device Instance
↓
INF correspondente
↓
pacote no Driver Store
↓
tentativa registrada pelo SetupAPI

Se o driver correto não está presente, descobrimos.

Se o pacote está presente, mas não corresponde ao Hardware ID, descobrimos.

Se corresponde e está no Driver Store, mas o Windows não consegue concluir a instalação, também temos como avançar.

A partir desse ponto, a pergunta deixa de ser:

“Qual driver eu baixo?”

e passa a ser:

“Por que o Windows não conseguiu associar ou iniciar corretamente o driver que deveria atender este dispositivo?”

Como ler o setupapi.dev.log e descobrir por que o driver não foi associado ao dispositivo

Nas partes anteriores, chegamos até aqui:

Dispositivo desconhecido
↓
Hardware ID identificado
↓
pacote oficial encontrado
↓
INF aparentemente compatível
↓
driver presente no sistema

Mesmo assim, o Gerenciador de Dispositivos continua mostrando problema.

É nesse ponto que muita gente volta para tentativas aleatórias:

reinstalar driver
↓
reiniciar
↓
baixar outro pacote
↓
atualizar tudo

Mas existe um caminho melhor.

O Windows registra operações de instalação de dispositivos em:

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

Esse arquivo pode mostrar o que aconteceu entre:

“Windows detectou o hardware”

e:

“dispositivo terminou ou não terminou a instalação”

O que o setupapi.dev.log pode revelar

Dependendo do caso, o log pode ajudar a responder:

Qual dispositivo estava sendo instalado?
Qual INF entrou na seleção?
Qual pacote foi considerado?
A instalação chegou a começar?
Em qual etapa ocorreu falha?
Qual foi o resultado final?

Isso muda completamente a qualidade do diagnóstico.

Não leia o arquivo inteiro

O setupapi.dev.log pode ter muitas entradas.

A estratégia correta é reduzir o problema usando:

Hardware ID
+
Instance ID
+
horário da tentativa

Primeiro anote o horário

Antes de repetir a instalação:

  1. abra o Gerenciador de Dispositivos;
  2. anote o horário atual;
  3. execute apenas uma tentativa;
  4. registre o resultado;
  5. abra o log imediatamente depois.

Exemplo:

15:42
Tentei atualizar o dispositivo
Resultado: falhou

Agora sabemos onde procurar.

Localize pelo Hardware ID

Imagine que o dispositivo tenha:

PCI\VEN_1234&DEV_5678

Pesquise no log por:

VEN_1234&DEV_5678

Quando possível, use uma parte mais específica, incluindo SUBSYS.

Isso reduz resultados de outros dispositivos semelhantes.

Instance ID pode ser ainda melhor

Se você copiou o caminho completo da instância:

PCI\VEN_1234&DEV_5678&SUBSYS_...\
...

procure por uma parte suficientemente única.

Isso ajuda a garantir que você está analisando o dispositivo certo.

Procure o início do bloco

Quando encontrar o identificador, não comece exatamente na linha localizada.

Suba algumas linhas.

O objetivo é encontrar o início da operação.

Você quer reconstruir:

início da instalação
↓
identificação do dispositivo
↓
seleção do pacote
↓
configuração
↓
resultado

O log costuma ter separadores visuais

Você poderá encontrar blocos delimitados por linhas e marcadores que ajudam a identificar o início e o fim de operações.

O texto exato pode variar entre versões do Windows.

Não tente decorar uma aparência específica.

Procure a sequência lógica.

Comece pela identidade do dispositivo

Confirme que o bloco pertence ao mesmo hardware.

Compare:

Hardware ID

com:

Instance ID

e com o que aparece no Gerenciador de Dispositivos.

Se os identificadores não correspondem, você está lendo o bloco errado.

Depois procure o pacote de driver

O log pode citar um INF por nome.

Por exemplo:

oem42.inf

Esse nome sozinho não diz qual driver é.

Precisamos relacioná-lo ao Driver Store.

Volte ao PnPUtil

Use:

pnputil /enum-drivers

Procure:

Published Name : oem42.inf

Depois registre:

Original Name
Provider Name
Class Name
Driver Version
Signer Name

Agora sabemos exatamente qual pacote o log estava utilizando.

Exemplo conceitual

No SetupAPI:

oem42.inf

No PnPUtil:

Published Name : oem42.inf
Original Name  : chipsetabc.inf
Provider Name  : Fabricante X
Class Name     : System

Agora temos a ligação:

Dispositivo
↓
SetupAPI
↓
oem42.inf
↓
chipsetabc.inf

Essa relação é muito importante

Sem ela, o usuário pode pensar:

“O Windows está usando um driver estranho chamado oem42.inf.”

Na verdade, esse é apenas o nome publicado pelo Windows para um pacote de terceiros.

Procure a fase de seleção

Um problema pode acontecer antes da instalação propriamente dita.

Por exemplo:

Windows detecta dispositivo
↓
procura candidatos
↓
não encontra pacote compatível

Nesse caso, o problema é diferente de:

pacote encontrado
↓
instalação começou
↓
falhou depois

Primeiro grande cenário: nenhum driver compatível foi selecionado

Esse é o caso mais próximo de:

driver realmente ausente

A investigação deve voltar para:

Hardware ID
INF
modelo do computador
versão do pacote

Verifique o INF novamente

Pesquise o Hardware ID dentro da pasta oficial extraída.

Exemplo:

Get-ChildItem "C:\Drivers" -Filter *.inf -Recurse |
Select-String -Pattern "VEN_1234&DEV_5678"

Se nada aparecer:

pacote provavelmente não contém correspondência direta

Não confunda pacote da mesma categoria com pacote compatível

Exemplo:

Driver de chipset

é um nome genérico.

Um pacote de chipset pode conter vários componentes.

Isso não significa que ele necessariamente atende aquele Hardware ID específico.

Segundo cenário: o driver foi encontrado, mas a instalação falhou

Agora já existe correspondência.

O problema ocorre depois.

A investigação muda para:

assinatura
arquivos
serviço
permissão
dependência
configuração

Observe o resultado final do bloco

Procure o encerramento da operação.

Não interprete apenas uma linha intermediária.

Um log pode conter avisos ou tentativas alternativas que não representam a causa final.

Cuidado com palavras assustadoras

Termos como:

error
failure
not found

podem aparecer em etapas secundárias.

A pergunta correta continua sendo:

Qual foi a primeira falha relevante que alterou o resultado da instalação?

Isso é parecido com usar Process Monitor

No Process Monitor:

milhares de eventos

não significam milhares de problemas.

No SetupAPI é parecido.

Precisamos entender contexto.

Terceiro cenário: o pacote está instalado, mas não foi associado ao dispositivo

Pode acontecer de:

driver no Driver Store

mas:

dispositivo sem associação válida

Essa diferença é extremamente importante.

Como comprovar

Temos três fatos:

1. pnputil /enum-drivers
→ pacote existe
2. INF contém Hardware ID
→ pacote conhece dispositivo
3. Gerenciador ainda mostra problema

Agora o SetupAPI deve explicar o que aconteceu durante a tentativa de associação.

Quarto cenário: o driver foi associado, mas o dispositivo não inicia

Esse caso já não é simplesmente “driver faltando”.

Imagine:

driver associado
↓
dispositivo continua com Código 10

Agora precisamos investigar:

driver
firmware
hardware
dependência
recurso
dispositivo

Código 10 exige outra linha de raciocínio

Um Código 10 geralmente significa que o dispositivo não conseguiu iniciar corretamente.

Isso é diferente de:

Windows não encontrou driver

Portanto, não continue procurando dezenas de pacotes diferentes sem antes entender o estado atual.

Código 43 também muda a investigação

Se aparece Código 43:

driver existe
↓
dispositivo reportou problema

Isso pode envolver:

hardware
firmware
USB
energia
driver

Não significa automaticamente que o dispositivo está queimado.

Código 28 aponta mais diretamente para driver ausente

Quando o Windows informa que drivers não estão instalados, o foco permanece em:

identificação
correspondência
pacote
instalação

Monte uma tabela com código e hipótese

CódigoDireção inicial de investigação
28driver ausente/não associado
10dispositivo não inicia
43dispositivo/driver reporta problema
outroconsultar significado específico

Não use essa tabela como diagnóstico final.

Use como direção inicial.

Compare o Gerenciador de Dispositivos antes e depois

Antes:

Dispositivo desconhecido
Código 28

Depois da instalação:

Nome real do dispositivo
Código 10

Isso significa que alguma coisa mudou.

O Windows agora reconhece o dispositivo e associou um driver, mas o hardware ainda não iniciou corretamente.

Esse é um avanço diagnóstico.

Não diga que “não funcionou nada”

A transição:

Código 28
↓
Código 10

mostra que o problema mudou de fase.

Antes:

não havia driver adequado

Depois:

driver foi associado, mas dispositivo não iniciou

Isso é informação valiosa.

Procure o nome real do dispositivo

Quando o driver é associado, o item pode sair de:

Outros dispositivos

e aparecer em outra classe.

Exemplo:

Dispositivos do sistema

ou:

Adaptadores de rede

ou:

Controladores USB

Use Get-PnpDevice novamente

Depois da tentativa:

Get-PnpDevice |
Where-Object Status -ne "OK"

Compare o FriendlyName, Class e InstanceId.

O nome mudou?

Se antes:

Dispositivo PCI

e depois:

Controlador XYZ

isso indica que a associação de driver avançou.

Verifique propriedades do driver

No Gerenciador:

Propriedades
↓
Driver

Observe:

Fornecedor
Data
Versão

Verifique também os arquivos do driver

Detalhes do Driver

Isso ajuda a descobrir quais arquivos entraram em uso.

Relacione novamente ao Driver Store

Se o dispositivo agora possui um driver associado, tente identificar qual INF está sendo utilizado.

Esse pacote deve corresponder ao que apareceu no SetupAPI.

Se dois pacotes parecem compatíveis

Você pode encontrar:

oem42.inf

e:

oem57.inf

para dispositivos semelhantes.

Não remova nenhum imediatamente.

Primeiro compare:

Provider
Version
Original Name
Class

e, quando possível, a correspondência com o Hardware ID.

Driver mais novo não é automaticamente melhor

O Windows leva em consideração critérios de seleção.

Um pacote numericamente mais novo pode não ser o pacote adequado para aquele hardware/OEM.

Não remova pacotes do Driver Store por tentativa

O PnPUtil também permite remover drivers.

Essa é uma operação que exige muito cuidado.

Apagar um pacote errado pode afetar outros dispositivos.

Antes de qualquer remoção

Confirme:

qual dispositivo usa?
é pacote duplicado?
é OEM?
é necessário para outro hardware?

Evite tutoriais que mandam apagar vários oemXX.inf

Essa prática pode transformar um único dispositivo problemático em vários.

Quinto cenário: o SetupAPI mostra tentativa com pacote inesperado

Imagine que você esperava:

Driver do fabricante A

mas o log mostra:

pacote do fabricante B

Isso merece investigação.

Primeiro confirme o Hardware ID

Talvez você tenha identificado o dispositivo errado.

Ou talvez o hardware compartilhe uma classe/driver genérico.

Não conclua conflito apenas pelo nome.

Compare o INF

Procure o Hardware ID no pacote selecionado.

Se ele realmente aparece, existe uma razão técnica para o Windows considerá-lo.

Verifique SUBSYS

Dois dispositivos com:

VEN
DEV

iguais podem diferir no SUBSYS.

Isso pode explicar por que o pacote OEM é diferente.

Sexto cenário: o instalador oficial termina com sucesso, mas nada muda

Esse problema é muito comum.

O instalador mostra:

Instalação concluída

mas o dispositivo continua com alerta.

Precisamos perguntar:

o instalador realmente tentou este dispositivo?

Um instalador pode instalar vários componentes

Exemplo:

setup.exe

pode instalar:

serviço
aplicativo
driver A
driver B
driver C

O instalador retornar sucesso não prova que o componente específico foi associado.

Consulte o Driver Store depois

Antes:

pnputil /enum-drivers

Depois:

pnputil /enum-drivers

Compare os pacotes.

Procure o INF novo

Se o pacote apareceu depois da instalação:

instalador adicionou driver ao Driver Store

Mas ainda precisamos confirmar:

dispositivo está usando?

O SetupAPI ajuda justamente nisso

Se o driver entrou no Driver Store mas o dispositivo continuou desconhecido, procure a tentativa correspondente.

Sétimo cenário: Windows Update troca o driver

Depois de instalar manualmente:

dispositivo funciona

mais tarde:

driver muda
↓
problema aparece

Esse é outro tipo de investigação.

Primeiro comprove a mudança

Registre:

Fornecedor
Versão
Data
INF

antes e depois.

Não conclua que o Windows Update trocou o driver apenas porque o problema apareceu após reiniciar.

Monitor de Confiabilidade pode ajudar na linha do tempo

Execute:

perfmon /rel

Procure:

instalações
atualizações
falhas

no período em que o comportamento mudou.

Windows Update History também pode fornecer contexto

Verifique se houve atualização de driver próxima ao momento da mudança.

O SetupAPI pode mostrar nova instalação

Se um novo pacote foi associado, o log pode registrar esse processo.

Isso ajuda a transformar suspeita em evidência.

Oitavo cenário: dispositivo aparece e desaparece

Imagine:

boot
↓
dispositivo aparece
↓
depois desaparece

ou:

conecta
↓
Windows detecta
↓
alguns segundos depois some

Nesse caso, o problema pode ocorrer antes ou depois da associação do driver.

Verifique o Gerenciador de Dispositivos em tempo real

Observe se:

item muda de nome

ou:

desaparece completamente

ou:

volta como dispositivo desconhecido

Cada comportamento indica uma fase diferente.

USB merece atenção especial aqui

Para USB, verifique:

porta
cabo
hub
energia
controlador

principalmente quando o identificador do dispositivo não é lido de forma consistente.

Se o Hardware ID muda ou some

Isso pode indicar que o Windows não consegue enumerar corretamente o dispositivo.

Nesse caso, simplesmente instalar um novo driver pode não resolver.

Nono cenário: aparece “Unknown USB Device”

Pode haver mensagens relacionadas a falha na obtenção do descritor ou outros problemas de enumeração.

Nesses casos, o Windows pode nem chegar à etapa normal de identificar corretamente:

VID
PID

Se VID/PID não aparecem de forma útil

A investigação deve incluir camada física e USB.

Não continue procurando driver pelo nome genérico.

Teste outra porta

Quando for um dispositivo USB externo e seguro:

porta diferente

pode ajudar a separar:

problema do dispositivo

de:

problema da porta/controlador

Evite hubs no teste inicial

Conecte diretamente ao computador quando possível.

Isso reduz uma variável.

Décimo cenário: dispositivo funciona em outro computador

Isso é informação importante.

Se:

PC A → falha
PC B → funciona

então o hardware pode estar funcional.

Agora investigue no PC A:

driver
controlador
porta
firmware
Windows

Mas não elimina defeito intermitente

Um dispositivo pode funcionar em um ambiente e falhar em outro por questões de energia, compatibilidade ou estado.

Portanto, o teste é evidência, não prova absoluta.

Como construir uma linha do tempo completa

Exemplo:

09:00 Windows inicia
09:02 dispositivo aparece como desconhecido
09:10 Hardware ID coletado
09:15 pacote oficial baixado
09:17 INF confirmado
09:20 instalação executada
09:21 item muda de nome
09:21 Código 10 aparece

Agora sabemos:

identificação → OK
correspondência → OK
instalação → avançou
inicialização do dispositivo → falhou

Essa linha do tempo é muito mais útil do que:

“Instalei o driver e não funcionou.”

Use o SetupAPI como histórico técnico

O valor do log não está apenas no erro.

Ele ajuda a reconstruir o caminho.

O que procurar em uma tentativa

Monte mentalmente:

1. qual dispositivo?
2. qual Hardware/Instance ID?
3. qual INF?
4. qual pacote?
5. qual etapa?
6. qual resultado?

Se não encontrar o dispositivo no log

Primeiro confirme:

identificador correto

Depois tente:

parte menor do Hardware ID

ou:

horário da instalação

Não pesquise somente o nome amigável

Nomes como:

Dispositivo desconhecido

não são suficientemente específicos.

Hardware ID e Instance ID são melhores.

Se o log é antigo demais

Faça uma nova tentativa controlada.

Anote o horário e pesquise imediatamente.

Se o arquivo parecer difícil de interpretar

Não tente entender todas as linhas.

Comece apenas com:

Device ID
INF
resultado

Depois aprofunde.

Mapeamento rápido dos quatro estados principais

Estado A — driver realmente ausente

dispositivo detectado
↓
nenhum pacote adequado
↓
Código 28

Foco:

Hardware ID
INF
pacote oficial

Estado B — pacote presente, mas não associado

driver no Driver Store
↓
dispositivo continua sem driver adequado

Foco:

seleção
SetupAPI
correspondência

Estado C — driver associado, dispositivo não inicia

driver existe
↓
nome real aparece
↓
Código 10 / outro erro

Foco:

driver
firmware
dependências
hardware

Estado D — dispositivo reporta problema

driver carregado
↓
dispositivo/driver reporta falha
↓
Código 43

Foco:

hardware
firmware
USB
energia
driver

O erro muda de significado ao longo do diagnóstico

Esse conceito é crucial.

Se começamos em:

Código 28

e terminamos em:

Código 10

não ficamos no mesmo lugar.

O Windows avançou uma etapa.

Agora devemos mudar o diagnóstico.

Não continue reinstalando o mesmo pacote indefinidamente

Se o dispositivo já possui driver associado e mostra Código 10:

reinstalar o mesmo INF 20 vezes

provavelmente não adicionará informação.

Procure a próxima camada.

Verifique atualização de BIOS/UEFI apenas quando houver relação

Alguns dispositivos dependem de firmware e plataforma.

Mas não transforme atualização de BIOS em tentativa genérica.

Confirme:

modelo exato
versão atual
notas oficiais
relação com hardware

O mesmo vale para firmware do dispositivo

Se o fabricante documenta uma correção específica, isso pode ser relevante.

Caso contrário, não atualize firmware por tentativa.

Verifique dependências de chipset

Alguns dispositivos do sistema dependem de pacotes de plataforma.

Se você instalou apenas o driver final, mas componentes anteriores continuam ausentes, o dispositivo pode não funcionar corretamente.

Isso é comum depois de instalação limpa do Windows

Fluxo possível:

Windows instalado
↓
faltam componentes de chipset/plataforma
↓
outros dispositivos aparecem desconhecidos

Instalar na ordem adequada do fabricante pode fazer diferença.

Mas não existe uma ordem universal para todos os computadores

Siga documentação do fabricante do equipamento.

Não use listas genéricas como:

1. chipset
2. vídeo
3. áudio

como regra absoluta para qualquer máquina.

Checklist da Parte 3

[ ] Anotei o horário da tentativa
[ ] Localizei Hardware ID no setupapi.dev.log
[ ] Confirmei o Instance ID
[ ] Identifiquei o bloco correto
[ ] Localizei o INF citado
[ ] Relacionei oemXX.inf ao pacote real
[ ] Consultei Provider
[ ] Consultei Original Name
[ ] Consultei Driver Version
[ ] Diferenciei driver ausente de instalação falha
[ ] Verifiquei se pacote está no Driver Store
[ ] Verifiquei se dispositivo está usando o pacote
[ ] Registrei o código de erro
[ ] Comparei antes e depois da instalação
[ ] Verifiquei se o nome do dispositivo mudou
[ ] Diferenciei Código 28, 10 e 43
[ ] Não removi drivers aleatoriamente
[ ] Não editei INF
[ ] Não instalei vários pacotes indiscriminadamente
[ ] Verifiquei linha do tempo
[ ] Considerei USB físico quando necessário

O principal aprendizado desta parte

O setupapi.dev.log ajuda a transformar um problema aparentemente simples de driver em uma sequência técnica:

Windows detectou
↓
identificou
↓
procurou candidatos
↓
selecionou ou não selecionou
↓
instalou ou falhou
↓
dispositivo iniciou ou não iniciou

Cada etapa responde uma pergunta diferente.

Isso permite distinguir:

driver faltando

de:

driver presente, mas não associado

de:

driver associado, mas dispositivo não inicia

de:

hardware/driver reportando problema

Essa separação evita perder tempo instalando pacotes aleatórios.

Parte 4 — Procedimento completo para identificar o dispositivo, localizar o driver correto e confirmar a instalação

Agora vamos transformar todo o diagnóstico das partes anteriores em um método reproduzível.

A ideia é simples:

não adivinhar
↓
identificar
↓
confirmar
↓
instalar
↓
validar

Esse processo funciona especialmente bem quando o Gerenciador de Dispositivos mostra algo genérico como:

Dispositivo desconhecido
Controlador PCI
Controlador de rede
Dispositivo USB desconhecido

Procedimento definitivo em 30 etapas

1. Abra o Gerenciador de Dispositivos

Pressione:

Win + R

Digite:

devmgmt.msc

Localize o dispositivo com alerta.

2. Anote o nome que o Windows está mostrando

Pode ser algo como:

Dispositivo desconhecido
Controlador PCI
Controlador multimídia
Controlador de rede

Não use esse nome como identificação final.

Ele serve apenas como ponto de partida.

3. Abra as propriedades

Clique com o botão direito:

Propriedades

Na guia:

Geral

anote o código de problema.

4. Registre o código exibido

Por exemplo:

Código 28
Código 10
Código 43

Esse número ajuda a definir em qual fase o problema está.

5. Vá até Detalhes

Abra:

Detalhes

Selecione:

IDs de Hardware

6. Copie o identificador mais específico

Exemplo conceitual PCI:

PCI\VEN_1234&DEV_5678&SUBSYS_ABCD0001&REV_01

Exemplo conceitual USB:

USB\VID_1234&PID_5678

Use sempre o ID real do seu equipamento.

7. Identifique o barramento

Se começa com:

PCI\

observe:

VEN
DEV
SUBSYS

Se começa com:

USB\

observe:

VID
PID

8. Copie também o Instance ID

Na guia Detalhes, procure a propriedade correspondente ao caminho da instância.

Guarde esse valor separadamente.

9. Descubra fabricante e modelo do computador

Execute:

msinfo32

ou:

Get-CimInstance Win32_ComputerSystem |
Select-Object Manufacturer, Model

Registre o modelo exato.

10. Confirme a versão do Windows

Execute:

winver

Confirme também a arquitetura do sistema.

11. Consulte dispositivos problemáticos pelo PnPUtil

Abra o Terminal.

Execute:

pnputil /enum-devices /problem

Compare o dispositivo encontrado com:

Instance ID
Description
Problem Code

12. Use PowerShell para uma segunda visão

Get-PnpDevice |
Where-Object Status -ne "OK" |
Select-Object Status, Class, FriendlyName, InstanceId

Isso ajuda quando existem vários dispositivos problemáticos.

13. Confirme que está investigando o mesmo dispositivo

Compare:

Gerenciador de Dispositivos
Instance ID
Hardware ID
Get-PnpDevice
PnPUtil

Os dados precisam apontar para a mesma instância.

14. Procure primeiro o driver oficial

Dê preferência a:

fabricante do computador
fabricante da placa-mãe
fabricante oficial do componente
Windows Update

Evite sites genéricos de drivers.

15. Não escolha apenas pelo nome do pacote

Um arquivo chamado:

ChipsetDriver.exe

não prova que atende seu Hardware ID.

16. Extraia o pacote quando necessário

Procure arquivos:

.inf
.sys
.cat

O INF será especialmente útil para comprovar correspondência.

17. Pesquise o Hardware ID nos INFs

Para PCI:

Get-ChildItem "C:\Drivers" -Filter *.inf -Recurse |
Select-String -Pattern "VEN_1234&DEV_5678"

Para USB:

Get-ChildItem "C:\Drivers" -Filter *.inf -Recurse |
Select-String -Pattern "VID_1234&PID_5678"

Substitua pelos valores reais.

18. Se necessário, refine com SUBSYS

Se vários pacotes aparecem, procure também a parte:

SUBSYS_...

Isso pode ajudar a diferenciar variantes OEM.

19. Não edite o INF

Se o Hardware ID não aparece:

não force compatibilidade

Volte e confirme se o pacote correto foi escolhido.

20. Verifique se o pacote entrou no Driver Store

Execute:

pnputil /enum-drivers

Procure:

Original Name
Published Name
Provider Name
Class Name
Driver Version
Signer Name

21. Relacione o nome original ao oemXX.inf

Exemplo:

Original Name  : abcdriver.inf
Published Name : oem42.inf

Agora você sabe como o Windows registrou o pacote.

22. Tente uma instalação controlada

Anote o horário.

Faça uma única tentativa de instalação.

Depois anote o resultado.

23. Abra o log do SetupAPI

Caminho:

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

24. Procure pelo Hardware ID

Pesquise:

VEN_XXXX&DEV_YYYY

ou:

VID_XXXX&PID_YYYY

Quando possível, use também parte do Instance ID.

25. Localize o bloco da tentativa correta

Use:

horário
Instance ID
Hardware ID

para encontrar a seção certa.

26. Identifique o INF citado

Se aparecer:

oem42.inf

volte ao:

pnputil /enum-drivers

e descubra qual pacote ele representa.

27. Classifique o resultado

Pergunte:

nenhum driver foi encontrado?

ou:

driver foi encontrado, mas instalação falhou?

ou:

driver foi associado, mas dispositivo não iniciou?

Essas são situações diferentes.

28. Compare o estado antes e depois

Antes:

Dispositivo desconhecido
Código 28

Depois:

Nome real do dispositivo
Código 10

Isso significa que houve progresso na identificação/associação.

29. Pare de reinstalar se o problema mudou de fase

Se o dispositivo já possui driver associado, mas não inicia:

não continue procurando simplesmente outro INF

Passe a investigar:

firmware
dependências
USB
energia
hardware

conforme o caso.

30. Documente o resultado

Guarde:

modelo do PC
Hardware ID
Instance ID
código original
driver instalado
INF utilizado
versão do driver
resultado final

Isso torna qualquer diagnóstico futuro muito mais rápido.

Fluxograma rápido

Dispositivo desconhecido
        ↓
Hardware ID disponível?
        ↓
Sim
        ↓
Identificar VEN/DEV ou VID/PID
        ↓
Confirmar modelo do computador
        ↓
Encontrar pacote oficial
        ↓
INF contém o ID?
        ↓
Sim
        ↓
Pacote está no Driver Store?
        ↓
Sim
        ↓
SetupAPI mostra associação?
        ↓
        ├── Não → investigar seleção/instalação
        │
        └── Sim
             ↓
        dispositivo iniciou?
             ↓
        ├── Sim → resolvido
        │
        └── Não → investigar driver/firmware/hardware

Cenário 1 — Formatei o notebook e apareceu Controlador PCI

Esse é um caso clássico.

Depois da instalação limpa:

Outros dispositivos
└── Controlador PCI

O erro mais comum é procurar:

driver controlador PCI Windows 11

O correto é abrir:

Propriedades
↓
Detalhes
↓
IDs de Hardware

e trabalhar com:

VEN
DEV
SUBSYS

Depois relacione ao modelo exato do notebook.

Cenário 2 — Controlador de rede desconhecido

Se o Windows não possui driver de rede, você pode ficar sem Internet.

Não pesquise apenas:

driver Wi-Fi

Primeiro confirme se o dispositivo é realmente Wi-Fi.

Observe o Hardware ID.

Depois identifique:

fabricante
modelo
variante OEM

Cenário 3 — Driver do Wi-Fi instala, mas continua sem funcionar

Imagine:

antes:
Controlador de rede
Código 28

depois:

Adaptador Wi-Fi XYZ
Código 10

Isso indica que o Windows conseguiu identificar e associar um pacote.

O problema agora está na inicialização do dispositivo.

Não trate mais como simples driver ausente.

Cenário 4 — Dispositivo USB desconhecido sem VID/PID útil

Se o Windows não consegue ler corretamente informações básicas do dispositivo USB, o problema pode estar antes da seleção normal do driver.

Teste, quando seguro:

outra porta
cabo diferente
conexão direta
sem hub
outro computador

Isso ajuda a separar driver de falha de enumeração física.

Cenário 5 — O driver está no Driver Store, mas nada acontece

Você executa:

pnputil /enum-drivers

e encontra o pacote.

Isso prova apenas:

pacote presente

Não prova:

dispositivo usando pacote

Procure a associação no SetupAPI.

Cenário 6 — O instalador oficial diz “sucesso”, mas o ícone amarelo continua

Esse caso exige cuidado.

O instalador pode ter instalado:

aplicativo
serviço
outros drivers

sem resolver especificamente aquele dispositivo.

Confirme o INF.

Cenário 7 — O Windows Update instalou um driver diferente

Registre antes:

Fornecedor
Versão
Data
INF

Se o problema aparecer depois, compare.

Não conclua troca apenas pela coincidência com uma reinicialização.

Cenário 8 — Código 43 depois de instalar o driver

O dispositivo já possui driver.

Agora investigue:

driver
firmware
energia
USB
hardware

Não use Código 43 como sinônimo de dispositivo queimado.

Cenário 9 — Código 10 aparece após instalação

O Windows reconheceu o dispositivo e tentou iniciá-lo.

A pergunta passa a ser:

por que ele não iniciou?

e não:

qual driver está faltando?

Cenário 10 — O Hardware ID pertence a um fabricante conhecido, mas nenhum driver funciona

Confirme:

modelo do computador
SUBSYS
arquitetura
versão do Windows
pacote OEM

O fabricante do chip não é necessariamente a única fonte relevante.

Tabela rápida de interpretação

SituaçãoO que significa inicialmentePróximo passo
Código 28driver ausente/não associadoHardware ID + INF
Pacote no Driver Storedriver existe no sistemaconfirmar associação
INF contém Hardware IDpacote conhece o dispositivoverificar seleção
Nome do dispositivo mudadriver provavelmente foi associadoconferir código atual
Código 10dispositivo não iniciadriver/firmware/dependências
Código 43dispositivo/driver reporta problemahardware/firmware/USB/driver
Sem VID/PID útil em USBenumeração pode ter falhadoporta/cabo/energia/dispositivo
SetupAPI cita outro INFoutro pacote foi consideradomapear oemXX.inf

Comandos úteis reunidos

Ver dispositivos problemáticos

pnputil /enum-devices /problem

Ver dispositivos conectados

pnputil /enum-devices /connected

Ver opções suportadas pelo PnPUtil

pnputil /?

Listar pacotes de drivers

pnputil /enum-drivers

PowerShell: dispositivos problemáticos

Get-PnpDevice |
Where-Object Status -ne "OK" |
Select-Object Status, Class, FriendlyName, InstanceId

Propriedades de uma instância

Get-PnpDeviceProperty -InstanceId "INSTANCE_ID"

Pesquisar VEN/DEV em arquivos INF

Get-ChildItem "C:\Drivers" -Filter *.inf -Recurse |
Select-String -Pattern "VEN_1234&DEV_5678"

Pesquisar VID/PID

Get-ChildItem "C:\Drivers" -Filter *.inf -Recurse |
Select-String -Pattern "VID_1234&PID_5678"

O que não fazer

Evite transformar diagnóstico de drivers em tentativa e erro.

Não recomendo:

baixar drivers de sites aleatórios

nem:

instalar dezenas de pacotes

nem:

apagar vários oemXX.inf

nem:

editar INF para forçar compatibilidade

nem:

concluir hardware queimado apenas por Código 43

Também evite atualizar tudo sem necessidade

Atualizadores genéricos de drivers podem trocar pacotes que já funcionavam corretamente.

O objetivo deste procedimento é justamente o oposto:

mudar apenas o que conseguimos identificar

Checklist final

[ ] Localizei o dispositivo problemático
[ ] Registrei o código
[ ] Copiei Hardware ID
[ ] Copiei Instance ID
[ ] Identifiquei PCI ou USB
[ ] Interpretei VEN/DEV ou VID/PID
[ ] Confirmei fabricante e modelo do PC
[ ] Procurei pacote oficial
[ ] Confirmei Hardware ID no INF
[ ] Não editei o INF
[ ] Consultei Driver Store
[ ] Mapeei Original Name para oemXX.inf
[ ] Fiz tentativa controlada
[ ] Analisei setupapi.dev.log
[ ] Confirmei qual INF foi considerado
[ ] Comparei antes e depois
[ ] Registrei o novo código
[ ] Diferenciei driver ausente de driver que não inicia
[ ] Testei hardware físico quando necessário
[ ] Documentei a solução

FAQ — Dispositivo desconhecido e Hardware IDs no Windows 11

O que é um dispositivo desconhecido no Windows 11?

É um dispositivo que o Windows detectou, mas não conseguiu apresentar/configurar normalmente com um driver apropriado ou encontrou algum problema durante esse processo.

Dispositivo desconhecido significa que o hardware está com defeito?

Não.

Pode ser apenas driver ausente, pacote incompatível, falha de instalação ou outro problema de configuração.

Onde encontro o Hardware ID?

No Gerenciador de Dispositivos:

Propriedades
↓
Detalhes
↓
IDs de Hardware

O que significa VEN?

Em dispositivos PCI, VEN representa o Vendor ID.

O que significa DEV?

Em PCI, DEV identifica o dispositivo.

O que significa SUBSYS?

Ajuda a identificar a implementação/subsistema específico do dispositivo, algo especialmente útil em computadores OEM.

O que significa VID em USB?

Vendor ID.

E PID?

Product ID.

Nesse contexto, não significa Process ID.

Posso pesquisar VEN e DEV no Google?

Pode ajudar a identificar o componente, mas o driver deve ser confirmado em uma fonte oficial e relacionado ao modelo do computador.

É seguro baixar driver em qualquer site que reconheça meu Hardware ID?

Não é a melhor prática.

Prefira fabricantes oficiais e Windows Update.

O fabricante do chip sempre oferece o melhor driver?

Não necessariamente.

Em notebooks e computadores OEM, pode existir pacote específico do fabricante do equipamento.

Por que existem vários Hardware IDs?

Eles representam diferentes níveis de especificidade e compatibilidade que podem ser utilizados durante a seleção de drivers.

Hardware ID e Instance ID são iguais?

Não.

O Hardware ID descreve o tipo de hardware; o Instance ID identifica uma instância específica no sistema.

O que é Compatible ID?

É um identificador usado para indicar níveis de compatibilidade mais genéricos.

O que é um arquivo INF?

É um arquivo usado pelo Windows para descrever informações e instruções de instalação de dispositivos.

Como descubro se um INF suporta meu dispositivo?

Pesquise o Hardware ID dentro do arquivo ou do conjunto de INFs do pacote.

Posso adicionar manualmente meu Hardware ID ao INF?

Não é recomendado.

Isso pode quebrar assinatura e não cria compatibilidade técnica real.

O que é Driver Store?

É o repositório do Windows onde pacotes de drivers são armazenados para uso pelo sistema.

Se o driver está no Driver Store, ele está sendo usado?

Não necessariamente.

Pacote presente e pacote associado ao dispositivo são coisas diferentes.

O que é oem42.inf?

É um exemplo de nome publicado pelo Windows para um pacote de driver de terceiros.

O nome original pode ser completamente diferente.

Como descubro o nome original?

Use:

pnputil /enum-drivers

e compare:

Published Name
Original Name

Para que serve pnputil /enum-devices /problem?

Ele ajuda a listar dispositivos que apresentam códigos de problema.

PnPUtil substitui o Gerenciador de Dispositivos?

Não.

As duas ferramentas se complementam.

Para que serve Get-PnpDevice?

Permite consultar dispositivos Plug and Play pelo PowerShell.

Onde fica o setupapi.dev.log?

Normalmente:

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

O que esse log registra?

Ele registra informações relacionadas à instalação e configuração de dispositivos e drivers.

Preciso ler o arquivo inteiro?

Não.

Procure pelo Hardware ID, Instance ID e horário da tentativa.

Código 28 significa o quê?

É uma forte indicação de que o dispositivo não possui driver apropriado instalado/associado.

E Código 10?

Indica que o dispositivo não conseguiu iniciar corretamente.

Código 43 significa dispositivo queimado?

Não necessariamente.

Pode envolver hardware, firmware, USB, energia ou driver.

Se o código muda de 28 para 10, piorou?

Não necessariamente.

Isso pode mostrar que o driver foi encontrado e associado, mas o dispositivo ainda não conseguiu iniciar.

Atualizar o Windows resolve?

Pode instalar drivers disponíveis, mas não substitui uma identificação correta do dispositivo.

Vale usar “Atualizações opcionais”?

Pode ser útil quando o Windows oferece driver para aquele equipamento, mas valide o resultado após a instalação.

Posso instalar todos os drivers da pasta do fabricante?

É melhor instalar somente os pacotes necessários e documentados para seu modelo.

O instalador oficial dizer “sucesso” prova que o dispositivo foi corrigido?

Não.

Confirme no Gerenciador de Dispositivos e no PnPUtil.

Preciso reiniciar sempre?

Alguns pacotes podem solicitar reinicialização, mas não use reboot como substituto do diagnóstico.

Posso remover o dispositivo e mandar detectar novamente?

Em alguns casos isso ajuda, mas primeiro registre Hardware ID, Instance ID e driver atual para não perder evidências.

Posso remover o pacote do Driver Store?

É possível administrar pacotes com ferramentas nativas, mas remover o pacote errado pode afetar outros dispositivos. Só faça isso quando souber exatamente qual pacote está relacionado ao problema.

O que fazer se não existe Hardware ID útil?

Em dispositivos USB, isso pode indicar que a enumeração falhou antes da identificação normal. Investigue conexão física, cabo, energia, porta e o próprio dispositivo.

Se funciona em outro PC, o hardware está perfeito?

Não é prova absoluta, mas reduz a suspeita de defeito total e ajuda a focar no ambiente do computador com problema.

Qual é o melhor comando para começar?

Para triagem:

pnputil /enum-devices /problem

Mas ele deve ser combinado com o Gerenciador de Dispositivos e Hardware IDs.

Conclusão

Um Dispositivo desconhecido no Windows 11 não precisa virar uma sequência de downloads aleatórios.

O próprio Windows fornece informações suficientes para conduzir uma investigação muito mais precisa.

O caminho começa em:

Hardware ID

e pode avançar para:

VEN / DEV
VID / PID
SUBSYS
Instance ID
INF
Driver Store
PnPUtil
SetupAPI.dev.log

Quando usamos essas informações em conjunto, conseguimos responder perguntas que o nome “Dispositivo desconhecido” jamais responderia sozinho:

qual hardware é este?

qual pacote conhece este dispositivo?

o driver realmente entrou no Windows?

o Windows tentou associá-lo?

a instalação falhou ou o dispositivo não iniciou?

Essa mudança de abordagem evita duas práticas muito comuns: baixar o primeiro driver encontrado na Internet e instalar pacotes em massa até o ícone amarelo desaparecer.

O objetivo não é apenas eliminar o aviso do Gerenciador de Dispositivos.

É entender por que o Windows não conseguiu configurar aquele hardware e corrigir exatamente a etapa que falhou.

Suporte técnico VMIA

Se o computador apresenta Dispositivo desconhecido, Código 28, Código 10, Código 43, drivers que não instalam ou hardware que deixou de funcionar depois de uma formatação ou atualização do Windows, a VMIA pode realizar o diagnóstico do equipamento e identificar a origem do problema.

A análise pode envolver Gerenciador de Dispositivos, Hardware IDs, PnPUtil, arquivos INF, Driver Store, logs do Windows e testes do próprio hardware.

VMIA – Manutenção e Configuração
Atendimento técnico em Windows, computadores, notebooks, impressoras, redes e suporte remoto ou presencial em São Paulo.
WhatsApp/Telefone: (11) 99779-7772
Atendimento com agendamento.

Seja o primeiro a comentar

Faça um comentário

Seu e-mail não será publicado.


*