Você liga o computador e percebe que determinado programa não funciona. Abre o console de Serviços do Windows, encontra o serviço responsável e descobre que ele está parado.

Então clica em:

Iniciar

e, surpreendentemente, o serviço começa a funcionar normalmente.

Você reinicia o computador.

O problema volta.

O serviço falha durante a inicialização, mas alguns segundos ou minutos depois pode ser iniciado manualmente sem apresentar erro.

Esse comportamento cria uma pista extremamente importante:

Talvez o serviço não esteja quebrado. Talvez ele esteja tentando iniciar cedo demais.

Esse é um tipo de problema muito diferente de um serviço que nunca consegue iniciar.

Podemos representar assim:

Windows inicia
      ↓
Serviço A tenta iniciar
      ↓
Dependência ainda indisponível
      ↓
Serviço A falha
      ↓
Windows termina de carregar
      ↓
Dependência fica disponível
      ↓
Usuário inicia Serviço A manualmente
      ↓
FUNCIONA

A diferença entre esses dois momentos é o centro do diagnóstico.

Neste guia da VMIA, vamos investigar como descobrir o que mudou entre a tentativa automática que falhou e a tentativa manual que funcionou, usando ferramentas como:

services.msc
sc.exe
Get-Service
Get-CimInstance
Event Viewer
Service Control Manager
Process Monitor
Autoruns
Task Scheduler
Test-NetConnection
Resolve-DnsName

O objetivo não será simplesmente configurar todos os serviços como Inicialização Automática (Atraso na Inicialização).

Primeiro precisamos descobrir o que o serviço estava esperando.

---

O sintoma mais importante: depois funciona

Considere dois problemas.

Cenário A — serviço sempre falha

boot
↓
serviço falha

iniciar manualmente
↓
serviço falha novamente

Nesse caso, podemos investigar:

configuração
executável
credenciais
permissões
arquivos
driver
dependência quebrada

Agora compare com:

Cenário B — falha apenas durante o boot

boot
↓
serviço falha

30 segundos depois
↓
iniciar manualmente
↓
funciona

Esse segundo comportamento sugere fortemente uma variável relacionada ao momento da inicialização.

---

O que pode não estar pronto?

Vários recursos podem mudar de estado durante os primeiros segundos do Windows.

Por exemplo:

rede
DNS
outro serviço
driver
volume
banco de dados
arquivo
certificado
dispositivo
credencial
interface de rede
servidor remoto

O serviço pode depender diretamente ou indiretamente de algum deles.

---

Dependência direta e dependência funcional não são a mesma coisa

Essa diferença é fundamental.

Um serviço pode declarar formalmente:

dependo do Serviço B

O Windows conhece essa relação.

Mas o programa também pode possuir uma dependência que não está formalmente registrada.

Por exemplo:

Serviço A
↓
abre banco em D:\Dados

ou:

Serviço A
↓
conecta servidor.interno

ou:

Serviço A
↓
espera adaptador de rede receber IP

O Service Control Manager pode não conhecer essa relação.

Para o Windows:

dependências formais satisfeitas

Mas para o aplicativo:

ambiente ainda não está pronto

É justamente aí que surgem alguns dos casos mais difíceis.

---

Não comece alterando o tipo de inicialização

É tentador abrir:

services.msc

e trocar:

Automático

por:

Automático (Atraso na Inicialização)

Isso pode até fazer o serviço funcionar.

Mas existe um problema:

Se você altera o timing antes de descobrir a causa, pode esconder a dependência verdadeira.

O atraso pode ser uma solução adequada em determinados cenários, mas primeiro deve existir um diagnóstico.

---

Primeira etapa: identifique corretamente o serviço

Abra:

Win + R

execute:

services.msc

Encontre o serviço problemático.

Registre:

Nome de exibição
Nome do serviço
Status
Tipo de inicialização
Conta utilizada
Caminho do executável

---

Nome de exibição não é necessariamente o nome do serviço

Um serviço pode aparecer na interface como:

Sistema de Backup Empresa

mas possuir nome interno:

BackupSvc

Para comandos, o nome interno é frequentemente o mais importante.

---

Descubra pelo PowerShell

Execute:

Get-Service

Para um serviço específico:

Get-Service -Name "BackupSvc"

Você pode observar:

Status
Name
DisplayName

---

Consulte detalhes pelo CIM

Use:

Get-CimInstance Win32_Service |
Where-Object Name -eq "BackupSvc"

Isso pode fornecer informações adicionais, como:

Name
DisplayName
State
StartMode
StartName
PathName
ProcessId

---

O PathName merece atenção

Imagine:

"C:\Program Files\Empresa\BackupService.exe"

Agora sabemos qual executável realmente representa o serviço.

Isso será importante quando chegarmos ao:

Process Monitor

---

Descubra a conta utilizada pelo serviço

No services.msc, abra as propriedades e examine:

Logon

O serviço pode executar como:

LocalSystem
LocalService
NetworkService
conta específica

Isso importa muito.

---

“Funciona para mim” não significa “funciona para o serviço”

Você abre manualmente:

\\SERVIDOR\Dados

e funciona.

Mas o serviço executa como:

LocalSystem

O contexto é diferente.

Credenciais, perfil, unidades mapeadas e permissões podem ser diferentes.

---

Unidade Z: é um exemplo clássico

O usuário possui:

Z: → \\SERVIDOR\Backup

e um programa consegue acessar:

Z:\Arquivos

Mas um serviço não deve ser presumido como tendo a mesma unidade mapeada disponível na sessão dele.

Se a configuração do serviço depende de:

Z:\Backup

investigue isso.

---

Prefira entender o recurso real

O caminho pode representar:

\\SERVIDOR\Backup

Mas mesmo usar UNC não resolve automaticamente questões de:

credenciais
permissões
rede
DNS
timing

---

Agora reproduza o problema corretamente

Faça um teste controlado.

Teste 1

Reinicie o computador.

Não inicie o serviço manualmente.

Depois que o Windows carregar, abra:

services.msc

e registre:

Status = Parado

---

Registre o horário

Anote aproximadamente:

Windows iniciado: 10:20
serviço encontrado parado: 10:21

Depois vamos procurar eventos nesse período.

---

Tente iniciar manualmente

Clique em:

Iniciar

ou use PowerShell:

Start-Service -Name "BackupSvc"

---

Se funcionar, registre

10:22:15
Start-Service
Resultado: sucesso

Temos agora dois estados:

BOOT → falhou

MANUAL → funcionou

Nossa pergunta é:

O que estava diferente entre esses dois momentos?

---

Não reinicie imediatamente

Esse é um erro comum.

Quando o serviço falha durante o boot, o computador está no estado que precisamos investigar.

Não destrua essa evidência reiniciando repetidamente sem coletar dados.

---

Consulte o Service Control Manager

Abra:

eventvwr.msc

Vá para:

Logs do Windows
→ Sistema

Procure eventos cuja origem esteja relacionada a:

Service Control Manager

no horário da inicialização.

---

Não procure somente eventos vermelhos

Analise:

Information
Warning
Error
Critical

A sequência temporal é muito importante.

---

Registre o Event ID e a mensagem

Exemplo conceitual:

10:20:31
Service Control Manager
Event ID: XXXX
Serviço BackupSvc...

Copie a mensagem completa para análise.

Não pesquise apenas:

Event ID XXXX

porque o contexto importa.

---

Erro 1053 é um exemplo conhecido

Um serviço pode apresentar mensagem semelhante a:

The service did not respond to the start or control request in a timely fashion

Mas isso ainda não diz por que ele não respondeu a tempo.

O timeout é consequência.

Precisamos encontrar a operação que demorou.

---

Erro 1068 aponta para dependência

Outro cenário possível envolve falha na inicialização de um serviço ou grupo de dependência.

Nesse caso, investigue a cadeia de dependências.

Não tente simplesmente iniciar o serviço final repetidamente.

---

Use sc.exe

No Prompt de Comando:

sc query BackupSvc

Isso mostra o estado atual.

---

Consulte configuração

sc qc BackupSvc

Esse comando é particularmente útil.

Você pode encontrar informações como:

TYPE
START_TYPE
ERROR_CONTROL
BINARY_PATH_NAME
DEPENDENCIES
SERVICE_START_NAME

---

Observe DEPENDENCIES

Exemplo:

DEPENDENCIES : Tcpip

ou outro serviço/grupo.

Agora temos uma relação formal.

---

Use PowerShell para dependências

Você também pode consultar:

Get-Service -Name "BackupSvc" -RequiredServices

Isso mostra serviços exigidos pelo serviço analisado.

---

E quem depende dele?

Use:

Get-Service -Name "BackupSvc" -DependentServices

Agora conseguimos distinguir:

o que ele precisa

de:

quem precisa dele

---

Dependência em Running não encerra a investigação

Imagine:

Serviço B = Running

Isso não prova que tudo que B fornece já está completamente pronto para o Serviço A.

Esse detalhe será importante em problemas de timing.

---

Running não significa “recurso funcional”

Um serviço de rede pode estar iniciado enquanto:

DHCP ainda negocia endereço
DNS ainda não resolve recurso
Wi-Fi ainda conecta
VPN ainda não está pronta

Portanto:

serviço necessário está Running

não significa necessariamente:

ambiente está pronto

---

Faça um teste de tempo

Depois de reiniciar, experimente:

imediatamente → Start-Service

e registre o resultado.

Depois faça outro boot e espere:

30 segundos

antes de iniciar.

Outro:

60 segundos

---

Monte uma tabela

Momento	Resultado
Durante o boot	Falha
5 s após desktop	Falha
20 s após desktop	Falha
40 s após desktop	Funciona
60 s após desktop	Funciona

Esse padrão é extremamente valioso.

Ele sugere que alguma condição fica disponível aproximadamente entre:

20 e 40 segundos

---

Agora descubra o que muda nesse intervalo

Pode ser:

IP recebido
DNS funcionando
servidor acessível
volume montado
outro serviço pronto
banco liberado
driver inicializado
VPN conectada

---

Rede é uma suspeita comum, mas não automática

Se o serviço utiliza rede, verifique o estado da máquina logo depois do boot.

Execute:

ipconfig /all

Observe:

IPv4
gateway
DNS
DHCP
adaptador

---

Um endereço APIPA é uma pista

Se você encontrar algo na faixa:

169.254.x.x

