Netlogon e Workstation não iniciam no Windows: diagnóstico e correção segura com SMBv2/mrxsmb20

Ao iniciar o Windows, o serviço Workstation (LanmanWorkstation) e, em cascata, o Netlogon podem falhar. Este guia mostra como diagnosticar dependências quebradas e restaurar o funcionamento com segurança, priorizando SMBv2/SMBv3 e evitando riscos com SMBv1.

Índice

Entendendo o problema

Quando o Workstation não inicia, o cliente SMB do Windows deixa de funcionar e acesso a compartilhamentos de rede falha. Em máquinas ingressadas no domínio, o Netlogon depende do Workstation para autenticação segura com controladores de domínio; assim, o Netlogon também não sobe ou cai logo após o boot. O resultado típico é a falha de mapeamento de unidades, GPOs não aplicadas e erros de logon de domínio.

Como os componentes se encaixam

Componente	Nome do serviço/driver	Função	Impacto se falhar
Cliente SMB	Workstation (LanmanWorkstation)	Cliente para acesso a compartilhamentos SMB.	Não monta compartilhamentos, falha em `net use`.
SMBv2/3	MRxSmb20 (`mrxsmb20`)	Driver do redirector SMB moderno (v2/v3).	Sem ele, Workstation não inicia corretamente.
Interface de Rede	NSI (`nsi`)	Driver Network Store Interface, base do stack de rede.	Serviços de rede em cascata não sobem.
Netlogon	Netlogon (`netlogon`)	Canal seguro com o AD; registro e localização de DC.	Ingressos de domínio e logons do AD falham.
SMBv1 (legado)	MRxSmb10 (`mrxsmb10`)	Driver do redirector SMB v1 (obsoleto).	Não é necessário em sistemas modernos; risco de segurança.

Sintomas comuns

Erro ao mapear unidades: System error 67 ou System error 53.
Falha em net use \\servidor\compartilhamento.
Eventos no Visualizador de Eventos > System (Service Control Manager) como 7000, 7001, 7023, 7036.
Em PCs no domínio: GPOs não aplicam, horário não sincroniza, logon de domínio demora ou falha.

Diagnóstico prático e direto

Comece inspecionando configurações e dependências. Use um Prompt de Comando elevado:

sc.exe qc lanmanworkstation
sc.exe qc bowser
sc.exe qc mrxsmb10
sc.exe qc mrxsmb20
sc.exe qc nsi
sc.exe qc netlogon

O objetivo é identificar se alguma dependência essencial está desabilitada (START_TYPE = DISABLED). Em versões recentes do Windows, bowser pode não existir — se não aparecer, ignore.

Como ler a saída

Campo	O que observar	Ação recomendada
START_TYPE	Se estiver DISABLED para `nsi` ou `mrxsmb20`.	Reabilitar (qualquer modo diferente de disabled já resolve).
DEPENDENCIES	Se `LanmanWorkstation` lista `mrxsmb20` e `nsi`.	Garantir que ambos não estejam desabilitados.
SERVICE_NAME	Conferir se `lanmanworkstation` e `netlogon` estão presentes.	Em imagens reduzidas, reinstale componentes de recursos se necessário.

Correção observada em um caso real

Em um cenário relatado, o driver SMBv1 (MRxSmb10) estava desabilitado e, após habilitá-lo, o Workstation voltou a iniciar:

sc.exe config mrxsmb10 start= auto
shutdown /r

Embora isso tenha resolvido naquela máquina, não é a abordagem recomendada em sistemas modernos. Veja o alerta a seguir.

Alerta importante de segurança

Evite habilitar SMBv1 (mrxsmb10) em Windows atuais: é obsoleto e eleva significativamente a superfície de ataque.
Acima do Windows 7/Server 2008 R2, o Workstation não depende do SMBv1 para iniciar; utiliza SMBv2/3 via mrxsmb20.
Portanto, priorize corrigir mrxsmb20 e nsi, garantindo que não estejam desabilitados. Considere SMBv1 apenas em cenários legados estritamente necessários, temporários e devidamente isolados.

Correção recomendada e segura

