Você encontra o driver mais recente no site do fabricante, instala manualmente, reinicia o computador e confirma no Gerenciador de Dispositivos que a nova versão está funcionando. Tudo parece resolvido. Algumas horas ou dias depois, porém, o problema retorna. Ao verificar novamente, você percebe algo estranho: o Windows 11 substituiu o driver que você instalou por outro.

Em algumas situações, o novo driver desaparece logo depois de uma atualização do Windows. Em outras, a substituição acontece após reiniciar o computador, remover e conectar novamente um dispositivo USB ou executar uma nova procura por alterações de hardware.

A primeira reação costuma ser culpar o Windows Update.

Entretanto, existe um mecanismo muito mais complexo por trás dessa escolha.

O Windows não trabalha simplesmente com a regra:

“O número de versão maior vence.”

O sistema utiliza um processo de seleção de pacotes de drivers baseado em diferentes critérios. O Windows analisa quais pacotes são compatíveis com o dispositivo e determina qual deles considera a melhor correspondência. Entre os elementos envolvidos estão assinatura, correspondência com identificadores do dispositivo, classificação do pacote e, em determinadas situações de desempate, data e versão.

Por isso, um driver que parece mais novo para o usuário não necessariamente será considerado pelo Windows como o melhor driver para aquele hardware. A própria documentação da Microsoft explica que o Windows classifica os pacotes compatíveis e seleciona a melhor correspondência; entre correspondências de mesma classificação, data e depois versão entram no processo de desempate.

Esse detalhe explica muitos casos aparentemente inexplicáveis.

Imagine, por exemplo, um notebook que possui um adaptador Wi-Fi. Você acessa o site do fabricante do chip, encontra um pacote mais recente e instala o driver. Ele funciona perfeitamente.

O fabricante do notebook, entretanto, pode possuir outro pacote preparado especificamente para aquele equipamento. Dependendo de como os pacotes correspondem ao hardware e de como foram publicados e classificados, o Windows pode preferir outro pacote compatível em vez daquele que você acabou de instalar.

O resultado para o usuário é simples:

“Instalei o driver novo e o Windows colocou o antigo de volta.”

Para entender por que isso acontece, precisamos primeiro entender como o Windows identifica um dispositivo.

O Windows não escolhe um driver pelo nome do dispositivo

Quando você abre o Gerenciador de Dispositivos, encontra nomes amigáveis como:

• Intel Wireless;
• Realtek PCIe;
• NVIDIA GeForce;
• AMD Radeon;
• controlador de áudio;
• webcam;
• impressora;
• adaptador Bluetooth;
• controlador USB.

Esses nomes ajudam o usuário, mas não representam toda a lógica utilizada pelo Plug and Play para identificar o hardware.

Um dispositivo apresenta ao Windows identificadores de hardware, conhecidos como Hardware IDs.

Esses identificadores permitem que o sistema determine exatamente qual equipamento está conectado e quais pacotes de driver podem atendê-lo.

A Microsoft define Hardware ID como uma cadeia de identificação utilizada pelo Windows para fazer a correspondência entre um dispositivo e um pacote de driver. Um mesmo dispositivo pode apresentar vários Hardware IDs, normalmente ordenados do mais específico para o menos específico.

Um adaptador PCI, por exemplo, pode apresentar identificadores contendo informações equivalentes ao fabricante, dispositivo e subsistema.

Um exemplo conceitual poderia ser:

PCI\VEN_XXXX&DEV_YYYY&SUBSYS_ZZZZZZZZ

O significado das partes pode variar conforme o barramento e o dispositivo, mas em equipamentos PCI encontramos frequentemente:

VEN

relacionado ao fabricante.

DEV

relacionado ao dispositivo.

SUBSYS

relacionado ao subsistema ou implementação específica daquele hardware.

É exatamente por isso que dois computadores aparentemente equipados com “a mesma placa” podem receber pacotes diferentes.

O chip principal pode ser semelhante, enquanto o fabricante do notebook ou da placa implementou características específicas.

Como visualizar o Hardware ID no Windows 11

O próprio Gerenciador de Dispositivos permite consultar essa informação.

Abra:

Gerenciador de Dispositivos → dispositivo desejado → Propriedades → Detalhes

No campo Propriedade, procure:

IDs de Hardware

O Windows exibirá uma ou mais identificações.

Essa informação é extremamente útil para diagnóstico porque permite descobrir com muito mais precisão qual dispositivo está instalado.

Mas existe outra categoria importante.

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

Além dos Hardware IDs, o Windows trabalha com Compatible IDs.

Um Compatible ID representa uma correspondência normalmente mais genérica. Segundo a Microsoft, quando o Windows não encontra um pacote correspondente aos Hardware IDs do dispositivo, ele pode recorrer aos Compatible IDs para encontrar um driver capaz de fornecer algum grau de funcionalidade.

Podemos imaginar a lógica desta maneira:

Hardware ID específico

↓

Hardware ID menos específico

↓

Compatible ID

↓

driver mais genérico

Isso ajuda a entender por que determinados dispositivos conseguem funcionar imediatamente depois de uma instalação limpa do Windows 11, mesmo antes de você instalar manualmente o pacote disponibilizado pelo fabricante.

O Windows pode possuir um driver compatível no seu próprio repositório.

Ele talvez não ofereça todos os recursos especiais do fabricante, mas pode ser suficiente para fazer o hardware funcionar.

O arquivo INF é fundamental nessa história

Quando falamos em driver, muita gente pensa apenas em um arquivo .sys.

Na realidade, um pacote de driver possui outros componentes.

Um dos mais importantes para a instalação é o arquivo:

.inf

O INF contém informações utilizadas durante o processo de instalação, inclusive dados que ajudam o Windows a determinar para quais dispositivos aquele pacote foi desenvolvido.

É justamente a correspondência entre os identificadores apresentados pelo dispositivo e aqueles declarados pelo pacote que participa do processo de seleção.

Isso explica uma situação interessante:

Você possui dois drivers aparentemente destinados ao mesmo dispositivo.

Driver A

Versão: 10.5.20

Driver B

Versão: 9.8.15

O usuário olha os números e conclui:

10.5.20 é maior, portanto o Driver A deveria ganhar.

Essa conclusão não é necessariamente correta.

O Windows precisa primeiro determinar qual pacote representa a melhor correspondência para aquele dispositivo.

A versão não funciona como um campeonato no qual o maior número automaticamente vence todos os demais critérios.

Existe um ranking de drivers

Quando vários pacotes podem atender ao mesmo dispositivo, o Windows atribui uma classificação às correspondências.

A documentação da Microsoft descreve esse ranking como um valor que representa o quanto determinado pacote corresponde ao dispositivo. De forma simplificada, quanto menor o valor de rank, melhor a correspondência.

A classificação considera fatores relacionados à assinatura, aos recursos do pacote e ao tipo de correspondência entre os identificadores apresentados pelo dispositivo e aqueles declarados pelo INF.

Esse mecanismo é importante porque um computador pode acumular vários pacotes capazes de controlar o mesmo equipamento.

O Windows precisa escolher um.

E aqui aparece uma das principais explicações para o problema deste artigo:

Instalar manualmente um pacote não significa necessariamente que ele continuará sendo a melhor correspondência encontrada pelo Windows em todas as seleções futuras.

Data e versão importam, mas existe uma ordem

Existe outra confusão comum.

Muitos usuários acreditam que o Windows compara todos os drivers disponíveis e simplesmente escolhe aquele com maior número de versão.

Não funciona dessa forma.

De acordo com a documentação da Microsoft, primeiro entra a classificação da correspondência. Quando existem pacotes igualmente classificados como melhor correspondência, o Windows utiliza a data do driver como próximo critério. Se a classificação e a data forem iguais, a versão é utilizada.

Portanto:

Rank → Data → Versão

é uma maneira útil de visualizar parte importante do processo de desempate entre pacotes que já correspondem ao dispositivo.

Isso produz situações que parecem absurdas quando observadas apenas pelo número da versão.

Um pacote com numeração aparentemente menor pode continuar sendo escolhido se tiver uma correspondência mais adequada dentro das regras do Windows.

A Microsoft inclusive alerta, em sua documentação de implantação de drivers, que um pacote importado corretamente para o Driver Store pode posteriormente perder para outro pacote que o Plug and Play considere melhor classificado.

E onde o Windows guarda todos esses drivers?

Aqui chegamos a outro componente fundamental:

Driver Store

O Windows mantém pacotes de drivers em um repositório próprio.