quando deveria existir endereço fornecido pela rede, o adaptador pode não ter recebido uma configuração IPv4 adequada naquele momento.

Isso pode afetar serviços que dependem de rede.

---

Mas não espere encontrar APIPA sempre

A rede pode receber IP rapidamente e ainda existir atraso em:

DNS
rota
servidor
autenticação

---

Teste o servidor necessário

Se o serviço depende de:

SERVIDOR-ARQUIVOS

execute:

Test-NetConnection SERVIDOR-ARQUIVOS -Port 445

quando SMB for realmente o recurso utilizado.

---

Teste logo após o boot

O momento do teste importa.

Queremos comparar:

5 segundos após desktop

com:

60 segundos após desktop

---

DNS também pode mudar o resultado

Use:

Resolve-DnsName SERVIDOR-ARQUIVOS

Se falha imediatamente após o boot e funciona depois, temos uma pista importante.

---

Teste pelo nome e pelo IP apenas para diagnóstico

Imagine:

servidor pelo IP → responde
servidor pelo nome → falha

Isso direciona a investigação para resolução de nomes.

Não transforme endereços IP fixos colocados dentro do programa em solução automática.

---

Wi-Fi pode tornar o timing mais evidente

Em alguns computadores:

Windows inicia
↓
serviço tenta iniciar
↓
Wi-Fi ainda estabelece conectividade
↓
serviço falha

Depois:

Wi-Fi conectado
↓
Start-Service
↓
funciona

Esse padrão merece investigação.

---

Compare com Ethernet

Quando possível:

Wi-Fi
versus
Ethernet

Se:

Wi-Fi → falha no boot
Ethernet → funciona

a hipótese de timing da conectividade ganha força.

---

Isso não prova defeito no Wi-Fi

Pode envolver:

driver
autenticação
DHCP
DNS
perfil
tempo de associação

---

Serviço pode depender de banco de dados

Exemplo:

AplicacaoSvc
↓
BancoDadosSvc

O banco aparece como iniciado, mas ainda está:

abrindo arquivos
recuperando transação
carregando banco

O aplicativo tenta conectar cedo demais e falha.

Minutos depois, inicia manualmente.

---

Dependência formal resolveria tudo?

Não necessariamente.

Se o serviço de banco passa para Running antes de estar completamente pronto para aceitar a operação que o cliente necessita, uma dependência formal pode não eliminar a condição de corrida.

---

O aplicativo deveria lidar com isso?

Um serviço bem projetado pode implementar:

retry
backoff
tratamento de falha temporária

em vez de encerrar permanentemente na primeira tentativa.

Mas nem todos fazem isso.

---

Retry é diferente de aumentar timeout

Imagine:

tentativa
↓
falha
↓
espera
↓
nova tentativa

Isso é diferente de:

uma única tentativa esperando 2 minutos

Entender o comportamento ajuda a escolher a correção.

---

Serviço pode depender de volume

Exemplo:

D:\Banco\Dados.db

Se o volume não está disponível no momento esperado, o serviço pode falhar.

Depois que o Windows termina de montar ou disponibilizar o recurso:

Start-Service

funciona.

---

Verifique o caminho real

No ProcMon, mais adiante, poderemos descobrir tentativas como:

D:\Dados
PATH NOT FOUND

durante a falha.

Esse tipo de evidência é muito mais útil do que simplesmente configurar atraso de 60 segundos.

---

Serviço pode depender de dispositivo

Um serviço de:

scanner
impressora
licença USB
backup
hardware específico

pode precisar que determinado dispositivo PnP esteja disponível.

Se o hardware ainda está sendo enumerado, a primeira tentativa pode falhar.

---

Consulte dispositivos problemáticos quando houver relação

PowerShell:

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

Use isso apenas quando houver uma hipótese envolvendo hardware.

---

Não transforme PnP em suspeito universal

Se o serviço é puramente de software e não usa dispositivo, não existe motivo para começar pelos drivers USB.

---

Conta do serviço também pode criar diferença temporal

Um serviço executado sob conta específica pode depender de:

credencial
senha
domínio
rede
permissão

Se a conta não consegue autenticar, o Event Viewer pode fornecer pistas.

---

“Logon as a service”

Contas usadas por serviços precisam do contexto e dos direitos apropriados.

Mudanças de política podem interferir.

Mas se o serviço funciona manualmente usando a mesma configuração depois, o timing ainda merece atenção.

---

Não troque o serviço para LocalSystem por tentativa

Isso pode:

alterar permissões
aumentar privilégios
quebrar acesso de rede
criar risco de segurança

A conta deve ser escolhida conforme o projeto do aplicativo.

---

Verifique se o serviço realmente morreu

Depois do boot:

Get-Service -Name "BackupSvc"

Pode mostrar:

Stopped

Mas também existe outro cenário:

Running

e o aplicativo continua sem funcionar.

---

Running mas não funcional é outro diagnóstico

Nesse caso:

serviço iniciou

mas talvez:

subcomponente falhou
porta não abriu
banco não conectou
worker morreu

Não confunda isso com “serviço não iniciou”.

---

Verifique o PID

Get-CimInstance Win32_Service |
Where-Object Name -eq "BackupSvc" |
Select-Object Name, State, ProcessId

Se existe PID, podemos investigar o processo correspondente.

---

Relacione com Get-Process

Get-Process -Id 1234

substituindo pelo PID observado.

---

Serviço hospedado em svchost.exe exige mais cuidado

Vários serviços do Windows podem usar processos hospedeiros.

Não finalize:

svchost.exe

aleatoriamente.

Isso pode interromper vários componentes.

---

Consulte serviços e PID

Você pode usar:

tasklist /svc

para relacionar processos e serviços.

---

Não mate o processo como primeira correção

Nosso objetivo é descobrir por que a inicialização falhou, não forçar estados diferentes.

---

Autoruns também mostra serviços

A ferramenta Autoruns possui uma área dedicada a serviços.

Ela pode ajudar a visualizar:

serviços de terceiros
editor
caminho
assinatura

---

Cuidado com serviços desconhecidos

“Não reconheço esse nome” não significa:

malware

Pode ser componente de:

driver
impressora
VPN
backup
fabricante
software instalado

Identifique antes de alterar.

---

Assinatura digital ajuda

No Process Explorer ou Autoruns, verifique:

Publisher
Verified Signer

quando disponível.

Isso ajuda a identificar o fabricante responsável pelo componente.

---

Monte a primeira linha do tempo

Exemplo:

10:20:00 Windows inicia
10:20:12 Serviço A tenta iniciar
10:20:13 Serviço A falha
10:20:19 Wi-Fi conecta
10:20:24 DHCP concluído
10:20:27 DNS resolve servidor
10:20:31 Servidor responde
10:20:40 Start-Service A
10:20:41 Serviço A funciona

Agora existe uma hipótese concreta:

O Serviço A está tentando usar um recurso de rede antes que a conectividade necessária esteja disponível.

---

Outro exemplo: banco de dados

08:10:12 BancoSvc inicia
08:10:13 AplicacaoSvc inicia
08:10:14 AplicacaoSvc falha
08:10:26 Banco termina recuperação
08:10:30 AplicacaoSvc iniciado manualmente
08:10:31 funciona

A pergunta passa a ser:

O estado Running do banco ocorre antes de ele estar pronto para atender a aplicação?

---

Outro exemplo: armazenamento

09:00:10 Serviço inicia
09:00:11 procura D:\Dados
09:00:11 caminho indisponível
09:00:12 serviço encerra
09:00:25 volume fica disponível
09:00:40 serviço manual funciona

Agora sabemos onde investigar.

---

O padrão é mais importante que o erro isolado

Nos três exemplos:

serviço funciona depois

porque algo mudou.

Essa mudança é a pista.

---

Primeira matriz de diagnóstico

Resultado	Direção principal
Nunca inicia	Configuração, executável, conta, arquivos
Só inicia depois	Timing/dependência
Funciona após rede conectar	Rede/DNS/DHCP/servidor
Funciona após outro serviço	Dependência
Funciona após volume aparecer	Armazenamento
Funciona após dispositivo aparecer	PnP/driver
Só falha com uma conta	Credenciais/permissões
Status Running, mas app falha	Subcomponente/porta/recurso
Delayed Start resolve	Forte pista de timing, não causa final
Falha aleatoriamente	Condição de corrida/intermitência

---

O que não fazer nesta etapa

Evite:

aumentar todos os timeouts
colocar tudo como Delayed Start
mudar conta para LocalSystem
desativar serviços do Windows
reinstalar Windows
alterar Registro aleatoriamente

Essas ações podem mascarar o problema.

---

A pergunta mais importante da Parte 1

Se o serviço falha às:

10:20:13

e funciona às:

10:20:40

pergunte:

O que ficou disponível nesses 27 segundos?

Pode ser exatamente a resposta que precisamos.

---

Checklist

[ ] Identifiquei o nome real do serviço
[ ] Registrei DisplayName e Name
[ ] Consultei PathName
[ ] Consultei a conta do serviço
[ ] Consultei StartMode
[ ] Reiniciei e reproduzi a falha
[ ] Registrei o horário
[ ] Confirmei que Start-Service funciona depois
[ ] Analisei Service Control Manager
[ ] Registrei Event ID e mensagem
[ ] Executei sc qc
[ ] Consultei dependências
[ ] Testei diferentes momentos após o boot
[ ] Verifiquei se depende de rede
[ ] Testei DNS quando aplicável
[ ] Testei servidor/porta quando aplicável
[ ] Considerei volume
[ ] Considerei dispositivo quando aplicável
[ ] Não alterei vários parâmetros
[ ] Montei uma linha do tempo

O principal aprendizado

Quando um serviço falha durante a inicialização do Windows 11, mas funciona perfeitamente quando você o inicia manualmente pouco depois, essa diferença é uma evidência valiosa.

Em vez de perguntar apenas:

“Por que o serviço falhou?”

pergunte:

“O que ainda não estava disponível quando ele tentou iniciar?”

A resposta pode estar em:

dependência
rede
DNS
servidor
volume
driver
dispositivo
banco de dados
credencial

Service Control Manager, dependências, Delayed Start e erros 1053/1068: descobrindo o que ficou pronto tarde demais

Na Parte 1, estabelecemos uma regra importante:

Se o serviço falha durante o boot, mas funciona manualmente pouco depois, a diferença entre esses dois momentos precisa ser investigada.

Agora vamos aprofundar essa diferença.

