Você liga o computador e percebe que o Windows 11 acabou de instalar alguma coisa.

Talvez tenha aparecido:

“Atualizações estão em andamento.”

Talvez o computador tenha pedido uma reinicialização.

Ou talvez você tenha percebido que o número da compilação do Windows mudou.

Então abre:

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

e tenta descobrir exatamente o que aconteceu.

Só que a atualização que você esperava encontrar não aparece.

Ou aparece alguma coisa no histórico, mas o número KB que você procura não está ali.

Em outra situação, você executa:

Get-HotFix

e encontra uma lista diferente daquela apresentada pelo Windows Update.

Qual delas está correta?

A atualização realmente foi instalada?

Ela foi substituída?

Foi incorporada a outra atualização?

O Windows removeu o pacote depois da reinicialização?

Ou estamos simplesmente consultando fontes diferentes que registram tipos diferentes de atualização?

Essa situação é mais comum do que parece porque “atualização do Windows” não representa um único tipo de pacote nem um único banco de informações.

O Windows 11 recebe:

• atualizações cumulativas;
• atualizações de segurança;
• atualizações de visualização;
• atualizações do .NET;
• drivers;
• atualizações de inteligência de segurança;
• atualizações de componentes;
• atualizações de configuração;
• atualizações de recursos;
• atualizações da Microsoft Store;
• atualizações do Microsoft Defender.

E nem todas aparecem exatamente da mesma maneira em todas as ferramentas.

Por isso, neste artigo não vamos simplesmente abrir o Histórico do Windows Update.

Vamos descobrir onde o Windows registra aquilo que realmente foi instalado.

---

Histórico de atualizações não é uma lista universal de tudo que existe no computador

Vamos começar pela principal confusão.

Quando acessamos:

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

o Windows apresenta diferentes categorias.

Dependendo da versão e das atualizações disponíveis, podemos encontrar áreas relacionadas a:

• atualizações de qualidade;
• atualizações de driver;
• atualizações de definição;
• outras atualizações.

Essa tela é extremamente útil.

A própria Microsoft recomenda o Histórico de atualizações para verificar quais atualizações foram instaladas e quando isso aconteceu.

Mas precisamos entender o significado da palavra histórico.

Estamos consultando um registro de atividades do mecanismo de atualização.

Não estamos necessariamente examinando diretamente cada componente presente no armazenamento interno de componentes do Windows.

Essa diferença ficará muito importante mais adiante.

---

Primeiro teste: abra o histórico pelo caminho correto

No Windows 11, acesse:

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

Agora observe as categorias.

Não procure apenas pelo número KB.

Veja também:

• nome da atualização;
• categoria;
• data;
• resultado da instalação;
• versão mencionada.

Um exemplo típico de atualização cumulativa pode conter:

KBxxxxxxx

e uma referência à compilação do sistema operacional.

Se o Windows acabou de reiniciar depois de uma atualização, anote o KB apresentado.

Essa informação será nossa primeira referência.

---

Descubra qual versão do Windows realmente está instalada

Antes de procurar uma atualização específica, precisamos saber qual Windows estamos analisando.

Pressione:

Win + R

Digite:

winver

e pressione Enter.

O Windows mostrará informações como:

• edição;
• versão;
• compilação do sistema operacional.

A compilação é extremamente importante.

Por exemplo, duas máquinas podem dizer:

Windows 11 25H2

mas estar em revisões diferentes da mesma versão.

Uma pode ter recebido a atualização cumulativa mais recente e outra ainda não.

Por isso, quando queremos saber se determinada atualização realmente chegou ao computador, o número da build ajuda bastante.

---

Por que a build pode ser mais útil do que procurar somente o KB?

As atualizações mensais modernas do Windows são cumulativas.

Isso significa que uma atualização mais recente incorpora correções fornecidas anteriormente.

Consequentemente, não devemos imaginar o Windows como uma coleção infinita de atualizações independentes:

KB1 + KB2 + KB3 + KB4 + KB5.

O modelo de manutenção cumulativa muda essa interpretação.

A Microsoft explica que, ao instalar a atualização mais recente de determinada versão do Windows 11, o sistema também recebe atualizações anteriores que possam estar ausentes, incluindo correções importantes de segurança.

Portanto, quando investigamos se uma correção está presente, às vezes a pergunta correta não é:

“O KB antigo ainda aparece?”

mas:

“Qual é a compilação atual e qual atualização cumulativa levou o sistema até ela?”

---

Compare a build com o histórico oficial da Microsoft

Depois de executar:

winver

anote o número da compilação.

Agora consulte o histórico oficial de atualizações correspondente à sua versão do Windows 11.

A Microsoft mantém páginas específicas para versões como:

• Windows 11 24H2;
• Windows 11 25H2;
• Windows 11 26H1.

Essas páginas relacionam as atualizações publicadas com suas respectivas builds.

Isso permite fazer uma comparação muito útil:

Build instalada no computador

versus

Build documentada pela Microsoft

Se os números coincidirem, conseguimos identificar qual atualização cumulativa corresponde à revisão atual do sistema.

---

Exemplo prático

Imagine que o usuário diga:

“Ontem o Windows instalou uma atualização, mas eu não encontro o KB.”

Em vez de começar procurando arquivos aleatórios, fazemos:

winver

Anotamos:

versão + compilação.

Depois abrimos:

Windows Update → Histórico de atualizações

Anotamos as entradas mais recentes.

Em seguida comparamos a build com a tabela oficial de atualizações da Microsoft.

Agora temos três fontes:

estado atual do sistema;

histórico local;

histórico oficial da versão.

Essa triangulação é muito mais confiável do que depender apenas de uma tela.

---

Agora entra o PowerShell

Uma das ferramentas mais conhecidas para verificar atualizações instaladas é:

Get-HotFix

Abra o PowerShell e execute:

Get-HotFix

Podemos encontrar uma saída contendo campos como:

Source

Description

HotFixID

InstalledBy

InstalledOn

O campo mais reconhecível costuma ser:

HotFixID

onde aparecem identificadores como:

KBxxxxxxx

Podemos ordenar pela data:

Get-HotFix | Sort-Object InstalledOn -Descending

Assim, as entradas mais recentes aparecem primeiro.

Também podemos limitar o resultado:

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

Esse comando é excelente para uma primeira investigação.

Mas existe uma armadilha.

---

Get-HotFix não mostra necessariamente todas as atualizações

Esse é um dos pontos mais importantes deste artigo.

É comum encontrar tutoriais dizendo:

“Para listar todas as atualizações instaladas, execute Get-HotFix.”

Essa frase precisa de uma ressalva.

Segundo a própria documentação da Microsoft, Get-HotFix utiliza a classe WMI:

Win32_QuickFixEngineering

Essa classe representa atualizações QFE aplicadas ao sistema operacional.

Mais importante ainda:

a documentação explica que ela retorna atualizações fornecidas pelo mecanismo Component-Based Servicing, ou CBS.

Isso significa que Get-HotFix não deve ser tratado como um inventário universal de qualquer atualização que já passou pelo computador.

Portanto, esta situação pode acontecer:

Windows Update mostra uma atualização

mas:

Get-HotFix

não mostra a mesma entrada.

Isso não prova que a atualização não foi instalada.

Pode simplesmente significar que estamos comparando fontes com escopos diferentes.

---

O inverso também pode confundir

Também podemos encontrar uma atualização em determinada ferramenta e não reconhecê-la imediatamente no Histórico do Windows Update.

Novamente, isso não significa necessariamente corrupção.

Precisamos descobrir:

que tipo de atualização estamos procurando?

Essa pergunta deveria vir antes de:

“Onde está o KB?”

---

Nem toda atualização possui o mesmo ciclo de vida

Considere alguns exemplos.

Uma atualização cumulativa do Windows modifica componentes do sistema operacional.

Uma atualização de driver altera software relacionado a determinado hardware.

Uma atualização de inteligência de segurança modifica informações utilizadas pelo Microsoft Defender.

Uma atualização da Microsoft Store modifica um aplicativo.

Embora todas possam ser chamadas genericamente de “atualizações”, elas pertencem a mecanismos e históricos diferentes.

