Serviço do Windows 11 não inicia? Como descobrir a causa e corrigir

setembro 11, 2026 admin Sistema Operacional, Windows 11 0

Serviço do Windows 11 não inicia com diagnóstico pelo Service Control Manager, PowerShell, Visualizador de Eventos e comandos SC
Diagnóstico de serviços do Windows 11 com ferramentas como Services, PowerShell, Visualizador de Eventos e comandos SC para identificar erros 1053, 1067, 1068 e 1079.
75 / 100
Desenvolvido por Rank Math SEO
Pontuação de SEO

Você abre o Windows 11 normalmente, tenta usar um programa, impressora, recurso de rede ou alguma ferramenta instalada no computador e percebe que alguma coisa simplesmente não funciona. Ao investigar um pouco mais, descobre que existe um serviço do Windows parado. Você abre services.msc, localiza o serviço e clica em Iniciar.

Então aparece um erro.

Em alguns casos, o Windows informa que não foi possível iniciar o serviço. Em outros, apresenta um código numérico. Também existem situações nas quais o serviço aparentemente começa a funcionar, mas para poucos segundos depois.

O problema fica ainda mais confuso quando o botão Iniciar parece funcionar, mas o aplicativo que depende daquele serviço continua apresentando erro.

Nessas situações, simplesmente reiniciar o computador ou alterar o tipo de inicialização de Manual para Automático pode não resolver absolutamente nada.

Um serviço pode deixar de iniciar por diversas razões:

  • outro serviço necessário está parado;
  • uma dependência não foi carregada;
  • um arquivo executável desapareceu;
  • o caminho do executável está incorreto;
  • uma DLL necessária está ausente ou corrompida;
  • a conta utilizada pelo serviço perdeu permissão;
  • a senha da conta utilizada pelo serviço mudou;
  • uma atualização alterou algum componente;
  • uma chave do Registro ficou incorreta;
  • uma porta TCP ou UDP necessária já está ocupada;
  • um driver necessário não iniciou;
  • o serviço encerra imediatamente após iniciar;
  • um programa de segurança bloqueou sua execução;
  • arquivos do Windows estão corrompidos;
  • o próprio aplicativo associado ao serviço está danificado.

Por isso, o melhor caminho não é tentar soluções aleatórias.

O Windows 11 possui diversas ferramentas que ajudam a descobrir por que o serviço não inicia.

Neste guia, vamos utilizar principalmente:

services.msc

sc.exe

sc query

sc qc

sc queryex

Get-Service

Get-CimInstance

Visualizador de Eventos

Monitor de Confiabilidade

Gerenciador de Tarefas

e, quando necessário, ferramentas complementares de diagnóstico.

O objetivo não será simplesmente fazer um serviço iniciar à força.

Vamos descobrir o motivo da falha.

O que é um serviço do Windows?

Um serviço do Windows é um programa ou componente desenvolvido para executar determinadas tarefas em segundo plano.

Diferentemente de um aplicativo tradicional, ele normalmente não precisa manter uma janela aberta na Área de Trabalho.

Muitos serviços também podem iniciar antes mesmo de você entrar na sua conta do Windows.

Isso permite que o sistema disponibilize determinados recursos desde a inicialização.

Impressão, atualizações, descoberta de dispositivos, autenticação, rede, áudio, segurança, sincronização e diversos outros recursos dependem de serviços.

Um exemplo conhecido é o Spooler de Impressão.

Seu nome de serviço é:

Spooler

Ele administra tarefas relacionadas à fila de impressão.

Outro exemplo é o serviço Windows Update, cujo nome interno é:

wuauserv

Também podemos encontrar serviços criados por programas de terceiros.

Antivírus, programas de backup, bancos de dados, VPNs, softwares de impressoras, ferramentas de acesso remoto e diversos outros aplicativos podem instalar seus próprios serviços.

Por isso, quando um serviço falha, o problema nem sempre está diretamente no Windows.

Ele pode estar no programa responsável por aquele serviço.

Nome exibido e nome do serviço não são necessariamente iguais

Essa diferença é extremamente importante durante o diagnóstico.

Abra:

services.msc

Você verá nomes amigáveis destinados ao usuário.

Entretanto, os comandos do Windows normalmente trabalham com o nome interno do serviço.

Por exemplo, o serviço exibido como:

Spooler de Impressão

possui o nome:

Spooler

Essa diferença pode causar confusão ao executar comandos.

Se você utilizar o nome errado em um comando, poderá receber uma mensagem informando que o serviço não existe.

Para descobrir o nome correto, podemos usar as propriedades do serviço ou ferramentas de linha de comando.

Primeiro passo: não altere várias configurações ao mesmo tempo

Esse é um princípio importante de diagnóstico.

Imagine que determinado serviço não inicia.

Você imediatamente:

  1. muda o tipo de inicialização;
  2. altera a conta do serviço;
  3. modifica permissões;
  4. executa SFC;
  5. executa DISM;
  6. reinstala o programa;
  7. altera o Registro;
  8. reinicia outros serviços.

Se o problema desaparecer, fica difícil saber qual alteração realmente resolveu a falha.

Além disso, alguma dessas modificações pode criar um segundo problema.

O melhor procedimento consiste em coletar informações primeiro.

Antes de alterar qualquer coisa, procure responder:

Qual serviço está falhando?

Qual é o nome interno dele?

Qual é o estado atual?

Qual executável ele utiliza?

De quais serviços ele depende?

Qual conta executa o serviço?

Qual código de erro aparece?

Existe algum evento relacionado no Visualizador de Eventos?

Essas respostas normalmente reduzem bastante o número de possibilidades.

Etapa 1 — Abra o Services.msc

Pressione:

Windows + R

Digite:

services.msc

Pressione Enter.

A janela Serviços será aberta.

Localize o serviço problemático.

Clique duas vezes nele.

A janela de propriedades apresenta informações importantes para nosso diagnóstico.

Observe principalmente:

  • Nome do serviço;
  • Nome para exibição;
  • Descrição;
  • Caminho para o executável;
  • Tipo de inicialização;
  • Status do serviço.

Não saia alterando essas opções ainda.

Primeiro, registre essas informações.

O caminho para o executável pode revelar o problema

Um dos campos mais importantes é:

Caminho para o executável

Imagine um serviço de determinado programa instalado em:

C:\Program Files\Programa\servico.exe

O Windows tenta executar esse arquivo quando o serviço é iniciado.

Mas imagine que o programa tenha sido parcialmente removido e servico.exe não exista mais.

O registro do serviço continua presente.

Nesse caso, o Windows sabe que o serviço existe, mas não consegue executar seu arquivo.

Esse cenário aparece com certa frequência após:

  • desinstalações incompletas;
  • atualizações malsucedidas;
  • remoção manual de programas;
  • restaurações de backup;
  • antivírus colocando arquivos em quarentena;
  • limpeza incorreta de diretórios.

Portanto, uma das primeiras verificações consiste em confirmar se o executável indicado realmente existe.

Mas atenção:

Nem todo serviço aponta diretamente para um .exe exclusivo.

Diversos serviços do próprio Windows utilizam processos compartilhados, como:

svchost.exe

Nesse caso, precisamos investigar de outra maneira.

Etapa 2 — Tente iniciar o serviço apenas uma vez

Dentro das propriedades do serviço, clique em:

Iniciar

Observe cuidadosamente a mensagem apresentada.

Não ignore o código do erro.

Ele pode ser uma das pistas mais importantes do diagnóstico.

Por exemplo, podemos encontrar mensagens relacionadas a:

  • acesso negado;
  • arquivo não encontrado;
  • dependência que não iniciou;
  • tempo limite;
  • falha de logon;
  • serviço desabilitado;
  • parâmetros incorretos.

Anote o código exato.

Uma diferença aparentemente pequena entre dois códigos pode apontar para causas completamente diferentes.

O serviço inicia e imediatamente para?

Existe uma situação bastante comum.

Você clica em Iniciar.

O serviço aparece como:

Em execução

Pouco depois, volta para:

Parado

Isso não significa necessariamente que o Windows não conseguiu iniciar o serviço.

Pode significar que o processo iniciou e encerrou posteriormente.

Essa diferença muda bastante o diagnóstico.

Precisamos descobrir se:

A) o Windows não consegue criar o processo;

ou

B) o processo é criado, mas termina depois.

No segundo caso, precisamos procurar o motivo da finalização.

É aí que ferramentas como Visualizador de Eventos e Monitor de Confiabilidade se tornam especialmente importantes.

Etapa 3 — Consulte o serviço com SC QUERY

Agora podemos sair da interface gráfica e obter informações diretamente pelo Windows.

Abra o Terminal, Prompt de Comando ou PowerShell como administrador.

Execute:

sc query Spooler

Neste exemplo estamos consultando o Spooler de Impressão.

O resultado será semelhante a:

SERVICE_NAME: Spooler
        TYPE               : 110  WIN32_OWN_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0
        SERVICE_EXIT_CODE  : 0
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Esses campos são muito úteis.

Vamos entender os principais.

SERVICE_NAME

Exemplo:

SERVICE_NAME: Spooler

Esse é o nome interno do serviço.

