Erro 1068 após KB5036899 no Windows Server 2016: causas, solução e prevenção

Após instalar a atualização cumulativa KB5036899 (abril) no Windows Server 2016, alguns ambientes relatam falhas em cadeia ao iniciar serviços com o “Erro 1068”. Este guia mostra como mitigar de imediato, diagnosticar a causa e prevenir recorrências com segurança.

Índice

Visão geral do problema

Ao aplicar a KB5036899 em servidores com Windows Server 2016 (versão 1607), diversos serviços podem deixar de iniciar e exibir a mensagem:

“Windows could not start the [Service Name] service on Local Computer. Error 1068: The dependency service or group failed to start.”

Ao desinstalar o patch, o ambiente volta ao normal. Isso indica que uma ou mais dependências não foram iniciadas com sucesso após a atualização e/ou reboot, ou que houve alteração de ordem de inicialização (race condition), credenciais de conta de serviço, permissões ou falha de algum componente base (por exemplo, filtragem/BFE, RPC, drivers de rede).

Mensagem-chave para quem está em produção

Mitigação imediata: desinstale a KB5036899 apenas nos hosts afetados e valide a retomada dos serviços.
Prevenção temporária: pause/controle a reinstalação até existir correção oficial ou validação em laboratório.
Diagnóstico: o Erro 1068 significa dependência ausente ou parada. Confirme dependências e status, inicie-as manualmente e então retente o serviço original.

O que significa o Erro 1068

O 1068 é emitido pelo Service Control Manager quando o serviço A não inicia porque depende do serviço B (ou de um grupo) que não está em execução. Em termos práticos, não é um erro do serviço principal, mas do encadeamento de dependências. Exemplos típicos:

Serviços que dependem de RPC, DCOM ou Base Filtering Engine (BFE) falham em cascata se um desses não subir.
Drivers/provedores de rede (Cluster, SMB, HTTP.sys, etc.) iniciam em ordem incorreta após um reboot e “atrasam” serviços de camada superior.
Conta de serviço com senha expirada ou sem “Fazer logon como serviço”.

Sintomas e evidências rápidas

Sintoma	Onde ver	O que procurar
Serviço X falha com Erro 1068	`services.msc` → Propriedades → Dependências	Lista de serviços/driver-base em “Este serviço depende…”.
Timeout ao iniciar	Event Viewer → Windows Logs → System	Service Control Manager IDs 7000–7003/7009/7011.
Falha em credenciais	`services.msc` → Logon	Conta de serviço e evento 7000 com “Logon failure”.
Rede/Firewall inativos	Serviços BFE/MpsSvc	BFE parado leva a firewall e dependentes inoperantes.

Mitigação imediata (produção)

1) Desinstalar a KB5036899 no(s) servidor(es) afetado(s)

cmd (elevado)
wusa /uninstall /kb:5036899 /quiet /norestart

Conclua com um reboot em janela de manutenção e valide o restabelecimento dos serviços. Alternativamente, via GUI: Painel de Controle → Programas e Recursos → Exibir atualizações instaladas → selecione KB5036899 → Desinstalar.

2) Prevenir reinstalação temporária

WSUS/SCCM: decline a KB nos grupos afetados ou pause o deployment.
Sem WSUS (standalone): use GPO para “Configurar Atualizações Automáticas” = 2 – Notificar para download e instalação (ou pausar temporariamente). Caminho: Configuração do Computador → Modelos Administrativos → Componentes do Windows → Windows Update.

Atenção: a KB pode conter correções críticas de segurança. Se optar por remover/pausar, reduza a superfície de ataque (isole serviços, limite portas, use WAF/VPN), acelere janelas de manutenção e planeje a reavaliação da atualização.

Diagnóstico estruturado do Erro 1068

Passo a passo essencial

Abrir services.msc, localizar o serviço que falha → Dependências → anotar cada item em “Este serviço depende…”.
Tentar iniciar manualmente as dependências em ordem (se uma falhar, pare e investigue essa falha primeiro).
Revisar Event Viewer → Windows Logs → System → filtrar por “Service Control Manager”. Registre os IDs 7000–7003/7009/7011 + mensagens.
Confirmar Logon do serviço: conta, senha, permissão “Fazer logon como serviço”. Se a senha foi trocada, atualizar e retentar.
Validar serviços de base: RPC, DCOM, BFE (Base Filtering Engine), Firewall do Windows (MpsSvc), Driver TCP/IP.
Se o incidente iniciou após a KB, repita o teste em laboratório (clone/VM) para reproduzir e identificar a dependência específica.

