約 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
そして最も厄介なのは、スプーラー サービスを再起動すると、次回の再起動まで問題が完全に消えてしまうことです...
Google で調査しても、回答のないメッセージが 1 つだけある以外は、あまり成果は得られませんでした。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 ダンプと動作していない procmon ダンプの間で共通するスレッドの唯一の顕著な違いは、動作中のサービスのダンプに EatAuthInfoFromPacket と呼ばれる追加のブランチが存在することでした。
ワイヤーシャーク:
- リモート マシンから Get-Printer を実行している間のトラフィック フローの表面的な分析では、プロトコル IREMOTEWINSPOOL を使用した winspool_AsyncEnumPrinters 要求と winspool_AsyncEnumPrinters 応答が表示されますが、追加情報は表示されず、スタブ データは暗号化されているように見えるため、そこから追加情報を収集することはできません。
プロセスエクスプローラー
- spoolsv.exe プロセスとそのスレッドおよびスタックについて表面的な分析が行われましたが、唯一興味深い点は、spoolsv.exe プロセスの文字列に、破損している場合は \machinehostname と \machinehostname.domain.com があり、破損していない場合は何もなかったことです。しかし、Windows の内部に関する私の知識は、これを完全に理解するには不十分であることを認めなければなりません。ただし、OpenAI が説明を手伝ってくれています。
ウインドウズ
- デバッガーは spoolsv.exe プロセスに接続され、リモート マシンからの Get-Printer と Windows エクスプローラーからのプリンターのマッピングの両方でテストが実行されましたが、どちらの場合も実行中にメッセージ デバッグ メッセージは表示されませんでした。さらに、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 などのオペレーティング システムは複数のタスクをより高速かつ並列に実行できるようになり、サービスの起動時間が大幅に改善されています。使用可能な RAM の量が急速に増加しました。つまり、ディスクへのページングが減り、起動時間も改善されます。最も重要な改善はストレージです。ストレージは現在、主にフラッシュ ベース (SSD) であり、一般的に高速 NVMe インターコネクトを使用しています。NAS や SAN などのストレージ バックエンドも、最近ではすべてフラッシュ ベースになっています。古い回転ディスク (HDD) と NVMe SSD の間の IO、レイテンシ、スループットの改善は、約 150 倍以上の桁違いの速さです。この変化は、10 年未満の期間に起こりました。 結果 改善が行われる前は、起動時にサービスが開始するまでに 2 桁の秒数を要していました。DAD が最初に Windows に追加された当時は、すべてのサービスが準備されるまでに数分かかることがありました。DAD を補正する必要はなかったため、ほとんどのコードでは IP アドレスの状態が無視されていました。サービス起動の動作の変更と最近のハードウェアの改善の組み合わせにより、サービスの起動に 1 桁の秒数しかかからないようになりました。Windows の動作と RFC 要件に基づいて、IP アドレスが使用可能になるずっと前です。IPv4 の DAD 送信の既定値を 1 に変更するだけでは、長期的な解決策にはなりません。ハードウェアとサービスが改善し続けると、1 秒の遅延でも起動時にサービス障害を引き起こす可能性があります。問題が発生しているサービスは、ネットワーク接続を試行したり IP にバインドしたりする前に、IP アドレスの状態を監視するように変更する必要があります。既知の問題 これは、DAD およびサービスの起動に関連して CSS が直面する可能性のある一般的な問題の一覧です。 ドメイン アカウントを使用するサービスが起動に失敗する ドメイン アカウントを使用するサービスは、ドメイン コントローラーで認証を実行するためにネットワークが準備されアクセス可能であることに特別に依存します。 認証されないとサービスは起動しません。 サービスが起動してタイムアウトになるのが、ネットワークの準備が整うのにかかる時間よりも短い場合 (これは通常、DAD の完了を待機していることに関連します)、サービスは起動しません。 これは SQL Server でよく見られますが、ログオンにドメイン アカウントを使用するすべてのサービスで発生する可能性があります。
この問題は、DAD 送信回数を減らす、DAD を無効にする、またはサービスの回復オプションを設定して再起動することで回避できます。回避策を参照してください。
サービスは起動時に IP アドレスにバインドできません。この問題は、サービスが IP アドレスにサービスをバインドしようとしたが、ネットワークの準備が整う前にタイムアウトまたはエラーになった場合に発生します。これも通常、DAD 待機が原因で発生します。ネットワーク スタックは、優先状態にない IP アドレスにサービスをバインドできません。この問題は、スプーラ (プリント サーバー) サービスでよく見られます。このような問題は、DAD を無効にするか、サービスのスタートアップを「自動 (遅延開始)」に設定することで回避できます。サービスが失敗/停止せず、IP アドレスにサービスをバインドせずにそのまま続行する場合、その他の回避策は機能しない可能性があります。再起動時に IPv6 アドレスが DNS サーバーから消える IPv6 DAD が完了する前に、DHCP クライアントが DNS 登録を要求する場合があります。これが発生すると、DNS クライアントによる動的 DNS 更新中に、IPv6 アドレスが DNS サーバーから削除/消えます。
これがお役に立てば幸いです。また、現時点では最終的な解決策が見つかっていないという事実にご留意いただきたいと思います。