É por isso que simplesmente desinstalar um dispositivo no Gerenciador de Dispositivos nem sempre produz o resultado esperado.

O dispositivo pode desaparecer da lista.

Você reinicia o computador.

O Plug and Play detecta novamente o hardware.

E poucos segundos depois…

o mesmo driver reaparece.

O Windows não necessariamente baixou aquele pacote novamente naquele momento.

Ele pode simplesmente ter utilizado um pacote que já estava disponível no repositório de drivers.

Essa diferença é importantíssima durante um diagnóstico.

Remover o dispositivo e remover determinado pacote de driver não são necessariamente a mesma operação.

É aqui que ferramentas como o PnPUtil começam a ficar muito interessantes.

O Windows Update também participa

O Windows Update pode distribuir drivers.

Isso significa que um computador pode ter acesso a pacotes provenientes de diferentes origens:

fabricante do computador;

fabricante do componente;

pacotes já existentes no Windows;

Driver Store;

Windows Update;

instalações anteriores;

softwares de atualização fornecidos pelo fabricante.

O Windows Update também não precisa entregar simplesmente “o driver com maior versão”. A documentação da Microsoft explica que o serviço utiliza critérios de aplicabilidade e seleção; além disso, drivers podem ser distribuídos em categorias diferentes, inclusive como atualizações opcionais.

Em sistemas atuais, isso torna inadequada a ideia de que:

Windows Update = sempre driver mais novo.

O objetivo é selecionar um pacote considerado aplicável e adequado ao equipamento dentro das regras utilizadas pelo Windows.

O próprio fabricante do computador pode influenciar

Existe ainda um mecanismo chamado CHID — Computer Hardware ID.

Ele permite que drivers distribuídos pelo Windows Update sejam direcionados a determinados grupos de computadores com base em informações do equipamento.

A documentação atual da Microsoft explica que o Windows Update utiliza CHIDs para reduzir o conjunto de sistemas aos quais determinado driver se aplica antes da classificação Plug and Play.

Isso ajuda a explicar por que dois computadores com componentes aparentemente semelhantes podem receber drivers diferentes pelo Windows Update.

O modelo do computador também pode importar.

Essa situação aparece bastante em:

notebooks;

computadores OEM;

workstations;

mini PCs;

equipamentos corporativos.

Como descobrir quem realmente substituiu o driver?

Até agora explicamos o mecanismo.

Mas o objetivo deste tutorial não é simplesmente aceitar que “o Windows escolheu outro”.

Queremos descobrir o que aconteceu de verdade.

E existe uma fonte extremamente poderosa para isso:

SetupAPI.dev.log

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

Por padrão, o arquivo fica em:

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

Segundo a Microsoft, o SetupAPI registra informações de instalação de dispositivos nesse arquivo de texto, permitindo verificar instalações e investigar problemas.

Mais interessante ainda: durante a seleção de drivers, o log pode registrar informações de Rank e do pacote INF envolvido.

Isso muda completamente o diagnóstico.

Em vez de perguntar:

“Por que o Windows insiste nesse driver?”

podemos tentar descobrir:

qual INF foi utilizado;

qual driver estava instalado;

quais candidatos foram considerados;

qual pacote venceu;

qual pacote perdeu;

quando a instalação ocorreu.

Ou seja, saímos do achismo e começamos a investigar as evidências deixadas pelo próprio Windows.

Como descobrir qual driver o Windows 11 realmente está usando

Na primeira parte entendemos que o Windows 11 não escolhe um driver simplesmente porque seu número de versão é maior. O Plug and Play analisa os pacotes compatíveis e determina qual deles representa a melhor correspondência para o dispositivo.

Agora surge uma pergunta mais importante:

Como descobrir exatamente qual driver está sendo usado?

Não basta abrir o Gerenciador de Dispositivos e observar algo como:

Versão do driver: 23.100.0.4

Precisamos relacionar o dispositivo ao pacote instalado, ao arquivo INF e aos demais pacotes disponíveis no Driver Store.

É nesse ponto que o diagnóstico começa a ficar realmente interessante.

Comece pelo Gerenciador de Dispositivos

O primeiro passo pode ser realizado pela interface gráfica.

Pressione:

Windows + X

e abra:

Gerenciador de Dispositivos

Localize o equipamento que apresenta o problema.

Pode ser, por exemplo:

• adaptador Wi-Fi;
• Bluetooth;
• placa de vídeo;
• controlador de áudio;
• webcam;
• impressora;
• controlador USB;
• placa Ethernet;
• dispositivo PCI;
• leitor de cartões.

Clique com o botão direito e abra:

Propriedades

Depois acesse:

Driver

Normalmente encontraremos informações como:

Fornecedor do driver

Data do driver

Versão do driver

Essas três informações já ajudam bastante.

Imagine o seguinte cenário:

Fornecedor:

Intel

Data:

15/04/2026

Versão:

23.x.x.x

Você instala manualmente outro pacote.

Depois de reiniciar, verifica novamente e encontra:

Fornecedor:

Microsoft

ou outra versão do fabricante.

Isso comprova que houve alguma alteração.

Mas ainda não sabemos qual pacote INF está controlando o dispositivo.

Para isso precisamos ir mais fundo.

---

Descobrindo o INF associado ao dispositivo

Volte para:

Propriedades → Detalhes

No menu Propriedade, procure informações relacionadas ao INF ou ao nome publicado do driver, quando disponíveis.

Dependendo do dispositivo e da versão do Windows, você poderá encontrar referências como:

oem42.inf

Esse pequeno nome é extremamente importante.

O arquivo:

oem42.inf

não significa que o fabricante criou originalmente um driver chamado oem42.

Esse é o nome publicado atribuído ao pacote quando ele foi adicionado ao Driver Store.

O pacote original poderia ter outro nome.

Depois que o Windows o adiciona ao repositório, ele pode receber um nome publicado no formato:

oemXX.inf

Por exemplo:

oem12.inf

oem27.inf

oem42.inf

oem105.inf

Isso permite que o Windows diferencie os diversos pacotes de terceiros armazenados no sistema.

E existe uma ferramenta nativa excelente para trabalhar com essas informações:

PnPUtil

O PnPUtil.exe acompanha o Windows e permite administrar diferentes aspectos do Plug and Play e dos pacotes de drivers.

Abra o Terminal como administrador.

Você pode usar Windows Terminal, PowerShell ou Prompt de Comando.

Digite:

pnputil /enum-drivers

O Windows apresentará os pacotes de drivers de terceiros presentes no Driver Store.

A saída pode conter informações semelhantes a:

Published Name: oem42.inf

Original Name: exemplo.inf

Provider Name: Fabricante

Class Name: Net

Driver Version: 04/15/2026 23.x.x.x

Signer Name: Microsoft Windows Hardware Compatibility Publisher

Os nomes apresentados podem variar conforme idioma e versão do Windows, mas o princípio é o mesmo.

Agora começamos a enxergar algo que o Gerenciador de Dispositivos normalmente não deixa tão evidente.

Podemos ter vários pacotes relacionados ao mesmo fabricante ou classe armazenados no computador.

---

Driver instalado não é sinônimo de único driver disponível

Essa distinção é essencial.

Imagine que o computador apresente três pacotes relacionados a um adaptador de rede:

oem18.inf

Versão A

oem37.inf

Versão B

oem62.inf

Versão C

O dispositivo está usando apenas um deles naquele momento.

Os demais, entretanto, podem continuar armazenados no Driver Store.

É por isso que determinadas tentativas de correção parecem não funcionar.

O usuário abre o Gerenciador de Dispositivos.

Seleciona:

Desinstalar dispositivo

Reinicia.

O Windows detecta novamente o hardware.

Poucos segundos depois, o driver reaparece.

A conclusão normalmente é:

“O Windows baixou o driver outra vez.”

Talvez.

Mas não necessariamente.

O pacote poderia já estar disponível localmente no Driver Store.

O Plug and Play apenas encontrou o dispositivo novamente, verificou os pacotes disponíveis e instalou aquele que considerou apropriado.

---

Como filtrar a enorme lista do PnPUtil

Em computadores utilizados há vários anos, o comando:

pnputil /enum-drivers

pode produzir uma lista bastante grande.

Não é raro encontrar dezenas ou até centenas de pacotes.

Podemos facilitar a análise.

No Prompt de Comando, por exemplo, podemos combinar a saída com:

findstr

Exemplo:

pnputil /enum-drivers | findstr /i "Intel"