Por isso, não existe necessariamente um único comando capaz de responder perfeitamente:

“Mostre absolutamente tudo que foi atualizado neste computador.”

Precisamos escolher a fonte de acordo com o que estamos procurando.

---

Atualização instalada versus atualização presente

Existe outra diferença conceitual importante.

Histórico de instalação

responde:

“O que o mecanismo registrou durante as operações de atualização?”

Já o estado atual do sistema responde:

“O que está presente agora?”

Essas duas perguntas não são idênticas.

Uma atualização pode ter sido:

• instalada;
• substituída posteriormente;
• removida;
• revertida;
• incorporada por uma atualização cumulativa mais recente.

Por isso, o fato de uma entrada existir no histórico não significa necessariamente que aquele pacote permaneça isoladamente como estava no momento da instalação.

Da mesma maneira, a ausência de um KB antigo em determinada consulta não significa automaticamente que suas correções desapareceram.

---

Atualizações cumulativas mudaram a maneira de pensar nos KBs

Durante muitos anos, usuários de Windows se acostumaram a procurar números KB individualmente.

Essa prática continua útil.

Mas no Windows 11 precisamos considerar o modelo cumulativo.

Imagine:

Atualização A contém correções:

1, 2 e 3.

No mês seguinte, atualização B contém:

1, 2, 3, 4 e 5.

Depois chega atualização C contendo:

1, 2, 3, 4, 5, 6 e 7.

Se o computador está corretamente atualizado com C, não devemos necessariamente esperar encontrar cada correção anterior como um pacote independente ativo.

O estado atual pode estar representado pela atualização cumulativa mais recente.

Essa lógica explica muitas aparentes contradições.

---

Como procurar um KB específico com Get-HotFix

Se você possui o número exato:

KBxxxxxxx

pode executar:

Get-HotFix -Id KBxxxxxxx

Se o cmdlet encontrar a atualização dentro do escopo que ele consulta, apresentará as informações correspondentes.

Se não encontrar, não conclua imediatamente:

“Não está instalada.”

Lembre-se da limitação do próprio Get-HotFix.

O resultado correto nesse momento é:

“Get-HotFix não encontrou esse KB.”

Isso é diferente de afirmar:

“O Windows nunca instalou esse KB.”

Essa precisão é fundamental em diagnóstico.

---

Um comando útil para descobrir os hotfixes mais recentes

Podemos executar:

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20 HotFixID,Description,InstalledOn

Isso cria uma lista mais limpa contendo:

• identificador;
• descrição;
• data.

Para muitos atendimentos, essa consulta já ajuda a descobrir se uma mudança recente coincide com uma atualização.

Mas não pare nela se os dados não coincidirem com o Histórico do Windows Update.

É justamente aí que começa a parte mais interessante do diagnóstico.

---

O Windows possui fontes mais profundas

Se:

Histórico de atualizações

diz uma coisa,

e:

Get-HotFix

parece dizer outra,

não precisamos escolher cegamente qual está “certo”.

Podemos consultar outras camadas.

Entre elas estão:

• histórico da API do Windows Update;
• armazenamento de componentes;
• DISM;
• pacotes instalados;
• logs do Windows Update;
• eventos;
• build atual do sistema.

Cada uma responde a uma pergunta diferente.

E é isso que veremos na próxima parte.

---

Não desinstale uma atualização apenas porque ela não aparece onde você esperava

Esse é um cuidado importante.

Imagine que um programa começou a apresentar problema depois de uma reinicialização.

O usuário acredita que uma atualização causou o defeito.

Ele procura o KB.

Não encontra.

Então começa a remover outras atualizações “para testar”.

Esse procedimento pode piorar o sistema sem confirmar a hipótese inicial.

Antes de remover qualquer atualização, descubra:

1. qual versão do Windows está instalada;
2. qual é a build;
3. quais operações aparecem no histórico;
4. quais hotfixes aparecem no PowerShell;
5. qual pacote corresponde à build;
6. se houve falha ou rollback;
7. se existe um problema conhecido relacionado àquela atualização.

Só depois disso faz sentido avaliar uma intervenção.

---

O histórico oficial da Microsoft também faz parte do diagnóstico

Existe uma vantagem importante em comparar a máquina com o histórico oficial.

A Microsoft publica, para cada versão do Windows 11, informações como:

• data da atualização;
• número KB;
• build;
• alterações;
• problemas conhecidos.

Isso permite responder perguntas que o computador sozinho não responde.

Por exemplo:

“Esta build corresponde a qual atualização?”

ou:

“Esse problema começou em uma atualização que possui falha conhecida?”

Portanto, um diagnóstico completo utiliza tanto informações locais quanto documentação oficial.

Quando Get-HotFix não encontra a atualização: consulte os pacotes do Windows com DISM

Na primeira parte vimos uma diferença fundamental:

Get-HotFix

não deve ser considerado uma lista universal de tudo que o Windows Update instalou.

Isso explica por que podemos encontrar determinada atualização no Histórico do Windows Update e não encontrá-la no resultado desse cmdlet.

Quando isso acontece, precisamos descer uma camada.

Uma das ferramentas mais importantes para isso é o:

DISM — Deployment Image Servicing and Management.

Muitos usuários conhecem o DISM apenas por este comando:

DISM /Online /Cleanup-Image /RestoreHealth

Mas o DISM faz muito mais do que reparar a imagem do Windows.

Ele também consegue consultar os pacotes presentes na instalação.

E isso é extremamente útil quando queremos descobrir o que realmente existe no sistema.

---

O que significa DISM /Online /Get-Packages?

Abra o Terminal ou Prompt de Comando como administrador e execute:

DISM /Online /Get-Packages

O parâmetro:

/Online

não significa Internet.

Essa é uma confusão bastante comum.

Nesse contexto, Online significa que o DISM trabalhará com o sistema operacional que está atualmente em execução.

Já:

/Get-Packages

solicita informações sobre os pacotes presentes na imagem do Windows.

A própria Microsoft documenta /Get-Packages como uma opção que exibe informações básicas sobre todos os pacotes da imagem.

Portanto, estamos olhando para uma camada diferente daquela consultada por Get-HotFix.

---

Como deixar a saída mais organizada

Podemos executar:

DISM /Online /Get-Packages /Format:Table

Isso organiza a saída em formato de tabela.

Normalmente aparecem informações relacionadas a:

Package Identity

State

Release Type

Install Time

O nome completo de alguns pacotes pode parecer complicado.

Isso acontece porque internamente o Windows não identifica tudo apenas por números como:

KB1234567

Um pacote pode possuir uma identidade muito mais extensa.

É justamente por isso que procurar somente por KB pode não contar toda a história.

---

O que é Package Identity?

A identidade de um pacote permite que o mecanismo de manutenção do Windows diferencie componentes e versões.

Podemos encontrar nomes longos contendo informações como:

• nome do pacote;
• arquitetura;
• identificadores;
• versão.

Para o usuário comum isso parece exageradamente complexo.

Para diagnóstico, porém, é extremamente útil.

Estamos olhando mais perto da maneira como o mecanismo de manutenção do Windows realmente enxerga seus pacotes.

---

O campo State merece atenção

O DISM também mostra o estado do pacote.

Um estado importante é:

Installed

ou seu equivalente apresentado na localização do Windows.

Isso indica que o pacote está instalado na imagem consultada.

Dependendo da operação e do momento em que a consulta é feita, outros estados podem existir.

É importante não interpretar qualquer estado diferente de Installed como corrupção.

Operações de manutenção podem envolver estados transitórios e reinicializações pendentes.

Por isso, se o Windows acabou de instalar uma atualização e solicita reinicialização, conclua primeiro o processo normal antes de tirar conclusões.

---

Por que DISM pode mostrar coisas que Get-HotFix não mostra?

Porque estamos fazendo perguntas diferentes.

Get-HotFix

consulta informações disponibilizadas pela infraestrutura relacionada a Win32_QuickFixEngineering.

Já:

DISM /Online /Get-Packages

consulta pacotes da imagem do Windows.