O Windows não inicia todos os serviços simplesmente em uma sequência fixa do tipo:

Serviço A
↓
Serviço B
↓
Serviço C
↓
Serviço D

Existem dependências, grupos, tipos de inicialização e componentes que podem trabalhar simultaneamente.

Além disso, um serviço pode entrar no estado:

Running

antes que o recurso do qual outro programa depende esteja realmente pronto.

Essa diferença entre “serviço iniciado” e “recurso funcional” explica muitos problemas que parecem misteriosos.

---

O que é o Service Control Manager?

O Windows utiliza o Service Control Manager, frequentemente abreviado como SCM, para gerenciar serviços.

Ele participa de operações como:

registrar serviços
iniciar
parar
consultar estado
controlar dependências
aplicar configuração de inicialização

Quando usamos:

services.msc

estamos trabalhando com uma interface gráfica para esse ecossistema.

---

O SCM conhece tudo que um serviço precisa?

Não.

Esse é um ponto fundamental.

O SCM conhece dependências formalmente declaradas.

Por exemplo:

AplicacaoSvc
depende de
BancoSvc

Se essa relação estiver registrada corretamente, o Windows pode considerar a ordem necessária.

Mas imagine que AplicacaoSvc também precisa de:

\\SERVIDOR\Dados

e essa dependência não está declarada como serviço.

O SCM não consegue simplesmente adivinhar:

AplicacaoSvc precisa que esse servidor esteja acessível

---

Dependência formal versus dependência funcional

Podemos dividir assim:

Dependência formal

Serviço A
↓
Serviço B

registrada na configuração do serviço.

Dependência funcional

Serviço A
↓
DNS
↓
rede
↓
servidor
↓
banco remoto

O aplicativo precisa disso para funcionar, mas o SCM pode não conhecer toda essa cadeia.

---

Consulte novamente com sc qc

Execute:

sc qc NomeDoServico

Exemplo:

sc qc BackupSvc

Observe principalmente:

START_TYPE
BINARY_PATH_NAME
DEPENDENCIES
SERVICE_START_NAME

---

O que START_TYPE informa?

Ele mostra como o serviço foi configurado para iniciar.

Os tipos variam conforme o serviço e a configuração.

No console gráfico, normalmente encontramos opções como:

Automático
Automático (Atraso na Inicialização)
Manual
Desabilitado

---

Automático não significa “primeiro”

Um serviço configurado como:

Automatic

não deve ser interpretado como:

será iniciado antes de absolutamente tudo

A inicialização envolve vários componentes e dependências.

---

Manual também não significa “usuário precisa clicar”

Esse detalhe costuma confundir.

Um serviço configurado como:

Manual

pode ser iniciado quando algum componente solicita sua execução.

Portanto, Manual não significa necessariamente que ele nunca inicia sozinho.

---

E o Automatic (Delayed Start)?

O modo:

Automatic (Delayed Start)

faz o serviço automático iniciar posteriormente em relação à fase inicial dos serviços automáticos.

Isso pode ajudar em cenários de timing.

Mas existe uma regra importante:

Delayed Start não deve ser usado como explicação da causa.

Se ele resolve, descobrimos algo importante:

iniciar mais tarde muda o resultado

Agora precisamos descobrir por quê.

---

Delayed Start como teste diagnóstico

Imagine:

Automatic
→ falha em todos os boots

Você testa:

Automatic (Delayed Start)
→ funciona em todos os boots

Essa comparação é muito valiosa.

Ela indica que alguma condição necessária provavelmente fica disponível entre os dois momentos.

---

O que pode ficar disponível nesse intervalo?

Por exemplo:

rede
DNS
DHCP
VPN
outro serviço
volume
driver
hardware
banco
arquivo

---

Não deixe Delayed Start como solução sem investigar

Em alguns ambientes, usar atraso pode ser perfeitamente aceitável.

Mas imagine que o verdadeiro problema seja:

DNS demora 45 segundos por configuração incorreta

Atrasar o serviço apenas mascara o defeito.

---

Como verificar se Delayed Start está configurado?

Além do console gráfico, informações do serviço podem ser consultadas com ferramentas do Windows.

PowerShell:

Get-CimInstance Win32_Service |
Where-Object Name -eq "BackupSvc" |
Select-Object Name, State, StartMode, StartName, PathName

Para detalhes específicos que não aparecem diretamente nessa saída, complemente com sc.exe e a configuração do Registro apenas quando necessário.

---

Não edite o Registro primeiro

Os serviços possuem configuração no Registro, mas modificar diretamente essas chaves sem entender o SCM pode causar falhas sérias.

Prefira:

services.msc
sc.exe
PowerShell

quando houver uma interface suportada para a alteração necessária.

---

Dependências declaradas

Execute:

Get-Service -Name "BackupSvc" -RequiredServices

Imagine o resultado:

LanmanWorkstation

Agora sabemos que o serviço possui uma dependência formal.

---

Consulte o estado da dependência

Get-Service -Name "LanmanWorkstation"

Observe:

Status
StartType

---

Faça isso durante o período problemático

Executar o comando cinco minutos depois do boot pode mostrar:

Running

mas não responder à pergunta:

Qual era o estado no momento em que o serviço falhou?

Precisamos reconstruir o timing.

---

Event Viewer ajuda a reconstruir a ordem

Abra:

eventvwr.msc

e vá para:

Windows Logs
→ System

Filtre pelo horário do boot.

---

Service Control Manager

Procure eventos cuja origem seja:

Service Control Manager

Agora organize mentalmente:

serviço B inicia
↓
serviço A tenta iniciar
↓
serviço A falha

---

Exporte os eventos quando necessário

Para casos mais complexos, salvar os eventos relevantes ajuda a comparar:

BOOT RUIM
versus
BOOT BOM

Essa comparação será importante.

---

Erro 1053: o serviço não respondeu a tempo

Um dos erros conhecidos relacionados à inicialização de serviços é o 1053.

A mensagem normalmente indica que o serviço não respondeu à solicitação de inicialização ou controle dentro do período esperado.

Isso não significa automaticamente:

Windows precisa de timeout maior

---

O erro 1053 é frequentemente uma consequência

Pergunte:

o processo iniciou?
travou onde?
esperou rede?
esperou arquivo?
esperou banco?
esperou outro serviço?

Aumentar timeout sem responder a essas perguntas pode apenas prolongar a espera.

---

Serviço pode ficar preso durante inicialização

Conceitualmente:

SCM
↓
Start Service
↓
processo inicia
↓
abre configuração
↓
tenta servidor
↓
espera
↓
SCM continua aguardando
↓
timeout

O problema verdadeiro pode estar na tentativa de acessar o servidor.

---

Como confirmar?

É aqui que mais tarde entra o Process Monitor.

Podemos descobrir que:

BackupService.exe

foi iniciado e imediatamente começou a tentar:

\\SERVIDOR\Backup

---

Não aumente ServicesPipeTimeout por padrão

Existem recomendações na Internet que sugerem alterar valores de timeout de serviços no Registro.

Isso não deve ser a primeira resposta.

Se um serviço deveria iniciar em 5 segundos, mas demora 90 porque tenta um recurso inexistente, aumentar o timeout para 180 segundos não corrige o recurso inexistente.

---

Erro 1068: serviço ou grupo de dependência falhou

Outro erro importante é o 1068.

Aqui a pergunta principal é:

Qual dependência falhou primeiro?

Não concentre toda a investigação no serviço final.

---

Exemplo

AplicacaoSvc
↓ depende de
BancoSvc
↓ depende de
ArmazenamentoSvc

Se:

ArmazenamentoSvc

falha, o erro visto em AplicacaoSvc pode ser apenas consequência.

---

Caminhe de baixo para cima

Em vez de:

AplicacaoSvc não inicia

faça:

qual dependência direta?
↓
ela iniciou?
↓
se não, de que depende?

até chegar à primeira falha.

---

sc queryex

Você também pode consultar informações ampliadas:

sc queryex BackupSvc

Dependendo do estado, isso pode mostrar o PID associado ao serviço.

---

PID é muito útil

Se o serviço está:

START_PENDING

e existe um PID, podemos descobrir qual processo está preso durante a inicialização.

---

Consulte pelo Process Explorer

Abra o Process Explorer e localize o PID.

Agora podemos observar:

processo
threads
CPU
handles
I/O

---

CPU alta versus CPU baixa

Se o processo está usando:

100% de um núcleo

durante a inicialização, ele pode estar processando algo intensivamente.

Se:

CPU ≈ 0%

mas permanece em START_PENDING, ele pode estar esperando algum recurso.

---

Espera é uma pista

Pode ser:

rede
arquivo
outro processo
evento
mutex
driver

---

Wait Chain

Em determinados cenários, ferramentas do Windows e o Process Explorer podem ajudar a analisar cadeias de espera.

Isso pode revelar uma thread aguardando outra operação.

Mas não espere que toda falha de serviço apareça claramente em uma Wait Chain.

---

Dependência pode ser um arquivo

Imagine:

C:\ProgramData\Empresa\Config.db

O serviço precisa desse arquivo.

Durante o boot:

arquivo bloqueado

ou outro processo ainda está trabalhando nele.

Depois:

bloqueio liberado
↓
Start-Service funciona

---

Como detectar?

O Process Monitor pode mostrar resultados como:

SHARING VIOLATION
ACCESS DENIED
NAME NOT FOUND
PATH NOT FOUND

quando relevantes.

---

Nem todo SHARING VIOLATION é a causa

A mesma regra do diagnóstico de arquivos se aplica:

resultado isolado ≠ causa

Procure:

repetição
timing
mesmo arquivo
mesmo processo

---

Dependência pode ser uma porta TCP

Imagine um serviço que depende de banco remoto:

Servidor SQL
porta específica

O serviço inicia cedo demais.

A rede ainda não consegue alcançar o servidor.

---

Test-NetConnection

Se souber a porta correta usada pela aplicação:

Test-NetConnection SERVIDOR -Port PORTA

Substitua PORTA pela porta realmente configurada para o serviço.

---

Não adivinhe a porta

Consulte:

documentação
configuração
logs do programa

---

Teste em dois momentos

Por exemplo:

5 s após desktop → TcpTestSucceeded False
45 s após desktop → TcpTestSucceeded True

Esse resultado é muito mais interessante do que um teste realizado dez minutos depois.

---

Dependência pode ser DNS

Faça:

Resolve-DnsName servidor.exemplo

no momento mais próximo possível da falha.

Depois repita quando o serviço consegue iniciar.

---

Compare tempos

BOOT:
Resolve-DnsName → falha/demora

DEPOIS:
Resolve-DnsName → imediato

Temos uma diferença mensurável.

---

Dependência pode ser DHCP

Use:

ipconfig /all

ou PowerShell:

Get-NetIPConfiguration

Observe se o adaptador já possui a configuração esperada.

---

Gateway também importa

Um computador pode possuir endereço IP, mas ainda não alcançar o destino necessário.

Teste:

IP
gateway
DNS
rota
destino

como etapas separadas.

---

Use Get-NetRoute quando necessário

PowerShell:

Get-NetRoute

Se o problema depende de rede específica ou VPN, a tabela de rotas pode explicar por que o recurso ainda não está alcançável.

---

VPN cria um caso especial

Imagine:

Windows inicia
↓
AplicacaoSvc inicia
↓
servidor corporativo indisponível
↓
AplicacaoSvc falha
↓
VPN conecta
↓
servidor fica acessível
↓
Start-Service funciona

Aqui o problema não é necessariamente o serviço nem a Internet.

É uma dependência arquitetural:

AplicacaoSvc precisa da VPN

---

Delayed Start pode mascarar isso

Se a VPN geralmente conecta em 30 segundos e você atrasa o serviço em 60, parece resolvido.

Mas em um dia em que a VPN leva 90 segundos:

problema volta

Por isso, atraso fixo nem sempre representa solução robusta.

---

Retry pode ser melhor arquiteturalmente

Quando o software suporta:

retry
reconnect
backoff

ele pode lidar melhor com recursos temporariamente indisponíveis.

Isso depende do aplicativo.

---

Não invente dependências no SCM

Adicionar manualmente uma dependência formal que o fabricante não documentou pode criar novos problemas.

Por exemplo:

Serviço A depende de Serviço B

parece lógico, mas pode não representar a arquitetura real.

---

Consulte a documentação do software

Para serviços de terceiros, descubra:

dependências suportadas
requisitos
conta recomendada
ordem de inicialização
parâmetros
logs

antes de alterar a configuração.

---

Logs próprios do aplicativo podem ser melhores que Event Viewer

Procure em locais documentados pelo fabricante, que podem incluir:

ProgramData
pasta do programa
AppData
Event Viewer

---

Procure timestamps

Imagine:

10:20:13 ERROR Cannot connect database

e depois:

10:20:40 Connection established

Essa evidência pode praticamente explicar o comportamento.

---

Não ignore os segundos

Para problemas de timing, horários como:

10:20:13
10:20:14
10:20:15

são mais úteis que apenas:

“aconteceu de manhã”

---

Use PowerShell para criar uma fotografia dos serviços

Você pode executar:

Get-Service |
Sort-Object Status, Name |
Format-Table Status, Name, DisplayName

logo após o boot.

Depois compare com uma captura feita quando tudo funciona.

---

Para o serviço específico

Get-CimInstance Win32_Service |
Where-Object Name -eq "BackupSvc" |
Select-Object Name, State, Status, StartMode, StartName, ProcessId, PathName

---

Fotografe também a rede

Get-NetIPConfiguration

e:

Get-NetAdapter

Agora temos estados comparáveis.

---

Monte um “snapshot ruim”

Por exemplo:

08:30:15

BackupSvc = Stopped
BancoSvc = Running
Ethernet = Up
IPv4 = 192.168.1.50
DNS do servidor = falha
Porta do banco = inacessível

---

Depois um “snapshot bom”

08:31:10

BackupSvc = Stopped
BancoSvc = Running
Ethernet = Up
IPv4 = 192.168.1.50
DNS do servidor = OK
Porta do banco = acessível

Agora:

Start-Service BackupSvc

funciona.

A diferença está ficando clara.

---

“Ethernet Up” não significa rede pronta

Essa é uma conclusão importante.

O adaptador pode mostrar:

Up

e ainda existir problema em:

DHCP
DNS
rota
autenticação
destino

---

O mesmo vale para Wi-Fi

Wi-Fi conectado

não prova que o servidor necessário está acessível.

---

Serviço iniciado não significa banco pronto

BancoSvc = Running

não prova que:

porta está ouvindo
banco terminou recuperação
aplicação consegue autenticar

---

Serviço pode depender de outro processo que nem é serviço

Por exemplo:

AplicacaoSvc
↓
precisa de AgenteEmpresa.exe

que é iniciado por:

Task Scheduler

ou por logon de usuário.

Essa arquitetura pode explicar por que o serviço funciona somente depois.

---

Um serviço não deveria depender de logon interativo sem intenção

Se ele só funciona depois que um usuário entra porque algum componente essencial é iniciado no perfil do usuário, isso merece investigação arquitetural.

---

Teste antes do logon

Um experimento interessante é:

reiniciar
não entrar na conta
esperar 2 minutos
entrar
verificar serviço

Compare com:

reiniciar
entrar imediatamente
verificar serviço

---

Como interpretar?

Se esperar na tela de logon faz o serviço funcionar:

tempo desde boot

pode ser mais importante que o logon do usuário.

Se ele só passa a funcionar depois do logon:

componente da sessão

merece atenção.

---

Esse teste é excelente para separar duas hipóteses

BOOT DEPENDENCY
versus
USER LOGON DEPENDENCY

---

Teste reinício sem usuário

Em ambiente seguro, reinicie e aguarde.

Depois consulte o estado.

Se o serviço já está funcionando antes do usuário entrar, o logon provavelmente não é necessário.

---

Serviços com gatilho

O Windows também suporta mecanismos em que determinados serviços podem iniciar em resposta a eventos/condições, dependendo de sua configuração.

Por isso, não interprete todo comportamento de serviço apenas pela coluna “Tipo de Inicialização”.

---

Consulte configuração antes de mudar

O diagnóstico deve responder:

como esse serviço foi projetado para iniciar?

e não:

como faço para forçá-lo a iniciar mais cedo?

---

Recovery: o que acontece quando o serviço falha?

Abra:

services.msc

Propriedades do serviço:

Recuperação

Dependendo do serviço, podem existir ações configuradas para:

Primeira falha
Segunda falha
Falhas subsequentes

---

Reiniciar o serviço automaticamente pode esconder o timing

Imagine:

08:00:10 → falha
08:00:40 → Windows reinicia serviço
08:00:41 → funciona

O usuário pode nem perceber.

---

Em outra máquina sem Recovery

08:00:10 → falha
↓
permanece parado

O mesmo problema de timing parece muito mais grave.

---

Recovery pode ser uma mitigação

Em determinados aplicativos, reiniciar automaticamente após falha pode ser apropriado.

Mas a causa continua sendo:

por que a primeira tentativa falhou?

---

Consulte a configuração de falha

O sc.exe possui recursos para consultar configurações do serviço. Use-os cuidadosamente e documente antes de alterar qualquer ação de recuperação.

---

Não configure reinício infinito cegamente

Um serviço que falha continuamente pode entrar em ciclo:

inicia
falha
reinicia
falha
reinicia

Isso pode gerar:

logs
CPU
I/O
instabilidade

---

Observe se já existe ciclo de reinicialização

No Event Viewer, procure eventos repetidos do mesmo serviço em intervalos curtos.

---

Isso muda o diagnóstico

Talvez o serviço não esteja simplesmente:

parado

Talvez esteja:

falhando e reiniciando continuamente

---

Crie uma linha do tempo completa

Exemplo:

07:59:50 Boot
08:00:04 Ethernet Up
08:00:08 BancoSvc Start
08:00:09 BancoSvc Running
08:00:10 AplicacaoSvc Start
08:00:12 AplicacaoSvc falha
08:00:25 DHCP/DNS estabiliza
08:00:28 banco começa a aceitar conexão
08:00:42 Recovery reinicia AplicacaoSvc
08:00:43 AplicacaoSvc funciona

Agora temos muito mais do que:

“o serviço dá erro às vezes”

---

Compare com um boot bom

07:59:50 Boot
08:00:03 Ethernet Up
08:00:05 DNS funcional
08:00:07 BancoSvc Start
08:00:10 banco pronto
08:00:15 AplicacaoSvc Start
08:00:16 funciona

---

A primeira diferença é o alvo

No exemplo:

DNS/recurso fica pronto antes

no boot bom.

Essa diferença merece validação.

---

Não pare na correlação

Faça um teste A/B.

Por exemplo, se existe uma configuração suportada para fazer o serviço aguardar corretamente o componente necessário, aplique apenas essa mudança e repita os boots.

---

Três boots são melhores que um

Registre:

Teste	Configuração	Resultado
1	Original	Falha
2	Original	Falha
3	Original	Falha
4	Alteração controlada	OK
5	Alteração controlada	OK
6	Alteração controlada	OK

Isso reduz a chance de atribuir a melhora ao acaso.

---

Checklist

[ ] Consultei sc qc
[ ] Identifiquei START_TYPE
[ ] Identifiquei dependências formais
[ ] Consultei RequiredServices
[ ] Analisei Service Control Manager
[ ] Investiguei a primeira falha da cadeia
[ ] Não tratei 1053 como causa final
[ ] Não aumentei timeout por tentativa
[ ] Investiguei erro 1068 pela dependência
[ ] Verifiquei PID quando disponível
[ ] Diferenciei CPU alta de espera
[ ] Testei rede no momento da falha
[ ] Testei DNS no momento da falha
[ ] Testei porta quando aplicável
[ ] Comparei snapshots ruim/bom
[ ] Testei antes e depois do logon
[ ] Analisei Recovery
[ ] Procurei ciclos de reinicialização
[ ] Montei uma linha do tempo
[ ] Fiz apenas alterações controladas

O principal aprendizado

Quando Automatic (Delayed Start) resolve um serviço que falhava durante o boot, isso não significa necessariamente que encontramos a causa.

Encontramos uma evidência:

O momento em que o serviço inicia altera o resultado.

Agora precisamos descobrir o que mudou nesse intervalo.

Pode ser:

Serviço B → Running
Rede → funcional
DNS → resolvendo
VPN → conectada
Volume → disponível
Banco → aceitando conexões
Dispositivo → enumerado
Arquivo → desbloqueado

O Service Control Manager mostra a parte formal da história. Mas muitos problemas reais estão nas dependências funcionais que não aparecem na lista de dependências do serviço.