No mesmo Prompt de Comando elevado, execute:

sc.exe config nsi start= auto
sc.exe config mrxsmb20 start= auto
sc.exe config lanmanworkstation start= auto
sc.exe config netlogon start= demand
shutdown /r

Esses comandos garantem que os drivers/serviços essenciais não estejam desabilitados. O reinício aplica as alterações de inicialização.

Checklist rápido

Rode sc.exe qc lanmanworkstation e anote as dependências listadas.
Confirme que NSI e MRxSmb20 não estão “disabled”.
Se estiverem desabilitados, reabilite-os para auto (ou manual) e reinicie.
Evite habilitar MRxSmb10 (SMBv1). Se a rede ainda exigir SMBv1, trate como exceção: habilite apenas nesse host, segmente a rede e planeje migração para SMBv2/3.
Verifique o Visualizador de Eventos > System (Service Control Manager) para confirmar a inicialização correta.

Guia passo a passo detalhado

Passo 1 — Mapear dependências e estados

sc.exe qc lanmanworkstation
sc.exe qc mrxsmb20
sc.exe qc nsi
sc.exe queryex type= service state= all | findstr /i "workstation netlogon"

Procure por START_TYPE em nsi e mrxsmb20. Se qualquer um aparecer como DISABLED, é o causador mais provável.

Passo 2 — Reabilitar drivers/serviços essenciais

sc.exe config nsi start= auto
sc.exe config mrxsmb20 start= auto
sc.exe config lanmanworkstation start= auto

Se sua estação faz parte de um domínio e o netlogon foi afetado, garanta que ele não esteja desabilitado:

sc.exe config netlogon start= demand

Passo 3 — Validar com o Visualizador de Eventos

Abra eventvwr.msc > Windows Logs > System e filtre por IDs: 7000, 7001, 7023, 7036. Confira qual dependência falhou. Como alternativa, use:

wevtutil qe System /q:"*[System[Provider[@Name='Service Control Manager'] and (EventID=7000 or EventID=7001 or EventID=7023 or EventID=7036)]]" /f:text /c:20

Passo 4 — Testes pós-correção

Verificar status: sc.exe query lanmanworkstation sc.exe query netlogon
Testar acesso SMB: net use * \<servidor><compartilhamento> /user:<domínio\usuário>
Em máquinas no domínio, validar canal seguro: nltest /scverify:<SEUDOMINIO> nltest /dsgetdc:<SEU_DOMINIO>

PowerShell para checagem e correção automática

Para admins que preferem PowerShell, o snippet a seguir verifica estados e corrige o mínimo necessário sem habilitar SMBv1. Execute em janela do PowerShell como Administrador.

# QuickFix-NetlogonWorkstation.ps1
$targets = @('nsi','mrxsmb20','lanmanworkstation')
foreach($name in $targets){
  $qc = (sc.exe qc $name) -join "`n"
  if($qc -match 'START_TYPE\s:\sDISABLED'){
    Write-Host "Reabilitando $name..."
    sc.exe config $name start= auto | Out-Null
  } else {
    Write-Host "$name já não está desabilitado."
  }
}
Garantir Netlogon não desabilitado (modo demanda é suficiente)
$qcN = (sc.exe qc netlogon) -join "`n"
if($qcN -match 'START_TYPE\s:\sDISABLED'){
  sc.exe config netlogon start= demand | Out-Null
}
Write-Host "Concluído. Reinicie o computador para aplicar as alterações."

Quando considerar SMBv1 e como mitigar

Somente para interoperar com um NAS ou dispositivo muito legado ainda preso ao SMBv1 e sem possibilidade de atualização. Se for inevitável:

Restrinja o escopo: habilite SMBv1 apenas na máquina que precisa acessar o legado.
Segmente a rede: VLAN isolada, firewall restritivo, sem acesso amplo à LAN.
Planeje a migração: substitua o dispositivo legado, programe janelas e testes.
Desabilite SMBv1 assim que a necessidade terminar.

Nesse cenário excepcional, o comando é:

sc.exe config mrxsmb10 start= auto
shutdown /r