Ou:

pnputil /enum-drivers | findstr /i "Realtek"

O parâmetro:

/i

faz com que a pesquisa não diferencie letras maiúsculas e minúsculas.

Mas existe uma limitação.

Ao filtrar dessa maneira, podemos perder linhas relacionadas ao mesmo bloco do pacote.

Portanto, o filtro serve principalmente para localização rápida.

Depois de descobrir um provável oemXX.inf, é melhor consultar o pacote de maneira mais específica.

---

PnPUtil ficou muito mais poderoso nas versões modernas do Windows

O PnPUtil não serve apenas para listar drivers.

Nas versões modernas do Windows, ele também possui comandos para enumerar dispositivos.

Um comando muito útil é:

pnputil /enum-devices /connected

Ele lista dispositivos atualmente conectados.

Isso ajuda quando queremos relacionar:

dispositivo físico → Instance ID → driver

Também podemos trabalhar com classes.

Por exemplo, adaptadores de rede pertencem normalmente à classe:

Net

Dependendo da versão do Windows e das opções disponíveis, o PnPUtil permite aplicar filtros adicionais.

Antes de copiar comandos encontrados em fóruns antigos, vale verificar quais parâmetros sua instalação do Windows realmente suporta.

Digite:

pnputil /?

Isso mostra a ajuda disponível naquela versão do Windows.

Esse cuidado é importante porque a Microsoft ampliou consideravelmente o PnPUtil ao longo das versões do Windows 10 e Windows 11.

---

Instance ID: a identidade daquela instância do dispositivo

Outro conceito importante é o:

Device Instance ID

ou:

ID da Instância do Dispositivo

Não devemos confundi-lo com Hardware ID.

O Hardware ID descreve características utilizadas para identificar e corresponder o hardware aos drivers.

O Instance ID identifica aquela instância específica do dispositivo dentro da árvore Plug and Play.

Podemos encontrar algo semelhante a:

PCI\VEN_XXXX&DEV_YYYY&SUBSYS_ZZZZZZZZ\...

ou, para USB:

USB\VID_XXXX&PID_YYYY\...

Essa informação é muito útil quando existem vários dispositivos parecidos.

Imagine um computador com:

adaptador Ethernet;

Wi-Fi;

adaptadores virtuais;

Bluetooth;

VPN;

Hyper-V;

máquinas virtuais;

adaptadores antigos não presentes.

Pesquisar apenas por palavras como “Intel” ou “Realtek” pode gerar confusão.

O Instance ID permite direcionar a investigação ao dispositivo correto.

---

Consultando um dispositivo específico com PnPUtil

Depois de identificar o Instance ID, podemos consultar aquele dispositivo.

Em versões compatíveis do Windows, podemos utilizar:

pnputil /enum-devices /instanceid "INSTANCE_ID"

Substitua INSTANCE_ID pelo identificador real.

Por exemplo, conceitualmente:

pnputil /enum-devices /instanceid "PCI\VEN_XXXX&DEV_YYYY..."

As aspas são importantes quando trabalhamos com valores que podem conter caracteres interpretados pelo shell.

Também podemos solicitar informações adicionais usando opções suportadas pela versão atual do PnPUtil.

Isso permite aproximar duas informações fundamentais:

Qual é o dispositivo?

e

Qual driver está associado a ele?

---

PowerShell também ajuda muito

Outra maneira de investigar dispositivos é utilizar o PowerShell.

Um comando bastante útil é:

Get-PnpDevice

Ele permite consultar dispositivos conhecidos pelo Plug and Play.

Experimente:

Get-PnpDevice | Sort-Object Class

A saída normalmente apresenta informações como:

Status

Class

FriendlyName

InstanceId

Agora podemos pesquisar um dispositivo pelo nome.

Por exemplo:

Get-PnpDevice | Where-Object FriendlyName -Like "*Realtek*"

Ou:

Get-PnpDevice | Where-Object FriendlyName -Like "*Intel*"

Não considere esses filtros uma prova definitiva da identidade do hardware. Eles apenas ajudam a localizar o dispositivo.

Depois de encontrar o InstanceId, podemos continuar a investigação com identificadores mais precisos.

---

Obtendo propriedades detalhadas com PowerShell

O PowerShell possui outro comando extremamente interessante:

Get-PnpDeviceProperty

Primeiro obtenha o Instance ID.

Depois execute:

Get-PnpDeviceProperty -InstanceId "INSTANCE_ID"

O resultado pode ser extenso porque um dispositivo possui muitas propriedades.

É possível encontrar informações relacionadas a:

driver;

fabricante;

classe;

identificadores;

serviço;

INF;

data;

versão;

entre outras propriedades Plug and Play.

Esse comando é especialmente interessante porque permite investigar propriedades que normalmente ficam espalhadas em diferentes telas do Gerenciador de Dispositivos.

---

Descobrindo o INF ativo pelo PowerShell

Uma propriedade particularmente interessante é aquela associada ao nome do INF.

Em muitos sistemas podemos consultar:

DEVPKEY_Device_DriverInfPath

Por exemplo:

Get-PnpDeviceProperty -InstanceId "INSTANCE_ID" -KeyName "DEVPKEY_Device_DriverInfPath"

A saída poderá indicar algo como:

oem42.inf

Agora temos uma evidência muito importante.

Sabemos:

qual dispositivo estamos investigando;

qual é seu Instance ID;

qual INF está associado à instalação atual.

Podemos fazer consultas semelhantes para outras propriedades relevantes.

Entre elas podem estar informações relacionadas à versão e à data do driver.

---

Uma investigação prática

Imagine o seguinte caso.

Ontem você instalou manualmente um driver do adaptador Wi-Fi.

Depois da instalação:

Versão:

23.90

Hoje o Wi-Fi começou novamente a apresentar o problema antigo.

Você abre o Gerenciador de Dispositivos.

Versão:

23.70

Claramente algo mudou.

Primeiro identificamos o dispositivo:

Get-PnpDevice | Where-Object FriendlyName -Like "*Wireless*"

Encontramos o Instance ID.

Depois consultamos:

Get-PnpDeviceProperty -InstanceId "INSTANCE_ID" -KeyName "DEVPKEY_Device_DriverInfPath"

Resultado:

oem54.inf

Agora executamos:

pnputil /enum-drivers

e procuramos:

oem54.inf

Encontramos o pacote correspondente.

Nesse momento já sabemos exatamente qual pacote está controlando o dispositivo agora.

Mas ainda falta uma pergunta:

Onde foi parar o driver 23.90 que instalamos ontem?

Talvez ele ainda esteja no Driver Store.

---

Comparando os pacotes armazenados

Procure no resultado do:

pnputil /enum-drivers

outros pacotes do mesmo fornecedor e da mesma classe.

Imagine encontrarmos:

oem54.inf

Fornecedor: Fabricante X
Classe: Net
Versão: 23.70

e:

oem71.inf

Fornecedor: Fabricante X
Classe: Net
Versão: 23.90

Isso é extremamente revelador.

O pacote 23.90 não desapareceu necessariamente do computador.

Ele continua armazenado.

Entretanto, o dispositivo está utilizando oem54.inf.

Agora nossa pergunta muda.

Antes:

“Por que o Windows apagou meu driver?”

Agora:

“Por que o Windows está associando o dispositivo ao oem54.inf se o oem71.inf também está disponível?”

Essa é uma pergunta técnica muito melhor.

E podemos investigá-la.

---

Cuidado: não saia apagando oemXX.inf

Ao descobrir que existem vários pacotes no Driver Store, muita gente encontra na internet comandos para excluí-los e começa a remover tudo que parece antigo.

Isso pode criar problemas sérios.

Um pacote aparentemente antigo pode ser necessário para:

outro dispositivo;

uma variante do mesmo hardware;

um dispositivo temporariamente desconectado;

uma interface secundária;

um componente interno que você não identificou corretamente.

Além disso, olhar apenas para o nome do fabricante não é suficiente.

Não remova um pacote apenas porque encontrou:

oem17.inf

e:

oem42.inf

com números de versão diferentes.

Primeiro descubra:

a qual dispositivo o pacote pertence;

quais Hardware IDs ele atende;

qual dispositivo está usando o pacote;

se existe outro pacote realmente apropriado;

se o fabricante recomenda aquela substituição.

Diagnóstico vem antes da remoção.

---

Não manipule manualmente a pasta DriverStore

Outro erro perigoso é abrir:

C:\Windows\System32\DriverStore

e começar a apagar diretórios manualmente.