É esse nome que normalmente utilizaremos nos comandos.

STATE

O campo:

STATE

mostra o estado atual do serviço.

Podemos encontrar estados como:

STOPPED
START_PENDING
STOP_PENDING
RUNNING
CONTINUE_PENDING
PAUSE_PENDING
PAUSED

Essa informação pode revelar situações interessantes.

Por exemplo, se o serviço permanece muito tempo em:

START_PENDING

ele recebeu a solicitação para iniciar, mas ainda não concluiu o processo de inicialização.

Isso é diferente de um serviço que imediatamente retorna para:

STOPPED

WIN32_EXIT_CODE

Outro campo importante é:

WIN32_EXIT_CODE

Quando tudo está normal, frequentemente encontramos:

0

Um valor diferente de zero pode fornecer uma pista sobre o motivo da falha.

Também existe:

SERVICE_EXIT_CODE

Alguns serviços utilizam códigos próprios para indicar erros internos.

Não devemos simplesmente ignorar esses números.

Eles podem ajudar a identificar exatamente em qual etapa o serviço falhou.

CHECKPOINT e WAIT_HINT

Esses dois campos passam despercebidos por muitos usuários.

Mas são interessantes quando um serviço fica preso durante a inicialização.

O Windows pode utilizar:

CHECKPOINT

para acompanhar o progresso de determinadas operações do serviço.

Já:

WAIT_HINT

pode indicar uma estimativa de tempo necessária para determinada operação pendente.

Quando investigamos um serviço preso em:

START_PENDING

esses campos podem ajudar a entender se ele ainda apresenta progresso ou se aparentemente ficou travado.

Etapa 4 — Descubra como o serviço foi configurado com SC QC

Agora execute:

sc qc Spooler

qc significa consulta à configuração do serviço.

O comando pode retornar informações semelhantes a:

SERVICE_NAME: Spooler
        TYPE
        START_TYPE
        ERROR_CONTROL
        BINARY_PATH_NAME
        LOAD_ORDER_GROUP
        TAG
        DISPLAY_NAME
        DEPENDENCIES
        SERVICE_START_NAME

Essa consulta é extremamente valiosa.

Enquanto:

sc query

mostra principalmente o estado atual,

sc qc

mostra a configuração utilizada para iniciar o serviço.

Essa diferença é fundamental.

BINARY_PATH_NAME

Observe:

BINARY_PATH_NAME

Esse campo informa qual comando ou executável está associado ao serviço.

Se estivermos investigando um serviço de terceiro, esse campo pode revelar imediatamente algo estranho.

Por exemplo:

C:\Program Files\Fabricante\Aplicativo\Service.exe

Agora podemos verificar se esse arquivo realmente existe.

Também podemos conferir:

  • fabricante;
  • assinatura digital;
  • versão;
  • data;
  • localização.

Um caminho apontando para um arquivo inexistente representa uma pista muito forte.

START_TYPE

Outro campo importante é:

START_TYPE

Ele determina como o serviço deve iniciar.

Dependendo da configuração, podemos encontrar comportamentos correspondentes a:

  • inicialização automática;
  • automática com atraso;
  • manual;
  • desabilitado.

Um serviço configurado como Manual não está necessariamente com problema simplesmente porque está parado.

Esse detalhe é importante.

Muitos serviços modernos do Windows trabalham sob demanda.

Eles permanecem parados até que algum componente precise deles.

Portanto:

serviço parado não significa automaticamente serviço com defeito.

Essa é uma das interpretações equivocadas mais comuns durante diagnósticos do Windows.

DEPENDENCIES

Agora chegamos a uma das partes mais importantes:

DEPENDENCIES

Um serviço pode depender de outros componentes para funcionar.

Se uma dependência falhar, o serviço principal também poderá não iniciar.

Imagine:

Serviço A
   ↓
depende do Serviço B
   ↓
depende do Serviço C

Você tenta corrigir o Serviço A.

Mas o verdadeiro defeito está no Serviço C.

Enquanto o Serviço C não funcionar, o restante da cadeia poderá continuar apresentando falha.

Esse é justamente o tipo de situação na qual simplesmente clicar repetidamente em Iniciar não resolve o problema.

Precisamos seguir a cadeia de dependências.

SERVICE_START_NAME

O campo:

SERVICE_START_NAME

mostra a identidade utilizada pelo serviço.

Dependendo do serviço, ele pode funcionar com contas internas do Windows ou uma conta específica.

Esse detalhe se torna especialmente importante quando aparece uma falha relacionada a logon ou permissão.

Serviços corporativos e programas de terceiros podem utilizar contas específicas para acessar:

  • arquivos;
  • bancos de dados;
  • compartilhamentos de rede;
  • servidores;
  • certificados;
  • outros recursos protegidos.

Se as credenciais ou permissões mudarem, o executável pode continuar perfeitamente intacto e, mesmo assim, o serviço não iniciar.

Já temos um mapa inicial do problema

Até este ponto, ainda não fizemos nenhuma alteração agressiva no Windows.

Mesmo assim, já conseguimos descobrir:

  • nome interno do serviço;
  • nome exibido;
  • estado atual;
  • tipo de inicialização;
  • caminho utilizado para iniciar;
  • conta utilizada;
  • possíveis dependências;
  • código de saída;
  • comportamento durante a inicialização.

Isso já permite separar muitos problemas.

Mas ainda falta uma das partes mais poderosas do diagnóstico.

Precisamos descobrir o que aconteceu no momento exato em que o Windows tentou iniciar o serviço.

Para isso, na próxima parte vamos entrar no Visualizador de Eventos, analisar o Service Control Manager, correlacionar horário e Event ID e descobrir como diferenciar falha de dependência, timeout, erro de logon, executável ausente e encerramento inesperado.

Depois vamos cruzar essas informações com PowerShell e outros comandos para chegar à verdadeira causa da falha.

e:

O serviço iniciou e depois morreu

são problemas diferentes.

No segundo caso, precisamos procurar o motivo pelo qual o processo encerrou.

Pode existir:

  • exceção no programa;
  • DLL problemática;
  • arquivo de configuração corrompido;
  • dependência interna;
  • problema de banco de dados;
  • conflito com outro software;
  • falha de driver;
  • problema de permissão.

O evento do Service Control Manager registra a consequência.

Outro evento pode registrar a causa.

Event ID 7034 — serviço encerrou inesperadamente

Também podemos encontrar:

Event ID 7034

relacionado ao encerramento inesperado de um serviço.

Nesse momento, uma estratégia importante é procurar eventos no log Aplicativo registrados no mesmo segundo ou poucos segundos antes.

Procure especialmente informações que identifiquem:

nome do aplicativo com falha
nome do módulo com falha
código de exceção
caminho do aplicativo

Essas informações podem mudar completamente o rumo do diagnóstico.

Event ID 7040 — alteração no tipo de inicialização

Nem todo evento encontrado durante nossa pesquisa representa uma falha.

Por exemplo, eventos relacionados à alteração do tipo de inicialização podem aparecer quando alguma configuração de serviço foi modificada.

Isso é útil para investigação histórica.

Imagine que um serviço sempre funcionou.

De repente, parou de iniciar automaticamente.

Você verifica suas propriedades e descobre:

Tipo de inicialização: Desabilitado

A pergunta passa a ser:

Quando essa configuração mudou?

Um evento relacionado à alteração do tipo de inicialização pode ajudar a montar a linha do tempo.

Isso é diferente de simplesmente concluir que o serviço “quebrou”.

Talvez alguém ou algum software tenha mudado sua configuração.

Cuidado ao mudar serviços para Automático

Quando usuários encontram um serviço parado, uma reação comum é alterar:

Manual

para:

Automático

Isso nem sempre é correto.

O Windows 11 utiliza vários mecanismos de inicialização sob demanda.

Determinados serviços não precisam ficar permanentemente ativos.

Eles podem iniciar somente quando algum recurso solicita sua execução.

Portanto, o fato de um serviço estar configurado como Manual não representa necessariamente erro.

Antes de alterar o tipo de inicialização, descubra qual é a configuração esperada para aquele serviço específico.

Event ID 7045 — instalação de um serviço

Outro evento interessante para investigação histórica é o relacionado à instalação de serviços.

Isso pode ser útil quando o problema começou depois da instalação de algum programa.

Imagine esta sequência:

Segunda-feira — computador normal

Terça-feira — programa X instalado

Terça-feira — novo serviço criado

Quarta-feira — problema começou

Isso não prova automaticamente que o programa X causou o defeito.

Mas estabelece uma correlação temporal que merece investigação.

Em diagnósticos técnicos, uma boa linha do tempo vale muito.

Etapa 7 — Verifique se o executável do serviço também está falhando

Suponha que o evento indique que o serviço encerrou inesperadamente.

Agora precisamos identificar seu executável.

Execute:

sc qc NomeDoServico

Observe:

BINARY_PATH_NAME

Depois, volte ao:

Visualizador de Eventos
→ Logs do Windows
→ Aplicativo

Procure eventos relacionados ao executável.

Se encontrarmos uma falha de aplicativo no mesmo horário, podemos investigar:

  • aplicativo com falha;
  • módulo com falha;
  • código da exceção;
  • caminho do executável.