Portanto, não devemos esperar que as duas saídas sejam cópias uma da outra.

Essa diferença é justamente uma das razões para este artigo existir.

---

Existe uma versão PowerShell do diagnóstico com DISM

Sim.

O Windows também possui cmdlets relacionados ao DISM.

Um deles é:

Get-WindowsPackage

Para consultar a instalação atualmente em execução:

Get-WindowsPackage -Online

Esse comando obtém informações sobre pacotes na imagem do Windows.

Podemos ordenar os resultados:

Get-WindowsPackage -Online | Sort-Object InstallTime -Descending

E selecionar campos:

Get-WindowsPackage -Online | Select-Object PackageName,PackageState,ReleaseType,InstallTime

Isso pode facilitar bastante a leitura em comparação com a saída tradicional do DISM.exe.

---

Como procurar os pacotes instalados recentemente

Podemos usar:

Get-WindowsPackage -Online | Sort-Object InstallTime -Descending | Select-Object -First 20 PackageName,PackageState,ReleaseType,InstallTime

Agora temos uma lista dos pacotes mais recentes segundo essa fonte.

Essa consulta é particularmente útil quando o usuário diz:

“Ontem o computador atualizou e depois começou o problema.”

Em vez de perguntar somente:

“Qual KB apareceu?”

podemos investigar quais pacotes tiveram atividade recente.

---

Mas cuidado com a data

Datas em diferentes fontes não devem ser interpretadas automaticamente como equivalentes.

Um horário pode representar:

• instalação;
• registro;
• manutenção;
• atualização de componente;
• processamento do pacote.

Por isso, correlacione a informação com outras fontes.

Nunca baseie toda a investigação em apenas um timestamp.

---

Como obter detalhes de um pacote específico

Depois de encontrar o nome de um pacote, podemos usar o próprio DISM para obter mais informações.

Por exemplo:

DISM /Online /Get-PackageInfo /PackageName:NOME_DO_PACOTE

Substitua NOME_DO_PACOTE pela identidade real retornada pelo /Get-Packages.

No PowerShell, também podemos consultar um pacote específico com:

Get-WindowsPackage -Online -PackageName "NOME_DO_PACOTE"

Isso permite aprofundar a investigação sem analisar a lista inteira.

---

Não remova pacotes apenas porque o nome parece estranho

Este ponto merece destaque.

Ao executar:

DISM /Online /Get-Packages

você encontrará muitos nomes que nunca viu antes.

Isso é normal.

Não use:

/Remove-Package

simplesmente porque acredita que determinado pacote é antigo ou desnecessário.

O armazenamento de componentes e o mecanismo de manutenção do Windows possuem dependências.

Nosso objetivo neste artigo é:

consultar.

Não:

limpar.

Existe uma enorme diferença entre as duas operações.

---

Agora vamos consultar o histórico pela própria infraestrutura do Windows Update

Até agora usamos:

Configurações

Get-HotFix

DISM

Get-WindowsPackage

Mas ainda podemos fazer outra pergunta:

O que o próprio Windows Update registrou como operações realizadas?

O Windows possui uma API para isso.

Uma maneira de acessá-la pelo PowerShell é criar uma sessão COM:

$Session = New-Object -ComObject Microsoft.Update.Session

Depois criamos um pesquisador:

$Searcher = $Session.CreateUpdateSearcher()

Agora podemos descobrir quantas entradas existem no histórico:

$Count = $Searcher.GetTotalHistoryCount()

E consultar o histórico:

$History = $Searcher.QueryHistory(0,$Count)

Por fim:

$History | Select-Object Date,Title,Operation,ResultCode

Essa consulta é extremamente interessante.

Ela trabalha com o histórico de eventos do Windows Update.

---

Por que essa consulta é diferente?

Agora não estamos perguntando:

“Quais pacotes estão presentes?”

Estamos perguntando algo mais próximo de:

“Quais operações o Windows Update registrou?”

A própria API do Windows Update possui um método chamado:

QueryHistory

destinado a consultar o computador em busca do histórico de eventos de atualização.

Segundo a documentação da Microsoft, os registros são retornados em ordem cronológica decrescente.

Isso significa que as operações mais recentes aparecem primeiro.

---

Limite o histórico para facilitar a leitura

Em um computador antigo, consultar todo o histórico pode gerar uma saída enorme.

Podemos mostrar somente as entradas mais recentes.

Depois de criar $Searcher, execute:

$Count = $Searcher.GetTotalHistoryCount()

Então escolha uma quantidade menor.

Por exemplo, se existirem pelo menos 30 registros:

$History = $Searcher.QueryHistory(0,30)

Depois:

$History | Select-Object Date,Title,Operation,ResultCode

Agora temos uma visão muito mais administrável.

---

O campo Title

Title

normalmente contém o nome apresentado para a atualização.

Ele pode incluir:

• número KB;
• tipo de atualização;
• versão;
• produto;
• driver;
• descrição.

Isso ajuda bastante quando queremos descobrir o que aconteceu recentemente.

---

O campo Date

Date

mostra a data associada ao evento registrado no histórico.

Isso permite correlacionar:

horário da atualização

com:

horário em que o problema começou.

Imagine:

10:02 — atualização registrada.

10:15 — computador reinicia.

10:19 — usuário percebe que a impressora não funciona.

Agora temos uma linha temporal.

Isso ainda não prova causalidade.

Mas cria uma hipótese muito melhor do que simplesmente dizer:

“Foi o Windows Update.”

---

Operation e ResultCode

Esses dois campos tornam o histórico ainda mais interessante.

Operation

representa o tipo de operação registrada.

ResultCode

representa o resultado da operação.

Dependendo da interface usada, esses valores podem aparecer numericamente.

Por isso, o objetivo inicial não é decorar códigos.

Primeiro queremos localizar:

• qual atualização;
• quando;
• qual operação;
• qual resultado.

Depois investigamos o significado específico se necessário.

---

Uma atualização pode aparecer várias vezes?

Sim.

E isso não significa necessariamente que o Windows instalou exatamente o mesmo pacote repetidamente sem motivo.

O histórico trabalha com eventos.

Podem existir diferentes operações relacionadas à mesma atualização.

Esse conceito é importante.

Estamos olhando um histórico de atividades, não apenas uma lista de objetos únicos.

---

O histórico pode mostrar falhas que depois foram corrigidas

Imagine:

14:00 — tentativa de atualização.

Resultado: falha.

14:20 — nova tentativa.

Resultado: sucesso.

Se olharmos apenas a primeira entrada, concluiremos:

“A atualização falhou.”

Se olharmos apenas a segunda:

“Nunca houve problema.”

O histórico completo mostra algo mais interessante:

houve uma falha e posteriormente uma instalação bem-sucedida.

Esse tipo de sequência explica vários relatos de usuários dizendo:

“O Windows deu erro, mas depois a atualização sumiu.”

Talvez ela não tenha sumido.

Talvez uma nova tentativa tenha sido concluída.

---

Por que o histórico gráfico e a API podem ajudar de maneiras diferentes?

A interface:

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

foi criada para usuários.

Ela organiza as informações de maneira amigável.

Já a API permite uma investigação programática dos eventos.

Portanto, quando estamos diagnosticando um comportamento estranho, faz sentido usar as duas.

A interface responde rapidamente:

“O que o Windows quer mostrar ao usuário?”

A API ajuda a responder:

“Quais eventos estão registrados no histórico consultável do Windows Update?”

---

Agora temos quatro fontes diferentes

Até este ponto do artigo, podemos consultar:

1. Histórico do Windows Update

Mostra informações de atualização em uma interface amigável.

2. Get-HotFix

Consulta hotfixes dentro do escopo suportado pelo cmdlet.

3. DISM / Get-WindowsPackage

Consulta pacotes presentes na imagem do Windows.

4. API do Windows Update

Consulta eventos registrados no histórico do Windows Update.

É completamente possível que essas quatro fontes não apresentem exatamente a mesma lista.

Isso não significa automaticamente que uma delas esteja quebrada.

Elas respondem a perguntas diferentes.

---

Um exemplo realista

Imagine que você procura:

KBXXXXXXX