Não faça isso.

O Driver Store é um repositório gerenciado pelo Windows.

Excluir arquivos diretamente pode deixar referências inconsistentes e causar problemas na instalação ou funcionamento dos dispositivos.

Quando existe uma necessidade legítima de adicionar ou remover pacotes, utilize mecanismos suportados pelo Windows, como PnPUtil, DISM ou ferramentas apropriadas do sistema.

---

O comando para adicionar um driver também explica muita coisa

O PnPUtil possui:

/add-driver

Por exemplo:

pnputil /add-driver caminho\driver.inf /install

Existe uma diferença conceitual importante aqui.

Adicionar um pacote ao Driver Store significa disponibilizá-lo ao Windows.

Isso não garante automaticamente que ele substituirá qualquer driver já instalado.

A própria documentação da Microsoft deixa claro que o /install tenta instalar ou atualizar o driver nos dispositivos correspondentes, mas não força a instalação se aquele pacote não for o driver de maior classificação para o dispositivo.

Esse detalhe é fundamental para o tema deste artigo.

Você pode executar um comando corretamente.

O pacote pode ser adicionado corretamente.

Mesmo assim, o Windows pode continuar utilizando outro pacote.

Isso não significa necessariamente que o PnPUtil falhou.

Pode significar que, pelas regras de seleção do Windows, outro pacote continua vencendo.

---

“Tenho o driver mais novo no Driver Store” não resolve o mistério

Agora podemos montar uma situação completa:

Dispositivo:

Adaptador Wi-Fi X

Driver atual:

oem54.inf

Versão:

23.70

Outro pacote armazenado:

oem71.inf

Versão:

23.90

O pacote mais novo está no computador.

Mesmo assim, o Windows escolheu o antigo.

Esse cenário reforça tudo que vimos na primeira parte.

A comparação não pode ficar limitada a:

23.90 > 23.70

Precisamos analisar a correspondência dos pacotes com aquele dispositivo.

E existe um lugar onde o Windows pode ter registrado exatamente essa disputa.

O arquivo:

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

---

Antes de abrir o SetupAPI.dev.log, anote quatro informações

Para facilitar muito a investigação, anote:

1. Instance ID do dispositivo

Exemplo:

PCI\VEN_XXXX&DEV_YYYY...

2. INF atualmente utilizado

Exemplo:

oem54.inf

3. INF do pacote que você esperava utilizar

Exemplo:

oem71.inf

4. Horário aproximado em que a troca aconteceu

Esse último item pode ser obtido pela sua própria observação.

Por exemplo:

“Instalei o driver às 14h.”

“Reiniciei às 14h15.”

“Às 15h o driver antigo já havia retornado.”

Quanto menor a janela de tempo, mais fácil será procurar a operação correspondente no log.

---

Como abrir o SetupAPI.dev.log

O arquivo normalmente está em:

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

Você pode abri-lo com um editor de texto.

Dependendo do histórico do computador, o arquivo pode ser bastante grande.

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

Pesquise primeiro pelo:

Instance ID

Depois tente:

oem54.inf

e:

oem71.inf

Isso permite localizar trechos relacionados ao dispositivo e aos pacotes envolvidos.

Quando encontrar uma seção correspondente ao momento em que ocorreu a instalação, observe:

data;

hora;

identificação do dispositivo;

INF considerado;

INF selecionado;

informações de classificação;

resultado da operação.

Agora começamos a chegar ao ponto mais importante deste tutorial.

O Windows pode ter deixado registrado por que um pacote venceu o outro.

---

O diagnóstico mudou completamente

No início tínhamos apenas:

“O Windows fica voltando meu driver.”

Depois da investigação desta parte, podemos chegar a algo muito mais concreto:

Dispositivo: identificado.

Instance ID: identificado.

Driver atual: identificado.

INF ativo: oem54.inf.

Driver desejado: identificado.

INF alternativo: oem71.inf.

Ambos estão no Driver Store: confirmado.

A partir daqui podemos investigar a seleção propriamente dita.

SetupAPI.dev.log: descubra por que o Windows 11 escolheu outro driver

Nas partes anteriores chegamos a uma situação muito específica.

Sabemos qual dispositivo apresenta o problema.

Sabemos seu Instance ID.

Descobrimos qual arquivo INF está sendo utilizado.

Também descobrimos que podem existir outros pacotes compatíveis armazenados no Driver Store.

Agora precisamos responder à pergunta principal deste artigo:

Por que o Windows escolheu justamente esse driver?

Para investigar isso, existe um arquivo extremamente valioso:

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

Esse arquivo funciona como um histórico técnico de diversas operações relacionadas à instalação de dispositivos.

Para quem presta suporte técnico, ele pode transformar uma situação aparentemente inexplicável em uma sequência de acontecimentos que pode ser investigada.

---

O que é o SetupAPI.dev.log?

O Windows utiliza a infraestrutura SetupAPI durante diferentes processos de instalação de dispositivos e drivers.

Durante essas operações, informações são registradas no:

setupapi.dev.log

O arquivo pode conter dados relacionados a:

• identificação do dispositivo;
• início de uma instalação;
• pacotes de drivers encontrados;
• arquivos INF envolvidos;
• pesquisa por drivers compatíveis;
• seleção do pacote;
• classificação de candidatos;
• atualização de dispositivo;
• instalação de serviços relacionados ao driver;
• conclusão ou falha da operação.

Isso significa que, quando o Windows troca um driver, podemos procurar evidências dessa operação.

Mas existe um problema.

O arquivo pode ser enorme.

Em um computador utilizado há bastante tempo, tentar lê-lo linha por linha não faz sentido.

Precisamos pesquisar de maneira direcionada.

---

Primeiro: descubra exatamente qual dispositivo investigar

Antes de abrir o log, obtenha novamente o Instance ID.

No PowerShell:

Get-PnpDevice

Localize o equipamento.

Depois anote o valor de:

InstanceId

Também podemos usar:

pnputil /enum-devices /connected

dependendo do dispositivo e da versão do Windows.

O Instance ID é muito mais útil para a investigação do que simplesmente procurar:

Intel

Realtek

NVIDIA

AMD

Um computador pode possuir diversos componentes do mesmo fabricante.

Pesquisar apenas o fabricante pode gerar dezenas ou centenas de ocorrências irrelevantes.

---

Abra o log e procure pelo Instance ID

Abra:

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

Podemos utilizar o Bloco de Notas para uma análise simples, embora editores capazes de trabalhar confortavelmente com arquivos grandes possam facilitar a investigação.

Pressione:

Ctrl + F

e procure pelo Instance ID.

Você poderá encontrar diversas ocorrências.

Isso é normal.

O mesmo dispositivo pode ter sido:

instalado;

atualizado;

reinstalado;

detectado novamente;

associado a outro pacote;

processado durante alguma atualização.

O objetivo não é simplesmente encontrar a primeira ocorrência.

Queremos encontrar a ocorrência correspondente ao momento em que o driver mudou.

---

Data e hora são fundamentais

É por isso que, na parte anterior, recomendamos anotar aproximadamente quando o problema aconteceu.

Imagine:

10:00 — você instalou manualmente o driver novo.

10:05 — confirmou que estava funcionando.

11:20 — reiniciou o computador.

11:30 — percebeu que o driver antigo havia retornado.

Agora temos uma janela muito menor para investigar.

Procure no log por operações relacionadas ao dispositivo nesse intervalo.

Esse procedimento é muito mais eficiente do que procurar indiscriminadamente por qualquer ocorrência do nome do fabricante.

---

Como reconhecer o início de uma operação

O setupapi.dev.log utiliza marcadores e seções que ajudam a separar diferentes operações.

É possível encontrar entradas começando com estruturas semelhantes a:

>>>

e finalizações utilizando:

<<<

Os detalhes exatos podem variar conforme a operação e a versão do Windows.

O importante é entender que muitas operações aparecem organizadas em blocos.

Quando encontrar o Instance ID, não leia apenas aquela linha.

Observe também as linhas anteriores e posteriores.

Queremos descobrir:

quem iniciou a operação;

qual dispositivo estava envolvido;

quais drivers foram considerados;

qual foi selecionado;

qual foi o resultado.

---

Procure também pelos arquivos oemXX.inf

Na parte anterior encontramos, hipoteticamente:

Driver atual:

oem54.inf

Driver que queríamos:

oem71.inf

Pesquise pelos dois nomes.

Primeiro:

oem54.inf

Depois:

oem71.inf