Importante: volte a desabilitar SMBv1 quando possível. Em muitas edições do Windows, SMBv1 é um recurso opcional; remova-o pelas Opções de Recursos do sistema se estiver instalado.

Causas-raiz típicas

Ajustes incorretos ou “otimizadores” que desabilitam drivers/serviços críticos como nsi ou mrxsmb20.
Imagem ou hardening inconsistente (GPO/SecBaseline) que altera StartType de drivers.
Atualizações incompletas ou interrupções durante o boot que corrompem a pilha de rede.
Arquivos de sistema corrompidos.

Medidas corretivas adicionais:

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

Boas práticas e diferenças entre versões

Sistema	SMBv1 por padrão	Presença de Bowser	Recomendação
Windows 7/Server 2008 R2	Instalado/ativado em muitas edições.	Pode existir.	Planeje atualização; habilite SMBv1 só se estritamente necessário e isole.
Windows 10/11 e Server modernos	Não instalado/ativado por padrão.	Ausente.	Use SMBv2/3 (`mrxsmb20`); não ative SMBv1.

Validações adicionais úteis

Confirmar a ordem do provedor de rede (raramente necessário, mas útil se alguém “otimizou” a pilha): reg query "HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order" /v ProviderOrder Verifique se LanmanWorkstation consta na lista. Não altere sem ter certeza do que está fazendo.
Checar se SMBv1 está ativo no cliente SMB (PowerShell): Get-SmbClientConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol
Listar conexões SMB ativas: Get-SmbConnection

Resolução de problemas persistentes

Persistem eventos 7001/7000 para Workstation ou Netlogon? Volte ao Event Viewer e identifique a dependência exata no texto do evento (o SCM costuma listar qual serviço/driver não iniciou).
Falha intermitente logo após o boot? Em ambientes com muitos drivers de rede, aumente o tempo de inicialização de serviços (valor ServicesPipeTimeout), apenas se o log indicar timeout: reg add "HKLM\SYSTEM\CurrentControlSet\Control" /v ServicesPipeTimeout /t REG_DWORD /d 60000 /f Reinicie e reavalie. Evite valores muito altos.
Máquina no domínio continua com Netlogon falhando? Repare o canal seguro: PowerShell: Test-ComputerSecureChannel -Repair -Credential <DOMÍNIO\Administrador>

Perguntas frequentes

É obrigatório o Netlogon em computador fora de domínio?
Não. Em estações de trabalho não ingressadas no AD, o Netlogon fica no modo Manual (Trigger Start) e inicia sob demanda. Já o Workstation deve estar operacional para acesso SMB.

Posso deixar o Workstation em “Automático”?
Sim. É o padrão recomendado para clientes Windows e servidores de arquivos.

O Bowser precisa existir?
Nas versões recentes, não. Se o comando sc qc bowser retornar inexistente, simplesmente ignore.

Habilitar o SMBv1 vai “resolver de vez”?
Pode mascarar o problema, mas adiciona um risco de segurança desnecessário. Corrija o que importa: mrxsmb20 e nsi.

Resumo operacional

Mapeie dependências de LanmanWorkstation.
Garanta nsi e mrxsmb20 habilitados (não “disabled”).
Evite SMBv1; use-o apenas como exceção, temporário e isolado.
Reinicie e valide com logs e testes SMB.

Comandos essenciais reunidos

:: Consultas
sc.exe qc lanmanworkstation
sc.exe qc mrxsmb20
sc.exe qc nsi
sc.exe qc netlogon
:: Correções mínimas e seguras
sc.exe config nsi start= auto
sc.exe config mrxsmb20 start= auto
sc.exe config lanmanworkstation start= auto
sc.exe config netlogon start= demand
shutdown /r
:: Exceção legada (evite)
sc.exe config mrxsmb10 start= auto
shutdown /r

Observações finais

O item bowser pode não existir em versões recentes do Windows; se não aparecer, ignore.
Se o problema persistir, consulte o Visualizador de Eventos > System (eventos do Service Control Manager) para identificar exatamente qual dependência falhou.
Antes de qualquer alteração em massa, teste em uma máquina piloto.