Process Monitor, Process Explorer e comparação GOOD/BAD: descobrindo exatamente onde o serviço falha

Nas partes anteriores, nós já conseguimos responder várias perguntas importantes:

o serviço falha apenas no boot?
ele funciona manualmente depois?
há dependências formais?
há rede envolvida?
há banco, volume, driver ou dispositivo envolvido?
Delayed Start muda o resultado?

Agora entra a etapa mais importante quando os logs comuns não explicam tudo:

capturar o que o processo do serviço realmente tentou fazer no momento da falha.

Para isso, duas ferramentas são especialmente úteis:

Process Monitor
Process Explorer

Ambas fazem parte da suíte Sysinternals da Microsoft.

O Process Monitor será usado para observar operações de:

arquivos
Registro
processos
threads

O Process Explorer ajuda a examinar:

processo
PID
threads
handles
assinatura
árvore de processos

O objetivo é transformar algo genérico:

Serviço falhou ao iniciar

em algo concreto:

BackupService.exe
↓
tentou abrir \\SERVIDOR\Backup\Config.db
↓
recurso não estava disponível
↓
repetiu várias vezes
↓
encerrou

---

Primeiro: descubra o executável correto

Na Parte 1, usamos:

sc qc NomeDoServico

Procure:

BINARY_PATH_NAME

Exemplo:

"C:\Program Files\Empresa\BackupService.exe"

Esse nome será essencial para filtrar o Process Monitor.

---

Confirme também pelo PowerShell

Get-CimInstance Win32_Service |
Where-Object Name -eq "BackupSvc" |
Select-Object Name, State, ProcessId, PathName

Quando o serviço estiver em execução, observe:

ProcessId

---

Por que o PID importa?

Porque vários processos podem ter nomes parecidos.

O PID identifica aquela instância específica.

Exemplo:

BackupService.exe
PID 5420

---

Quando o serviço falha muito cedo, o processo pode desaparecer

Esse é um problema comum.

Você reinicia o Windows, o serviço tenta iniciar, falha e o processo termina antes que seja possível abrir o Process Explorer.

Nesse caso, o Process Monitor é mais útil.

---

O ProcMon precisa capturar o boot

Abrir o Process Monitor depois que o Windows já carregou pode perder exatamente a falha.

Use o recurso de:

Enable Boot Logging

quando necessário.

A sequência conceitual fica:

abrir ProcMon
↓
ativar Boot Logging
↓
reiniciar
↓
deixar o serviço falhar
↓
entrar no Windows
↓
abrir ProcMon
↓
salvar a captura

---

Salve a captura original

Antes de aplicar muitos filtros, salve:

servico-boot-falha.pml

Isso permite voltar aos dados brutos.

---

Faça também uma captura GOOD

Agora temos uma oportunidade excelente.

Depois do boot ruim, espere até o momento em que o serviço normalmente funciona manualmente.

Inicie uma captura separada no ProcMon.

Execute:

Start-Service -Name "BackupSvc"

Pare a captura logo depois.

Salve como:

servico-manual-ok.pml

---

Temos agora BAD versus GOOD

BAD

boot
↓
serviço tenta iniciar
↓
falha

GOOD

Windows já carregado
↓
Start-Service
↓
funciona

Essa comparação é extremamente poderosa.

---

Primeiro filtro: nome do processo

No Process Monitor, filtre conceitualmente:

Process Name
is
BackupService.exe

Isso reduz drasticamente o volume de eventos.

---

Se houver launcher, cuidado

Alguns serviços podem iniciar:

launcher.exe

que depois abre:

servicehost.exe

Por isso, analise também:

Process Start

e árvore de processos.

---

Procure Process Start

Filtre por:

Operation
is
Process Start

Isso ajuda a descobrir:

quando o processo iniciou
quem iniciou
qual linha de comando foi usada

---

Compare a linha de comando

É possível existir diferença entre:

boot automático

e:

execução manual

principalmente quando o software usa launchers, parâmetros ou wrappers.

---

Serviço normal deve usar a mesma configuração

Se a mesma entrada do SCM é usada nos dois momentos, a linha de comando tende a ser a mesma.

Se não for, investigue.

---

O primeiro objetivo: encontrar a última atividade antes da falha

No BAD, procure:

Process Start
↓
operações
↓
últimas operações
↓
Process Exit

O trecho imediatamente antes do encerramento é muito importante.

---

Procure Process Exit

Filtre:

Operation
is
Process Exit

Agora temos os limites da execução.

---

Monte a janela do processo

Exemplo:

08:00:12.100 Process Start
08:00:12.130 RegOpenKey
08:00:12.160 CreateFile
08:00:12.200 CreateFile
08:00:14.900 ...
08:00:15.000 Process Exit

O processo viveu:

aproximadamente 3 segundos

---

Agora compare com o GOOD

08:05:00.100 Process Start
08:05:00.140 RegOpenKey
08:05:00.180 CreateFile
08:05:00.250 ...
08:05:00.900 serviço continua rodando

A pergunta é:

Qual é a primeira operação relevante que muda entre as duas capturas?

---

Procure caminhos diferentes

Imagine:

BAD

CreateFile
\\SERVIDOR\Backup\Config.db
PATH NOT FOUND

GOOD

CreateFile
\\SERVIDOR\Backup\Config.db
SUCCESS

Temos uma divergência excelente.

---

PATH NOT FOUND merece atenção quando é repetitivo e correlacionado

Nem todo PATH NOT FOUND é problema.

Mas se:

mesmo processo
mesmo caminho
várias tentativas
durante a inicialização
GOOD = SUCCESS
BAD = PATH NOT FOUND

a relevância é alta.

---

NAME NOT FOUND também pode ser normal

Programas frequentemente testam caminhos alternativos.

Por isso:

NAME NOT FOUND

isolado não basta.

---

Procure padrões

O que importa é:

repetição
sequência
timing
comparação GOOD/BAD

---

ACCESS DENIED pode revelar diferença de contexto

Imagine:

BAD

C:\ProgramData\Empresa\Config.ini
ACCESS DENIED

GOOD

C:\ProgramData\Empresa\Config.ini
SUCCESS

Agora investigue:

quem criou o arquivo?
qual ACL?
qual conta do serviço?
houve mudança no intervalo?

---

Mas cuidado: mesma conta deveria manter as mesmas permissões

Se o serviço executa sob a mesma conta nos dois momentos, um ACCESS DENIED que desaparece depois pode indicar:

arquivo ainda bloqueado
ACL sendo alterada
volume ainda não pronto
arquivo sendo recriado

e não apenas “falta de permissão permanente”.

---

SHARING VIOLATION é especialmente interessante

Imagine:

Config.db
SHARING VIOLATION

durante o boot.

Depois:

Config.db
SUCCESS

Isso sugere que outro processo pode estar usando o arquivo durante a inicialização.

---

Descubra quem abre o arquivo

No ProcMon, filtre pelo caminho:

Path
contains
Config.db

Agora veja quais processos acessam esse arquivo.

---

Exemplo

BancoUpdater.exe
↓
abre Config.db
↓
BackupService.exe tenta abrir
↓
SHARING VIOLATION
↓
BancoUpdater.exe encerra
↓
BackupService manual funciona

Aqui o problema não é rede nem Delayed Start.

É uma disputa temporal pelo arquivo.

---

Esse é um caso clássico de condição de corrida

Dois componentes iniciam quase ao mesmo tempo.

Dependendo da ordem:

A chega primeiro → funciona
B chega primeiro → A falha

Isso pode explicar problemas intermitentes.

---

Procure intervalos grandes

Em alguns casos, o processo não falha imediatamente.

Exemplo:

08:00:10 operação
08:00:11 operação
08:00:12 operação
...
08:00:55 próxima operação

Existe um intervalo enorme.

Pergunte:

O que aconteceu imediatamente antes dessa pausa?

---

Uma espera de rede pode aparecer assim

Por exemplo:

CreateFile
\\SERVIDOR\Dados

seguida de longo intervalo.

Depois:

resultado de falha

---

Nem toda atividade de rede aparece de forma intuitiva no ProcMon

Por isso, quando a suspeita é rede, combine com:

Test-NetConnection
Resolve-DnsName
Wireshark, quando necessário

---

Compare IP e nome

Se o software depende de:

SERVIDOR-BANCO

teste:

Resolve-DnsName SERVIDOR-BANCO

e:

Test-NetConnection SERVIDOR-BANCO -Port PORTA

logo após o boot e depois.

---

Se pelo IP funciona e pelo nome falha

Temos forte indicação de resolução de nomes.

Mas não substitua o hostname por IP como correção automática.

Pode haver:

certificado
SPN
autenticação
configuração

dependendo do sistema.

---

Process Monitor também mostra Registro

O serviço pode depender de uma chave:

HKLM\Software\Empresa\Config

ou:

HKCU...

embora serviços normalmente tenham contexto diferente de usuários interativos.

---

Procure operações de Registro

Exemplos:

RegOpenKey
RegQueryValue
RegCreateKey
RegSetValue

Compare BAD e GOOD.

---

Exemplo de configuração ausente no boot

BAD:

RegQueryValue
HKLM\Software\Empresa\Server
NAME NOT FOUND

GOOD:

RegQueryValue
HKLM\Software\Empresa\Server
SUCCESS

Isso seria estranho e merece descobrir:

quem cria esse valor?

---

Talvez outra tarefa configure o serviço depois do boot

ProcMon pode revelar:

ConfigAgent.exe
↓
RegSetValue
↓
cria configuração

Depois disso o serviço manual funciona.

Agora entendemos por que ele falha antes.

---

Task Scheduler pode ser o componente intermediário

Imagine:

boot
↓
BackupSvc tenta iniciar
↓
falta chave
↓
falha
↓
Task Scheduler inicia ConfigAgent
↓
ConfigAgent cria chave
↓
Start-Service funciona

Isso é um problema de ordem de inicialização.

---

Autoruns ajuda a enxergar a cadeia

Use:

Services
Scheduled Tasks
Drivers

para identificar componentes relacionados ao software.

---

Procure executáveis do mesmo fabricante

Se você encontra:

BackupSvc.exe
BackupAgent.exe
BackupUpdater.exe
BackupTray.exe

não assuma que todos são necessários ao serviço.

Descubra a função de cada um.

---

Assinatura digital e fabricante

No Process Explorer, verifique:

Company Name
Verified Signer
Image Path

Isso ajuda a confirmar se o componente pertence ao mesmo pacote.

---

Process Explorer: quando o serviço fica em START_PENDING

Se o serviço não encerra, mas fica preso em:

START_PENDING

o Process Explorer é particularmente útil.

---

Descubra o PID

sc queryex BackupSvc

ou:

Get-CimInstance Win32_Service |
Where-Object Name -eq "BackupSvc" |
Select-Object State, ProcessId

---

Localize o PID no Process Explorer

Agora observe:

CPU
Threads
Handles
I/O

---

Se CPU fica quase zero

Pode estar esperando:

evento
mutex
arquivo
rede
outro processo

---

Abra a aba Threads

No Process Explorer, examine as threads quando houver experiência técnica suficiente para interpretar.

Uma thread que permanece muito tempo em estado de espera pode dar pistas sobre o módulo envolvido.

---

Stack pode ser útil

Em alguns casos, a stack de uma thread pode mostrar DLLs ou módulos relacionados a:

rede
banco
driver
biblioteca específica

Mas interpretação de stack exige cuidado.

Não conclua pela presença de uma DLL isolada.

---

Módulo presente não significa culpado

Se:

ntdll.dll
kernel32.dll

aparece na stack, isso não significa que o Windows esteja com defeito.

Essas bibliotecas aparecem em inúmeras operações normais.

---

Procure módulo de terceiro

Se a stack aponta repetidamente para:

EmpresaDatabase.dll

durante a espera, isso pode ser uma pista melhor.

---

Handles também ajudam

No Process Explorer, procure handles para:

arquivos
eventos
mutantes/mutex
Registry keys

Isso pode indicar o recurso aberto pelo processo.

---

Se o serviço trava esperando outro processo

Uma cadeia pode ser:

BackupSvc.exe
↓ espera
BancoSvc.exe
↓ espera
arquivo

Descobrir a cadeia real muda a correção.

---

Não finalize processos do sistema aleatoriamente

Process Explorer é ferramenta de diagnóstico.

Encerrar processos críticos pode derrubar serviços ou reiniciar o Windows.

---

Compare boot bom e boot ruim quando a falha é intermitente

Se algumas inicializações funcionam e outras não, faça:

BOOT 1 = GOOD
BOOT 2 = BAD

com Boot Logging nos dois.

---

Essa comparação pode revelar condição de corrida

Exemplo:

GOOD

08:00:10 BancoSvc inicia
08:00:14 banco fica pronto
08:00:16 AplicacaoSvc inicia

BAD

08:00:10 AplicacaoSvc inicia
08:00:11 tenta banco
08:00:12 falha
08:00:15 BancoSvc fica pronto

Agora está claro.

---

Isso pode acontecer mesmo com dependência formal?

Sim, se:

BancoSvc = Running

antes de realmente aceitar a operação necessária.

O SCM enxerga o estado do serviço, não necessariamente a prontidão funcional interna do aplicativo.

---

Teste a porta do banco

Se o banco escuta em determinada porta documentada:

Test-NetConnection SERVIDOR -Port PORTA

compare o momento:

BancoSvc = Running

com:

porta = acessível

---

Se há diferença de vários segundos

Temos evidência de que:

Running

e:

pronto para cliente

não são equivalentes naquele software.

---

Serviço local também pode ouvir porta local

Use:

Get-NetTCPConnection -State Listen

ou filtro por porta/processo quando apropriado.

---

Relacione porta ao PID

Você pode consultar conexões e processos para descobrir quando a porta fica disponível.

Isso ajuda em serviços que dependem de outro daemon local.

---

Arquivo de log próprio do software

Não dependa apenas do Event Viewer.

Procure documentação do aplicativo para descobrir se existe log como:

C:\ProgramData\Empresa\Logs\

ou outro local oficial.

---

Compare timestamps

BAD:

08:00:11 Connecting database
08:00:15 Connection failed
08:00:15 Service stopping

GOOD:

08:05:20 Connecting database
08:05:20 Connected

---

Logs de aplicativo podem revelar erro mais específico

Por exemplo:

Host not found
Connection refused
Database locked
File not found
Access denied
Certificate unavailable

Cada mensagem aponta para uma direção diferente.

---

Connection refused é diferente de timeout

Connection refused

Pode significar que:

destino respondeu
mas não há serviço aceitando naquela porta

Timeout

Pode indicar:

caminho sem resposta
filtragem
recurso indisponível

A interpretação depende do contexto.

---

Host not found aponta para nome

Se o log diz:

host not found

investigue resolução de nomes.

---

Database locked aponta para concorrência

Se aparece:

database locked

investigue outro processo usando o banco durante o boot.

---

File not found pode indicar timing de arquivo/volume

Se o arquivo surge segundos depois, descubra quem o cria.

---

Access denied exige olhar a conta real do serviço

Volte para:

SERVICE_START_NAME

e confira permissões para aquela identidade.

---

Não teste usando seu usuário como prova

Se você consegue abrir:

C:\Dados

isso só prova a permissão do seu usuário.

O serviço pode usar outra conta.

---

Use icacls quando a suspeita é ACL

Exemplo:

icacls "C:\ProgramData\Empresa"

Compare com a conta do serviço.

---

Cuidado com contas internas

Permissões envolvendo:

SYSTEM
LOCAL SERVICE
NETWORK SERVICE

devem ser alteradas somente com entendimento claro da necessidade do aplicativo.

---

Dependência de certificado

Alguns serviços podem precisar de:

certificado
chave privada
store local

Se um certificado ou componente criptográfico não está disponível como esperado, o serviço pode falhar.

---

ProcMon pode ajudar parcialmente

Acesso a:

cert stores
Registry
arquivos de chave

pode aparecer, mas diagnóstico criptográfico pode exigir ferramentas adicionais.

---

Dependência de dispositivo

Para serviço ligado a hardware, combine:

ProcMon
Event Viewer
Get-PnpDevice
PnPUtil

---

Exemplo

serviço de licença
↓
procura dispositivo USB
↓
dispositivo ainda não enumerado
↓
falha

Minutos depois:

USB presente
↓
Start-Service
↓
funciona

---

Identifique o dispositivo pelo Instance ID

PowerShell:

Get-PnpDevice

e, quando necessário, propriedades específicas do dispositivo.

---

Não force atraso se o driver está falhando

Se o dispositivo leva muito tempo porque reconecta repetidamente, o problema pode estar em:

USB
energia
driver
hardware

e não no serviço.

---

Dependência de volume

Se o serviço usa:

D:\Dados

verifique:

Get-Volume

e:

Get-Disk

quando aplicável.

---

ProcMon pode mostrar o momento exato da falha

BAD:

D:\Dados\Config.db
PATH NOT FOUND

GOOD:

D:\Dados\Config.db
SUCCESS

---

Talvez a letra do volume mude

Em ambientes com discos externos, VHDs ou armazenamento específico, a dependência por letra fixa pode ser frágil.

Investigue a arquitetura antes de alterar.

---

Compare um snapshot BAD e GOOD

Monte algo assim:

Item	BAD	GOOD
BackupSvc	Falha	Funciona
BancoSvc	Running	Running
Porta 5432	Fechada	Aberta
DNS	OK	OK
D:\Dados	Disponível	Disponível
Config.db	Existe	Existe

Agora a diferença está em:

porta do banco

---

Outro exemplo

Item	BAD	GOOD
Serviço	Falha	OK
Porta	OK	OK
DNS	OK	OK
Config.db	SHARING VIOLATION	SUCCESS
Updater.exe	ativo	encerrado

Agora o culpado provável é outra classe de problema.

---

Outro exemplo

Item	BAD	GOOD
Serviço	Falha	OK
Rede	OK	OK
DNS	Falha	OK
Teste por IP	OK	OK
Teste por nome	Falha	OK

Aqui a investigação aponta para DNS.

---

Não aplique várias correções

Se você simultaneamente:

muda serviço para Delayed Start
troca DNS
desativa updater
altera permissões

e funciona, o diagnóstico foi perdido.

---

Faça um teste por hipótese

Exemplo:

Hipótese:
Updater.exe bloqueia Config.db durante o boot.

Teste:
impedir apenas o Updater de iniciar, de forma reversível.

Resultado:
3 boots consecutivos sem falha.

Isso é uma evidência forte.

---

Reative para confirmar quando seguro

Em ambiente de teste:

reativar updater
↓
problema volta

reforça a relação causal.

---

Hipótese de rede

Hipótese:
serviço inicia antes do servidor ficar acessível.

Teste:
monitorar porta durante o boot.

Resultado:
serviço falha às 08:00:12
porta passa a responder às 08:00:28
serviço manual funciona às 08:00:30

Aqui há uma relação temporal muito clara.

---

Hipótese de volume

Hipótese:
serviço tenta abrir D:\Dados antes do volume estar disponível.

BAD:
PATH NOT FOUND

GOOD:
SUCCESS

---

Hipótese de configuração criada tarde

Hipótese:
Task Scheduler executa ConfigAgent depois do serviço.

BAD:
Registry value inexistente

depois:
ConfigAgent RegSetValue

GOOD:
serviço inicia

---

Quando Delayed Start faz sentido?

Depois de demonstrar que o software realmente precisa apenas iniciar posteriormente e que isso está de acordo com a arquitetura suportada.

Ainda assim, prefira uma solução documentada pelo fabricante quando disponível.

---

Quando Recovery faz sentido?

Quando uma falha temporária é esperada e o aplicativo foi projetado para se recuperar por nova tentativa.

Mas não use Recovery para esconder:

configuração errada
arquivo ausente
senha inválida
driver quebrado

---

Quando corrigir o recurso em vez do serviço?

Se a causa está em:

DNS lento
servidor indisponível
volume tardio
banco lento
driver
arquivo bloqueado

corrigir o recurso pode ser melhor do que atrasar o serviço.

---

Procedimento técnico da Parte 3