Isso pode revelar onde cada pacote aparece no processo de instalação ou seleção.

A investigação fica especialmente interessante quando os dois aparecem próximos dentro de uma operação relacionada ao mesmo dispositivo.

Temos então evidências de que ambos podem ter participado do processo.

---

O que significa Rank no log?

Aqui entramos em um dos conceitos mais importantes do artigo.

O Windows pode registrar informações relacionadas ao Rank de um pacote de driver.

De maneira simplificada:

quanto melhor a correspondência do pacote com o dispositivo, melhor sua posição no processo de seleção.

Um ponto que confunde bastante é que, ao lidar diretamente com os valores numéricos de Rank, um valor numericamente menor representa uma classificação melhor.

Portanto, não pense:

“Rank maior = melhor.”

Nesse contexto, a lógica é inversa.

Um pacote pode possuir um número de versão aparentemente superior e ainda perder porque outro pacote obteve uma correspondência melhor.

---

Por que dois drivers compatíveis recebem classificações diferentes?

Imagine dois pacotes:

Pacote A

oem54.inf

Versão:

23.70

Pacote B

oem71.inf

Versão:

23.90

Os dois parecem servir para o mesmo adaptador Wi-Fi.

Entretanto, o INF do Pacote A pode possuir uma correspondência mais específica para aquele dispositivo.

O Pacote B pode atender ao hardware por uma identificação mais genérica.

Nesse cenário, olhar apenas para:

23.90 > 23.70

não explica a escolha.

O Windows pode considerar o Pacote A uma correspondência melhor.

É justamente por isso que os Hardware IDs estudados na primeira parte são tão importantes.

---

Um exemplo conceitual

Suponha que o dispositivo apresente:

PCI\VEN_1234&DEV_5678&SUBSYS_ABCD0001

Um pacote possui uma entrada altamente específica para:

PCI\VEN_1234&DEV_5678&SUBSYS_ABCD0001

Outro pacote corresponde apenas a algo mais amplo, como:

PCI\VEN_1234&DEV_5678

Os dois podem ser compatíveis.

Mas eles não são necessariamente correspondências equivalentes.

Isso ajuda a explicar por que um driver personalizado pelo fabricante do notebook pode competir de maneira diferente de um pacote genérico do fabricante do chipset.

---

Data e versão entram depois na comparação apropriada

Outro detalhe merece reforço.

Não devemos interpretar a seleção como:

“Windows procura todos os drivers e escolhe o de maior versão.”

A classificação da correspondência tem papel central.

Quando os melhores candidatos possuem classificação equivalente, outros critérios entram no desempate.

A data do driver possui importância.

Depois, em condições equivalentes, a versão também pode participar do desempate.

Uma representação didática é:

Correspondência/Rank

↓

Data

↓

Versão

Isso explica por que simplesmente editar mentalmente a lista do PnPUtil e escolher o maior número de versão pode levar a uma conclusão errada.

---

A data do driver também pode causar confusão

Existe ainda uma peculiaridade interessante.

A data mostrada pelo Windows não precisa ser exatamente a data em que você baixou o pacote.

Também não representa necessariamente quando o fabricante publicou a página de download.

O INF possui informações próprias relacionadas à data e versão do driver.

Portanto, podemos encontrar situações em que:

site do fabricante:

“Publicado em 2026”

mas o pacote apresenta internamente outra data.

Durante um diagnóstico, devemos observar os metadados efetivamente utilizados pelo Windows, e não apenas a data exibida no site de download.

---

Como saber se o Windows Update participou?

Essa é uma das perguntas mais importantes.

Se o driver mudou depois de reiniciar, muita gente conclui automaticamente:

“Foi o Windows Update.”

Mas precisamos provar isso.

Existem pelo menos três cenários diferentes.

Cenário 1 — O pacote já estava no Driver Store

Você remove ou reinstala o dispositivo.

O Plug and Play detecta o hardware.

Encontra um pacote já armazenado.

Seleciona esse pacote.

Nesse caso, o driver pode reaparecer sem que tenha ocorrido um novo download naquele momento.

---

Cenário 2 — O Windows Update disponibilizou outro pacote

O Windows Update encontra um driver aplicável ao dispositivo.

O pacote é obtido e entra no processo de instalação.

Depois disso, o dispositivo passa a utilizar esse pacote.

Aqui podemos realmente dizer que uma atualização distribuída pelo Windows participou da mudança.

---

Cenário 3 — Um software do fabricante atualizou o driver

Muitos computadores possuem utilitários OEM.

Eles podem verificar e instalar:

BIOS;

firmware;

chipset;

vídeo;

Wi-Fi;

Bluetooth;

áudio;

touchpad;

outros componentes.

Nesse caso, o Windows Update pode não ter sido o responsável direto.

Um utilitário do próprio fabricante pode ter iniciado a instalação.

Por isso é importante observar no log informações relacionadas ao processo ou contexto que iniciou determinada operação quando elas estiverem disponíveis.

---

O Visualizador de Eventos pode complementar a investigação

O setupapi.dev.log não precisa ser analisado sozinho.

O Visualizador de Eventos também pode ajudar a reconstruir a linha do tempo.

Abra:

eventvwr.msc

Existem logs relacionados ao sistema, Plug and Play, instalação de dispositivos e Windows Update que podem fornecer informações adicionais dependendo do caso.

Não existe uma única entrada universal que sempre diga:

“O Windows Update trocou seu driver às 11:23.”

O diagnóstico pode exigir correlação.

Por exemplo:

11:20 — instalação de atualização.

11:22 — atividade relacionada ao dispositivo.

11:23 — novo pacote instalado.

11:24 — dispositivo iniciado com outro driver.

Quando horários e identificadores coincidem, conseguimos montar uma linha do tempo muito mais confiável.

---

O Histórico do Windows Update também ajuda

Abra:

Configurações → Windows Update → Histórico de atualizações

Procure por entradas relacionadas a drivers.

Dependendo do pacote, podemos encontrar informações sobre:

fabricante;

componente;

versão.

Isso ajuda a responder:

“Um driver foi realmente entregue pelo Windows Update recentemente?”

Mas cuidado novamente.

Encontrar uma atualização de driver no histórico não significa automaticamente que ela causou o problema atual.

Precisamos relacionar:

data + dispositivo + versão + INF + momento da alteração.

---

E as Atualizações Opcionais?

Alguns drivers podem aparecer como atualizações opcionais.

Dependendo da versão atual do Windows 11, essa área pode ser encontrada dentro das opções relacionadas ao Windows Update.

É importante entender que um pacote oferecido ali não precisa ser simplesmente:

“um driver mais novo.”

Pode ser uma alternativa disponibilizada para determinado hardware.

Por isso, instalar todos os drivers opcionais indiscriminadamente não é uma estratégia de manutenção que eu recomendo.

Se o computador funciona corretamente, não existe vantagem automática em substituir todos os drivers apenas porque aparecem opções adicionais.

Driver deve ser tratado como componente de funcionamento do hardware, não como uma coleção que precisa sempre possuir o maior número possível.

---

“Atualizar driver” no Gerenciador de Dispositivos também pode surpreender

Existe outra situação clássica.

Você seleciona:

Atualizar driver → Pesquisar drivers automaticamente

e o Windows responde:

“Os melhores drivers para o dispositivo já estão instalados.”

Você fica indignado porque acabou de baixar uma versão aparentemente superior.

Mas agora essa mensagem começa a fazer sentido.

“Melhor” não significa necessariamente:

maior versão encontrada na internet.

Significa melhor candidato dentro do mecanismo de seleção e das fontes consultadas naquela operação.

É uma diferença enorme.

---

“Procurar drivers no computador” permite outro tipo de seleção

Também existe:

Atualizar driver → Procurar drivers no meu computador

Isso permite indicar um local contendo drivers.

Mas novamente:

apresentar um pacote ao Windows não significa que ele obrigatoriamente substituirá qualquer pacote atualmente selecionado.

A correspondência e as regras de seleção continuam importantes.

Existe ainda a opção de escolher entre drivers disponíveis no computador, dependendo da categoria e do dispositivo.

Essa ferramenta pode ser útil para testes e rollback, mas exige cuidado.

Selecionar manualmente um driver incompatível apenas porque o nome parece semelhante pode causar:

instabilidade;

perda de funcionalidade;

falha de inicialização do dispositivo;

recursos ausentes;

erros no Gerenciador de Dispositivos.

---

Quando um driver OEM mais antigo pode ser a escolha correta

