Примерно 8–10 месяцев назад мы столкнулись со странными проблемами с принтерами, которые в этом месяце вылились в огромное количество ошибок, в устранение которых была вовлечена большая часть компании. Это позволило нам выявить основные проблемы: на некоторых машинах (~7–8%) иногда после перезагрузки что-то происходит с диспетчером очереди печати, из-за чего принтеры не объявляются/не доступны по IP-адресу, а только по имени хоста.
Конкретно эта проблема проявляется в трех аспектах:
При отправке печати с сервера Linux сервер получит сообщение об ошибке, а в журнале событий будет следующая ошибка: «Автоматически Служба Line Printer Daemon (LPD) отклонила задание печати с %LINUXSERVERIP% для принтера \%WindowsIP%%PrinterName%, так как указанный принтер не существует на этом компьютере».
При попытке сопоставить принтер из проводника Windows, перейдя на компьютер с Windows с помощью \%WindowsIP%\ в проводнике Windows, принтер будет виден, но попытка добавить его приведет к ошибке «Операция не может быть завершена (ошибка 0x00000709)». Обычно это связано с KBKB5006670, но оно не установлено на наших компьютерах, и первые случаи вышеупомянутой ошибки относятся к декабрю 2021 г./январю 2022 г., то есть задолго до того, как этот патч был выпущен.
При запуске команды powershell Get-Printer -Computername %WindowsIP%. Если команда запущена с именем хоста машины, то результат будет правильным (список общих принтеров), если она запущена с IP-адресом машины, то выдается следующая ошибка:
+ CategoryInfo : NotSpecified: (MSFT_Printer:ROOT/StandardCimv2/MSFT_Printer) [Get-Printer], CimException + FullyQualifiedErrorId : HRESULT 0x8007007b,Get-Printer
И самое обидное: если перезапустить службу Spooler, то проблема полностью исчезает до следующей перезагрузки...
Поиск в Google не увенчался особым успехом, за исключением одного-единственного сообщения, оставшегося без ответа:https://hardforum.com/threads/weird-network-printing-problem.1635293/
Для всего есть свой XKCD, не так ли?https://xkcd.com/979/
Дополнительный анализ был выполнен с помощью Procmon, Wireshark, Process Explorer, WinDbg и xbootmgr и дал следующие результаты:
Прокмон:
- Анализ spoolsv.exe во время выполнения Get-Printer %WindowsIP% с другого компьютера не показывает никаких других действий, кроме сетевого взаимодействия.
- Анализ spoolsv.exe во время добавления общего принтера через проводник Windows показывает сетевое подключение и некоторые RegQueryKey для HKU%SIDOFREMOTEACCOUNT% и HKU.DEFAULT\Printers\Connections,,%WINDOWSIP%,%PRINTERNAME% с результатом «NAME NOT FOUND» и больше ничего
- Попытка анализа spoolsv.exe во время загрузки с помощью параметра Enable Boot Logging оказалась успешной, но бесполезной, поскольку проблема не возникала при загрузке с включенной опцией.
- Была предпринята попытка провести дополнительный анализ с помощью функции сводки стека, чтобы отследить стек от spoolsv.exe, но единственным заметным различием в потоке, которое было общим для рабочего и нерабочего дампа procmon, было наличие дополнительной ветви с именем EatAuthInfoFromPacket в дампе работающей службы.
Wireshark:
- Поверхностный анализ потока трафика при выполнении Get-Printer с удаленной машины показывает запрос winspool_AsyncEnumPrinters и ответ winspool_AsyncEnumPrinters с протоколом IREMOTEWINSPOOL, но никакой дополнительной информации, а данные заглушки выглядят зашифрованными, поэтому я не могу извлечь из них дополнительную информацию.
Исследователь процессов
- Был проведен поверхностный анализ процесса spoolsv.exe, его потоков и стека, и единственным интересным моментом было то, что в строках процесса spoolsv.exe были \machinehostname и \machinehostname.domain.com, когда он был сломан, и ничего, когда он не был сломан. Но я должен признать, что мои знания внутренних компонентов Windows недостаточны, чтобы полностью разобраться в этом. OpenAI помог с объяснениями!
WinDbg
- Отладчик был присоединен к процессу spoolsv.exe, и тестирование было выполнено как с Get-Printer с удаленной машины, так и с попыткой сопоставить принтер через Windows Explorer, но в обоих случаях никаких сообщений не было видно во время выполнения. Кроме того, я создал дамп процесса из Process Explorer и передал его WindDbg для запуска команды !analyze, но он вернул только точку останова, а не фактическую ошибку. Как и прежде, я новичок в этом инструменте, поэтому если у вас есть какие-либо предложения, я буду рад их принять!
xbootmgr
- xbootmgr -trace boot -traceflags dispatcher+latency -stackwalk readythread+threadcreate+profile+cswitch был запущен для отладки службы во время загрузки, но, как и Procmon, когда машина перезагружается с этой трассировкой, проблема не проявляется, поэтому вывод довольно бесполезен.
Итак, вот резюме. Я немного запутался, и ни Google, ни OpenAI, похоже, не имеют ни малейшего представления о том, что здесь происходит, поэтому я был бы признателен за любые идеи, которые вы могли бы предоставить по дополнительному устранению неполадок для этой проблемы или, возможно, решению, если вы сталкивались с этим раньше.
решение1
Если у кого-то еще возникла такая проблема, вот ответ от Microsoft:
Причина (предыстория) многоуровневая. Это базовый обзор. Запуск службы В Windows было внесено много изменений для улучшения времени запуска службы при загрузке. Это позволяет некоторым службам запускаться раньше, чем раньше. Служба может не запуститься, если у нее есть сетевая зависимость и истечет время ожидания до завершения DAD, а интерфейс и IP будут готовы к использованию. Аппаратное обеспечение Улучшения в компьютерном оборудовании являются основным фактором. Все современные процессоры имеют несколько ядер/потоков, что позволяет параллельно обрабатывать задачи операционной системы. Скорость процессоров также значительно возросла. Эти изменения позволяют операционной системе, такой как Windows, выполнять несколько задач быстрее и параллельно, и, таким образом, значительно сокращать время запуска службы. Объем доступной оперативной памяти быстро увеличился. Это означает меньшую подкачку на диск, что также сокращает время запуска. Наиболее значительным улучшением стало хранилище. Теперь хранилище в основном основано на флэш-памяти (SSD) и обычно использует высокоскоростное соединение NVMe. Даже бэкэнды хранения, такие как NAS или SAN, в наши дни полностью основаны на флэш-памяти. Улучшения ввода-вывода, задержки и пропускной способности между старыми жесткими дисками (HDD) и твердотельными накопителями NVMe на порядок выше примерно в 150 раз. Это изменение произошло менее чем за 10 лет. Результат До улучшений запуск служб при загрузке занимал двузначные секунды. Когда DAD впервые был добавлен в Windows, могли пройти минуты, прежде чем все службы были готовы. Компенсация DAD не была необходима, поэтому большая часть кода просто игнорировала состояние IP-адреса. Совместное изменение поведения запуска служб и недавние улучшения оборудования позволили запускать службы за единицу секунд. Задолго до того, как IP-адрес будет готов к использованию, на основе поведения Windows и требований RFC. Простое изменение значения передачи DAD по умолчанию для IPv4 на 1 не является долгосрочным решением. Поскольку оборудование и обслуживание продолжают совершенствоваться, вполне возможно, что даже одной секунды задержки будет достаточно, чтобы вызвать сбой службы при загрузке. Службы, испытывающие эту проблему, должны быть изменены для отслеживания состояния IP-адреса перед попыткой сетевого подключения или привязки к IP. Известные проблемы Это список распространенных проблем, с которыми может столкнуться CSS, связанных с DAD и запуском службы. Служба, использующая учетную запись домена, не запускается Службы, использующие учетную запись домена, имеют особую зависимость от готовности и доступности сети для выполнения аутентификации с контроллером домена. Служба не запустится без аутентификации. Когда служба запускается и время ожидания истекает быстрее, чем требуется для готовности сети, что обычно связано с ожиданием завершения DAD, то служба не запускается. Это часто наблюдается в SQL Server, но это может случиться с любой службой, использующей учетную запись домена для входа.
Эту проблему можно обойти, уменьшив количество передач DAD, отключив DAD или установив опцию Recovery на службе для перезапуска. Смотрите обходной путь:
Service Cannot Bind to an IP Address on Start Эта проблема возникает, когда служба пытается привязать службу к IP-адресу, но истекает время ожидания или возникают ошибки до готовности сети. Опять же, это обычно происходит из-за ожидания DAD. Сетевой стек не может привязать службу к IP-адресу, который не находится в предпочтительном состоянии. Эта проблема часто наблюдается со службой спулера (сервера печати). Подобные проблемы можно обойти, отключив DAD или установив запуск службы на «Автоматический (отложенный запуск)». Другие обходные пути могут не работать, когда служба не выходит из строя/не останавливается, а просто продолжает работу без привязки службы к IP-адресу. Адреса IPv6 исчезают с DNS-сервера при перезагрузке Клиент DHCP может запросить регистрацию DNS до завершения IPv6 DAD. Когда это происходит, адрес IPv6 удаляется/исчезает с DNS-сервера во время динамического обновления DNS клиентом DNS.
Надеюсь, это вам поможет, и хочу обратить ваше внимание на то, что на данный момент окончательного решения не найдено.