1. descubra o executável do serviço
2. confirme conta e PID
3. ative Boot Logging se necessário
4. reproduza a falha
5. salve captura BAD
6. espere o momento em que o serviço funciona
7. capture Start-Service manual
8. salve captura GOOD
9. filtre pelo processo
10. identifique Process Start
11. identifique Process Exit
12. procure última operação antes da falha
13. compare caminhos BAD/GOOD
14. procure PATH NOT FOUND
15. procure NAME NOT FOUND repetitivo
16. procure ACCESS DENIED
17. procure SHARING VIOLATION
18. procure grandes intervalos
19. filtre pelo caminho suspeito
20. descubra outros processos envolvidos
21. analise Process Explorer se houver START_PENDING
22. consulte threads quando necessário
23. confira logs próprios do aplicativo
24. valide rede/porta/DNS
25. valide volume/dispositivo
26. formule uma hipótese
27. altere apenas uma variável
28. reinicie
29. repita pelo menos mais de uma vez
30. confirme a relação causal

---

O que não fazer

Evite:

aumentar ServicesPipeTimeout sem evidência

Evite:

trocar conta do serviço por LocalSystem

apenas para “ver se funciona”.

Evite:

colocar dependências aleatórias no SCM

Evite:

Delayed Start em todos os serviços

Evite:

desabilitar metade dos serviços Microsoft

---

O principal aprendizado da Parte 3

A diferença entre um serviço que falha no boot e o mesmo serviço que funciona manualmente depois pode ser observada diretamente.

A comparação:

BAD
versus
GOOD

permite encontrar diferenças como:

PATH NOT FOUND → SUCCESS
ACCESS DENIED → SUCCESS
SHARING VIOLATION → SUCCESS
porta fechada → porta aberta
DNS falhando → DNS funcionando
dispositivo ausente → dispositivo presente
volume ausente → volume disponível

É muito mais útil descobrir uma dessas transições do que simplesmente aumentar um timeout.

Agora já temos as principais peças do diagnóstico:

serviço
↓
momento da falha
↓
dependências formais
↓
dependências funcionais
↓
Service Control Manager
↓
Event Viewer
↓
Process Monitor
↓
Process Explorer
↓
comparação BAD x GOOD

Nesta última parte, vamos transformar tudo isso em um procedimento reproduzível.

A meta é sair de uma situação vaga como:

“O serviço não inicia com o Windows.”

para uma conclusão técnica como:

“O serviço tenta abrir um banco remoto antes de a porta ficar disponível, falha durante o boot e funciona manualmente depois porque a dependência de rede já está pronta.”

Essa diferença muda completamente a forma de corrigir o problema.

---

Procedimento definitivo em 30 etapas

1. Confirme o sintoma

Reinicie o Windows 11 e verifique se o serviço realmente fica parado ou falha.

Abra:

services.msc

Não inicie o serviço ainda.

---

2. Anote o horário

Registre aproximadamente:

horário do boot
horário em que o serviço falhou
horário em que você percebeu o problema

Quanto mais precisa a linha do tempo, melhor.

---

3. Descubra o nome interno

Use:

Get-Service

ou localize o serviço no services.msc.

Anote:

DisplayName
Name
Status
StartType

---

4. Consulte a configuração completa

Execute:

sc qc NomeDoServico

Registre:

BINARY_PATH_NAME
START_TYPE
DEPENDENCIES
SERVICE_START_NAME

---

5. Confirme a conta utilizada

Descubra se ele executa como:

LocalSystem
LocalService
NetworkService
conta específica

Isso será essencial ao analisar permissões e rede.

---

6. Verifique se existe dependência formal

PowerShell:

Get-Service -Name "NomeDoServico" -RequiredServices

Se houver dependências, consulte o estado delas.

---

7. Analise o Event Viewer

Abra:

eventvwr.msc

Vá para:

Logs do Windows
→ Sistema

Procure:

Service Control Manager

no momento exato da falha.

---

8. Registre Event ID e mensagem completa

Não anote apenas:

erro 1053

ou:

erro 1068

Registre a mensagem completa e o horário.

---

9. Teste o serviço manualmente

Depois de esperar algum tempo:

Start-Service -Name "NomeDoServico"

Se funcionar, registre o horário.

---

10. Repita em momentos diferentes

Teste, por exemplo:

5 segundos após desktop
20 segundos
40 segundos
60 segundos

A ideia não é criar uma regra universal de tempo.

É descobrir em qual intervalo o comportamento muda.

---

11. Monte uma linha do tempo

Exemplo:

08:10:12 serviço tenta iniciar
08:10:13 falha
08:10:18 rede conecta
08:10:24 DNS resolve
08:10:29 servidor responde
08:10:32 Start-Service funciona

Agora já existe uma hipótese.

---

12. Verifique a rede se o serviço depende dela

Use:

Get-NetIPConfiguration

e:

ipconfig /all

Observe:

IP
gateway
DNS
DHCP
interface

---

13. Teste DNS

Se o serviço acessa um hostname:

Resolve-DnsName servidor

Compare o resultado logo após o boot e depois.

---

14. Teste a porta correta

Se conhece a porta usada pelo serviço:

Test-NetConnection servidor -Port PORTA

Não adivinhe a porta.

Use a configuração ou a documentação do software.

---

15. Verifique volumes

Se o serviço usa:

D:\Dados
E:\Banco

consulte:

Get-Volume

e confirme se o volume está disponível quando a tentativa automática acontece.

---

16. Verifique dispositivos quando aplicável

Para serviços ligados a hardware:

Get-PnpDevice

Procure dispositivos que ainda estão:

Unknown
Error
Degraded

ou que aparecem apenas depois.

---

17. Consulte logs próprios do aplicativo

Procure no local documentado pelo fabricante.

Exemplos de mensagens úteis:

connection refused
host not found
access denied
database locked
file not found
timeout

---

18. Use Boot Logging no Process Monitor

Quando o problema continua obscuro, capture o boot.

Salve como:

servico-boot-falha.pml

---

19. Capture também a execução manual bem-sucedida

Espere até o momento em que o serviço funciona.

Inicie uma nova captura.

Execute:

Start-Service -Name "NomeDoServico"

Salve:

servico-manual-ok.pml

---

20. Compare BAD e GOOD

Filtre pelo executável do serviço.

Compare:

Process Start
arquivos
Registro
Process Exit

---

21. Procure divergências

Especialmente:

PATH NOT FOUND
NAME NOT FOUND
ACCESS DENIED
SHARING VIOLATION

mas sempre dentro do contexto.

---

22. Procure intervalos longos

Uma pausa grande pode indicar espera por:

rede
arquivo
evento
driver
banco
outro processo

---

23. Analise o processo se ele ficar em START_PENDING

Use:

sc queryex NomeDoServico

Descubra o PID.

Depois examine no Process Explorer.

---

24. Observe CPU e threads

Se há CPU alta:

pode estar processando

Se CPU está praticamente zerada:

pode estar esperando

Isso não fecha o diagnóstico, mas ajuda a direcionar.

---

25. Descubra dependências funcionais ocultas

Pergunte:

o serviço usa rede?
DNS?
banco?
arquivo?
USB?
certificado?
VPN?
volume?

Essas dependências podem não aparecer em sc qc.

---

26. Formule uma única hipótese

Exemplo:

O serviço falha porque tenta abrir \\SERVIDOR\Backup antes que a rede esteja pronta.

Não formule dez hipóteses ao mesmo tempo.

---

27. Mude uma variável

Faça apenas uma alteração controlada.

Exemplo:

Delayed Start

ou uma correção documentada da dependência real.

---

28. Reinicie novamente

Teste se o problema desaparece.

---

29. Repita o teste

Um único boot bom não prova a correção.

Faça alguns reinícios controlados.

---

30. Documente a causa final

Exemplo:

Causa:
BackupSvc iniciava antes de a VPN tornar o servidor acessível.

Evidência:
porta indisponível no boot, disponível depois.

Correção:
ajuste suportado pelo software para aguardar/repetir conexão.

Agora existe diagnóstico, não apenas tentativa.

---

Árvore de decisão rápida

Serviço falha no boot
        ↓
Funciona manualmente depois?
        ↓
       SIM
        ↓
Existe dependência formal?
   ↓                 ↓
  SIM               NÃO
   ↓                 ↓
ela estava         procurar dependência
realmente pronta?  funcional
   ↓                 ↓
rede / DNS / banco / volume / driver / dispositivo
        ↓
Delayed Start muda o resultado?
        ↓
       SIM
        ↓
forte pista de timing
        ↓
capturar BAD x GOOD
        ↓
identificar primeira divergência
        ↓
corrigir a dependência real

Se:

Funciona manualmente depois?
        ↓
       NÃO

então investigue:

configuração
conta
permissões
arquivos
executável
driver
credenciais
corrupção

---

Cenário 1 — serviço de backup depende de compartilhamento SMB

Imagine:

BackupSvc
↓
\\SERVIDOR\Backup

No boot:

08:00:10 BackupSvc inicia
08:00:11 recurso SMB indisponível
08:00:12 serviço falha

Depois:

08:00:25 servidor responde
08:00:30 Start-Service
08:00:31 funciona

Diagnóstico:

dependência funcional de rede

Teste:

Test-NetConnection SERVIDOR -Port 445

nos dois momentos.

---

Cenário 2 — DNS fica pronto tarde

Sintoma:

servidor pelo nome → falha
servidor pelo IP → responde

logo depois do boot.

Depois:

nome → funciona

Teste:

Resolve-DnsName SERVIDOR

Se a diferença for repetível, investigue DNS.

---

Cenário 3 — serviço depende de banco local

Temos:

AplicacaoSvc
↓
BancoSvc

O banco já mostra:

Running

mas a porta ainda não aceita conexão.

Poucos segundos depois:

porta aberta

e o aplicativo funciona.

Esse é um exemplo importante de:

Running não significa necessariamente pronto.

---

Cenário 4 — arquivo bloqueado por outro processo

BAD:

Config.db
SHARING VIOLATION

GOOD:

Config.db
SUCCESS

Outro processo:

Updater.exe

usa o arquivo durante o boot.

Agora o foco está em uma condição de corrida.

---

Cenário 5 — volume ainda não está disponível

Serviço usa:

D:\Dados\App.db

BAD:

PATH NOT FOUND

GOOD:

SUCCESS

A correção deve considerar por que o volume não está disponível naquele momento.

---

Cenário 6 — dispositivo USB aparece tarde

Um serviço de licença ou aquisição de dados procura um dispositivo específico.

Durante o boot:

dispositivo ausente

Poucos segundos depois:

dispositivo enumerado

e o serviço passa a iniciar.

Investigue:

PnP
driver
USB
energia

antes de simplesmente aumentar atraso.

---

Cenário 7 — VPN é necessária

Fluxo:

Windows inicia
↓
serviço inicia
↓
servidor corporativo inacessível
↓
serviço falha
↓
VPN conecta
↓
Start-Service funciona

Aqui Delayed Start pode até melhorar.

Mas, se a VPN levar mais tempo em outro dia, o problema pode voltar.

---

Cenário 8 — credencial de rede

O serviço executa como:

LocalSystem

e tenta acessar:

\\SERVIDOR\Dados

O usuário consegue abrir o caminho manualmente, mas isso não prova que a conta do serviço consegue.

Investigue a identidade real.

---

Cenário 9 — serviço inicia apenas depois do logon do usuário

Faça o teste:

reiniciar
↓
esperar na tela de logon
↓
entrar depois

Se o serviço não inicia até o usuário entrar, investigue:

tarefas de logon
componentes do perfil
agentes do usuário
credenciais
scripts

---

Cenário 10 — funciona se esperar na tela de logon

Se o serviço funciona quando você espera 2 minutos antes de entrar:

tempo desde o boot

provavelmente é mais importante do que o logon.

Isso direciona a investigação para:

rede
serviços
driver
banco
volume

---

Cenário 11 — erro 1053

O serviço apresenta 1053.

A resposta errada seria:

aumentar timeout imediatamente

A resposta correta é descobrir:

o que o processo estava fazendo durante a espera?

Use:

ProcMon
Process Explorer
logs do aplicativo

---

Cenário 12 — erro 1068

O serviço final apresenta 1068.

Não comece por ele.

Descubra:

qual dependência falhou primeiro?

Caminhe pela cadeia.

---

Cenário 13 — Delayed Start resolve

Se:

Automatic → falha
Delayed Start → funciona

concluímos:

timing é relevante

Não necessariamente:

Delayed Start é a causa

Use a diferença de tempo como pista.

---

Cenário 14 — Recovery resolve sozinho

Talvez o serviço falhe no primeiro boot e o Windows o reinicie 30 segundos depois.

Então ele funciona.

O problema continua existindo.

A configuração de Recovery apenas mascarou a primeira falha.

---

Cenário 15 — problema intermitente

Em três boots:

boot 1 = funciona
boot 2 = falha
boot 3 = funciona

Isso aumenta a suspeita de:

condição de corrida
timing
rede
dispositivo

Capture um GOOD e um BAD.

---

Quando usar Automatic (Delayed Start)?

Use quando:

o software suporta
há justificativa
a dependência realmente precisa de tempo adicional

e o comportamento foi validado.

Não use apenas porque:

“vi em um fórum”

---

Quando usar Recovery?

Pode ser adequado quando:

falhas transitórias são esperadas
o software suporta reinício
a política está documentada

Mas não substitui investigação de falha permanente.

---

Quando aumentar timeout?

Somente quando houver evidência de que:

o serviço realmente precisa de mais tempo

por um motivo legítimo.

Não para compensar:

DNS quebrado
servidor inexistente
arquivo bloqueado
senha errada

---

Quando alterar dependências formais?

Apenas quando:

há documentação
a arquitetura exige
a alteração é suportada

Adicionar dependência arbitrária pode criar novos problemas de boot.

---

Quando corrigir a rede?

Quando os testes mostram:

DNS falha
porta inacessível
rota ausente
VPN tardia
DHCP não pronto

e o serviço depende disso.

---

Quando corrigir permissões?

Quando:

ACCESS DENIED

é reproduzível com a conta real do serviço.

---

Quando corrigir armazenamento?

Quando a comparação mostra:

volume ausente
arquivo indisponível
caminho inexistente

no momento da falha.

---

Quando investigar hardware?

Quando o serviço depende de:

USB
serial
scanner
token
placa
driver

e o dispositivo ainda não está disponível.

---

Quando reinstalar o programa?

Somente depois de identificar evidência de:

instalação corrompida
arquivos faltando
serviço mal registrado
configuração quebrada

Reinstalar antes do diagnóstico pode apagar evidências.

---

E reinstalar o Windows?

Neste tipo de problema, quase nunca deveria ser a primeira medida.

Se o serviço:

funciona manualmente

isso já sugere que existe muito para investigar antes de pensar em reinstalar o sistema.

---

FAQ — Perguntas frequentes

1. Por que um serviço funciona manualmente mas não inicia com o Windows?

Porque o ambiente pode estar diferente durante o boot. Rede, DNS, banco, volume, driver ou outro serviço ainda podem não estar prontos.

2. Automatic (Delayed Start) sempre resolve?

Não. Ele pode contornar problemas de timing, mas não corrige necessariamente a causa.

3. O que significa erro 1053?

Significa que o serviço não respondeu à solicitação dentro do período esperado. O motivo da demora precisa ser investigado.

4. Erro 1053 significa que o Windows está com defeito?

Não necessariamente.

5. Devo aumentar o ServicesPipeTimeout?

Não como primeira medida.

6. O que significa erro 1068?

Normalmente indica falha relacionada a serviço ou grupo de dependência.

7. Como descubro dependências?

Use:

Get-Service -Name "Servico" -RequiredServices

ou:

sc qc Servico

8. Um serviço pode depender de algo que não aparece em sc qc?

Sim. São as dependências funcionais.

9. Rede pode ser uma dependência oculta?

Sim.

10. DNS também?

Sim.

11. VPN pode causar esse comportamento?

Sim, se o serviço precisa de recursos disponíveis apenas após a VPN conectar.

12. O serviço está Running, então está funcionando?

Não necessariamente.

13. Banco Running significa que já aceita conexões?

Nem sempre.

14. Como descubro se a porta está aberta?

Use:

Test-NetConnection servidor -Port PORTA

15. Como testar DNS?

Use:

Resolve-DnsName servidor

16. Posso usar Ping?

Pode ajudar, mas não prova que o serviço de aplicação esteja acessível.

17. Por que o usuário abre uma pasta de rede e o serviço não?

Porque eles podem usar contas e contextos diferentes.

18. Serviço enxerga unidade Z:?

Não presuma isso.

19. Caminho UNC é melhor?

Ele evita depender da letra mapeada, mas ainda exige rede, credenciais e permissões corretas.

20. Como descubro a conta do serviço?

Use services.msc, sc qc ou Get-CimInstance Win32_Service.

21. Posso mudar para LocalSystem?

Não como teste genérico.

22. Por quê?

Porque isso altera privilégios e contexto de rede.

23. Process Monitor ajuda?

Muito.

24. O que procurar no ProcMon?

Compare BAD e GOOD e observe operações imediatamente antes da falha.

25. NAME NOT FOUND sempre é erro?

Não.

26. PATH NOT FOUND sempre é causa?

Não. Precisa estar correlacionado ao problema.

27. ACCESS DENIED é importante?

Sim, principalmente se ocorre no recurso essencial.

28. SHARING VIOLATION pode causar falha?

Pode.

29. O que significa START_PENDING?

O serviço está em processo de inicialização.

30. Posso descobrir o PID?

Use:

sc queryex NomeDoServico

31. Process Explorer ajuda em START_PENDING?

Sim.

32. CPU baixa significa travamento?

Não necessariamente. Pode indicar espera.

33. CPU alta significa defeito?

Também não. O processo pode estar trabalhando.

34. Preciso usar Wireshark?

Nem sempre.

35. Quando vale a pena?

Quando a suspeita de rede precisa de análise mais profunda.

36. O Event Viewer basta?

Em alguns casos, sim. Em outros, apenas mostra a consequência.

37. Logs do próprio programa são importantes?

Muito.

38. O que é uma condição de corrida?

É quando o resultado depende da ordem ou timing entre componentes concorrentes.

39. Isso explica falha intermitente?

Pode explicar.

40. Como confirmar?

Compare boots bons e ruins.

41. Recovery pode ser usado?

Sim, quando apropriado e suportado.

42. Recovery corrige a causa?

Não necessariamente.

43. Um serviço pode depender de USB?

Sim.

44. Pode depender de um disco externo?

Sim.

45. Pode depender de certificado?

Sim.

46. Pode depender do usuário fazer logon?

Alguns softwares são construídos dessa forma, embora isso deva ser investigado.

47. Posso usar inicialização limpa?

Pode ser útil em casos complexos, principalmente quando terceiros interferem.

48. Posso desativar serviços Microsoft para testar?

Evite desativação indiscriminada.

49. SFC e DISM ajudam?

Somente quando existe suspeita de corrupção do Windows. Eles não corrigem dependência de rede, banco ou timing de terceiro.

50. Qual é o melhor ponto de partida?

Compare o momento em que o serviço falha com o momento em que passa a funcionar.

---

Conclusão

Quando um serviço falha durante a inicialização do Windows 11, mas funciona normalmente quando você o inicia manualmente depois, essa diferença não deve ser tratada como coincidência.

Ela é a principal pista do diagnóstico.

O problema pode não estar no executável do serviço.

Pode estar no fato de que, durante o boot:

a rede ainda não estava pronta
o DNS ainda não resolvia
o banco ainda não aceitava conexões
a VPN ainda não havia conectado
o volume ainda não estava disponível
um arquivo permanecia bloqueado
um dispositivo ainda não havia sido enumerado

O Service Control Manager ajuda a identificar dependências formais, mas nem sempre conhece toda a cadeia funcional necessária ao aplicativo.

Por isso, o diagnóstico mais eficiente combina:

services.msc
sc.exe
PowerShell
Event Viewer
Process Monitor
Process Explorer
logs do programa
testes de rede
linha do tempo

O ponto central não é perguntar apenas:

“Como faço esse serviço iniciar mais tarde?”

A pergunta mais útil é:

“O que ainda não estava pronto quando ele tentou iniciar?”

Quando você encontra essa resposta, deixa de aplicar correções genéricas e passa a atuar diretamente sobre a causa.

Precisa de ajuda para diagnosticar serviços e falhas de inicialização no Windows 11?

A VMIA – Manutenção e Configuração realiza diagnóstico técnico de Windows, programas, serviços, redes, impressoras e problemas de inicialização, tanto por acesso remoto quanto por atendimento presencial agendado.

Podemos investigar situações em que um serviço funciona manualmente, mas falha durante o boot, analisar logs, Event Viewer, Process Monitor, dependências, rede, drivers e outros componentes envolvidos.

VMIA – Manutenção e Configuração
Telefone e WhatsApp: (11) 99779-7772
Atendimento mediante agendamento, com suporte remoto e presencial em São Paulo.