No Histórico do Windows Update ele aparece como instalado.

Em:

Get-HotFix

não aparece.

Então você executa:

DISM /Online /Get-Packages /Format:Table

e encontra pacotes relacionados à atualização cumulativa correspondente.

Depois consulta:

$Session = New-Object -ComObject Microsoft.Update.Session

$Searcher = $Session.CreateUpdateSearcher()

$History = $Searcher.QueryHistory(0,30)

$History | Select-Object Date,Title,Operation,ResultCode

E encontra o evento da instalação.

Agora temos evidências suficientes para dizer que:

a ausência no Get-HotFix não significava ausência da atualização.

O problema estava na interpretação da ferramenta.

---

E se a atualização aparece no histórico, mas não está mais presente?

Agora entramos em outro cenário.

Imagine:

Histórico:

KBXXXXXXX — instalado.

Mas a build atual corresponde a uma atualização posterior.

Ou o pacote antigo não aparece mais da maneira esperada.

Isso pode ser completamente normal em um modelo cumulativo.

A atualização mais recente pode ter substituído componentes anteriores.

O histórico continua dizendo:

“essa operação aconteceu.”

O estado atual diz:

“agora o sistema está neste nível de manutenção.”

As duas informações podem estar corretas ao mesmo tempo.

---

Histórico não significa estado atual

Essa frase merece ser lembrada:

Histórico registra acontecimentos.

Estado atual mostra o que existe agora.

É exatamente como o histórico de um navegador.

O fato de você ter acessado determinada página ontem não significa que ela esteja aberta agora.

Da mesma maneira, uma atualização registrada no histórico representa um acontecimento.

Para descobrir o estado atual, precisamos consultar a build e os pacotes presentes.

---

E quando houve rollback?

Agora temos um cenário ainda mais interessante.

O Windows tenta instalar uma atualização.

Reinicia.

Algo dá errado durante o processamento.

O Windows desfaz alterações.

O usuário volta para a Área de Trabalho.

Nesse cenário, simplesmente procurar a atualização em uma única fonte pode gerar muita confusão.

Precisamos descobrir:

• houve tentativa?
• houve falha?
• houve reinicialização?
• houve rollback?
• qual build permaneceu?
• qual pacote está presente agora?

É aí que entram os logs.

---

WindowsUpdate.log ainda existe?

Usuários antigos do Windows lembram do arquivo:

WindowsUpdate.log

Em versões modernas do Windows, a arquitetura de logs mudou.

O Windows utiliza rastreamento baseado em ETW para diversos componentes.

O PowerShell possui um cmdlet chamado:

Get-WindowsUpdateLog

Ele pode criar um arquivo WindowsUpdate.log legível a partir dos rastreamentos disponíveis.

Esse log pode ajudar em diagnósticos mais profundos.

Mas não devemos começar por ele.

A quantidade de informações pode ser enorme.

Primeiro localize:

• data;
• horário;
• KB;
• operação.

Depois use os logs para investigar aquela janela de tempo.

---

Diagnóstico eficiente trabalha do simples para o complexo

Uma boa ordem seria:

1. winver

Descubra versão e build.

2. Histórico do Windows Update

Veja o que a interface registra.

3. Get-HotFix

Consulte os hotfixes reconhecidos por essa fonte.

4. Get-WindowsPackage -Online

Consulte os pacotes.

5. API do Windows Update

Consulte os eventos.

6. Logs

Aprofunde somente quando necessário.

Essa ordem evita transformar uma dúvida simples em uma investigação de milhares de linhas de log.

Windows Update: como descobrir se houve falha, rollback ou uma atualização que “sumiu”

Nas partes anteriores vimos que existem diferentes maneiras de perguntar ao Windows quais atualizações foram instaladas.

Já usamos:

winver

Get-HotFix

DISM /Online /Get-Packages

Get-WindowsPackage -Online

e a API do Windows Update.

Agora chegamos ao cenário mais complicado.

O computador claramente passou por um processo de atualização.

O Windows mostrou porcentagens.

Houve uma ou mais reinicializações.

Talvez tenha aparecido:

“Trabalhando nas atualizações.”

Depois o Windows voltou à Área de Trabalho.

Só que a atualização esperada não aparece onde imaginávamos.

Nesse momento precisamos descobrir se ela:

• foi instalada com sucesso;
• falhou;
• foi revertida;
• foi substituída;
• permanece pendente;
• foi instalada e posteriormente removida;
• aparece em outra fonte de informações.

Para isso, precisamos começar a reconstruir a linha do tempo.

---

Primeiro: confirme a build que existe agora

Antes de abrir qualquer log, execute:

winver

Anote:

Versão

e

Compilação do Sistema Operacional.

Essa informação representa o estado atual.

Se estamos investigando uma atualização cumulativa, a build atual pode ser uma das melhores pistas para descobrir até onde o processo realmente chegou.

Não confunda:

o Windows tentou instalar determinada atualização

com:

o Windows está atualmente executando a build resultante daquela atualização.

São afirmações diferentes.

---

Uma tentativa de atualização não significa instalação concluída

Essa diferença explica muitos casos.

O Windows pode:

1. baixar a atualização;
2. preparar arquivos;
3. iniciar a instalação;
4. solicitar reinicialização;
5. continuar o processamento durante o boot;
6. encontrar um problema;
7. desfazer as alterações;
8. retornar para a build anterior.

Para o usuário, houve claramente uma atualização.

Ele viu todo o processo.

Mas o estado final pode continuar sendo a versão anterior.

Portanto, quando alguém diz:

“O Windows instalou uma atualização ontem.”

tecnicamente precisamos perguntar:

“A instalação foi concluída?”

---

Como reconhecer um possível rollback

Um indício clássico ocorre quando o Windows apresenta mensagens relacionadas a desfazer alterações durante a inicialização.

Mesmo que o usuário não tenha anotado a mensagem, podemos investigar depois.

Compare:

build atual

com:

build que a atualização deveria instalar.

Se a atualização deveria levar o computador para uma build mais nova, mas winver ainda mostra a anterior, temos uma evidência de que o estado esperado não foi alcançado.

Isso não prova sozinho que houve rollback.

Precisamos procurar os registros.

---

Visualizador de Eventos: comece pelo WindowsUpdateClient

Pressione:

Win + R

Digite:

eventvwr.msc

e pressione Enter.

Navegue até:

Logs de Aplicativos e Serviços → Microsoft → Windows → WindowsUpdateClient → Operational

Dependendo da configuração e da versão do Windows, esse log pode fornecer eventos relacionados às operações do Windows Update.

O grande valor aqui é a cronologia.

Procure o horário em que o usuário lembra que a atualização aconteceu.

---

Não procure apenas por “Erro”

Esse é um erro frequente durante análise de logs.

O usuário abre o Visualizador de Eventos e filtra somente eventos vermelhos.

Mas uma atualização envolve uma sequência.

Podemos encontrar:

detecção

→ download

→ instalação

→ reinicialização

→ resultado

Se observarmos somente o evento final, podemos perder o contexto.

O objetivo é reconstruir a sequência.

---

Use o PowerShell para consultar eventos

Também podemos consultar logs pelo PowerShell.

Por exemplo:

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational'

Em máquinas com muitos registros, a saída será grande.

Podemos limitar:

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 50

Isso retorna os eventos mais recentes.

Podemos selecionar campos importantes:

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 50 | Select-Object TimeCreated,Id,LevelDisplayName,Message

Agora temos:

• horário;
• ID;
• nível;
• mensagem.

---

Filtrar por horário é melhor do que ler milhares de eventos

Imagine que o usuário diga:

“O problema começou ontem por volta das 19h.”

Em vez de analisar o histórico inteiro, podemos definir uma janela.

Por exemplo:

$inicio = (Get-Date).AddDays(-1)

Depois:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-WindowsUpdateClient/Operational'; StartTime=$inicio}

Também podemos selecionar:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-WindowsUpdateClient/Operational'; StartTime=$inicio} | Select-Object TimeCreated,Id,LevelDisplayName,Message

Isso facilita bastante.

O ideal é ajustar o período ao caso real.

---

