Desde hace aproximadamente 8 a 10 meses hemos estado enfrentando problemas extraños con las impresoras que culminaron este mes con una gran cantidad de errores que involucraron a la mayor parte de la empresa y que nos permitieron identificar los problemas principales: en algunas máquinas (~7- 8%) a veces, después de reiniciar, sucede algo con la cola de impresión que hace que las impresoras no se anuncien/dispongan a través de la dirección IP, solo a través del nombre de host.
Específicamente el problema se presenta de 3 maneras:
Al enviar una impresión desde un servidor Linux, el servidor recibirá un error y el registro de eventos tendrá el siguiente error "Automático. El servicio Line Printer Daemon (LPD) rechazó un trabajo de impresión de %LINUXSERVERIP% para la impresora \%WindowsIP%%PrinterName%. porque la impresora especificada no existe en esta computadora."
Al intentar asignar una impresora desde el Explorador de Windows yendo a la máquina Windows con \%WindowsIP%\ en el Explorador de Windows, la impresora estará visible pero al intentar agregarla se producirá el error "No se pudo completar la operación (error 0x00000709)". que generalmente está asociado con KBKB5006670, pero no está instalado en nuestras máquinas y las primeras instancias del error antes mencionado son de diciembre de 2021/enero de 2022, mucho antes de que se lanzara ese parche.
Al ejecutar el comando de PowerShell Get-Printer -Computername %WindowsIP%. Si el comando se ejecuta con el nombre de host de la máquina, entonces el resultado es correcto (una lista de impresoras compartidas); si se ejecuta con la dirección IP de la máquina, arroja el siguiente error:
+ CategoryInfo : NotSpecified: (MSFT_Printer:ROOT/StandardCimv2/MSFT_Printer) [Get-Printer], CimException + FullyQualifiedErrorId : HRESULT 0x8007007b,Get-Printer
Y lo más molesto es: si reinicia el servicio Spooler, el problema desaparece por completo hasta el próximo reinicio...
La investigación en Google no ha tenido mucho éxito, excepto por un único mensaje sin respuesta:https://hardforum.com/threads/weird-network-printing-problem.1635293/
Hay un XKCD para todo, ¿no?https://xkcd.com/979/
Se han realizado análisis adicionales con Procmon, Wireshark, Process Explorer, WinDbg y xbootmgr con los siguientes resultados:
Procmón:
- El análisis de spoolsv.exe durante la ejecución de Get-Printer %WindowsIP% desde otra computadora no muestra otras acciones además de la comunicación de red
- El análisis de spoolsv.exe durante la adición de una impresora compartida a través del Explorador de Windows muestra la conexión de red y algunas RegQueryKey para HKU%SIDOFREMOTEACCOUNT% y HKU.DEFAULT\Printers\Connections,%WINDOWSIP%,%PRINTERNAME% con el resultado de "NOMBRE NO ENCONTRADO" pero nada más
- El intento de análisis de spoolsv.exe durante el arranque a través de Habilitar registro de arranque fue exitoso pero inútil debido a que el problema no aparece al arrancar con esa opción habilitada.
- Se intentó realizar un análisis adicional a través de la función de resumen de pila para rastrear la pila desde spoolsv.exe, pero la única diferencia notable en el subproceso que era común entre el volcado de procmon que funcionaba y el que no funcionaba era la presencia de una rama adicional llamada EatAuthInfoFromPacket en el volcado del servicio de trabajo.
Tiburón de alambre:
- El análisis superficial del flujo de tráfico mientras se ejecuta Get-Printer desde una máquina remota muestra la solicitud winspool_AsyncEnumPrinters y la respuesta winspool_AsyncEnumPrinters con el protocolo IREMOTEWINSPOOL, pero no hay información adicional y los datos auxiliares aparecen cifrados, por lo que no puedo obtener información adicional de ellos.
Explorador de procesos
- Se ha realizado un análisis superficial del proceso spoolsv.exe y sus subprocesos y pila y el único punto interesante fue que en las cadenas del proceso spoolsv.exe había \machinehostname y \machinehostname.domain.com cuando estaba roto y nada cuando no lo fue. Pero tengo que admitir que mi conocimiento de Windows Internals es insuficiente para entenderlo por completo. ¡Sin embargo, OpenAI ha estado ayudando con las explicaciones!
WinDbg
- El depurador se adjuntó al proceso spoolsv.exe y se realizaron pruebas con Get-Printer desde una máquina remota y al intentar asignar la impresora a través del Explorador de Windows, pero en ambos casos no se vieron mensajes de depuración durante la ejecución. Además, creé un volcado de proceso desde Process Explorer y lo envié a WindDbg para ejecutar el comando! Analyze, pero solo devolvió un punto de interrupción, ningún error real. Igual que antes, soy nuevo en esta herramienta, así que si tienes alguna sugerencia, estaré encantado de aceptarla.
xbootmgr
- xbootmgr -trace boot -traceflags Dispatcher+latency -stackwalk readythread+threadcreate+profile+cswitch se ejecutó para depurar el servicio durante el arranque pero, al igual que Procmon, cuando la máquina se reinicia con este seguimiento, el problema no se presenta, por lo que la salida es bastante inútil
Y así este es el resumen. Estoy un poco perdido y ni Google ni OpenAI parecen tener idea de lo que está sucediendo aquí, por lo que agradecería cualquier información que pueda brindarme sobre solución de problemas adicionales para este problema o tal vez una solución si lo ha enfrentado antes.
Respuesta1
Si alguien más tiene el problema, aquí está la respuesta de Microsoft:
La Causa (historia de fondo) tiene varios niveles. Este es el resumen básico. Inicio del servicio Ha habido muchos cambios en Windows para mejorar los tiempos de inicio del servicio en el arranque. Esto permite que algunos servicios se inicien antes que en el pasado. Es posible que un servicio no se inicie si tiene una dependencia de red y se agota el tiempo de espera antes de que DAD se complete y la interfaz y la IP estén listas para su uso. Hardware Las mejoras en el hardware de las computadoras son un factor importante. Todos los procesadores modernos tienen múltiples núcleos/hilos, lo que permite el procesamiento paralelo de tareas del sistema operativo. La velocidad de los procesadores también ha aumentado drásticamente. Estos cambios permiten que un sistema operativo como Windows realice múltiples tareas más rápido y en paralelo y, por lo tanto, mejore drásticamente el tiempo de inicio del servicio. La cantidad de RAM disponible ha aumentado rápidamente. Esto significa menos paginación en el disco y también mejora el tiempo de inicio. La mejora más significativa ha sido la del almacenamiento. El almacenamiento ahora se basa principalmente en flash (SSD) y comúnmente utiliza una interconexión NVMe de alta velocidad. Incluso los backends de almacenamiento, como un NAS o SAN, se basan exclusivamente en tecnología flash en la actualidad. Las mejoras de E/S, latencia y rendimiento entre los discos giratorios antiguos (HDD) y los SSD NVMe son de un orden de magnitud aproximadamente 150+ veces más rápido. Este cambio ocurrió en un lapso de tiempo de menos de 10 años. El resultado Antes de las mejoras, los servicios tardaban dos dígitos en iniciarse al arrancar. Cuando DAD se agregó por primera vez a Windows, podían pasar minutos antes de que todos los servicios estuvieran listos. No era necesario compensar DAD, por lo que la mayoría del código simplemente ignoraba el estado de la dirección IP. El cambio combinado del comportamiento de inicio del servicio y las recientes mejoras de hardware han permitido que el inicio del servicio tarde un solo dígito en segundos. Mucho antes de que una dirección IP esté lista para usarse, según el comportamiento de Windows y los requisitos de RFC. Simplemente cambiar el valor predeterminado de transmisión DAD para IPv4 a 1 no es una solución a largo plazo. A medida que el hardware y el servicio continúan mejorando, es factible que incluso un solo segundo de retraso sea suficiente para provocar una falla del servicio en el arranque. Los servicios que experimentan el problema deben cambiarse para monitorear el estado de la dirección IP antes de intentar una conexión de red o vincularse a una IP. Problemas conocidos Esta es una lista de problemas comunes que CSS puede enfrentar en relación con DAD y el inicio del servicio. El servicio que utiliza una cuenta de dominio no se inicia. Los servicios que utilizan una cuenta de dominio dependen especialmente de que la red esté lista y sea accesible para realizar la autenticación con el controlador de dominio. El servicio no se iniciará sin estar autenticado. Cuando el servicio se inicia y se agota más rápido de lo que tarda la red en estar lista, lo que generalmente está relacionado con esperar a que DAD se complete, entonces el servicio no se iniciará. Esto se ve comúnmente con SQL Server, pero puede sucederle a cualquier servicio que utilice una cuenta de dominio para iniciar sesión.
Este problema se puede solucionar reduciendo la cantidad de transmisiones de DAD, deshabilitando DAD o configurando la opción de Recuperación en el servicio para que se reinicie. Vea la solución:
El servicio no se puede vincular a una dirección IP al iniciar Este problema ocurre cuando el servicio intenta vincular un servicio a una dirección IP pero se agota el tiempo de espera o se produce un error antes de que la red esté lista. Nuevamente, esto suele suceder debido a la espera del DAD. La pila de red no puede vincular un servicio a una dirección IP que no esté en un estado Preferido. Este problema se observa a menudo con el servicio de cola de impresión (servidor de impresión). Problemas como este se pueden solucionar desactivando DAD o configurando el inicio del servicio en "Automático (inicio retrasado)". Es posible que otras soluciones no funcionen cuando el servicio no falla ni se detiene, simplemente continúa sin un servicio vinculado a una dirección IP. Las direcciones IPv6 desaparecen del servidor DNS al reiniciar. El cliente DHCP puede solicitar el registro DNS antes de que se complete IPv6 DAD. Cuando esto sucede, la dirección IPv6 se elimina/desaparece del servidor DNS durante la actualización del DNS dinámico por parte del cliente DNS.
Espero que esto les ayude y me gustaría llamar su atención sobre el hecho de que por el momento no se ha encontrado una solución final.