Isso começa a responder uma pergunta essencial:

O problema está no Windows Service Control Manager ou no programa executado como serviço?

Etapa 8 — Use o Monitor de Confiabilidade como segunda visão

Existe outra ferramenta do Windows muito útil nesse tipo de diagnóstico.

Pressione:

Windows + R

Digite:

perfmon /rel

Pressione Enter.

O Monitor de Confiabilidade apresenta uma linha do tempo com falhas de aplicativos, falhas do Windows e outros acontecimentos relevantes.

Ele não substitui o Visualizador de Eventos.

Mas pode facilitar a visualização de problemas recorrentes.

Imagine que um serviço falha todos os dias aproximadamente às 08:00.

O Monitor de Confiabilidade pode ajudar a perceber esse padrão.

Também pode mostrar que o executável associado apresenta falhas repetidas.

Etapa 9 — Descubra o PID do serviço

Se o serviço ainda estiver executando, ou permanecer algum tempo ativo antes de falhar, podemos tentar identificar seu PID.

Execute:

sc queryex NomeDoServico

Entre as informações apresentadas, procure:

PID

PID significa:

Process Identifier

ou identificador do processo.

Ele permite relacionar:

Serviço
↓
PID
↓
Processo

Essa associação será muito útil quando avançarmos para o Gerenciador de Tarefas e outras ferramentas.

Um serviço pode compartilhar processo com outros serviços

Aqui aparece um detalhe importante.

Nem todo serviço possui um processo exclusivo.

Diversos componentes do Windows podem utilizar:

svchost.exe

Por isso, simplesmente abrir o Gerenciador de Tarefas e encontrar svchost.exe nem sempre responde qual serviço estamos investigando.

Podemos usar:

tasklist /svc

Esse comando relaciona processos com serviços.

O resultado permite visualizar associações entre:

PID

e:

Serviços

Isso é especialmente útil quando precisamos entender qual instância de um processo está relacionada ao serviço problemático.

Etapa 10 — Consulte o serviço com PowerShell

O PowerShell oferece outra forma muito eficiente de investigar serviços.

Abra o Terminal como administrador e execute:

Get-Service -Name Spooler

O resultado mostra informações básicas como:

Status
Name
DisplayName

Para localizar serviços parados, podemos utilizar:

Get-Service | Where-Object Status -eq 'Stopped'

Mas lembre-se:

uma lista de serviços parados não é uma lista de serviços com defeito.

Muitos serviços permanecem parados normalmente até que sejam necessários.

Descobrindo serviços dependentes com PowerShell

Podemos consultar serviços que dependem de determinado serviço:

Get-Service -Name Spooler -DependentServices

Também podemos investigar serviços necessários para seu funcionamento:

Get-Service -Name Spooler -RequiredServices

Esses comandos ajudam a visualizar relações de dependência sem depender exclusivamente da interface gráfica.

Get-CimInstance oferece informações adicionais

Para uma investigação mais detalhada, podemos utilizar CIM.

Por exemplo:

Get-CimInstance Win32_Service -Filter "Name='Spooler'"

Podemos selecionar propriedades específicas:

Get-CimInstance Win32_Service -Filter "Name='Spooler'" |
Select-Object Name, DisplayName, State, StartMode, StartName, PathName, ProcessId

Esse comando reúne informações extremamente úteis:

Name
DisplayName
State
StartMode
StartName
PathName
ProcessId

Em uma única consulta conseguimos visualizar boa parte do mapa do serviço.

Como interpretar StartName

Observe especialmente:

StartName

Essa propriedade indica a identidade usada para executar o serviço.

Dependendo do serviço, podemos encontrar contas internas do Windows ou contas específicas configuradas pelo aplicativo.

Se o serviço utiliza uma conta personalizada, devemos considerar problemas relacionados a:

  • senha alterada;
  • conta bloqueada;
  • conta desativada;
  • direitos insuficientes;
  • acesso negado a arquivos;
  • acesso negado a recursos de rede.

Isso nos leva a outra categoria importante de falha.

Quando o problema é logon do serviço

Um serviço pode existir.

O executável pode estar correto.

As dependências podem funcionar.

Mesmo assim, ele pode não iniciar porque a identidade configurada não consegue realizar logon corretamente.

Isso aparece principalmente em ambientes nos quais programas utilizam contas específicas para executar serviços.

Nesses casos, mudar aleatoriamente a conta para uma conta administrativa não é uma boa solução.

Além de criar riscos de segurança, isso pode mascarar o problema original.

Precisamos descobrir:

Qual conta deveria executar o serviço?
Essa conta ainda existe?
Ela possui os direitos necessários?
A senha mudou?
O serviço consegue acessar os recursos de que precisa?

O Visualizador de Eventos novamente pode fornecer pistas importantes.

Monte uma linha do tempo do problema

Neste estágio, já conseguimos construir algo parecido com:

09:42:20
Usuário solicita inicialização do serviço

        ↓

09:42:21
Service Control Manager tenta iniciar

        ↓

09:42:22
Processo é criado

        ↓

09:42:23
Aplicativo registra uma falha

        ↓

09:42:23
Processo termina

        ↓

09:42:24
Service Control Manager registra encerramento inesperado

Agora temos algo muito mais útil do que:

"O serviço não funciona."

Temos uma sequência.

E essa sequência permite procurar a causa.

Não confunda causa com consequência

Esse é provavelmente um dos conceitos mais importantes deste tutorial.

Imagine que encontramos:

Serviço A não iniciou.

Isso pode ser consequência de:

Serviço B falhou.

Mas o Serviço B pode ter falhado porque:

Arquivo C não existe.

Nesse exemplo:

Serviço A parado = consequência

Serviço B falhando = consequência intermediária

Arquivo C ausente = possível causa raiz

Um bom diagnóstico tenta chegar o mais perto possível da causa raiz.

Até aqui, nosso diagnóstico ficou muito mais preciso

Agora conseguimos combinar:

services.msc

com:

sc query
sc queryex
sc qc
tasklist /svc

e PowerShell:

Get-Service
Get-CimInstance Win32_Service

além do:

Visualizador de Eventos

e:

Monitor de Confiabilidade

Essa combinação permite descobrir se estamos diante de:

  • serviço desabilitado;
  • dependência quebrada;
  • executável ausente;
  • processo encerrando;
  • timeout;
  • problema de conta;
  • falha do aplicativo;
  • configuração incorreta;
  • serviço simplesmente parado por comportamento normal.

Erros 1053, 1067, 1068, 1079, acesso negado e serviços presos em START_PENDING

Depois de identificar o serviço, consultar sua configuração e analisar o Visualizador de Eventos, normalmente chegamos a uma situação mais específica.

Em vez de simplesmente:

O serviço não inicia.

passamos a ter algo como:

Erro 1053

ou:

Erro 1067

ou ainda:

Erro 1068

Esses códigos ajudam bastante porque reduzem o número de possibilidades.

Mesmo assim, existe uma regra importante:

o código de erro indica o tipo de falha, mas nem sempre revela sozinho a causa raiz.

Por isso, devemos combinar:

código do erro
+
eventos
+
configuração do serviço
+
dependências
+
executável
+
permissões

Vamos analisar os cenários mais comuns.

Erro 1053 — o serviço não respondeu à solicitação de início ou controle em tempo hábil

Uma das mensagens mais conhecidas é semelhante a:

Erro 1053:
O serviço não respondeu à solicitação de início ou controle em tempo hábil.

Esse erro merece atenção porque muita gente interpreta da maneira errada.

O Erro 1053 não significa necessariamente que o serviço esteja completamente quebrado.

Ele indica que o Windows esperava determinada resposta do serviço e ela não aconteceu dentro do período esperado.

Podemos imaginar:

Windows solicita inicialização

        ↓

processo do serviço inicia

        ↓

Windows aguarda confirmação

        ↓

serviço demora demais

        ↓

timeout

        ↓

Erro 1053

A pergunta importante passa a ser:

por que ele demorou?

Possíveis causas de um Erro 1053

Entre as possibilidades estão:

  • aplicativo travado durante a inicialização;
  • dependência interna demorando;
  • acesso a banco de dados;
  • recurso de rede indisponível;
  • problema de DNS;
  • servidor remoto indisponível;
  • driver demorando para responder;
  • arquivo de configuração corrompido;
  • antivírus interferindo;
  • executável com problema;
  • biblioteca necessária falhando;
  • serviço mal desenvolvido;
  • atualização problemática.

Perceba que alterar simplesmente o tempo limite não deve ser a primeira ação.

Se o serviço está demorando porque existe uma falha interna, aumentar o timeout pode apenas fazer o Windows esperar mais tempo antes de apresentar o mesmo problema.

Primeiro teste para o Erro 1053

Execute:

sc queryex NomeDoServico

Observe principalmente:

STATE

Se durante a tentativa o serviço ficar em:

START_PENDING

significa que a solicitação de inicialização ocorreu, mas o serviço ainda não informou que concluiu o processo.

Observe também:

CHECKPOINT

e:

WAIT_HINT