E o WindowsUpdate.log?

O Windows moderno não utiliza o antigo WindowsUpdate.log da mesma maneira que versões antigas do sistema.

Para produzir um arquivo legível a partir dos rastreamentos do Windows Update, podemos usar:

Get-WindowsUpdateLog

O cmdlet converte os arquivos de rastreamento do Windows Update em um arquivo de log legível.

Por padrão, podemos obter um arquivo chamado:

WindowsUpdate.log

Esse arquivo pode ser aberto em um editor de texto.

---

Para que serve Get-WindowsUpdateLog?

Ele se torna útil quando precisamos entender detalhes que não ficaram claros nas interfaces mais simples.

Por exemplo:

• tentativa de detecção;
• download;
• processamento;
• comunicação entre componentes;
• erros relacionados ao Windows Update.

Mas existe um problema:

o arquivo pode ser grande e complexo.

Por isso, não comece por ele.

Antes, descubra:

qual dia?

qual horário?

qual KB?

qual build?

qual sintoma?

Depois procure a janela correspondente.

---

CBS.log: uma fonte diferente

Outro arquivo extremamente conhecido em diagnóstico do Windows é:

C:\Windows\Logs\CBS\CBS.log

CBS significa:

Component-Based Servicing.

Essa infraestrutura participa da manutenção dos componentes do Windows.

Por isso, o CBS.log pode conter informações importantes relacionadas à instalação e manutenção de componentes e pacotes.

Mas novamente:

CBS.log não é simplesmente outro WindowsUpdate.log.

As duas fontes possuem funções diferentes.

---

Windows Update e CBS trabalham em partes diferentes do processo

Podemos simplificar assim:

Windows Update

cuida de aspectos como descobrir, obter e coordenar atualizações.

CBS

participa do servicing dos componentes do Windows.

Essa simplificação ajuda a entender por que uma atualização pode aparecer em registros diferentes durante fases diferentes.

Imagine:

Windows Update encontra o pacote.

O pacote é baixado.

A instalação começa.

O CBS processa componentes.

Uma operação falha.

Nesse cenário, investigar apenas o Windows Update pode não mostrar todos os detalhes da etapa de servicing.

---

Como abrir o CBS.log

O arquivo normalmente está em:

C:\Windows\Logs\CBS\CBS.log

Como pode ser grande, não recomendo simplesmente abrir e começar a ler desde a primeira linha.

Use:

• horário;
• código de erro;
• nome do pacote;
• KB;
• palavra relevante.

como referência.

Em diagnóstico profissional, contexto temporal economiza muito tempo.

---

O CBS.log pode mostrar um KB diretamente?

Às vezes encontramos referências úteis ao pacote ou à atualização.

Mas não espere que toda informação apareça sempre como um número KB amigável.

Lembre-se da Parte 2:

internamente o Windows trabalha com identidades de pacotes.

Por isso, o nome encontrado no DISM pode ser útil para procurar informações no CBS.

---

Descubra a identidade do pacote antes de procurar no log

Execute:

Get-WindowsPackage -Online | Sort-Object InstallTime -Descending | Select-Object -First 20 PackageName,PackageState,InstallTime

Agora temos os nomes dos pacotes recentes.

Se um deles parece relacionado à atualização investigada, podemos usar esse nome como referência durante a análise do CBS.

Isso costuma ser mais eficiente do que procurar apenas:

KBxxxxxxx

---

O que significa uma atualização “sumir”?

Na prática, usuários usam essa expressão para vários fenômenos diferentes.

Vamos separar.

Situação 1 — A atualização foi instalada, mas Get-HotFix não mostra

Isso pode acontecer devido ao escopo da ferramenta.

Não significa automaticamente que ela desapareceu.

Situação 2 — O histórico mostra a atualização, mas uma atualização cumulativa posterior já está instalada

Nesse caso, o histórico registra o acontecimento anterior enquanto o estado atual está em um nível de manutenção mais recente.

Situação 3 — A instalação falhou

O Windows tentou instalar, mas nunca concluiu.

Situação 4 — Houve rollback

A atualização avançou até determinada etapa, encontrou um problema e o Windows desfez alterações.

Situação 5 — A atualização foi removida

Nesse caso, pode existir histórico de instalação e posteriormente outra operação relacionada à remoção.

Situação 6 — Estamos procurando na categoria errada

Talvez seja um driver, uma atualização de inteligência de segurança ou outro tipo de pacote.

A atualização não desapareceu.

Estamos procurando na fonte errada.

---

Como saber se houve uma desinstalação?

Volte ao histórico consultado pela API do Windows Update:

$Session = New-Object -ComObject Microsoft.Update.Session

$Searcher = $Session.CreateUpdateSearcher()

$Count = $Searcher.GetTotalHistoryCount()

$History = $Searcher.QueryHistory(0,$Count)

Agora:

$History | Select-Object Date,Title,Operation,ResultCode

Procure eventos relacionados à atualização.

O campo:

Operation

ajuda a distinguir tipos de operação registrados no histórico.

Se houver mais de um evento associado ao mesmo título, analise a sequência cronológica.

---

Transforme o histórico em uma linha do tempo

Podemos ordenar:

$History | Sort-Object Date | Select-Object Date,Title,Operation,ResultCode

Agora os eventos aparecem do mais antigo para o mais recente.

Isso facilita responder:

O que aconteceu primeiro?

Imagine:

18:42 — operação relacionada à atualização.

19:05 — nova operação.

19:12 — reinicialização.

19:20 — outro resultado.

Ao correlacionar esses horários com os eventos do WindowsUpdateClient e CBS, conseguimos reconstruir o processo com muito mais precisão.

---

Atualização pendente também pode confundir

Existe outro cenário:

a atualização foi baixada e parcialmente preparada, mas ainda precisa de reinicialização.

O usuário consulta algumas ferramentas antes de reiniciar.

Os resultados podem não representar ainda o estado final.

Por isso, antes de diagnosticar uma atualização que aparentemente “sumiu”, verifique se o Windows Update mostra:

Reinicialização necessária

ou algo equivalente.

Se houver uma reinicialização pendente, conclua o ciclo normal quando for seguro fazê-lo.

Depois repita:

winver

Get-HotFix

Get-WindowsPackage -Online

e as consultas de histórico.

---

Não desligue o computador à força durante uma atualização

Quando o Windows está aplicando atualizações durante a reinicialização, interromper o processo sem necessidade pode complicar o cenário.

Se o computador parece demorar, isso não significa automaticamente que travou.

Atualizações podem levar tempos diferentes dependendo de:

• desempenho do armazenamento;
• quantidade de componentes;
• tamanho da atualização;
• estado do sistema;
• operações de manutenção necessárias.

Uma interrupção forçada deve ser considerada somente quando existe evidência de que o sistema realmente não consegue prosseguir, e não apenas porque a porcentagem ficou algum tempo no mesmo valor.

---

Como descobrir se a build mudou depois da atualização

Aqui existe um procedimento simples e extremamente útil.

Antes de uma manutenção importante, execute:

winver

Anote a build.

Depois da atualização e da reinicialização:

winver

novamente.

Compare.

Se passou de uma revisão para outra, temos evidência objetiva de alteração no nível da compilação.

Isso é especialmente útil para atualizações cumulativas.

---

O comando systeminfo também pode ajudar

Execute:

systeminfo

Ele mostra diversas informações do sistema.

Dependendo da versão e do ambiente, podemos encontrar dados relacionados à instalação e hotfixes.

Também podemos filtrar:

systeminfo | findstr /i "KB"

Essa consulta pode ser útil como fonte adicional.

Mas, assim como Get-HotFix, não deve ser tratada como inventário universal de qualquer atualização possível.

---

Outra consulta útil: informações do sistema pelo PowerShell

Podemos usar:

Get-ComputerInfo

A saída é extensa.

Para algumas informações relacionadas ao Windows:

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber

Isso ajuda a registrar o estado do sistema durante o diagnóstico.

Mais uma vez:

não substitui as outras fontes.

Complementa.

---

E se o Windows Update diz que está atualizado?

A mensagem:

“Você está atualizado”

