自大約8-10 個月前以來，我們一直面臨著奇怪的印表機問題，最終在本月出現了大量錯誤，導致公司的大部分人員都參與其中，這使我們能夠識別核心問題：在某些機器上（~7- 8%）有時在重新啟動後，列印後台處理程序會發生一些情況，導致印表機無法透過 IP 位址進行廣告/可用，而只能透過主機名稱進行廣告/使用。
具體而言，該問題以 3 種方式呈現：
從 Linux 伺服器發送列印時，伺服器將收到錯誤，並且事件日誌將顯示以下錯誤「自動行式印表機守護程式 (LPD) 服務拒絕了印表機 \%WindowsIP%%PrinterName% 的 %LINUXSERVERIP% 的列印作業因為指定的印表機在此計算機上不存在。
當嘗試透過在 Windows 資源管理器中使用 \%WindowsIP%\ 前往 Windows 電腦來從 Windows 資源管理器對應印表機時，印表機將可見，但嘗試新增它將導致錯誤「操作無法完成（錯誤 0x00000709）」。它通常與 KBKB5006670 相關，但它沒有安裝在我們的電腦上，並且上述錯誤的第一個實例是從 2021 年 12 月/2022 年 1 月開始的，遠早於該補丁發布
執行 powershell 指令 Get-Printer -Computername %WindowsIP% 時。如果使用電腦的主機名稱執行該命令，則結果是正確的（共用印表機清單），如果使用電腦的 IP 位址執行該命令，則會引發以下錯誤：
+ CategoryInfo : NotSpecified: (MSFT_Printer:ROOT/StandardCimv2/MSFT_Printer) [Get-Printer], CimException + FullyQualifiedErrorId : HRESULT 0x8007007b,Get-Printer
最煩人的是：如果您重新啟動後台列印程式服務，問題就會完全消失，直到下次重新啟動...
對谷歌的研究並沒有太大成功，除了一則未回覆的訊息：https://hardforum.com/threads/weird-network-printing-problem.1635293/
一切都有一個 XKCD，不是嗎？https://xkcd.com/979/
使用 Procmon、Wireshark、Process Explorer、WinDbg 和 xbootmgr 進行了其他分析，結果如下：
過程監控：
- 從另一台電腦執行 Get-Printer %WindowsIP% 期間對 spoolsv.exe 的分析顯示，除了網路通訊之外沒有其他操作
- 透過Windows 資源管理器新增共用印表機期間對spoolsv.exe 的分析顯示了網路連線以及HKU%SIDOFREMOTEACCOUNT% 和HKU.DEFAULT\Printers\Connections,,%WINDOWSIP%,%PRINTERNAME% 的網路連線和一些RegQueryKey，結果為「NAME NOT FOUND」但沒有別的
- 嘗試在啟動過程中透過「啟用啟動日誌記錄」分析 spoolsv.exe 成功，但沒有用，因為在啟用該選項的情況下啟動時沒有出現問題
- 已嘗試透過堆疊摘要函數進行其他分析，以從 spoolsv.exe 向下追蹤堆疊，但工作和非工作 procmon 轉儲之間常見的執行緒中唯一明顯的區別是存在一個名為 EatAuthInfoFromPacket 的附加分支。的轉儲。
線鯊：
- 從遠端電腦執行 Get-Printer 時流量的表面分析顯示，winspool_AsyncEnumPrinters 請求和 Winspool_AsyncEnumPrinters 使用協議 IREMOTEWINSPOOL 進行回應，但沒有其他信息，存根資料似乎已加密，因此我無法從中獲取其他信息
流程瀏覽器
- 對spoolsv.exe 進程及其執行緒和堆疊進行了粗淺的分析，唯一有趣的一點是，在spoolsv.exe 進程的字串中，當它被破壞時，有\machinehostname 和\machinehostname.domain.com ，而當它被破壞時，沒有任何事實並非如此。但我必須承認，我對 Windows 內部結構的了解還不足以完全了解它。不過 OpenAI 一直在幫忙解釋！
資料庫管理工具
- 偵錯器已附加到spoolsv.exe 進程，並使用遠端電腦上的Get-Printer 進行測試並嘗試透過Windows 資源管理器對應印表機，但在這兩種情況下，在執行期間都看不到任何訊息偵錯訊息。此外，我從 Process Explorer 建立了一個進程轉儲並將其提供給 WindDbg 以執行 !analyze 命令，但它只傳回一個斷點，沒有實際錯誤。和以前一樣，我是這個工具的新手，所以如果您有任何建議，我將很樂意接受！
啟動管理器
- xbootmgr -trace boot -traceflagsdispatcher+latency -stackwalkreadythread+threadcreate+profile+cswitch 已在啟動期間運行以調試服務，但與 Procmon 相同，當計算機使用此跟踪重新啟動時，問題不會出現，因此輸出相當無用
這就是總結。我有點迷失了，Google 和 OpenAI 似乎都不知道這裡發生了什麼，所以我很感激您提供有關此問題的其他故障排除的任何見解，或者如果您以前遇到過這個問題，也許可以提供解決方案。
答案1
如果其他人也遇到這個問題，以下是 Microsoft 的答案：
原因（背景故事）是多層次的。這是基本概要。服務啟動 WIndows 中進行了許多變更以縮短啟動時的服務啟動時間。這使得某些服務比過去更早啟動。如果服務具有網路依賴性，且在 DAD 完成且介面和 IP 可供使用之前逾時，則服務可能無法啟動。硬體 電腦硬體的改進是一個主要因素。所有現代處理器都具有多個核心/線程，允許並行處理作業系統任務。處理器的速度也顯著提高。這些變更使 Windows 等作業系統能夠更快地並行執行多個任務，從而顯著縮短服務啟動時間。可用 RAM 量迅速增加。這意味著更少的磁碟分頁，也縮短了啟動時間。最顯著的改進是儲存。儲存現在主要基於快閃記憶體 (SSD)，並且通常使用高速 NVMe 互連。如今，甚至儲存後端（例如 NAS 或 SAN）也是基於全快閃記憶體的。舊的旋轉磁碟 (HDD) 和 NVMe SSD 之間的 IO、延遲和吞吐量改進大約快 150 倍以上。這項變化發生在不到10年的時間。結果 在進行改進之前，服務啟動需要花費兩位數的秒數。當 DAD 首次添加到 Windows 時，所有服務可能需要幾分鐘才能準備就緒。補償 DAD 是不必要的，因此大多數代碼只是忽略 IP 位址狀態。服務啟動行為的變化和最近的硬體改進相結合，使得服務啟動只需個位數秒。根據 Windows 行為和 RFC 要求，在 IP 位址可供使用之前。簡單地將 IPv4 的 DAD 傳輸預設值變更為 1 並不是一個長期解決方案。隨著硬體和服務的不斷完善，即使一秒的延遲也足以導致啟動時服務失敗。在嘗試網路連線或綁定到 IP 之前，必須變更遇到問題的服務以監視 IP 位址狀態。已知問題 這是 CSS 可能面臨的與 DAD 和服務啟動相關的常見問題清單。使用網域帳戶的服務無法啟動 使用網域帳戶的服務對網路是否已準備好且可存取以執行網域控制站驗證有特殊的相依性。如果沒有經過身份驗證，該服務將不會啟動。當服務啟動和逾時的速度快於網路準備就緒的速度（這通常與等待 DAD 完成有關）時，該服務將不會啟動。這種情況在 SQL Server 中很常見，但任何使用網域帳戶登入的服務都可能發生這種情況。
可以透過減少 DAD 傳輸次數、停用 DAD 或將服務上的「恢復」選項設定為重新啟動來解決此問題。請參閱解決方法：
服務無法在啟動時綁定到 IP 位址 當服務嘗試將服務綁定到 IP 位址但在網路準備就緒之前逾時或出錯時，就會出現此問題。同樣，這通常是由於 DAD 等待而發生的。網路堆疊無法將服務綁定到不處於首選狀態的 IP 位址。此問題在後台處理程序（列印伺服器）服務中經常出現。可以透過停用 DAD 或將服務啟動設定為「自動（延遲啟動）」來解決此類問題。當服務沒有失敗/停止時，其他解決方法可能不起作用，它只是在沒有服務綁定到 IP 位址的情況下繼續運作。 IPv6 位址在重新啟動時從 DNS 伺服器中消失 DHCP 用戶端可能會在 IPv6 DAD 完成之前請求 DNS 註冊。發生這種情況時，在 DNS 用戶端進行動態 DNS 更新期間，IPv6 位址將從 DNS 伺服器中刪除/消失。
我希望這對您有所幫助，並且我想提請您注意以下事實：目前尚未找到最終解決方案。