Quando o serviço implementa corretamente esses mecanismos, eles podem fornecer pistas sobre o progresso da inicialização.

Se o valor de CHECKPOINT nunca muda enquanto o serviço permanece preso, isso pode indicar que o processo não está avançando.

Procure eventos próximos ao Erro 1053

Abra:

eventvwr.msc

e investigue:

Logs do Windows
→ Sistema

Procure eventos do:

Service Control Manager

naquele horário.

Depois, examine:

Logs do Windows
→ Aplicativo

Talvez o Service Control Manager registre o timeout enquanto o log Aplicativo apresenta a verdadeira falha.

Por exemplo:

10:17:22 — aplicação inicia
10:17:23 — erro de acesso ao banco
10:17:52 — serviço não respondeu
10:17:52 — Erro 1053

Nesse caso, o Erro 1053 seria apenas a consequência final.

Erro 1067 — o processo foi finalizado de forma inesperada

Outra mensagem bastante comum é:

Erro 1067:
O processo foi finalizado de forma inesperada.

Esse erro muda bastante nosso raciocínio.

Aqui, existe uma forte indicação de que o processo associado ao serviço chegou a ser iniciado, mas encerrou inesperadamente.

Podemos representar assim:

Windows solicita início

        ↓

executável inicia

        ↓

processo encontra um problema

        ↓

processo termina

        ↓

Erro 1067

Nesse cenário, investigar apenas services.msc raramente será suficiente.

Precisamos investigar o próprio aplicativo.

Como diagnosticar o Erro 1067

Comece descobrindo o executável:

sc qc NomeDoServico

Procure:

BINARY_PATH_NAME

Depois consulte:

Visualizador de Eventos
→ Logs do Windows
→ Aplicativo

Procure no mesmo horário por eventos que indiquem falha do programa.

Podemos encontrar informações relacionadas a:

Faulting application
Faulting module
Exception code
Application path

Dependendo do programa, ele também pode possuir logs próprios.

Procure logs específicos do aplicativo

Softwares que executam como serviço frequentemente criam arquivos de log próprios.

Eles podem estar em caminhos como:

C:\ProgramData\Fabricante\Programa\Logs

ou:

C:\Program Files\Programa\Logs

ou ainda:

C:\Users\Public\

O local varia conforme o desenvolvedor.

Programas de banco de dados, backup, VPN, monitoramento e segurança frequentemente possuem logs muito mais detalhados que o Windows.

Neles podemos encontrar mensagens como:

Cannot connect to database
Configuration file invalid
Port already in use
Permission denied
Certificate not found

Essas informações podem indicar diretamente a causa do Erro 1067.

Porta ocupada também pode derrubar um serviço

Alguns serviços precisam abrir uma porta TCP ou UDP durante a inicialização.

Imagine que determinado aplicativo precisa escutar na porta:

8080

Mas outro programa já está utilizando essa porta.

O serviço tenta iniciar.

Tenta abrir a porta.

Não consegue.

O programa encerra.

O Windows então registra algo parecido com:

Erro 1067

Nesse caso, o problema não está diretamente no mecanismo de serviços.

Está em uma disputa por um recurso.

Podemos investigar portas com:

netstat -ano

ou:

Get-NetTCPConnection

Depois, podemos relacionar o PID encontrado ao processo responsável.

Erro 1068 — falha ao iniciar serviço ou grupo de dependência

Outro erro muito importante é:

Erro 1068:
Não foi possível iniciar o serviço ou grupo de dependência.

Esse é um dos casos nos quais a palavra dependência deve guiar imediatamente o diagnóstico.

Imagine:

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

Você tenta iniciar A.

O Windows responde com Erro 1068.

O problema pode estar em B ou C.

Portanto, tentar reparar diretamente A pode ser perda de tempo.

Descubra as dependências

Execute:

sc qc NomeDoServico

Procure:

DEPENDENCIES

Também podemos usar PowerShell:

Get-Service -Name NomeDoServico -RequiredServices

Depois consulte cada dependência:

sc query NomeDaDependencia

ou:

Get-Service -Name NomeDaDependencia

O objetivo é descobrir:

Qual dependência está falhando primeiro?

Não inicie dependências aleatoriamente

Existe um erro comum durante esse diagnóstico.

O usuário identifica três dependências e tenta iniciar todas manualmente.

Isso pode não fazer sentido.

Alguns serviços podem funcionar sob demanda.

Outros podem depender de condições específicas.

A investigação correta consiste em descobrir:

  1. qual dependência deveria estar disponível;
  2. qual está falhando;
  3. qual erro aparece ao tentar iniciar essa dependência;
  4. se existe outra dependência abaixo dela.

Talvez o serviço que você começou investigando nem tenha problema.

Erro 1079 — conta do serviço diferente da conta de outros serviços relacionados

Outra mensagem que pode aparecer é:

Erro 1079

Esse erro costuma estar relacionado à identidade utilizada pelo serviço.

Em determinados cenários, a conta configurada para executar o serviço não corresponde ao que o Windows espera para aquele conjunto de serviços.

Antes de alterar qualquer coisa, abra:

services.msc

Clique duas vezes no serviço.

Abra a guia:

Logon

Observe a conta configurada.

Também podemos consultar:

Get-CimInstance Win32_Service -Filter "Name='NomeDoServico'" |
Select-Object Name, StartName

Compare essa configuração com a documentação apropriada para aquele serviço.

Não escolha “Sistema Local” apenas para tentar resolver

Um erro perigoso consiste em trocar qualquer conta problemática para:

Sistema Local

só porque ela possui muitos privilégios.

Isso pode criar riscos de segurança e ainda esconder o defeito real.

A conta utilizada por um serviço faz parte da arquitetura daquele componente.

Um serviço pode ser configurado para operar com:

  • LocalSystem;
  • LocalService;
  • NetworkService;
  • conta virtual;
  • conta de domínio;
  • usuário específico.

Cada modelo possui permissões e objetivos diferentes.

Mudar isso sem compreender o serviço pode criar um problema ainda maior.

Serviço apresenta “Acesso negado”

Outro cenário frequente ocorre quando tentamos iniciar ou controlar um serviço e recebemos:

Acesso negado

Antes de alterar ACLs ou Registro, verifique algo simples:

o Terminal foi aberto como administrador?

Muitos comandos de gerenciamento de serviços exigem elevação.

Abra:

Terminal

com:

Executar como administrador

e teste novamente.

Se continuar recebendo acesso negado, precisamos aprofundar a investigação.

Acesso negado ao controlar o serviço

Um serviço possui uma lista de controle de acesso própria.

Ou seja, usuários diferentes podem ter permissões diferentes para:

  • iniciar;
  • parar;
  • pausar;
  • consultar;
  • alterar configurações;
  • excluir.

Em ambientes corporativos ou após determinados softwares de segurança, essas permissões podem ter sido modificadas.

É possível consultar informações avançadas com ferramentas como:

sc sdshow NomeDoServico

O resultado utiliza SDDL, uma representação de descritores de segurança.

Esse conteúdo é mais avançado e não deve ser modificado sem conhecimento adequado.

Uma alteração errada nas permissões de um serviço pode impedir seu gerenciamento.

Acesso negado ao arquivo executável

Existe também outro cenário.

O Service Control Manager consegue localizar o arquivo, mas a identidade do serviço não possui permissão para acessá-lo.

Verifique o caminho:

sc qc NomeDoServico

Depois localize:

BINARY_PATH_NAME

As permissões NTFS do arquivo e das pastas do caminho podem influenciar sua execução.

Se alguém alterou permissões manualmente, o serviço pode deixar de conseguir:

  • ler o executável;
  • carregar DLLs;
  • acessar configuração;
  • gravar logs;
  • acessar dados.

Tome cuidado com TAKEOWN e ICACLS

Ferramentas como:

takeown

e:

icacls

são poderosas.

Mas não devem virar a primeira solução para qualquer mensagem de acesso negado.

Alterar proprietário e permissões de arquivos do Windows sem entender a configuração original pode causar novos problemas.

Antes de utilizar essas ferramentas, descubra:

Qual arquivo está gerando acesso negado?
Qual identidade precisa acessá-lo?
Qual deveria ser a permissão correta?

Somente depois faça alguma alteração.

Serviço preso em START_PENDING

Agora vamos analisar um cenário especialmente interessante.

Você executa:

sc query NomeDoServico

e recebe:

STATE : START_PENDING

Espera alguns segundos.

Executa novamente.

Continua:

START_PENDING

Isso indica que o serviço começou seu processo de inicialização, mas ainda não chegou ao estado:

RUNNING

O que pode deixar um serviço preso em START_PENDING?

Algumas possibilidades:

  • inicialização interna travada;
  • dependência esperando resposta;
  • acesso a rede;
  • conexão a banco de dados;
  • consulta DNS;
  • recurso remoto indisponível;
  • driver;
  • dispositivo;
  • arquivo bloqueado;
  • antivírus;
  • deadlock interno do programa;
  • componente externo.

Agora precisamos descobrir o que o processo está fazendo.

Descubra o PID

Execute:

sc queryex NomeDoServico

Procure:

PID

Com esse número, abra:

Gerenciador de Tarefas