significa que o mecanismo não está oferecendo naquele momento outras atualizações aplicáveis dentro das condições atuais.

Isso não significa:

“Todo computador Windows 11 do mundo possui exatamente a mesma build.”

Existem diferenças de:

• versão;
• hardware;
• compatibilidade;
• políticas;
• canal;
• distribuição gradual;
• safeguard holds;
• tipos de atualização.

Por isso, compare sempre máquinas dentro do contexto correto.

---

Atualização substituída não significa correção perdida

Esse conceito merece reforço.

Se uma atualização cumulativa mais recente substitui uma anterior, isso não significa necessariamente que as correções anteriores desapareceram.

O modelo cumulativo foi projetado justamente para incorporar correções anteriores aplicáveis.

Portanto, não tente reinstalar um KB antigo apenas porque ele não aparece da forma esperada.

Primeiro descubra qual cumulativa atual está instalada.

---

Um exemplo completo de investigação

Imagine este caso.

O usuário diz:

“O Windows atualizou ontem e depois meu programa começou a fechar.”

Primeiro:

winver

Registramos a build.

Depois:

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

Encontramos uma atualização recente.

Executamos:

Get-HotFix | Sort-Object InstalledOn -Descending

O KB não aparece.

Isso parece contraditório.

Mas não concluímos nada ainda.

Executamos:

Get-WindowsPackage -Online | Sort-Object InstallTime -Descending

Encontramos pacotes recentes.

Depois consultamos a API:

$Session = New-Object -ComObject Microsoft.Update.Session

$Searcher = $Session.CreateUpdateSearcher()

$History = $Searcher.QueryHistory(0,30)

$History | Select-Object Date,Title,Operation,ResultCode

Encontramos a operação registrada.

Agora consultamos:

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 50

e correlacionamos os horários.

Finalmente comparamos a build atual com a documentação oficial da Microsoft.

Agora podemos afirmar com muito mais confiança se a atualização realmente chegou ao sistema.

---

Correlação não significa causalidade

Existe ainda uma armadilha.

Imagine:

18:00 — Windows instala atualização.

18:30 — usuário abre Outlook.

18:31 — Outlook fecha sozinho.

É tentador afirmar:

“A atualização quebrou o Outlook.”

Mas a sequência temporal sozinha não prova isso.

Precisamos investigar:

• existem outros usuários com o mesmo problema?
• existe problema conhecido documentado?
• houve atualização do próprio Outlook?
• qual módulo causou a falha?
• o Visualizador de Eventos mostra alguma relação?
• remover a atualização é realmente indicado?

Esse cuidado evita diagnósticos precipitados.

---

Quando consultar os problemas conhecidos da Microsoft

Depois de identificar:

versão

build

e

KB

consulte a página oficial de integridade de versão do Windows.

A Microsoft publica informações sobre problemas conhecidos relacionados a determinadas atualizações.

Essa etapa é extremamente importante antes de remover um pacote.

Se o problema já estiver documentado, talvez exista:

• workaround oficial;
• Known Issue Rollback;
• atualização corretiva;
• orientação específica.

---

Não remova atualizações como primeiro teste

Uma atualização cumulativa pode conter correções importantes de segurança.

Removê-la apenas para verificar se determinado problema desaparece deve ser uma decisão fundamentada.

Primeiro descubra:

qual atualização está instalada;

quando foi instalada;

qual build resultou dela;

qual problema apareceu;

se existe relação documentada.

Isso reduz riscos.

---

O verdadeiro objetivo é reconstruir a história

Quando o Windows Update parece contradizer outras ferramentas, a pergunta não deve ser:

“Qual comando está errado?”

Cada fonte pode estar mostrando uma parte diferente da história.

O Histórico mostra eventos.

Get-HotFix mostra informações dentro de seu escopo.

DISM mostra pacotes.

winver mostra o estado atual da compilação.

WindowsUpdateClient mostra eventos.

CBS registra atividades do mecanismo de servicing.

A documentação da Microsoft mostra qual KB corresponde a determinada build.

Quando juntamos essas informações, conseguimos reconstruir o processo.

---

Checklist: como descobrir se uma atualização realmente foi instalada no Windows 11

Depois de analisar diferentes fontes de informação, podemos transformar o diagnóstico em uma sequência prática.

O objetivo é responder:

O Windows realmente instalou essa atualização?

E, se instalou:

ela ainda faz parte do estado atual do sistema?

Essas perguntas parecem iguais, mas não são.

Uma atualização pode aparecer no histórico porque uma operação aconteceu e, posteriormente, ter sido substituída por uma cumulativa mais recente.

Também pode existir uma tentativa de instalação que terminou em falha ou reversão.

Por isso, não devemos depender de uma única ferramenta.

---

Etapa 1 — Descubra exatamente qual Windows está instalado

Comece pressionando:

Win + R

Digite:

winver

Anote:

• edição;
• versão;
• compilação do sistema operacional.

A build é uma das informações mais importantes de todo o diagnóstico.

Se estamos investigando uma atualização cumulativa, ela ajuda a determinar o nível atual de manutenção do Windows.

Não registre apenas:

Windows 11.

Registre algo como:

Windows 11 + versão + build completa.

---

Etapa 2 — Consulte o Histórico do Windows Update

Abra:

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

Procure a atualização.

Observe:

• título;
• número KB;
• categoria;
• data;
• status apresentado.

Não procure somente em uma categoria.

Dependendo do que estamos investigando, a atualização pode estar relacionada a:

• qualidade;
• driver;
• definição;
• outros componentes.

Anote o número KB quando existir.

---

Etapa 3 — Compare a build com a documentação oficial

Depois de descobrir a build com:

winver

compare-a com o histórico oficial da versão correspondente do Windows 11 publicado pela Microsoft.

Essa comparação ajuda a responder:

Qual atualização cumulativa corresponde à build atualmente instalada?

Essa etapa é extremamente importante quando o Histórico do Windows Update parece incompleto ou confuso.

---

Etapa 4 — Consulte Get-HotFix

Abra o PowerShell:

Get-HotFix

Para facilitar:

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20 HotFixID,Description,InstalledOn

Se você possui um KB específico:

Get-HotFix -Id KBXXXXXXX

Se ele aparecer, temos uma informação útil.

Se não aparecer, não conclua imediatamente que a atualização nunca foi instalada.

Lembre-se:

Get-HotFix possui um escopo específico.

Ele não representa todo tipo de atualização possível do Windows.

---

Etapa 5 — Consulte os pacotes do sistema

Agora execute:

DISM /Online /Get-Packages /Format:Table

Ou pelo PowerShell:

Get-WindowsPackage -Online

Para localizar os pacotes recentes:

Get-WindowsPackage -Online | Sort-Object InstallTime -Descending | Select-Object -First 20 PackageName,PackageState,ReleaseType,InstallTime

Agora estamos examinando os pacotes da imagem do Windows.

Essa consulta responde a uma pergunta diferente daquela feita por Get-HotFix.

---

Etapa 6 — Consulte o histórico da API do Windows Update

No PowerShell:

$Session = New-Object -ComObject Microsoft.Update.Session

Depois:

$Searcher = $Session.CreateUpdateSearcher()

Descubra a quantidade de entradas:

$Count = $Searcher.GetTotalHistoryCount()

Podemos consultar, por exemplo, as 50 entradas mais recentes:

$History = $Searcher.QueryHistory(0,[Math]::Min(50,$Count))

Depois:

$History | Select-Object Date,Title,Operation,ResultCode

Essa consulta ajuda a descobrir operações registradas pelo Windows Update.

Procure:

• título;
• KB;
• data;
• operação;
• resultado.

---

Etapa 7 — Monte uma linha do tempo

Ordene:

$History | Sort-Object Date | Select-Object Date,Title,Operation,ResultCode

Agora compare os horários com aquilo que o usuário observou.

Por exemplo:

18:40 — operação de atualização.

19:00 — solicitação de reinicialização.

19:10 — computador reinicia.

19:20 — usuário entra no Windows.

19:25 — problema começa.

Essa sequência não prova que a atualização causou o problema.

Mas fornece uma linha temporal para investigação.