Comandos úteis (diagnóstico)

powershell
Listar dependências e status de um serviço
(Get-Service -Name 'NomeDoServico').ServicesDependedOn | Select-Object Name, Status

Tentar iniciar uma dependência específica

Start-Service -Name 'NomeDaDependencia'

Ver tudo que não está em Execução

Get-Service | Where-Object Status -ne 'Running' | Sort-Object Status, Name | Format-Table -Auto

Verificar ordem de inicialização e considerar 'delayed-auto' para mitigar corrida

sc.exe qc \
sc.exe config \ start= delayed-auto

cmd
Consultar rapidamente eventos de SCM por falha de dependência (executar como admin em hosts com PowerShell 5)
wevtutil qe System /q:"*[System[Provider[@Name='Service Control Manager'] and (EventID=7000 or EventID=7001 or EventID=7003 or EventID=7009 or EventID=7011)]]" /f:text /c:20

Rotas de desinstalação: linha de comando e DISM

A forma mais direta é com wusa (acima). Em cenários onde o WUSA recuse ou não liste o pacote, utilize o DISM:

cmd (elevado)
DISM /Online /Get-Packages | findstr /i 5036899

Identifique o nome exato do pacote (ex.: Package\for\RollupFix~~31bf3856ad364e35~~amd64~~14393.XXXX.Y.Z)

DISM /Online /Remove-Package /PackageName\:Package\for\RollupFix~~31bf3856ad364e35~~amd64~~14393.XXXX.Y.Z /NoRestart

Conclua com reboot controlado. Em farms ou clusters, faça em rolling e valide a saúde do serviço/role entre cada nó.

Bloqueio de reinstalação (temporário e seguro)

WSUS/SCCM

Criar um anel de implantação para “piloto/QA” e outro para “produção”.
No anel de produção, decline a KB5036899 até o teste em QA comprovar estabilidade.
Documentar critérios de “Go/No-Go” (tempo de boot, lista de serviços críticos, logs limpos por n horas).

Sem WSUS

GPO → “Configurar Atualizações Automáticas” = 2 (notificar). Opcionalmente defina “Selecionar quando as Atualizações de Qualidade são recebidas” para adiar por alguns dias, se disponível.
Evite ferramentas de ocultar updates de cliente em servidores críticos; prefira política centralizada e inventário.

Investigação aprofundada (laboratório ou pós-mitigação)

Mapeamento de dependências

Além do services.msc, use PowerShell para “caminhar” na árvore de dependências e registrar o primeiro ponto de falha:

powershell
param([string]$ServiceName = 'NomeDoServico')

function Test-ServiceChain {
param(\[System.ServiceProcess.ServiceController]\$svc)
foreach (\$dep in \$svc.ServicesDependedOn) {
if (\$dep.Status -ne 'Running') {
try {
Start-Service -Name \$dep.Name -ErrorAction Stop
Write-Host "Dependência iniciada: \$(\$dep.Name)"
} catch {
Write-Warning "Falhou iniciar dependência: \$(\$dep.Name) - \$($\_.Exception.Message)"
return \$dep.Name
}
}
}
return \$null
}

\$svc = Get-Service -Name \$ServiceName -ErrorAction Stop
\$bad = Test-ServiceChain -svc \$svc
if (\$bad -eq \$null) {
try {
Start-Service -Name \$ServiceName -ErrorAction Stop
Write-Host "Serviço \$ServiceName iniciado com sucesso."
} catch {
Write-Warning "Serviço \$ServiceName ainda falha: \$($\_.Exception.Message)"
}
} else {
Write-Warning "Cadeia interrompida em: \$bad"
}

Eventos do Service Control Manager (SCM)