ou execute:

tasklist /fi "PID eq 1234"

substituindo 1234 pelo PID real.

Isso confirma qual processo está ligado ao serviço.

Observe CPU, disco e rede

Se o serviço está preso em START_PENDING, observe o comportamento do processo.

No Gerenciador de Tarefas ou Monitor de Recursos, veja:

  • CPU;
  • disco;
  • rede;
  • memória.

Um processo parado em 0% de CPU não significa necessariamente que esteja travado.

Ele pode estar aguardando uma operação externa.

Mas o comportamento ajuda a formar hipóteses.

Por exemplo:

CPU baixa
+
rede ativa

pode indicar espera por comunicação.

Já:

CPU alta constantemente

pode indicar processamento excessivo ou loop.

Use o Monitor de Recursos

Pressione:

Windows + R

Digite:

resmon

O Monitor de Recursos pode mostrar detalhes de:

  • CPU;
  • disco;
  • rede;
  • memória.

Na guia Disco, podemos observar quais arquivos um processo está acessando.

Na guia Rede, podemos analisar conexões e atividade.

Essa informação pode indicar o recurso que está bloqueando a inicialização.

DLL ausente ou problemática pode impedir o serviço

Muitos executáveis dependem de bibliotecas DLL.

Quando o serviço inicia, o Windows precisa carregar diversas bibliotecas necessárias ao processo.

Se uma DLL estiver:

  • ausente;
  • incompatível;
  • corrompida;
  • bloqueada;
  • na versão errada;

o processo pode falhar.

Isso pode resultar em:

  • Erro 1067;
  • encerramento inesperado;
  • evento de Application Error;
  • falha registrada pelo próprio programa.

Mas existe uma recomendação importante:

não baixe DLLs isoladas de sites aleatórios.

Esse procedimento pode introduzir arquivos incorretos ou maliciosos no sistema.

A DLL correta deve vir do Windows, do instalador original do software ou de uma fonte oficial do fabricante.

Quando SFC faz sentido?

Muitos tutoriais recomendam imediatamente:

sfc /scannow

para qualquer problema no Windows.

O comando é útil, mas não deveria ser usado como explicação universal.

O SFC verifica arquivos protegidos do sistema Windows.

Ele pode ajudar quando existem evidências de corrupção em componentes do próprio Windows.

Por exemplo:

  • diversos serviços nativos falhando;
  • DLL do sistema corrompida;
  • componentes protegidos alterados;
  • erros relacionados a arquivos do Windows.

Nesse cenário, podemos executar em Terminal administrativo:

sfc /scannow

Depois, devemos observar o resultado apresentado.

Quando o SFC provavelmente não resolverá

Imagine um serviço de um aplicativo chamado:

MeuBackupService

e seu executável seja:

C:\Program Files\MeuBackup\backupservice.exe

Se esse arquivo estiver corrompido, o SFC provavelmente não irá repará-lo porque ele não pertence aos arquivos protegidos do Windows.

Nesse caso, o caminho correto pode envolver:

  • reparação do aplicativo;
  • reinstalação;
  • atualização;
  • restauração da configuração;
  • suporte do fabricante.

Essa distinção economiza bastante tempo.

Quando DISM faz sentido?

Outro comando frequentemente citado é:

DISM /Online /Cleanup-Image /RestoreHealth

O DISM pode reparar componentes da imagem do Windows utilizados, entre outras coisas, pelo próprio mecanismo de manutenção do sistema.

Ele pode ser relevante quando existe suspeita de corrupção na infraestrutura do Windows.

Uma abordagem comum em cenários apropriados pode ser:

DISM /Online /Cleanup-Image /RestoreHealth

seguido de:

sfc /scannow

Mas novamente:

DISM não corrige automaticamente qualquer serviço de terceiro.

Se o problema pertence ao executável, banco de dados ou configuração de um aplicativo específico, precisamos investigar esse aplicativo.

Serviço do Windows ou serviço de terceiro?

Essa separação é extremamente importante.

Primeiro descubra quem criou o serviço.

Execute:

sc qc NomeDoServico

Observe o caminho.

Se encontrarmos algo dentro de:

C:\Program Files\Fabricante\

provavelmente estamos diante de um serviço instalado por software de terceiro.

Também podemos verificar as propriedades do executável:

Botão direito
→ Propriedades
→ Assinaturas Digitais

ou:

Detalhes

Isso pode mostrar fabricante e versão.

Serviços de terceiro possuem sua própria lógica

Imagine um serviço de:

  • VPN;
  • banco de dados;
  • backup;
  • antivírus;
  • impressora;
  • software empresarial.

Ele pode depender de:

arquivo de configuração
licença
certificado
servidor
porta
banco de dados
credencial

O Windows pode apenas executar o programa.

Se o programa decide encerrar porque não encontra seu banco de dados, o Service Control Manager verá apenas que o serviço terminou.

Por isso, os logs do fabricante tornam-se fundamentais.

Não reinstale antes de coletar informações

Reinstalar um programa pode resolver determinadas falhas.

Mas existe um problema.

A reinstalação também pode apagar:

  • logs;
  • arquivos temporários;
  • configurações;
  • informações úteis para diagnóstico.

Quando possível, antes de reinstalar:

  1. registre o erro;
  2. exporte eventos;
  3. identifique o serviço;
  4. anote o executável;
  5. copie os logs relevantes;
  6. verifique versão do programa.

Depois disso, a reinstalação pode ser considerada com mais segurança.

Como consultar vários detalhes do serviço de uma vez

Podemos criar uma consulta simples no PowerShell:

Get-CimInstance Win32_Service -Filter "Name='NomeDoServico'" |
Select-Object Name,
              DisplayName,
              State,
              Status,
              StartMode,
              StartName,
              PathName,
              ProcessId,
              ExitCode

Isso apresenta um resumo bastante útil.

Podemos visualizar:

Nome
Estado
Modo de inicialização
Conta
Executável
PID
Código de saída

É praticamente uma ficha técnica do serviço.

Consulte também a saída do SC

Podemos combinar:

sc queryex NomeDoServico

com:

sc qc NomeDoServico

O primeiro responde principalmente:

Como ele está agora?

O segundo responde:

Como ele está configurado?

Esse conceito vale lembrar.

Um roteiro de diagnóstico para os principais erros

Podemos resumir nossa abordagem assim:

Erro 1053
↓
serviço demorou a responder
↓
ver START_PENDING
↓
ver Event Viewer
↓
investigar o que está atrasando a inicialização
Erro 1067
↓
processo terminou
↓
ver executável
↓
ver log Aplicativo
↓
ver logs do programa
↓
investigar DLL, configuração, porta, banco etc.
Erro 1068
↓
dependência falhou
↓
consultar DEPENDENCIES
↓
achar primeira dependência com problema
Erro 1079
↓
possível problema na identidade do serviço
↓
ver StartName
↓
comparar configuração esperada
Acesso negado
↓
confirmar elevação administrativa
↓
ver identidade
↓
ver permissões do serviço e arquivos
START_PENDING
↓
descobrir PID
↓
analisar processo
↓
ver CPU, disco, rede e eventos

Agora chegamos a um diagnóstico de nível muito mais profundo

Neste ponto já não estamos mais simplesmente tentando iniciar um serviço.

Estamos determinando:

  • se o processo realmente iniciou;
  • se ele caiu;
  • se ficou esperando;
  • se uma dependência falhou;
  • se a conta está incorreta;
  • se existe problema de permissão;
  • se existe corrupção no Windows;
  • se o problema pertence a software de terceiro;
  • se existe conflito de porta;
  • se o programa depende de outro recurso.

Essa mudança de abordagem é fundamental.

Em manutenção de computadores, a diferença entre tentativa e diagnóstico está justamente nisso:

não perguntar apenas “como faço o serviço iniciar?”, mas “o que impede esse serviço de chegar ao estado RUNNING?”

Process Monitor, Process Explorer, Autoruns, Registro e diagnóstico completo da causa raiz

Até aqui, já utilizamos ferramentas nativas do Windows para descobrir muita coisa sobre um serviço problemático.

Nós já sabemos verificar:

  • estado atual;
  • tipo de inicialização;
  • executável;
  • dependências;
  • conta utilizada;
  • PID;
  • códigos de saída;
  • eventos do Service Control Manager;
  • falhas no log Aplicativo;
  • erros 1053, 1067, 1068 e 1079;
  • situações de acesso negado;
  • serviços presos em START_PENDING;
  • quando SFC e DISM realmente fazem sentido.

Mas alguns problemas ainda permanecem difíceis.

Às vezes, o Visualizador de Eventos mostra apenas:

O serviço terminou inesperadamente.

Ou:

O processo foi finalizado.

Sem explicar exatamente o que o executável tentou fazer antes de falhar.

É nesse ponto que ferramentas mais avançadas podem revelar a causa.

Entre as mais úteis estão ferramentas da suíte Microsoft Sysinternals.

Principalmente:

Process Monitor
Process Explorer
Autoruns

Essas ferramentas permitem observar o que acontece por trás da interface do Windows.

O Process Monitor pode revelar o último erro antes da falha