Existe uma tendência de pensar:

“Driver mais recente do fabricante do chip sempre é melhor.”

Isso também não é uma regra segura.

Considere um notebook.

O fabricante pode ter personalizado:

gerenciamento de energia;

suspensão;

teclas especiais;

áudio;

microfone;

câmera;

touchpad;

GPU híbrida;

Bluetooth;

Wi-Fi;

sensores.

Um driver genérico mais recente pode funcionar.

Mas o pacote OEM pode ter sido validado especificamente para aquele modelo.

Em determinados casos, o driver OEM aparentemente mais antigo pode proporcionar funcionamento mais estável.

Isso aparece especialmente em notebooks e equipamentos com componentes muito integrados.

---

Quando o driver mais antigo realmente é o problema

O contrário também acontece.

Um driver distribuído anteriormente pode possuir:

bugs;

problemas de estabilidade;

falhas de desempenho;

incompatibilidade com uma atualização recente do Windows;

problemas de segurança já corrigidos;

falhas de suspensão;

problemas de conectividade;

erros específicos de hardware.

Nesse caso, manter uma versão problemática apenas porque o Windows continua selecionando o pacote não resolve a situação.

Precisamos descobrir como substituir corretamente o driver e evitar que o pacote indesejado volte.

Mas antes de fazer isso, precisamos confirmar que realmente estamos trabalhando com o pacote correto.

---

Compare o Hardware ID com o pacote

Se existem dúvidas sobre qual pacote deveria controlar o dispositivo, consulte:

Gerenciador de Dispositivos → Propriedades → Detalhes → IDs de Hardware

Anote os valores.

Depois analise o INF do pacote que pretende utilizar.

Arquivos INF são arquivos estruturados de configuração e podem ser examinados como texto para fins de diagnóstico.

Procure pelas seções relacionadas aos modelos suportados.

É possível encontrar identificadores correspondentes aos dispositivos atendidos pelo pacote.

Essa comparação ajuda a responder:

O driver foi realmente criado para este hardware?

e, em alguns casos:

Ele possui uma correspondência específica ou apenas genérica?

---

Não edite o INF para “enganar” o Windows

Ao descobrir que determinado Hardware ID não está presente no pacote, algumas pessoas tentam editar manualmente o INF e adicionar o identificador.

Isso não é uma solução comum recomendada.

Modificar um INF pode afetar sua assinatura e o modelo de confiança utilizado pelo Windows.

Além disso, fazer um driver carregar em um hardware para o qual ele não foi projetado pode causar instabilidade ou impedir o funcionamento do dispositivo.

Se o fabricante não declara suporte ao seu hardware, não presuma que uma pequena alteração de texto torna o pacote compatível.

---

Como construir uma linha do tempo confiável

Para diagnosticar corretamente uma troca de driver, crie uma sequência.

Exemplo:

09:30

Driver instalado:

oem71.inf

Versão 23.90.

09:35

Computador reiniciado.

09:40

Dispositivo funcionando com 23.90.

11:15

Windows Update executou determinada operação.

11:20

SetupAPI registra nova instalação para o Instance ID.

11:21

oem54.inf aparece associado ao dispositivo.

11:25

Gerenciador de Dispositivos mostra versão 23.70.

Agora temos algo muito mais forte do que:

“Acho que o Windows Update fez isso.”

Temos evidências correlacionadas.

---

Faça um teste controlado

Quando o problema é recorrente, podemos transformar a próxima ocorrência em um experimento controlado.

Antes da instalação:

anote versão;

data;

fornecedor;

INF;

Instance ID.

Instale o driver desejado.

Depois confirme novamente:

versão;

INF;

estado do dispositivo.

Reinicie.

Verifique outra vez.

Depois execute o Windows Update.

Verifique novamente.

O objetivo é descobrir em qual etapa ocorre a alteração.

Se o driver muda imediatamente depois do reboot, temos um caminho de investigação.

Se permanece correto após vários reboots, mas muda somente depois do Windows Update, temos outro.

Se muda depois de abrir o utilitário OEM, temos outra pista.

Esse método reduz drasticamente o achismo.

---

Um detalhe importante: reiniciar e desligar não são sempre equivalentes

Durante testes, prefira utilizar explicitamente:

Reiniciar

quando quiser provocar uma nova inicialização completa do Windows.

Dependendo das configurações de Inicialização Rápida, desligar e ligar pode seguir um fluxo diferente de um reinício tradicional.

Para testes de driver, manter o procedimento consistente ajuda a comparar os resultados.

---

O driver voltou. E agora?

Neste ponto já temos condições de responder algumas perguntas.

O pacote estava no Driver Store?

Se sim, o Windows pode ter reutilizado um pacote local.

Houve instalação recente pelo Windows Update?

Se sim, investigamos a relação temporal e o pacote instalado.

O INF atual mudou?

Se mudou, sabemos exatamente qual pacote assumiu o dispositivo.

O pacote desejado continua no Driver Store?

Se continua, podemos comparar os dois.

Os pacotes possuem correspondências diferentes para o Hardware ID?

Isso pode explicar a preferência.

O SetupAPI mostra diferença de Rank?

Temos uma evidência ainda mais forte da lógica de seleção.

Agora chegamos à etapa delicada:

corrigir o problema.

---

Não bloqueie drivers antes de descobrir a causa

Esse é provavelmente o conselho mais importante antes da próxima parte.

Não comece desativando Windows Update.

Não saia apagando todos os oemXX.inf.

Não bloqueie atualizações de segurança.

Não desative Plug and Play.

Não remova aleatoriamente pacotes do Driver Store.

Primeiro descubra exatamente:

qual driver é ruim;

qual driver funciona;

qual pacote corresponde a cada versão;

como o pacote indesejado está chegando;

se outro dispositivo depende dele.

Somente depois disso podemos escolher a correção adequada.

Como impedir que o Windows 11 volte para o driver errado

Depois de toda a investigação das partes anteriores, já podemos trabalhar com evidências.

Sabemos identificar:

• o dispositivo;
• Hardware IDs;
• Instance ID;
• versão instalada;
• arquivo oemXX.inf;
• pacotes existentes no Driver Store;
• registros no setupapi.dev.log;
• possível participação do Windows Update.

Agora podemos corrigir o problema.

A primeira regra continua sendo:

não remova drivers aleatoriamente.

Antes de qualquer alteração, confirme qual pacote está causando o problema e qual pacote funciona corretamente.

---

Método 1 — Usar Reverter Driver

O método mais simples é verificar se o Windows disponibiliza a opção:

Reverter Driver

Abra:

Gerenciador de Dispositivos → dispositivo → Propriedades → Driver

Procure:

Reverter Driver

Quando disponível, essa função permite retornar ao driver anteriormente utilizado.

Ela é particularmente útil quando:

1. o dispositivo funcionava normalmente;
2. ocorreu uma atualização;
3. o problema começou imediatamente depois;
4. o Windows ainda possui informações suficientes para retornar à versão anterior.

Exemplo:

Antes:

23.80

Depois da atualização:

23.100

Problema:

Wi-Fi desconectando após suspensão.

Se a opção estiver disponível, reverter para 23.80 pode servir tanto como correção temporária quanto como teste diagnóstico.

Se o problema desaparecer imediatamente, aumenta a evidência de que a mudança do driver participou da falha.

Isso não significa automaticamente que a versão nova seja defeituosa em todos os computadores.

Pode existir uma incompatibilidade específica com aquele equipamento.

---

Por que Reverter Driver pode estar desabilitado?

Às vezes o botão aparece indisponível.

Isso pode acontecer quando o Windows não possui uma versão anterior adequada disponível para aquela operação ou quando não existe um histórico de atualização que permita a reversão pela interface.

Nesse caso, precisaremos trabalhar diretamente com os pacotes.

É aqui que o PnPUtil volta a ser útil.

---

Método 2 — Descobrir exatamente qual INF será removido

Execute como administrador:

pnputil /enum-drivers

Localize cuidadosamente o pacote.

Imagine que encontramos:

Published Name: oem54.inf

e confirmamos que:

oem54.inf

é exatamente o pacote problemático.

Antes de remover qualquer coisa, verifique novamente.

Anote:

Published Name

Original Name

Provider Name

Class Name

Driver Version

Signer Name

Depois confirme que o pacote desejado também está disponível ou que você possui o instalador correto fornecido por uma fonte confiável.

Não execute a remoção apenas porque o número da versão parece antigo.

---

Removendo um pacote com PnPUtil