---

Etapa 8 — Verifique o WindowsUpdateClient

Abra:

eventvwr.msc

Acesse:

Logs de Aplicativos e Serviços → Microsoft → Windows → WindowsUpdateClient → Operational

Ou use:

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 100 | Select-Object TimeCreated,Id,LevelDisplayName,Message

Procure eventos próximos ao horário da instalação.

O objetivo é descobrir se houve:

• atividade de atualização;
• sucesso;
• falha;
• outra operação relevante.

---

Etapa 9 — Gere o WindowsUpdate.log quando precisar aprofundar

Execute:

Get-WindowsUpdateLog

O Windows gera um arquivo legível a partir dos rastreamentos do Windows Update.

Esse arquivo pode conter muitas informações.

Não leia milhares de linhas aleatoriamente.

Use primeiro:

• data;
• horário;
• KB;
• código de erro;
• título da atualização.

Depois procure esses elementos no log.

---

Etapa 10 — Consulte CBS.log quando o problema estiver no servicing

O arquivo:

C:\Windows\Logs\CBS\CBS.log

pode ajudar quando precisamos investigar o processamento dos componentes do Windows.

Procure informações relacionadas ao mesmo período encontrado no Windows Update.

O CBS pode ajudar principalmente quando a atualização foi detectada e iniciada, mas algo parece ter dado errado durante o processamento dos componentes.

---

Como interpretar os resultados

Depois dessas verificações, podemos separar o caso em diferentes cenários.

Cenário 1 — Atualização instalada normalmente

Encontramos:

• entrada no Histórico;
• evento de sucesso;
• build correspondente;
• pacotes compatíveis com o estado esperado.

Nesse cenário, temos evidências fortes de instalação concluída.

---

Cenário 2 — Get-HotFix não mostra, mas outras fontes confirmam

Encontramos:

• atualização no Histórico;
• evento na API;
• build correspondente;
• pacote presente;

mas:

Get-HotFix

não mostra o KB.

Nesse caso, a ausência no Get-HotFix não é suficiente para afirmar que a atualização não foi instalada.

A limitação está na interpretação do comando.

---

Cenário 3 — Houve tentativa, mas a instalação falhou

Encontramos:

• eventos de tentativa;
• resultado de falha;
• build anterior ainda instalada;
• ausência do estado esperado.

Nesse caso, dizer:

“O Windows instalou a atualização”

seria impreciso.

O mais correto é:

“O Windows tentou instalar a atualização, mas a operação não foi concluída com sucesso.”

---

Cenário 4 — Possível rollback

Encontramos evidências de que:

• a atualização começou;
• houve reinicialização;
• ocorreram falhas durante o processo;
• o sistema voltou para a build anterior.

Nesse cenário, pode ter ocorrido uma reversão.

Os logs ajudam a confirmar o que aconteceu.

---

Cenário 5 — A atualização antiga foi substituída

Encontramos no histórico:

KB-A

Mas o sistema atualmente possui uma cumulativa mais nova:

KB-B

e uma build posterior.

Isso não significa automaticamente que as correções de KB-A desapareceram.

No modelo cumulativo, a atualização mais recente normalmente incorpora correções anteriores aplicáveis.

O histórico continua registrando que KB-A foi instalada em determinado momento.

O estado atual, porém, já está em outro nível.

---

Cenário 6 — Era um driver

O usuário diz:

“O Windows instalou uma atualização.”

Mas não encontra o KB esperado.

Ao consultar o Histórico, descobrimos que era uma:

atualização de driver.

Nesse caso, procurar apenas em Get-HotFix não responde corretamente à pergunta.

O tipo de atualização determina onde devemos investigar.

---

Cenário 7 — Era atualização do Microsoft Defender

Atualizações de inteligência de segurança do Defender também podem aparecer dentro da experiência do Windows Update.

Mas elas possuem ciclo de atualização muito mais frequente.

Podemos consultar o estado atual do Defender com:

Get-MpComputerStatus

e propriedades relacionadas às assinaturas.

Novamente:

“passou pelo Windows Update”

não significa:

“obrigatoriamente aparecerá como um hotfix tradicional.”

---

Cenário 8 — A atualização está pendente de reinicialização

Outro caso ocorre quando a instalação ainda não terminou.

O Windows pode ter preparado componentes, mas aguarda reinicialização.

Nesse cenário, não tire conclusões antes de concluir normalmente o ciclo da atualização.

Depois da reinicialização:

1. execute winver;
2. consulte novamente o Histórico;
3. execute as consultas PowerShell;
4. confira os pacotes.

Compare o antes e o depois.

---

Por que anotar a build antes de grandes atualizações é uma boa prática?

Para técnicos, esse hábito é extremamente útil.

Antes de iniciar uma manutenção:

winver

Anote a build.

Depois da atualização:

winver

novamente.

Assim temos uma evidência objetiva da mudança.

O mesmo vale para outros dados importantes.

Podemos registrar:

• build;
• KB atual;
• drivers relevantes;
• horário;
• sintomas existentes.

Isso facilita muito quando o cliente informa depois:

“Depois da atualização apareceu um problema.”

---

Não atribua qualquer problema ao Windows Update

Existe uma tendência natural de culpar a última mudança conhecida.

Se o computador atualizou ontem e hoje uma impressora falha, o usuário associa os acontecimentos.

Essa hipótese merece investigação.

Mas não representa prova.

No mesmo período também podem ter ocorrido:

• atualização de driver;
• atualização de aplicativo;
• atualização do navegador;
• mudança no antivírus;
• atualização do Office;
• alteração de rede;
• reinicialização que ativou uma configuração pendente.

Por isso, investigue a linha do tempo.

---

Antes de remover uma atualização, consulte problemas conhecidos

Depois de identificar:

versão + build + KB

consulte a documentação oficial da Microsoft.

Verifique se existe algum problema conhecido associado à atualização.

Isso é especialmente importante porque a Microsoft pode já ter:

• reconhecido o problema;
• publicado uma solução alternativa;
• disponibilizado correção;
• aplicado Known Issue Rollback;
• publicado uma atualização posterior.

Remover imediatamente uma atualização cumulativa pode retirar correções importantes sem solucionar a verdadeira causa.

---

Atualizações cumulativas mudaram o diagnóstico do Windows

Em versões antigas do Windows, muitos usuários criaram o hábito de pensar em cada KB como uma correção completamente isolada.

O modelo moderno de manutenção é muito mais cumulativo.

Por isso, precisamos prestar atenção ao:

estado atual da build

e não somente à presença visual de cada KB histórico.

Essa mudança de raciocínio evita muitas interpretações erradas.

---

A diferença fundamental: evento versus estado

Podemos resumir todo este artigo em dois conceitos.

Evento

Algo aconteceu.

Uma atualização:

• foi oferecida;
• baixada;
• instalada;
• falhou;
• foi removida;
• teve outra operação registrada.

O histórico ajuda a reconstruir eventos.

Estado

É aquilo que existe agora.

A build atual e os pacotes instalados ajudam a determinar o estado presente.

Um computador pode ter um histórico enorme de eventos e, ainda assim, possuir apenas um estado atual.

É exatamente por isso que duas ferramentas podem mostrar listas diferentes sem que uma esteja necessariamente errada.

---

Checklist rápido VMIA

Quando uma atualização aparentemente não aparece no histórico esperado, siga esta sequência:

1. Execute winver.

Registre versão e build.

2. Abra o Histórico do Windows Update.

Procure a atualização e sua categoria.

3. Identifique o KB, quando existir.

4. Compare a build com o histórico oficial da Microsoft.

5. Execute Get-HotFix.

Não trate a ausência como prova definitiva.

6. Execute Get-WindowsPackage -Online.

Confira os pacotes e seus estados.

7. Consulte a API Microsoft.Update.Session.

Reconstrua os eventos do Windows Update.

8. Consulte WindowsUpdateClient.

Observe principalmente a janela de tempo relevante.

9. Gere WindowsUpdate.log se precisar aprofundar.

10. Consulte CBS.log quando houver indícios de falha de servicing.

11. Compare novamente a build.