ID	Significado	Ação sugerida
7000	Serviço não pôde iniciar	Ver dependências/logon; testar início manual; validar binário presente.
7001	Dependência falhou	Corrigir/ativar a dependência antes do serviço principal.
7003	Grupo de dependência não iniciou	Checar serviços do grupo (rede, drivers, firewall, etc.).
7009	Timeout de início	Aumentar timeout, usar “delayed-auto” ou otimizar inicialização.
7011	Timeout de resposta	Validar carga no boot; serviços pesados com atraso controlado.

Boas práticas para evitar recorrência

Testes por anéis: patch em “piloto” antes de “produção”.
Inventário de serviços críticos: lista validada (DNS, DHCP, AD DS, File, Print, IIS, SQL, RDS, serviços de aplicação).
Ordem de inicialização: aplicar delayed-auto em serviços de camada de aplicação que dependem de subsistemas pesados (disco, rede, firewall).
Contas de serviço: política de rotação de senha com secrets guardados; monitore “Logon como serviço”.
Backups e snapshot: para hosts virtualizados, snapshot pré-patch (curto prazo) e backup vértice (longo prazo).
Reboot único e ordenado: após atualizar, um reboot e aguarde estabilização, evitando reinicializações consecutivas que mascaram falhas.
Observabilidade: colete eventos do SCM e métricas de boot (CPU/IO) para correlacionar “race conditions”.

Checklists operacionais

Checklist de ação rápida

Desinstalar a KB5036899 no(s) host(s) afetado(s).
Impedir reinstalação (WSUS/SCCM ou GPO/pausa).
Revisar dependências dos serviços que falharam e iniciar as que estiverem paradas.
Registrar evidências (IDs de evento, serviços impactados) para futura correção.
Reavaliar a KB em lote piloto quando houver nova versão/correção.

Checklist de validação pós-reboot

Rede operacional (ping gateway, DNS resolve).
Serviços críticos Running; sem eventos 7000–7011 nos últimos 30 min.
Aplicações de negócio respondem (smoke test).
Métricas de boot dentro da normalidade (CPU/IO).
Backup/monitoramento reativado (se pausado).

Táticas para “race condition” no boot

Alguns serviços sobem antes de o subsistema de que dependem estar realmente pronto. Ajustes:

Configurar Inicialização Automática Atrasada para serviços de aplicação:

cmd
sc.exe config &lt;NomeDoServico&gt; start= delayed-auto

Aumentar (com critério) o timeout de inicialização via registro para serviços que demoram.
Postergar jobs pesados de inicialização (antivírus completo, inventário) para +5–10 min pós-boot.

Crédito de segurança: remover a KB não é o fim do trabalho

Se a atualização incluía correções de segurança, mitigue o risco enquanto a correção definitiva não chega:

Fechar portas não essenciais, aplicar regras de firewall por IP/porta.
Restringir exposição à internet (WAF, VPN, bastion/jump host).
Aumentar monitoramento (IDS/EDR), regras temporárias de SIEM para CVEs citadas no mês.

Exemplos de verificação por função (genéricos)

Função	Dependências comuns	Teste rápido
AD DS	RPC, Netlogon, DNS Client	`nltest /dsgetdc:dominio`; eventos 4624/4719 normais.
DNS Server	RPC, TCP/IP	`Resolve-DnsName` local/externo.
DHCP	BFE, RPC	Concessões novas surgem após reboot?
File/SMB	LanmanServer, TCP/IP	Acessar compartilhamento e medir latência.
IIS/Web	HTTP.sys, Windows Process Activation	`iisreset /status`; página de saúde responde.
SQL Server	SQL Server Agent, Shared Memory/TCP	Conectar via sqlcmd/SSMS localmente.

Modelos úteis (copiar e adaptar)

Runbook de contingência

1) Confirmar incidente: capturar mensagem 1068 e serviço afetado.
2) Determinar escopo: único host ou múltiplos? Funções críticas?
3) Decisão: janela de manutenção de emergência aprovada? (sim/não)
4) Mitigação: wusa /uninstall /kb:5036899 /quiet /norestart
5) Reboot controlado; validação smoke test (rede/serviços/app).
6) Bloqueio de reinstalação (WSUS/GPO).
7) Evidências: IDs 7000–7011, lista de serviços afetados, hora do evento.
8) Pós-incidente: laboratório para reproduzir e mapear dependências.
9) Plano de reintrodução: piloto, rollback documentado, comunicação.