O Process Monitor, também conhecido como Procmon, registra atividades como:

  • acesso a arquivos;
  • acesso ao Registro;
  • criação de processos;
  • carregamento de bibliotecas;
  • operações de rede específicas do processo;
  • resultados de chamadas realizadas pelo aplicativo.

Isso permite observar o que o serviço tentou fazer imediatamente antes de falhar.

Imagine que o serviço:

MeuServico.exe

encerra com Erro 1067.

O Visualizador de Eventos não fornece detalhes suficientes.

No Process Monitor, podemos descobrir que antes de encerrar ele tentou acessar:

C:\ProgramData\Empresa\Config\config.xml

e recebeu:

NAME NOT FOUND

Nesse caso, temos uma pista muito concreta.

O serviço pode estar encerrando porque o arquivo de configuração não existe.

Outro exemplo: acesso negado

Imagine o seguinte resultado:

C:\ProgramData\Empresa\Database\data.db

Resultado:

ACCESS DENIED

Agora temos uma hipótese diferente.

O arquivo existe.

Mas a identidade utilizada pelo serviço não consegue acessá-lo.

Isso aponta para problema de:

  • permissões NTFS;
  • conta do serviço;
  • proprietário;
  • política de segurança;
  • software de proteção.

Essa descoberta é muito mais útil do que simplesmente receber:

Erro 1067

Como usar o Process Monitor com um serviço

O ideal é capturar somente o período da falha.

O Process Monitor registra enorme quantidade de informações.

Se você deixá-lo funcionando por muito tempo sem filtros, terá milhares ou até milhões de eventos.

Por isso, primeiro descubra o executável do serviço:

sc qc NomeDoServico

Observe:

BINARY_PATH_NAME

Suponha que seja:

C:\Program Files\Empresa\MeuServico.exe

Agora abra o Process Monitor.

Pause a captura inicialmente.

Limpe os eventos existentes.

Crie um filtro para:

Process Name
is
MeuServico.exe

Depois inicie novamente a captura.

Volte ao:

services.msc

e tente iniciar o serviço.

Assim que a falha acontecer, pare a captura.

Agora você tem um intervalo muito menor para analisar.

Resultados importantes no Process Monitor

Alguns resultados merecem atenção.

Entre eles:

NAME NOT FOUND
PATH NOT FOUND
ACCESS DENIED
SHARING VIOLATION
BUFFER OVERFLOW
REPARSE

Mas não devemos interpretar todos como falhas fatais.

Aplicativos frequentemente tentam acessar arquivos ou chaves que não existem e depois usam outra alternativa.

Por isso, é importante observar a sequência.

O resultado:

NAME NOT FOUND

isoladamente não prova que aquele arquivo ausente causou a falha.

A pergunta correta é:

o que aconteceu imediatamente depois?

Procure o momento em que o processo termina

Se o serviço encerra inesperadamente, vá para o final da captura daquele processo.

Observe as últimas operações.

Imagine:

ReadFile → SUCCESS
RegOpenKey → SUCCESS
CreateFile config.ini → NAME NOT FOUND
CreateFile backup-config.ini → NAME NOT FOUND
Process Exit

Essa sequência torna o arquivo de configuração altamente suspeito.

Agora imagine:

CreateFile log.txt → ACCESS DENIED
RegOpenKey → ACCESS DENIED
Process Exit

Aqui, o problema pode estar relacionado a permissões.

Procure bibliotecas que falham ao carregar

Serviços também podem falhar durante o carregamento de DLLs.

O Process Monitor pode ajudar a visualizar buscas por arquivos DLL.

Imagine que o programa procure:

vendorlib.dll

em diferentes diretórios.

Se todas as tentativas retornarem:

NAME NOT FOUND

e logo depois o processo encerrar, essa biblioteca merece investigação.

Novamente:

não baixe a DLL aleatoriamente da Internet.

A solução correta pode envolver:

  • reparar o programa;
  • reinstalar o componente;
  • instalar redistribuível oficial;
  • restaurar dependência;
  • instalar atualização do fabricante.

Serviços podem depender do Microsoft Visual C++ Runtime

Aplicativos de terceiros frequentemente utilizam componentes do Microsoft Visual C++ Redistributable.

Quando determinada dependência necessária está ausente ou danificada, o serviço pode não iniciar corretamente.

Em vez de baixar DLL individualmente, o melhor caminho é identificar qual runtime o software exige e usar o instalador oficial apropriado.

O mesmo raciocínio vale para:

  • .NET;
  • Java;
  • drivers;
  • bibliotecas do fabricante;
  • componentes auxiliares.

Process Explorer: enxergando o processo de outra forma

Outra ferramenta útil da Sysinternals é o Process Explorer.

Ele oferece uma visão mais detalhada dos processos do que o Gerenciador de Tarefas tradicional.

Com ele podemos investigar:

  • processo;
  • PID;
  • processo pai;
  • usuário;
  • assinatura digital;
  • caminho;
  • DLLs carregadas;
  • handles abertos;
  • utilização de CPU.

Isso pode ser útil quando o serviço consegue permanecer ativo por alguns segundos antes de falhar.

Verifique a assinatura digital do executável

Imagine que determinado serviço aponta para:

C:\Program Files\Empresa\Service.exe

No Process Explorer ou nas propriedades do arquivo, verifique:

assinatura digital
empresa
versão

Isso ajuda a confirmar se aquele arquivo realmente pertence ao software esperado.

Também pode revelar situações estranhas nas quais o serviço aponta para um arquivo modificado ou não reconhecido.

Verifique o processo pai

Alguns serviços ou componentes criam processos filhos.

Isso pode produzir uma situação interessante:

Service.exe
    ↓
Worker.exe

O serviço principal pode permanecer ativo, mas o processo Worker.exe pode ser quem realmente falha.

Por isso, é importante observar a árvore de processos.

O Process Explorer torna essa relação muito mais clara.

Use Autoruns para investigar serviços registrados

Autoruns é outra ferramenta muito útil da Microsoft Sysinternals.

Ela mostra vários pontos de inicialização automática do Windows.

Entre eles, serviços e drivers registrados.

Isso é especialmente útil para descobrir:

  • serviços deixados por programas antigos;
  • drivers órfãos;
  • componentes iniciados automaticamente;
  • caminhos quebrados;
  • entradas de softwares removidos.

Como um serviço órfão aparece

Imagine que um programa foi desinstalado.

A pasta:

C:\Program Files\ProgramaAntigo\

foi removida.

Mas o Registro ainda possui uma entrada de serviço apontando para:

C:\Program Files\ProgramaAntigo\Service.exe

Agora, durante a inicialização do Windows, o Service Control Manager tenta iniciar aquele serviço.

Mas o arquivo não existe.

O resultado pode gerar erros recorrentes no log Sistema.

Esse é um exemplo clássico de serviço órfão.

Como identificar um serviço órfão com SC

Execute:

sc qc NomeDoServico

Observe:

BINARY_PATH_NAME

Depois verifique se o arquivo realmente existe.

Se o caminho não existir, investigue:

  • qual programa criou o serviço;
  • se o programa ainda está instalado;
  • se houve desinstalação incompleta;
  • se existe instalador oficial para reparar ou remover.

Evite simplesmente apagar a entrada imediatamente.

Primeiro descubra sua origem.

Onde os serviços ficam registrados no Registro

Informações sobre serviços podem ser encontradas em uma área importante do Registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Dentro dessa chave existem diversas subchaves correspondentes a serviços e drivers.

Por exemplo:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Spooler

Nessas chaves podemos encontrar valores relacionados a:

  • tipo;
  • inicialização;
  • caminho;
  • grupo;
  • dependências;
  • parâmetros.

Mas isso não significa que devemos editar o Registro diretamente como primeira solução.

O Registro deve ser usado principalmente para confirmação

Antes de alterar qualquer coisa no Registro, prefira primeiro:

sc qc
sc config

PowerShell

ou a interface services.msc, quando apropriado.

Essas ferramentas lidam com o serviço de maneira mais estruturada.

Editar diretamente:

HKLM\SYSTEM\CurrentControlSet\Services

sem compreender cada valor pode impedir a inicialização de componentes do Windows.

Valores importantes encontrados em serviços

Dependendo do serviço, podemos encontrar valores como:

ImagePath

que pode indicar o executável ou comando associado.

Também podemos encontrar:

Start

que representa o modo de inicialização em formato numérico.

Outras entradas podem representar:

  • dependências;
  • parâmetros;
  • nome de grupo;
  • conta;
  • configuração específica do serviço.

Não altere esses valores copiando números encontrados em tutoriais genéricos.

O valor correto depende do serviço.

Cuidado com CurrentControlSet

Ao explorar o Registro, podemos encontrar estruturas como:

ControlSet001
ControlSet002

e:

CurrentControlSet

Para diagnóstico do sistema em execução, normalmente trabalhamos com:

CurrentControlSet

porque ele representa o conjunto de controle atualmente utilizado pelo Windows.

Esse detalhe evita confusão durante investigações.

Como confirmar se o serviço realmente pertence ao programa esperado

Combine várias fontes.

Primeiro:

sc qc NomeDoServico

Depois:

Get-CimInstance Win32_Service -Filter "Name='NomeDoServico'" |
Select-Object Name, DisplayName, PathName, StartName

Depois verifique:

propriedades do executável
assinatura digital
fabricante
localização
Autoruns

Assim podemos criar uma relação:

Nome do serviço
↓
Executável
↓
Fabricante
↓
Programa instalado

O serviço existe, mas não deveria mais existir?

Esse cenário é importante.

Talvez você descubra que o serviço pertence a:

Programa X

Mas o Programa X foi removido há meses.

Nesse caso, provavelmente estamos diante de uma entrada residual.

Antes de removê-la:

  1. confirme que o programa realmente não está mais instalado;
  2. procure o desinstalador oficial;
  3. verifique se não existe outro componente dependente;
  4. exporte informações relevantes;
  5. crie um ponto de restauração quando apropriado.

Como excluir um serviço com SC

O Windows possui o comando:

sc delete NomeDoServico

Ele remove o registro daquele serviço.

Mas esse comando deve ser utilizado somente quando você tem certeza de que:

  • o serviço não é necessário;
  • pertence a software removido;
  • não possui dependências importantes;
  • você identificou corretamente sua origem.

Não use sc delete para “testar”.

Em serviços do Windows, a remoção indevida pode causar problemas graves.

Desabilitar não é o mesmo que excluir

Existe uma diferença importante.

Desabilitar um serviço mantém sua configuração no sistema, mas impede sua inicialização normal.

Excluir remove o registro do serviço.

Portanto:

desabilitar ≠ excluir

Quando ainda existe dúvida sobre a necessidade do serviço, remover definitivamente costuma ser uma escolha ruim.

Como usar Get-WinEvent para procurar falhas de serviços

Também podemos consultar eventos pelo PowerShell.

Por exemplo:

Get-WinEvent -LogName System |
Where-Object {$_.ProviderName -eq 'Service Control Manager'} |
Select-Object TimeCreated, Id, LevelDisplayName, Message

Esse comando lista eventos do Service Control Manager.

Em computadores com muitos eventos, pode ser interessante limitar o número de registros:

Get-WinEvent -LogName System -MaxEvents 200 |
Where-Object {$_.ProviderName -eq 'Service Control Manager'} |
Select-Object TimeCreated, Id, Message

Isso cria uma visão rápida dos eventos recentes.

Filtrando por Event ID

Também podemos procurar determinados IDs.

Por exemplo:

Get-WinEvent -FilterHashtable @{
    LogName='System'
    Id=7000,7001,7009,7011,7023,7031,7034
} |
Select-Object TimeCreated, Id, Message

Isso pode agilizar o diagnóstico.

Mas lembre-se de que existem muitos outros eventos possíveis.

Esses números não devem ser usados como uma lista definitiva.

Procure pelo nome do serviço nos eventos

Outra estratégia consiste em procurar o nome do serviço dentro da mensagem.

Exemplo:

Get-WinEvent -LogName System |
Where-Object {$_.Message -match 'NomeDoServico'} |
Select-Object TimeCreated, Id, Message

Isso pode revelar histórico de erros relacionados àquele serviço.

Dependendo do tamanho do log, a consulta pode demorar.

Descubra se o serviço falha somente na inicialização do Windows

Existe uma diferença importante entre:

Serviço não inicia durante o boot

e:

Serviço também não inicia manualmente depois.

Faça o teste.

Após o Windows terminar de carregar completamente, tente iniciar manualmente o serviço.

Se ele funcionar manualmente, mas falhar somente durante o boot, podemos suspeitar de:

  • dependência ainda indisponível;
  • rede não inicializada;
  • recurso remoto;
  • ordem de inicialização;
  • atraso necessário;
  • conflito temporário.

Isso muda o diagnóstico.

Inicialização Automática com Atraso

Alguns serviços podem ser configurados como:

Automático (Inicialização Atrasada)

Esse modo existe justamente para evitar que determinados serviços concorram com tudo que está carregando imediatamente após o boot.

Mas não devemos transformar qualquer serviço problemático em inicialização atrasada sem investigação.

Primeiro confirme se o fabricante ou a arquitetura do serviço permitem essa configuração.

Compare antes e depois de uma atualização

Se o serviço começou a falhar recentemente, construa uma linha do tempo.

Pergunte:

Quando funcionou pela última vez?

Depois verifique:

  • atualização do Windows;
  • atualização do programa;
  • atualização de driver;
  • antivírus;
  • mudança de senha;
  • alteração de rede;
  • instalação de software;
  • remoção de software.

O objetivo não é culpar automaticamente a última atualização.

É apenas procurar correlações.

Monitor de Confiabilidade ajuda a construir essa linha do tempo

Abra:

perfmon /rel

Observe os dias anteriores ao problema.

Procure:

  • instalações;
  • falhas de aplicativos;
  • falhas do Windows;
  • atualizações;
  • encerramentos inesperados.

Às vezes, encontramos uma sequência muito clara:

Dia 1 — atualização do programa
Dia 1 — serviço começa a falhar
Dia 2 — serviço continua falhando
Dia 3 — serviço continua falhando

Essa informação ajuda bastante.

Serviços podem falhar por certificados vencidos

Alguns serviços utilizam certificados para:

  • HTTPS;
  • autenticação;
  • comunicação segura;
  • assinatura;
  • conexão com servidor.

Se determinado certificado expirar, for removido ou ficar inacessível à conta do serviço, o aplicativo pode falhar durante a inicialização.

Isso aparece com mais frequência em:

  • servidores;
  • VPNs;
  • softwares empresariais;
  • agentes de segurança;
  • sistemas de backup.

Nesse caso, procure logs específicos do programa.

Serviços podem falhar por falta de espaço em disco

Outro problema aparentemente simples pode causar sintomas estranhos.

Verifique:

espaço livre na unidade do sistema

e na unidade onde o aplicativo grava dados.

Um serviço pode precisar criar:

  • logs;
  • banco de dados;
  • cache;
  • arquivos temporários;
  • arquivos de atualização.

Se não houver espaço suficiente, ele pode iniciar e encerrar.

O log do fabricante normalmente oferece pistas nesse cenário.

Arquivos bloqueados por outro processo

Imagine que o serviço precisa abrir:

database.db

com acesso exclusivo.

Mas outro processo já está utilizando o arquivo.

O serviço pode receber uma falha relacionada a compartilhamento.

No Process Monitor podemos encontrar:

SHARING VIOLATION

Nesse caso, precisamos descobrir qual processo possui o arquivo aberto.

Ferramentas como Process Explorer podem ajudar na investigação de handles.

Não mate processos indiscriminadamente

Se descobrir que determinado processo mantém um arquivo aberto, não encerre imediatamente o processo sem saber sua função.

Primeiro identifique:

  • o programa;
  • por que ele abriu o arquivo;
  • se o processo pode ser encerrado com segurança.

Encerrar processos do sistema ou aplicações que gravam dados pode causar corrupção ou perda de trabalho.

O serviço depende de rede?

Se o serviço se comunica com outro equipamento, servidor ou banco de dados remoto, teste a rede.

Podemos começar com:

ping servidor

Mas lembre-se:

ping sozinho não confirma que o serviço remoto está disponível.

Talvez o host responda a ICMP, mas a porta necessária esteja fechada.

PowerShell pode testar uma porta TCP:

Test-NetConnection servidor -Port 443

Substitua:

443

pela porta realmente utilizada pelo aplicativo.

Teste o DNS quando o serviço utiliza nomes

Imagine que a configuração utiliza:

servidor.empresa.local

Se a resolução DNS falhar, o serviço pode não encontrar o servidor.

Teste:

nslookup servidor.empresa.local

ou:

Resolve-DnsName servidor.empresa.local

Se o serviço funciona com IP, mas não funciona utilizando nome, o DNS merece investigação.

Não confunda problema de rede com problema do serviço

Imagine:

serviço inicia
↓
tenta conectar ao servidor
↓
servidor indisponível
↓
serviço encerra

O Windows pode registrar que o serviço terminou.

Mas o verdadeiro problema está na conectividade.

É por isso que o diagnóstico precisa olhar além do services.msc.

Um fluxo completo de diagnóstico de serviços

Agora podemos organizar tudo em um procedimento único.

1. Identifique o serviço

Abra:

services.msc

Anote:

  • nome exibido;
  • nome interno;
  • status;
  • tipo de inicialização.

2. Consulte o estado

Execute:

sc query NomeDoServico

Observe:

STATE
WIN32_EXIT_CODE
SERVICE_EXIT_CODE
CHECKPOINT
WAIT_HINT

3. Consulte a configuração

Execute:

sc qc NomeDoServico

Observe:

BINARY_PATH_NAME
START_TYPE
DEPENDENCIES
SERVICE_START_NAME

4. Tente reproduzir a falha

Anote o horário.

Tente iniciar o serviço.

Registre:

  • mensagem;
  • código;
  • comportamento.

5. Consulte o Visualizador de Eventos

Abra:

eventvwr.msc

Verifique:

Logs do Windows
→ Sistema

e:

Logs do Windows
→ Aplicativo

