Desde cerca de 8 a 10 meses atrás, temos enfrentado problemas estranhos com impressoras que culminaram neste mês com uma enorme quantidade de erros que envolveram a maior parte da empresa e que nos permitiram identificar os principais problemas: em algumas máquinas (~7- 8%) às vezes, após a reinicialização, algo acontece com o Spooler de impressão que faz com que as impressoras não sejam anunciadas/disponíveis via endereço IP, apenas via nome de host.
Especificamente, o problema se apresenta de três maneiras:
Ao enviar uma impressão de um servidor Linux, o servidor receberá um erro e o log de eventos terá o seguinte erro "Automático O serviço Line Printer Daemon (LPD) recusou um trabalho de impressão de %LINUXSERVERIP% para a impressora \%WindowsIP%%PrinterName% porque a impressora especificada não existe neste computador."
Ao tentar mapear uma impressora no Windows Explorer acessando a máquina Windows com \%WindowsIP%\ no Windows Explorer, a impressora ficará visível, mas tentar adicioná-la resultará no erro "A operação não pôde ser concluída (erro 0x00000709)". que geralmente está associado ao KBKB5006670, mas não está instalado em nossas máquinas e as primeiras instâncias do erro mencionado são de dezembro de 2021/janeiro de 2022, muito antes mesmo desse patch ser lançado
Ao executar o comando do PowerShell Get-Printer -Computername% WindowsIP%. Se o comando for executado com o nome do host da máquina então o resultado está correto (uma lista de impressoras compartilhadas), se for executado com o endereço IP da máquina então gera o seguinte erro:
+ CategoryInfo : NotSpecified: (MSFT_Printer:ROOT/StandardCimv2/MSFT_Printer) [Get-Printer], CimException + FullyQualifiedErrorId : HRESULT 0x8007007b,Get-Printer
E o mais chato é: se você reiniciar o Spooler Service o problema desaparece completamente até a próxima reinicialização...
A pesquisa no Google não resultou em muito sucesso, exceto por uma única mensagem sem resposta:https://hardforum.com/threads/weird-network-printing-problem.1635293/
Existe um XKCD para tudo, não é?https://xkcd.com/979/
Análises adicionais foram realizadas com Procmon, Wireshark, Process Explorer, WinDbg e xbootmgr com os seguintes resultados:
Procmon:
- A análise de spoolsv.exe durante a execução de Get-Printer %WindowsIP% de outro computador não mostra outras ações além da comunicação de rede
- A análise de spoolsv.exe durante a adição de impressora compartilhada por meio do Windows Explorer mostra a conexão de rede e algumas RegQueryKey para HKU%SIDOFREMOTEACCOUNT% e HKU.DEFAULT\Printers\Connections,,%WINDOWSIP%,%PRINTERNAME% com resultado de "NAME NOT FOUND" mas nada mais
- A tentativa de análise de spoolsv.exe durante a inicialização por meio de Habilitar registro de inicialização foi bem-sucedida, mas inútil devido ao problema não aparecer ao inicializar com essa opção habilitada
- Análise adicional foi tentada por meio da função de resumo de pilha para rastrear a pilha a partir de spoolsv.exe, mas a única diferença perceptível no thread que era comum entre o despejo procmon funcional e não funcional era a presença de uma ramificação adicional chamada EatAuthInfoFromPacket no despejo do serviço de trabalho.
Wireshark:
- A análise superficial do fluxo de tráfego durante a execução do Get-Printer a partir de uma máquina remota mostra a solicitação do Winspool_AsyncEnumPrinters e a resposta do Winspool_AsyncEnumPrinters com o protocolo IREMOTEWINSPOOL, mas nenhuma informação adicional e os dados do stub aparecem criptografados, por isso não consigo obter informações adicionais dele
Explorador de processos
- Foi feita uma análise superficial do processo spoolsv.exe e seus Threads e Stack e o único ponto interessante foi que nas Strings do processo spoolsv.exe havia \machinehostname e \machinehostname.domain.com quando estava quebrado e nada quando não foi. Mas tenho que admitir que meu conhecimento do Windows Internals é insuficiente para entender completamente isso. A OpenAI tem ajudado com as explicações!
WinDbg
- O depurador foi anexado ao processo spoolsv.exe e o teste foi feito com Get-Printer de uma máquina remota e tentativa de mapear a impressora por meio do Windows Explorer, mas em ambos os casos nenhuma mensagem de depuração estava visível durante a execução. Além disso, criei um despejo de processo no Process Explorer e o enviei ao WindDbg para executar o comando !analyze, mas ele retornou apenas um ponto de interrupção, sem erro real. Como antes, sou novo nesta ferramenta, então se você tiver alguma sugestão ficarei feliz em aceitá-la!
xbootmgr
- xbootmgr -trace boot -traceflags dispatcher+latency -stackwalk readythread+threadcreate+profile+cswitch foi executado para depurar o serviço durante a inicialização, mas, assim como o Procmon, quando a máquina reinicia com esse rastreamento no problema não se apresenta, então o a saída é bastante inútil
E assim este é o resumo. Estou um pouco perdido e nem o Google nem o OpenAI parecem ter alguma ideia do que está acontecendo aqui, então agradeceria qualquer informação que você pudesse fornecer sobre solução de problemas adicionais para esse problema ou talvez uma solução, caso você já tenha enfrentado isso antes.
Responder1
Se outra pessoa tiver o problema, aqui está a resposta da Microsoft:
A Causa (história por trás) tem vários níveis. Este é o resumo básico. Inicialização do serviço Houve muitas mudanças no Windows para melhorar os tempos de inicialização do serviço na inicialização. Isso permite que alguns serviços sejam iniciados mais cedo do que no passado. Um serviço pode falhar ao iniciar se tiver uma dependência de rede e atingir o tempo limite antes que o DAD seja concluído e a interface e o IP estejam prontos para uso. Hardware Melhorias no hardware do computador são um fator importante. Todos os processadores modernos possuem múltiplos núcleos/threads, permitindo o processamento paralelo de tarefas do sistema operacional. A velocidade dos processadores também aumentou dramaticamente. Essas mudanças permitem que um sistema operacional como o Windows execute múltiplas tarefas de forma mais rápida e paralela, melhorando assim drasticamente o tempo de início do serviço. A quantidade de RAM disponível aumentou rapidamente. Isso significa menos paginação em disco, melhorando também o tempo de inicialização. A melhoria mais significativa foi no armazenamento. O armazenamento agora é baseado principalmente em flash (SSD) e normalmente usa uma interconexão NVMe de alta velocidade. Até mesmo back-ends de armazenamento, como NAS ou SAN, são totalmente baseados em flash atualmente. As melhorias de E/S, latência e rendimento entre discos spinny antigos (HDD) e SSDs NVMe são em uma ordem de magnitude cerca de 150 vezes mais rápidas. Essa mudança aconteceu em um intervalo de tempo inferior a 10 anos. O resultado Antes das melhorias, eram necessários segundos de dois dígitos para que os serviços iniciassem na inicialização. Na época em que o DAD foi adicionado ao Windows, poderia levar alguns minutos até que todos os serviços estivessem prontos. A compensação pelo DAD não era necessária, portanto a maior parte do código simplesmente ignorava o estado do endereço IP. A mudança combinada no comportamento de inicialização do serviço e as recentes melhorias de hardware permitiram que a inicialização do serviço demorasse apenas um dígito em segundos. Muito antes de um endereço IP estar pronto para uso, com base no comportamento do Windows e nos requisitos de RFC. Simplesmente alterar o padrão de transmissão DAD para IPv4 para 1 não é uma solução de longo prazo. À medida que o hardware e o serviço continuam a melhorar, é possível que mesmo um único segundo de atraso seja suficiente para causar uma falha no serviço na inicialização. Os serviços que enfrentam o problema devem ser alterados para monitorar o estado do endereço IP antes de tentar uma conexão de rede ou ligação a um IP. Problemas conhecidos Esta é uma lista de problemas comuns que o CSS pode enfrentar relacionados ao DAD e à inicialização do serviço. O serviço que usa uma conta de domínio falha ao iniciar Os serviços que usam uma conta de domínio têm uma dependência especial de que a rede esteja pronta e acessível para executar a autenticação com o controlador de domínio. O serviço não será iniciado sem ser autenticado. Quando o serviço inicia e expira mais rápido do que o necessário para a rede ficar pronta, o que normalmente está relacionado à espera da conclusão do DAD, o serviço não será iniciado. Isso é comumente visto no SQL Server, mas pode acontecer com qualquer serviço que use uma conta de domínio para logon.
Esse problema pode ser contornado reduzindo o número de transmissões DAD, desativando o DAD ou configurando a opção Recuperação no serviço para reiniciar. Veja a solução alternativa:
O serviço não pode ser vinculado a um endereço IP na inicialização Esse problema ocorre quando o serviço tenta vincular um serviço a um endereço IP, mas atinge o tempo limite ou ocorre erro antes que a rede esteja pronta. Novamente, isso normalmente acontece por causa da espera do DAD. A pilha de rede não pode vincular um serviço a um endereço IP que não esteja no estado Preferencial. Esse problema é visto frequentemente com o serviço de spooler (servidor de impressão). Problemas como esse podem ser contornados desativando o DAD ou definindo a inicialização do serviço como "Automático (Início Atrasado)". Outras soluções alternativas podem não funcionar quando o serviço não falha/para, ele simplesmente continua sem uma ligação de serviço a um endereço IP. Endereços IPv6 desaparecem do servidor DNS na reinicialização O cliente DHCP pode solicitar o registro DNS antes que o DAD IPv6 seja concluído. Quando isso acontece, o endereço IPv6 é excluído/desaparece do servidor DNS durante a atualização do DNS dinâmico pelo cliente DNS.
Espero que isto o ajude e gostaria de chamar a sua atenção para o facto de neste momento não ter sido encontrada uma solução definitiva.