Script para verificar e iniciar dependências em lote

powershell
$ServicesAlvo = @('Spooler','W32Time','Dnscache') # edite a lista
foreach ($s in $ServicesAlvo) {
  try {
    $svc = Get-Service -Name $s -ErrorAction Stop
    foreach ($dep in $svc.ServicesDependedOn) {
      if ($dep.Status -ne 'Running') {
        try {
          Start-Service -Name $dep.Name -ErrorAction Stop
          Write-Host "OK: $($dep.Name) iniciado."
        } catch {
          Write-Warning "Falha: $($dep.Name) - $($_.Exception.Message)"
        }
      }
    }
    if ($svc.Status -ne 'Running') {
      Start-Service -Name $svc.Name
      Write-Host "OK: $s iniciado."
    }
  } catch {
    Write-Warning "Serviço não encontrado: $s"
  }
}

FAQ (perguntas frequentes)

Posso simplesmente desinstalar e esquecer?
Não. Use a desinstalação como mitigação para restaurar o serviço, bloqueie reinstalação temporariamente e trate a causa (dependências e/ou conflito pós-patch). Planeje reintroduzir a atualização com controle.

Como provar que o problema foi a ordem de inicialização?
Colete eventos 7000–7011, tempos de boot, e compare o comportamento com e sem delayed-auto nos serviços de aplicação. Registros do Event Viewer e logs de aplicação ajudam a correlacionar.

E se o BFE/Firewall estiverem quebrados?
Restaurar o BFE é prioritário, pois muitos serviços dependem dele. Inicie BFE primeiro; se falhar, verifique integridade (SFC/DISM), políticas e drivers de filtro de terceiros.

Há problema conhecido público específico desta KB?
No relato que originou este guia, não havia confirmação oficial específica associada à KB5036899. Trate como incidente de dependência pós-update e valide em laboratório antes de reimplantar.

Boas práticas de qualidade e segurança no ciclo de patch

Janela e plano de rollback definidos por serviço/role.
Critérios de aprovação objetivos (zero 7000–7011 em 24h, KPIs de disponibilidade).
Comunicação clara com donos de aplicação (pré, durante, pós).
Inventário sempre atualizado de contas de serviço, senhas e dependências.

Resumo de bolso

O que está acontecendo? Erro 1068 pós-KB5036899 indica que dependências não iniciaram após o patch/reboot.

O que fazer agora? Remover a KB nos hosts afetados, bloquear reinstalação e reiniciar; checar services.msc → Dependências e iniciar manualmente; coletar eventos 7000–7011.

Como evitar de novo? Teste em anel piloto, ajuste serviços para delayed-auto quando fizer sentido, garanta credenciais válidas e monitore a ordem de inicialização.

Apêndice: comandos e caminhos de política

Item	Comando/Caminho	Uso
Desinstalar KB	`wusa /uninstall /kb:5036899 /quiet /norestart`	Mitigação imediata
Listar pacotes	`DISM /Online /Get-Packages \| findstr 5036899`	Localizar nome exato do pacote
Remover pacote	`DISM /Online /Remove-Package /PackageName:...`	Alternativa ao WUSA
Ver dependências	`(Get-Service 'Nome').ServicesDependedOn`	Diagnóstico do 1068
SCM Events	IDs 7000–7003/7009/7011	Determina causa-raiz
GPO Windows Update	Computador → Modelos Adm → Componentes do Windows → Windows Update	Notificar/pausar até correção
Delayed Auto Start	`sc.exe config <serviço> start= delayed-auto`	Mitigar corrida de inicialização

Conclusão

O Erro 1068 após a KB5036899 no Windows Server 2016 é um efeito de dependência que não iniciou — não necessariamente um defeito direto do seu serviço de negócio. Trate com uma sequência clara: mitigar (remover a KB e recuperar operação), prevenir (bloquear reinstalação controladamente), investigar (dependências, eventos, credenciais) e reintroduzir a atualização com governança de mudança. Esse método reduz impacto, encurta MTTR e mantém a postura de segurança sob controle.