O PnPUtil possui:

/delete-driver

A sintaxe básica é:

pnputil /delete-driver oemXX.inf

Por exemplo:

pnputil /delete-driver oem54.inf

Isso solicita a exclusão daquele pacote do Driver Store.

Entretanto, se o pacote estiver sendo utilizado, a situação exige atenção adicional.

Existem opções como:

/uninstall

e:

/force

mas elas não devem ser adicionadas automaticamente a qualquer comando encontrado na internet.

---

O que faz /uninstall?

Podemos encontrar uma estrutura como:

pnputil /delete-driver oem54.inf /uninstall

O /uninstall remove o pacote dos dispositivos que o estão utilizando antes da remoção do Driver Store.

Isso torna a operação muito mais impactante.

Se aquele pacote estiver controlando o adaptador de rede que você está utilizando para acessar remotamente o computador, por exemplo, você poderá perder a conexão durante o procedimento.

Em um atendimento remoto isso é particularmente importante.

Imagine remover o driver do adaptador Wi-Fi responsável pela própria sessão remota.

A conexão poderá cair antes que você consiga instalar o substituto.

Portanto, planeje a operação antes de executá-la.

---

E o /force?

Existe ainda a opção:

/force

Ela deve ser tratada com cautela.

O fato de uma ferramenta possuir uma opção chamada “force” não significa que devemos utilizá-la por padrão.

Se o Windows está impedindo uma remoção, primeiro descubra por quê.

Forçar uma operação sem compreender dependências pode deixar um dispositivo sem driver funcional.

Para diagnóstico e manutenção, a sequência correta é:

identificar → confirmar → preparar substituto → remover quando necessário → instalar → validar.

Não:

forçar → reiniciar → torcer para funcionar.

---

Tenha o driver correto antes da remoção

Essa recomendação parece óbvia, mas evita muitos problemas.

Antes de remover o pacote problemático, tenha disponível localmente o driver que pretende instalar.

Não dependa exclusivamente da internet depois da remoção.

Isso é especialmente importante para:

Wi-Fi;

Ethernet;

controladores USB;

chipset;

armazenamento;

GPU em determinados cenários.

Se você remover o driver de rede e perder conectividade, precisará instalar o substituto sem depender daquela conexão.

---

Adicionando o pacote correto ao Driver Store

Suponha que o INF correto esteja em:

C:\Drivers\WiFi\driver.inf

Podemos utilizar:

pnputil /add-driver "C:\Drivers\WiFi\driver.inf" /install

Isso adiciona o pacote ao Driver Store e solicita a instalação nos dispositivos correspondentes.

Mas existe uma observação importantíssima:

o /install não significa “ignore a classificação e obrigue este driver a vencer”.

Se outro pacote continuar sendo considerado uma correspondência superior pelas regras de seleção, simplesmente adicionar novamente o driver pode não produzir o resultado esperado.

É justamente por isso que fizemos toda a investigação das partes anteriores.

---

Instaladores do fabricante também podem ser necessários

Nem todo driver deve ser tratado apenas como um INF isolado.

Alguns fabricantes distribuem pacotes que incluem:

driver;

serviços;

aplicativos;

extensões;

componentes adicionais;

firmware;

painéis de controle.

Nesses casos, executar apenas um INF pode instalar o componente básico sem todos os recursos esperados.

Quando o fabricante fornece um instalador específico para o modelo do computador, avalie primeiro essa opção.

Em notebooks OEM, principalmente, eu recomendo verificar inicialmente o suporte do fabricante do próprio equipamento.

---

Driver do fabricante do chip ou driver do notebook?

Essa é uma dúvida muito comum.

Imagine um notebook equipado com Wi-Fi Intel.

Podemos encontrar um driver no site da Intel e outro no site do fabricante do notebook.

Qual usar?

Não existe uma resposta universal.

O driver mais recente do fabricante do componente pode trazer:

correções;

melhorias;

compatibilidade recente;

soluções de segurança.

O pacote OEM pode trazer:

validação específica;

ajustes para aquele modelo;

integração com gerenciamento de energia;

compatibilidade testada com firmware;

configurações específicas.

Se o equipamento apresenta instabilidade com o driver genérico mais novo e funciona perfeitamente com o OEM, o maior número de versão não é motivo suficiente para abandonar o pacote estável.

---

Quando o Windows Update continua reinstalando o pacote

Agora chegamos ao cenário mais incômodo.

Você confirmou:

Driver A funciona.

Driver B causa o problema.

Remove Driver B.

Instala Driver A.

Reinicia.

Tudo funciona.

Depois de uma atualização, Driver B retorna.

Nesse caso, precisamos avaliar como as atualizações de drivers estão sendo administradas.

---

Existe política para não incluir drivers no Windows Update

Em edições do Windows que oferecem o Editor de Política de Grupo Local, administradores podem encontrar uma política relacionada a:

Não incluir drivers com as Atualizações do Windows

Ela fica nas configurações administrativas relacionadas ao Windows Update.

Essa política pode impedir a inclusão de drivers nas atualizações de qualidade do Windows.

Mas atenção:

isso é uma mudança ampla de comportamento.

Ela não significa simplesmente:

“bloqueie somente o driver ruim da minha placa Wi-Fi”.

Portanto, não recomendo ativá-la automaticamente para todo computador doméstico.

Você poderá impedir atualizações legítimas de outros drivers que seriam úteis.

---

Registro do Windows também não deve virar primeira opção

Existem configurações administrativas correspondentes que podem ser controladas por políticas e Registro.

Mas editar o Registro não deve ser o primeiro passo.

Antes disso, confirme:

o Windows Update realmente está causando a substituição?

Se não houver evidência, alterar políticas de atualização pode não resolver o problema.

Pior: você modifica o comportamento do sistema inteiro tentando corrigir algo que poderia ser apenas um pacote antigo já presente no Driver Store.

---

Não desative completamente o Windows Update

Uma solução comum encontrada em tutoriais ruins é:

“Desative o serviço Windows Update.”

Isso não é uma boa solução para um problema específico de driver.

Windows Update distribui muito mais do que drivers.

Ele também participa da entrega de:

atualizações de segurança;

correções do sistema;

atualizações cumulativas;

componentes do Windows;

outras melhorias.

Desativar todo o mecanismo para impedir a instalação de um único driver cria um problema maior que o original.

---

O objetivo deve ser resolver especificamente o conflito

O procedimento ideal é:

1. identificar o driver problemático;

2. descobrir sua origem;

3. confirmar o pacote INF;

4. instalar uma versão estável e compatível;

5. validar após reinicialização;

6. verificar se o pacote problemático retorna;

7. somente então avaliar mecanismos de bloqueio ou política.

Esse método preserva o restante do sistema de atualização.

---

Faça um teste antes e depois

Depois de instalar o driver correto, registre novamente:

Fornecedor

Data

Versão

INF

Instance ID

Depois reinicie.

Verifique novamente.

Se tudo permanecer igual, execute os testes relacionados ao problema original.

Por exemplo, para Wi-Fi:

conectar e desconectar;

suspender e retornar;

testar diferentes redes;

verificar estabilidade;

testar velocidade;

observar perda de pacotes.

Para GPU:

reiniciar;

suspender;

testar aceleração;

verificar aplicativos que apresentavam falha.

Para áudio:

testar entrada;

saída;

microfone;

suspensão;

troca de dispositivo.

Para Bluetooth:

pareamento;

reconexão;

suspensão;

transferência de áudio.

Um driver não deve ser considerado “melhor” apenas porque instalou sem apresentar erro.

Precisamos verificar se o hardware realmente funciona corretamente.

---

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

Existe uma categoria de programas que promete:

“Encontramos 37 drivers desatualizados!”

Esse tipo de abordagem pode transformar um computador estável em uma coleção de problemas.

Não existe necessidade de atualizar todos os drivers apenas porque alguma ferramenta encontrou números de versão diferentes.

Além disso, utilizar bases de terceiros para componentes críticos adiciona outra variável desnecessária ao diagnóstico.

Prefira:

Windows Update;

fabricante do computador;

fabricante do componente, quando apropriado;

Microsoft Update Catalog em situações específicas;

ferramentas oficiais do fabricante.

---

Driver antigo não significa vulnerável automaticamente

Também precisamos evitar outra generalização.

“Antigo” e “vulnerável” não são sinônimos.

Por outro lado, drivers podem realmente apresentar vulnerabilidades e receber correções de segurança.