12. Consulte problemas conhecidos da Microsoft antes de remover qualquer atualização.

---

Conclusão: onde descobrir o que o Windows realmente instalou?

Não existe uma única tela que represente perfeitamente todos os tipos de atualização e todas as etapas do processo de manutenção do Windows 11.

Esse é o motivo pelo qual podemos encontrar informações aparentemente contraditórias.

O:

Get-HotFix

pode mostrar uma lista.

O Histórico do Windows Update pode mostrar outra.

O DISM pode revelar pacotes diferentes.

A API do Windows Update pode registrar eventos que não aparecem da mesma maneira nas outras fontes.

E nenhuma dessas diferenças significa automaticamente corrupção do sistema.

Cada ferramenta responde a uma pergunta diferente.

Se queremos descobrir o que aconteceu, devemos olhar para o histórico e para os eventos.

Se queremos descobrir o que existe agora, devemos verificar build e pacotes.

Para atualizações cumulativas, a build atual possui enorme importância porque permite relacionar o estado do computador ao histórico oficial de atualizações da Microsoft.

Portanto, quando alguém disser:

“O Windows instalou uma atualização, mas ela sumiu do histórico”

não comece removendo pacotes.

Primeiro descubra:

o que foi instalado;

quando;

qual foi o resultado;

qual build ficou instalada;

e qual pacote está presente agora.

Esse método transforma uma impressão vaga em um diagnóstico técnico verificável.

---

FAQ — Atualizações que não aparecem no histórico do Windows 11

Uma atualização pode estar instalada e não aparecer no Get-HotFix?

Sim.

Get-HotFix não representa um inventário universal de todos os tipos de atualização existentes no Windows.

Ele consulta informações dentro de um escopo específico.

Por isso, a ausência de determinado KB no resultado não prova sozinha que a atualização nunca foi instalada.

---

Como vejo as atualizações pelo PowerShell?

Uma opção é:

Get-HotFix

Para ordenar:

Get-HotFix | Sort-Object InstalledOn -Descending

Mas, dependendo do tipo de atualização, também podemos precisar de:

Get-WindowsPackage -Online

ou do histórico da API do Windows Update.

---

Como saber qual atualização cumulativa está instalada?

Primeiro execute:

winver

Anote a versão e a build.

Depois compare essa build com o histórico oficial da sua versão do Windows 11 publicado pela Microsoft.

Essa é uma das formas mais confiáveis de identificar o nível atual da atualização cumulativa.

---

Como listar os pacotes instalados no Windows?

Use:

DISM /Online /Get-Packages /Format:Table

Ou no PowerShell:

Get-WindowsPackage -Online

Essas ferramentas consultam os pacotes da imagem do Windows.

---

O que significa /Online no DISM?

Nesse contexto, /Online significa que o DISM trabalhará com o sistema operacional atualmente em execução.

Não significa que o comando obrigatoriamente precisa consultar a Internet.

---

Onde fica o WindowsUpdate.log?

Nas versões modernas do Windows, podemos gerar um arquivo legível usando:

Get-WindowsUpdateLog

O cmdlet reúne e converte informações dos rastreamentos do Windows Update para facilitar a análise.

---

Onde fica o CBS.log?

Normalmente em:

C:\Windows\Logs\CBS\CBS.log

Ele contém informações relacionadas ao Component-Based Servicing do Windows.

---

Histórico do Windows Update e CBS.log são a mesma coisa?

Não.

O Histórico apresenta operações de atualização de maneira amigável ao usuário.

O CBS.log registra atividades relacionadas ao mecanismo de servicing de componentes.

Eles podem participar da investigação do mesmo problema, mas possuem funções diferentes.

---

Uma atualização pode aparecer no histórico mesmo não estando mais instalada?

Sim.

Histórico e estado atual são conceitos diferentes.

O histórico pode registrar que uma operação ocorreu anteriormente.

Depois disso, uma atualização pode ter sido substituída, removida ou sucedida por outra cumulativa.

---

Se uma atualização cumulativa mais nova foi instalada, perdi as correções da anterior?

Normalmente não.

As atualizações cumulativas modernas incluem correções anteriores aplicáveis.

Por isso, uma cumulativa mais recente representa um nível de manutenção posterior.

---

Como saber se houve rollback?

Compare:

• build anterior;
• build atual;
• histórico;
• eventos do WindowsUpdateClient;
• histórico da API;
• registros de servicing.

Se a atualização tentou avançar a build, encontrou problemas e o sistema permaneceu ou retornou à build anterior, uma reversão passa a ser uma hipótese importante.

Os logs ajudam a confirmar.

---

Devo remover a atualização se um problema começou logo depois?

Não automaticamente.

Primeiro confirme qual atualização foi realmente instalada e procure problemas conhecidos documentados pela Microsoft.

A proximidade temporal entre atualização e defeito cria uma hipótese, mas não prova que a atualização causou o problema.

---

O Windows Update diz “Você está atualizado”, mas outro computador possui build diferente. Existe problema?

Não necessariamente.

Os computadores podem estar em versões diferentes ou sujeitos a condições diferentes de compatibilidade, políticas e distribuição de atualizações.

Compare primeiro a mesma versão do Windows e o contexto das duas máquinas.

---

Drivers aparecem no Get-HotFix?

Get-HotFix não deve ser usado como ferramenta universal para inventariar atualizações de drivers.

Verifique a categoria correspondente no Histórico do Windows Update e, quando necessário, investigue o driver diretamente.

---

Atualizações do Microsoft Defender aparecem como hotfix?

Não devemos presumir isso.

O Defender possui atualizações próprias, incluindo inteligência de segurança, plataforma e mecanismo.

Para investigar o Defender, use também as ferramentas específicas do produto.

---

Qual é a melhor ferramenta para descobrir uma atualização instalada?

Depende da pergunta.

Para uma investigação completa, combine:

winver

Histórico do Windows Update

Get-HotFix

Get-WindowsPackage

API do Windows Update

WindowsUpdateClient

WindowsUpdate.log

e, quando necessário:

CBS.log

A combinação das fontes fornece uma visão muito mais precisa do que qualquer uma isoladamente.

---

Precisa descobrir qual atualização alterou seu Windows?

Uma atualização que aparentemente desapareceu do histórico pode representar situações completamente diferentes: diferença entre ferramentas, atualização cumulativa substituída, instalação incompleta, rollback ou simplesmente um tipo diferente de atualização.

A VMIA – Manutenção e Configuração realiza diagnóstico de problemas do Windows 11, Windows Update, programas, drivers, desempenho, impressoras, redes e outros componentes do computador.

O atendimento pode ocorrer por acesso remoto, quando tecnicamente possível, ou por visita técnica agendada.

VMIA – Manutenção e Configuração

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

Telefone/WhatsApp: (11) 99779-7772

Site: https://vmia.site

Blog: https://vmia.com.br

Fontes e documentação

Para a produção deste artigo foram utilizadas principalmente documentações oficiais da Microsoft relacionadas ao Windows Update, PowerShell, DISM e manutenção de componentes do Windows.

Microsoft Learn — Get-HotFix
Documentação do cmdlet e de seu relacionamento com Win32_QuickFixEngineering.

Microsoft Learn — DISM Operating System Package Servicing Command-Line Options
Documentação das opções de consulta e manutenção de pacotes, incluindo /Get-Packages.

Microsoft Learn — Get-WindowsPackage
Documentação do cmdlet usado para consultar pacotes de uma imagem do Windows.

Microsoft Learn — Windows Update Agent API / QueryHistory
Documentação da API utilizada para consultar eventos do histórico do Windows Update.

Microsoft Learn — Get-WindowsUpdateLog
Documentação do cmdlet utilizado para converter rastreamentos do Windows Update em um arquivo de log legível.

Microsoft Learn — Windows Release Health
Documentação utilizada para relacionar versões, builds, atualizações e problemas conhecidos do Windows.

Como o Windows 11 recebe atualizações continuamente, números de build, KBs e problemas conhecidos mudam ao longo do tempo. Antes de remover uma atualização ou aplicar uma solução específica, confirme as informações na documentação atual da Microsoft.