Procure eventos próximos ao horário da falha.

6. Verifique dependências

Execute:

Get-Service -Name NomeDoServico -RequiredServices

Consulte o estado de cada dependência.

7. Verifique o executável

Confirme se:

BINARY_PATH_NAME

existe.

Verifique:

  • assinatura;
  • fabricante;
  • versão;
  • permissões.

8. Descubra o PID

Execute:

sc queryex NomeDoServico

Se houver processo ativo, relacione PID e processo.

9. Consulte logs do fabricante

Procure logs específicos do software.

Eles podem revelar erros relacionados a:

  • banco;
  • arquivo;
  • porta;
  • certificado;
  • autenticação;
  • licença;
  • configuração.

10. Use Process Monitor quando necessário

Filtre pelo executável.

Reproduza o erro.

Observe as últimas operações antes da falha.

Procure:

ACCESS DENIED
NAME NOT FOUND
PATH NOT FOUND
SHARING VIOLATION

sempre analisando o contexto.

11. Investigue rede se o serviço depende dela

Teste:

ping
nslookup

e:

Test-NetConnection

conforme o caso.

12. Só então pense em reparo

Dependendo da causa, a solução pode envolver:

  • corrigir permissões;
  • restaurar arquivo;
  • reparar aplicativo;
  • reinstalar componente;
  • corrigir dependência;
  • liberar porta;
  • corrigir rede;
  • atualizar software;
  • corrigir credenciais;
  • reparar arquivos do Windows;
  • remover serviço órfão.

A solução deve ser consequência do diagnóstico.

Exemplo prático de diagnóstico completo

Imagine o seguinte cenário:

Serviço: BackupAgent
Status: Parado
Erro ao iniciar: 1067

Primeiro:

sc qc BackupAgent

Resultado:

BINARY_PATH_NAME:
C:\Program Files\BackupAgent\agent.exe

O arquivo existe.

Depois:

sc queryex BackupAgent

Durante a tentativa, o processo aparece e logo desaparece.

No Visualizador de Eventos encontramos:

Application Error

no mesmo horário.

Depois abrimos o log do aplicativo e encontramos:

Cannot open configuration database

No Process Monitor:

C:\ProgramData\BackupAgent\config.db
ACCESS DENIED

Agora temos uma cadeia clara:

serviço inicia
↓
processo abre
↓
tenta acessar config.db
↓
recebe ACCESS DENIED
↓
processo encerra
↓
Windows apresenta Erro 1067

A causa raiz não era:

Erro 1067

Era:

permissão incorreta no arquivo config.db

Esse é o objetivo de um diagnóstico técnico bem feito.

Outro exemplo: serviço aparentemente quebrado, mas problema é DNS

Imagine:

Serviço: SyncAgent
Erro: 1053

O serviço precisa conectar a:

api.empresa.local

No log encontramos:

Unable to resolve host

Testamos:

nslookup api.empresa.local

e a resolução falha.

Agora o problema não é o serviço em si.

O serviço está esperando um recurso que não consegue encontrar.

A causa está no DNS.

Outro exemplo: serviço órfão

Imagine que o log registre falha diária ao iniciar:

OldPrinterService

Executamos:

sc qc OldPrinterService

e encontramos:

C:\Program Files\OldPrinter\Service.exe

Mas a pasta não existe.

O programa foi removido há meses.

Nesse caso, temos fortes indícios de um serviço residual.

Agora podemos investigar se existe desinstalador oficial ou, após confirmação, considerar a remoção da entrada.

O diagnóstico deve sempre responder três perguntas

Ao terminar, tente responder:

1. O que o Windows tentou fazer?

Exemplo:

Iniciar o serviço X

2. Onde exatamente ocorreu a falha?

Exemplo:

o executável tentou abrir um arquivo e recebeu acesso negado

3. Qual é a causa raiz provável?

Exemplo:

permissão NTFS incorreta

Se conseguimos responder essas três perguntas, já estamos muito perto de uma solução correta.

Evite soluções genéricas

Frases como:

reinicie o computador
execute SFC
execute DISM
reinstale tudo
mude para Automático

podem eventualmente resolver alguma coisa.

Mas sem diagnóstico, elas não explicam o problema.

A abordagem técnica deve ser:

sintoma
↓
evidência
↓
causa
↓
correção

e não:

sintoma
↓
tentativas aleatórias

Conclusão

Quando um serviço do Windows 11 não inicia, o problema pode estar muito além da janela services.msc.

Um serviço pode falhar por causa de:

  • dependências;
  • executável ausente;
  • biblioteca faltando;
  • configuração corrompida;
  • credenciais;
  • permissões;
  • timeout;
  • falha de rede;
  • DNS;
  • porta ocupada;
  • banco de dados;
  • certificado;
  • aplicação de terceiro;
  • serviço órfão.

O Windows possui diversas ferramentas capazes de revelar essas causas.

Comandos como:

sc query
sc queryex
sc qc
tasklist /svc

combinados com:

Get-Service
Get-CimInstance
Get-WinEvent

e ferramentas como:

Visualizador de Eventos
Process Monitor
Process Explorer
Autoruns
Monitor de Confiabilidade

transformam uma mensagem genérica em um diagnóstico muito mais preciso.

O objetivo nunca deve ser apenas obrigar o serviço a iniciar.

O objetivo correto é descobrir:

o que impede o serviço de atingir e manter o estado RUNNING.

Quando a causa é identificada, a solução deixa de ser tentativa e passa a ser consequência lógica do diagnóstico.

Perguntas frequentes

Um serviço parado significa que existe um problema?

Não.

Muitos serviços utilizam inicialização manual ou sob demanda e permanecem parados até que algum componente realmente precise deles.

O estado STOPPED sozinho não significa defeito.

Posso colocar todos os serviços em Automático?

Não.

Isso pode aumentar consumo de recursos e alterar o comportamento esperado do Windows.

Cada serviço possui uma configuração apropriada.

O que significa START_PENDING?

Significa que o serviço recebeu a solicitação para iniciar, mas ainda não concluiu sua inicialização.

Se permanecer assim por muito tempo, devemos investigar timeout, dependências e o processo associado.

Erro 1067 significa que o Windows está corrompido?

Não necessariamente.

Ele indica que o processo terminou inesperadamente.

O problema pode estar no próprio aplicativo, em arquivos, permissões, banco de dados, porta, biblioteca ou outro componente.

O Erro 1068 significa problema de dependência?

Sim, ele normalmente aponta para falha em serviço ou grupo de dependência.

É importante investigar a cadeia de dependências e descobrir qual componente falhou primeiro.

SFC corrige qualquer serviço?

Não.

SFC verifica e repara determinados arquivos protegidos do Windows.

Ele não corrige automaticamente executáveis e configurações de programas de terceiros.

DISM resolve serviços que não iniciam?

Pode ajudar quando o problema envolve corrupção de componentes do Windows.

Mas não é uma solução universal para serviços de programas externos.

Posso apagar um serviço que dá erro?

Somente depois de confirmar que ele realmente não é mais necessário.

Serviços pertencentes ao Windows ou a programas ainda instalados não devem ser removidos aleatoriamente.

Process Monitor é seguro?

É uma ferramenta de diagnóstico da Microsoft Sysinternals.

O principal cuidado está na interpretação: ele mostra enorme quantidade de operações normais e erros que podem fazer parte do funcionamento comum de um programa.

NAME NOT FOUND no Process Monitor significa problema?

Não obrigatoriamente.

Programas frequentemente procuram arquivos ou chaves opcionais que não existem.

É preciso analisar o que ocorre depois e se a ausência está realmente relacionada à falha.

ACCESS DENIED no Process Monitor é mais importante?

Pode ser bastante relevante, principalmente se aparece imediatamente antes da falha.

Mas ainda devemos descobrir qual conta está executando o processo e qual permissão deveria existir.

O serviço pode falhar por problema de DNS?

Sim.

Serviços que dependem de servidores remotos ou recursos de rede podem falhar ou entrar em timeout quando a resolução de nomes não funciona.

Uma porta ocupada pode impedir um serviço de iniciar?

Sim.

Se o serviço precisa escutar em determinada porta e ela já está sendo usada, ele pode falhar durante a inicialização.

Onde encontro informações de serviços no Registro?

Uma das áreas principais é:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Mas alterações diretas devem ser feitas somente com conhecimento técnico e quando realmente necessárias.

Precisa descobrir por que um serviço do Windows 11 não inicia?

Um serviço que falha pode afetar impressão, rede, programas, backups, atualizações, acesso remoto e diversos outros recursos do computador.

A VMIA realiza diagnóstico técnico de problemas no Windows, programas, impressoras e redes, incluindo investigação de serviços que não iniciam, erros de dependência, falhas de aplicativos e problemas de configuração.

O atendimento pode ser realizado por acesso remoto, visita técnica agendada ou com o equipamento levado até a VMIA.

VMIA – Manutenção e Configuração

Site: https://vmia.site

Blog: https://vmia.com.br

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

Telefone/WhatsApp: (11) 99779-7772

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

Atendimento com agendamento.

Seja o primeiro a comentar

Faça um comentário

Seu e-mail não será publicado.


*