Portanto, quando a decisão envolve permanecer em uma versão anterior por estabilidade, vale verificar se existem alertas de segurança relevantes do fabricante.

A decisão deve equilibrar:

compatibilidade;

estabilidade;

segurança;

suporte oficial.

---

E se nenhum driver funcionar corretamente?

Nesse ponto precisamos considerar que talvez o driver não seja a causa principal.

Um dispositivo pode apresentar problemas por:

hardware defeituoso;

firmware;

BIOS;

energia;

cabo;

porta;

temperatura;

interferência;

configuração;

serviço do Windows;

corrupção do sistema;

conflito com software.

Imagine um adaptador Wi-Fi desconectando.

Você testa três versões do driver e o comportamento permanece idêntico.

Talvez o problema esteja no:

roteador;

sinal;

economia de energia;

adaptador físico;

antena;

firmware;

interferência.

O driver era apenas o suspeito mais visível.

---

Procedimento VMIA para investigar um driver que “volta sozinho”

Podemos resumir o diagnóstico em uma sequência técnica.

Etapa 1 — Identifique o dispositivo

Obtenha:

Friendly Name;

Hardware IDs;

Instance ID.

Etapa 2 — Registre o driver atual

Anote:

Fornecedor;

Data;

Versão;

INF.

Etapa 3 — Liste os pacotes

Execute:

pnputil /enum-drivers

Identifique os pacotes relacionados.

Etapa 4 — Descubra o INF ativo

Utilize propriedades Plug and Play, Gerenciador de Dispositivos ou PowerShell.

Etapa 5 — Instale o driver desejado

Use uma fonte confiável e compatível.

Etapa 6 — Registre novamente os dados

Confirme versão e INF.

Etapa 7 — Reinicie

Verifique se o driver permanece.

Etapa 8 — Teste o Windows Update

Se necessário, observe se a alteração ocorre depois da atualização.

Etapa 9 — Analise o SetupAPI

Abra:

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

Pesquise:

Instance ID;

INF antigo;

INF novo;

horário da operação;

informações de seleção.

Etapa 10 — Só depois escolha a correção

A correção pode ser:

rollback;

reinstalação;

remoção de pacote;

driver OEM;

driver do fabricante do componente;

ajuste de política;

correção de outro problema que estava sendo confundido com driver.

---

Conclusão — O Windows não está simplesmente escolhendo “o driver mais velho”

Quando o Windows 11 substitui um driver que você acabou de instalar, a situação pode parecer completamente aleatória.

Na maioria das vezes, entretanto, existe uma lógica técnica por trás do comportamento.

O Windows trabalha com identificação Plug and Play, Hardware IDs, Compatible IDs, arquivos INF, Driver Store, classificação de pacotes e outros critérios para decidir qual driver utilizar.

Por isso:

versão maior não significa automaticamente driver vencedor.

Também aprendemos outra diferença essencial:

remover um dispositivo não significa necessariamente remover seu pacote do Driver Store.

O Windows pode detectar novamente o hardware e reutilizar um pacote que já estava armazenado.

E nem toda troca significa automaticamente que:

“o Windows Update instalou o driver errado.”

Pode ter ocorrido:

reutilização de pacote local;

seleção Plug and Play;

instalação pelo Windows Update;

atualização por ferramenta OEM;

reinstalação do dispositivo;

mudança de pacote após atualização.

A melhor ferramenta para resolver esse tipo de mistério não é tentativa e erro.

É evidência.

Gerenciador de Dispositivos, PnPUtil, PowerShell e principalmente:

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

permitem reconstruir grande parte do que aconteceu.

Em vez de perguntar:

“Como faço o Windows parar de trocar meus drivers?”

comece perguntando:

“Qual INF estava instalado, qual INF assumiu o dispositivo e por que o Windows selecionou esse pacote?”

Essa mudança de abordagem transforma um problema aparentemente aleatório em um diagnóstico técnico.

---

FAQ — Windows 11 substituindo drivers

Por que o Windows 11 instala um driver antigo sozinho?

Existem várias possibilidades. Outro pacote pode ser considerado uma correspondência melhor para o dispositivo, o pacote pode já existir no Driver Store, o Windows Update pode disponibilizar outro driver ou um utilitário do fabricante pode realizar a instalação.

Não determine a causa apenas comparando os números das versões.

O Windows sempre instala o driver mais recente?

Não.

A seleção de drivers não é baseada exclusivamente no maior número de versão.

O Windows precisa determinar primeiro quais pacotes são aplicáveis e como eles correspondem ao dispositivo.

Como descobrir qual driver está realmente instalado?

Abra:

Gerenciador de Dispositivos → dispositivo → Propriedades → Driver

Para uma investigação mais detalhada, utilize:

pnputil

Get-PnpDevice

Get-PnpDeviceProperty

e o arquivo:

setupapi.dev.log

O que significa oem42.inf?

É um exemplo do nome publicado atribuído a um pacote INF de terceiros dentro do Driver Store.

O nome original do INF pode ser diferente.

Use:

pnputil /enum-drivers

para relacionar o nome publicado ao pacote.

Posso apagar todos os drivers antigos do Driver Store?

Não é recomendável.

Um pacote aparentemente antigo pode ser necessário para outro dispositivo ou configuração.

Remova somente pacotes que você identificou corretamente e quando existir uma razão técnica para isso.

Posso apagar arquivos diretamente da pasta DriverStore?

Não é uma boa prática.

Utilize as ferramentas suportadas pelo Windows para administrar pacotes de drivers.

O que é SetupAPI.dev.log?

É um log utilizado pelo Windows para registrar informações relacionadas a operações de instalação de dispositivos.

Ele fica normalmente em:

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

e pode ser extremamente útil no diagnóstico de problemas de drivers.

O que é Rank de driver?

É parte do mecanismo utilizado pelo Windows para classificar candidatos compatíveis.

Em termos simplificados, uma correspondência melhor recebe preferência durante o processo de seleção.

O número da versão não é o único fator envolvido.

Driver OEM é melhor que o driver do fabricante do chip?

Depende.

Um pacote OEM pode conter ajustes e validações específicos para determinado computador.

Um driver do fabricante do componente pode ser mais recente e trazer outras correções.

A decisão deve considerar compatibilidade, estabilidade, segurança e recomendação oficial.

Posso impedir o Windows Update de atualizar drivers?

Existem políticas administrativas capazes de alterar a distribuição de drivers pelas atualizações do Windows.

Entretanto, não recomendo alterar globalmente esse comportamento antes de confirmar que o Windows Update realmente é responsável pelo problema.

Desativar Windows Update resolve?

Não é uma boa solução.

Você poderá comprometer a entrega de atualizações importantes do Windows apenas para tentar bloquear um driver específico.

PnPUtil consegue forçar qualquer driver?

Não dessa maneira.

Adicionar um pacote e utilizar /install não significa ignorar todas as regras de seleção do Windows.

O pacote precisa ser aplicável ao dispositivo.

O driver voltou depois de reiniciar. Significa que foi baixado novamente?

Não necessariamente.

Ele pode já estar armazenado no Driver Store.

O Plug and Play pode simplesmente ter reutilizado o pacote existente.

Como saber se foi realmente o Windows Update?

Compare o horário da mudança com:

Histórico do Windows Update;

versão instalada;

INF;

SetupAPI.dev.log;

eventos relacionados à instalação.

Quanto mais evidências coincidirem, mais confiável será a conclusão.

---

Precisa de ajuda com drivers e Windows 11 em São Paulo?

Um computador pode apresentar problemas de Wi-Fi, Bluetooth, vídeo, áudio, USB, impressoras ou outros dispositivos mesmo quando o Gerenciador de Dispositivos aparentemente mostra tudo funcionando.

A VMIA – Manutenção e Configuração realiza diagnóstico de computadores e notebooks Windows, identificando problemas de drivers, dispositivos, rede, desempenho e configuração.

O atendimento pode ser realizado por acesso remoto ou visita técnica agendada, dependendo do tipo de problema.

VMIA – Manutenção e Configuração

Rua Prof. Sud Menucci, 291
Vila Mariana – São Paulo – SP
CEP 04017-080

Telefone / WhatsApp: (11) 99779-7772

Site: https://vmia.site

Blog: https://vmia.com.br

WhatsApp: https://whats.vmia.com.br

Em vez de formatar o computador ou instalar drivers aleatoriamente, um diagnóstico técnico pode mostrar exatamente qual dispositivo está falhando, qual pacote está sendo utilizado e por que o Windows está escolhendo determinado driver.