Windows Server 2019 のファイルサーバーで、SMB 共有が日に何度も固まり、クライアントからアクセス不能になる。しかも Server（LanmanServer）サービスが「停止中」のまま再起動できず、結局サーバー再起動しか復旧手段がない――この症状は、SMB そのものより「背後のストレージ I/O 遅延」が引き金になっているケースが多いです。本記事ではイベント ID 1020 を手掛かりに、原因切り分けから実務的な対処までを体系的にまとめます。
Windows Server 2019 の SMB 共有が応答しないときに起きがちな「本当の現象」
最初に押さえておきたいのは、SMB 共有が固まるとき、必ずしも SMB プロトコル自体が壊れているわけではないことです。Windows Server 2019 のファイルサーバーでは、共有の読み書き要求がファイルシステムとストレージへ流れます。ここで下層の I/O が詰まると、上に乗っている SMB の処理も待たされ、結果的に 「共有が応答しない」ように見えます。
この状況でよく伴うのが、後から見える SMB-Server のイベント ID 1020 と、復旧手段が サーバー再起動のみになってしまう点です。しかも Server（LanmanServer）サービスを再起動しようとしても Stopping（停止中） のまま固まることがあり、現場では「サービス再起動すら効かない」状態に陥ります。
| 観測できる症状 | よくある裏側 | 最初に疑うレイヤー |
|---|---|---|
| SMB 共有の参照/コピーが固まる（待ちが続く） | ファイルシステム処理が完了せず要求が滞留 | ストレージ I/O、フィルタドライバ、バックアップ/VSS |
| サーバー自体は応答している（RDP は入れる等） | 全停止ではなく I/O 待ちが局所化 | 特定ボリューム/LUN、パス、キュー詰まり |
| Server サービスが停止中のまま戻らない | カーネル/ドライバ層の待ちに巻き込まれる | Storport/HBA/NIC、ストレージ装置、仮想基盤 |
| イベントログに派手なエラーがない | 「障害」ではなく「遅延」が根 | SMBServer/Operational と System の突き合わせ |
イベント ID 1020 の意味：SMB の不具合というより「処理が長すぎる」サイン
イベント ID 1020 は、SMB サーバーがクライアント要求を捌く過程で、ファイルシステム側の処理が想定より長時間かかったときに見えることがあります。重要なのは、これが「ネットワーク切断」や「SMB の設定ミス」を直接示すとは限らない点です。むしろ多くの場合、SMB は 入口 に過ぎず、ディスク I/O、ストレージ経路、バックアップやフィルタドライバなど下層の遅延が表面化している、と捉える方が現実に合います。
起点になるログは次の場所です。
- イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → SMBServer → Operational
ここで 1020 の発生時刻を確定し、同時刻の System ログやバックアップ製品ログと突き合わせます。「1020 が出た」だけで終わらせず、その秒・分に何が起きたかを追うのが最短ルートです。
なぜ Server（LanmanServer）サービスが再起動できないのか
「サービスが止まらない＝SMB サービスだけが壊れている」と捉えると遠回りになります。LanmanServer はカーネル内の SMB/ファイルシステム経路と密接に連携しており、停止処理では内部のワーカースレッドや I/O を順番に片付けます。もしその途中で、
- ディスク I/O が完了しない
- ストレージ装置や経路が一時的に極端に遅い
- フィルタドライバ（バックアップ/ウイルス対策/暗号化/監査など）が I/O を握ったまま返さない
といった状態になると、サービス側は「停止要求を受けたが、片付けが終わらない」ため Stopping のまま張り付くことがあります。この状態はユーザーランドの再起動で回復しづらく、結果として OS 再起動が必要になります。
最初の 30 分でやる切り分け：ストレージ遅延か、ネットワークか、全体停止か
原因が「ストレージ寄り」か「ネットワーク寄り」かを早めに分けると、調査が一気に進みます。現場で役立つ観点を表にまとめます。
| 観点 | 確認方法（例） | ストレージ寄りの所見 | ネットワーク寄りの所見 |
|---|---|---|---|
| サーバー上でローカルアクセスは速いか | サーバーにログオンして対象フォルダを直接開く/コピーする | ローカル操作も遅い・固まる | ローカルは快適、SMB 経由だけ遅い |
| 同一サーバーの別ボリュームは正常か | 別ドライブの共有/ファイル I/O を試す | 特定 LUN/ボリュームだけ遅いことが多い | 全共有が均等に遅いことが多い |
| RDP/管理共有（C$）は入れるか | 管理者で RDP、管理共有、イベント閲覧 | RDP は入れるが I/O 操作が遅い | RDP 自体が不安定、パケットロスや切断 |
| 同時刻に Disk/Storport/NTFS ログがあるか | System ログで Disk/Storport/NTFS を確認 | Reset/Timeout/エラーが出ることがある | ネットワーク系（NIC/スイッチ）ログが中心 |
現場でそのまま使えるチェックコマンド集
「何が詰まっているのか」を把握するために、まずは “見える化” できるコマンドを揃えます。停止中に実行できない場合もありますが、普段から取れるものを定型化しておくと、障害対応が速くなります。
| 目的 | コマンド例 | 見えること | ポイント |
|---|---|---|---|
| 1020 を時刻で抽出 | Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-SMBServer/Operational'; Id=1020} | Select-Object TimeCreated,Id,Message -First 20 | 発生時刻とメッセージ | まず「いつ」を確定する |
| SMB セッション確認 | Get-SmbSession | Select-Object ClientComputerName,ClientUserName,NumOpens,SecondsConnected | 接続中クライアント、開いている数 | 特定クライアントが偏っていないか |
| 開いているファイル確認 | Get-SmbOpenFile | Select-Object ClientComputerName,Path,NumLocks -First 30 | ロックや集中パス | ロック競合と遅延は別物だがヒントになる |
| サービス状態の詳細 | sc queryex lanmanserver | STATE と PID | Stopping 固着時に「どこで待っているか」は別途解析が必要 |
| ディスク遅延の即席確認 | resmon.exe | ディスクの応答時間、キュー、プロセス | 固まる直前/直後に見ると相関が掴みやすい |
コマンドは長くなりがちなので、コピペ用にまとめておきます（管理者 PowerShell で実行）。
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-SMBServer/Operational'; Id=1020} |
Select-Object TimeCreated,Id,Message -First 50
Get-SmbSession | Select-Object ClientComputerName,ClientUserName,NumOpens,SecondsConnected
Get-SmbOpenFile | Select-Object ClientComputerName,Path,NumLocks -First 50
sc queryex lanmanserver1020 の発生時刻を起点に「同時刻ログ」を突き合わせる
1020 は「結果」であって「原因」ではありません。原因に近いログは別にあることが多いので、次の順で同時刻を調べます。
| ログ/観測点 | 見る場所 | 見つかりやすい兆候 | 次に取るアクション |
|---|---|---|---|
| System（Disk / Storport / NTFS） | イベント ビューアー → Windows ログ → System | タイムアウト、リセット、I/O エラー、ファイルシステム警告 | 対象ディスク/LUN を特定、ドライバ/ファーム/パスを確認 |
| VSS / Backup | Windows ログ → Application、バックアップ製品ログ | スナップショット実行時刻と一致、Writer エラー | バックアップ時間帯変更/一時停止で再現性を見る |
| セキュリティ/監査（フィルタドライバ） | 製品ログ、ドライバ更新履歴 | スキャンや監査が集中、フィルタ更新直後から悪化 | 除外設定/更新/一時停止で切り分け |
| 仮想基盤・ストレージ装置ログ | Hyper-V/VMware のホストログ、SAN/NAS のイベント | 同時刻に遅延・パス切替・スロットリング | 装置側の性能/障害/キュー/キャッシュを調査 |
ストレージ I/O 遅延を「数字」で掴む（体感ではなく指標で判断）
「固まった気がする」だけだと責任分界が曖昧になりがちです。Windows 側で I/O 遅延を観測できる代表的なカウンターを押さえておくと、調査が前に進みます。
最低限押さえたいパフォーマンスカウンター
| カウンター | 意味 | 読み方のコツ |
|---|---|---|
| PhysicalDisk(*)\Avg. Disk sec/Read | 読み取り 1 回にかかる平均時間 | 1020 の時刻に合わせてスパイクしていないかを見る |
| PhysicalDisk(*)\Avg. Disk sec/Write | 書き込み 1 回にかかる平均時間 | バックアップ・大量コピー・スナップショットと相関しやすい |
| PhysicalDisk(*)\Current Disk Queue Length | 処理待ち I/O の長さ | 高止まりは「詰まり」のサイン（CPU ではなく I/O 側の飽和を示唆） |
| LogicalDisk(*)\% Free Space | 空き容量 | 空きが極端に少ないとメタデータ更新が増え、遅延が増えることがある |
| Memory\Available MBytes | 空きメモリ | メモリ不足はキャッシュ効率を落とし I/O を増やす |
ログ取得の実務（再現時刻を逃さない）
「たまに起きる」「夜中にだけ起きる」場合は、その瞬間を後追いできるように採取の仕組みを先に作ります。以下は汎用的に使いやすい方法です。
- パフォーマンスモニターのデータコレクターセット（1～5 秒間隔）を常時回す
- イベントログを定期エクスポート（
wevtutil epl）して保全する - 仮想基盤やストレージ装置側でも同時刻の遅延指標（レイテンシ/IOPS/キュー）を取得する
例：イベントログの保全（管理者権限のコマンドプロンプト/PowerShell で実行）
wevtutil epl Microsoft-Windows-SMBServer/Operational C:\Temp\SMBServer_Operational.evtx
wevtutil epl System C:\Temp\System.evtx
wevtutil epl Application C:\Temp\Application.evtx典型原因：VSS（シャドウコピー）・バックアップ・大量コピーの「重なり」
ファイルサーバーでは VSS やバックアップ製品が避けて通れません。スナップショット作成や整合性確保のタイミングで I/O が一時的に滞留し、結果として SMB が固まったように見えることがあります。特に、
- バックアップ開始直後に固まる
- robocopy の開始タイミングで固まる
- 「別サーバーにコピーしたら別サーバー側も落ちた」ように見える
といった場合、SMB を直接疑うより、コピーによる I/O 増加がボトルネックを顕在化させたと考える方が筋が良いケースが多いです。
VSS を疑うときのチェックリスト
| チェック項目 | 確認方法 | 判断のポイント |
|---|---|---|
| VSS の実行時刻 | バックアップ製品のジョブ履歴 / タスクスケジューラ | 1020 の時刻と一致するか |
| Writer の状態 | vssadmin list writers | エラー/リトライが継続していないか |
| シャドウコピーの増加 | vssadmin list shadows | 想定以上の作成/削除が発生していないか |
| フィルタドライバの影響 | 導入製品一覧、ドライバ更新履歴 | 更新直後から現象が増えたなら強いヒント |
仮想環境で頻発するパターン：ホスト/共有ストレージの遅延が VM の SMB を止める
Windows Server 2019 のファイルサーバーが VM の場合、VM 内のイベントだけ追っても結論が出ないことがあります。ホスト側の混雑や、共有ストレージ（SAN/NAS）の遅延、パス切替が VM のディスク I/O に影響し、その結果 SMB が詰まります。
- 同一ストレージ上の他 VM が大量 I/O を発生させていないか
- ホスト側のストレージレイテンシ（Datastore/CSV など）が跳ねていないか
- マルチパス（MPIO）や HBA/NIC のドライバ/ファームが推奨組み合わせか
「ファイルサーバーだけが悪い」ように見えて、実際は 同居している他ワークロードやホスト側処理が原因というのは現場でよくあります。必ずホスト/装置の時刻と突き合わせてください。
ネットワーク起因を疑うべきケース（ただし 1020 だけでは断定しない）
もちろんネットワークが原因のこともあります。たとえば、SMB マルチチャネル、RDMA、NIC の省電力設定、スイッチ側の輻輳やエラーなどで SMB が体感的に止まることがあります。ただし「Server サービスが停止中で張り付く」まで行くケースは、ネットワーク単体よりも ストレージ/ドライバ層の停滞が絡むことが多いのが実情です。
ネットワーク要因を早期にふるい落とすために、次の観測が役立ちます。
- 同時刻に NIC のリンクアップ/ダウン、チーミング切替、RDMA の異常が出ていないか
- クライアント側の「SMB クライアント」系ログで切断・再接続が記録されていないか
- サーバーは ping/管理アクセスできるのに SMB だけ詰まるのか、全 TCP が不安定なのか
実務的な対処を「やる順番」で整理する
原因が複合することも多いため、闇雲に設定を変えるより、影響の大きい順に潰します。現場で効果が出やすい順番は次の通りです。
ログと時刻の相関をまず固める
- SMBServer/Operational の 1020 を起点に、System/Application/製品ログを同時刻で突き合わせる
- 「発生時刻・継続時間・影響範囲（全共有か特定共有か）」を記録する
- 可能なら「発生前後の負荷（バックアップ/コピー/バッチ）」も紐付ける
ドライバ/ファーム/パッチの整合性を見直す
Windows Update だけで OS を最新にしても、ストレージ経路の不具合は解消しないことがあります。特に以下は見落とされやすいポイントです。
- HBA/NIC/RAID コントローラのドライバとファームウェア
- ストレージ装置側（コントローラ/ディスク）のファーム、推奨設定
- 仮想基盤（Hyper-V/VMware）のパッチ、ストレージスタックの更新
更新は慎重に、装置ベンダーの推奨組み合わせに合わせるのが基本です。
バックアップ/VSS を時間帯変更して切り分ける
業務影響を最小化しつつ原因を掴むには、バックアップのスケジュール調整が有効です。例えば、
- バックアップ時間帯をずらす
- 一時的に対象ボリュームを除外して再現性を見る
- スナップショットの並列数やスロットリング設定を見直す（製品依存）
これだけで 1020 が止まるなら、SMB の設定より先にバックアップ設計の見直しが必要です。
ファイルサーバーの負荷特性に合わせてストレージを再設計する
ファイルサーバーは「細かい I/O が多い」「メタデータ操作が多い」傾向があり、単純な IOPS だけでなくレイテンシが重要です。既存ストレージが共有用途に向いていない場合、いくら OS 側を調整しても根治しません。
| 施策 | 狙い | 効果が出やすい状況 | 注意点 |
|---|---|---|---|
| 共有ボリュームを別 LUN/別階層へ移す | 競合 I/O を隔離 | 同一ストレージ上の他負荷とぶつかっている | 移行計画とメンテナンスが必要 |
| バックアップ方式の変更（増分/スナップ頻度/整合性方式） | I/O フリーズを減らす | バックアップ時刻と一致 | 復旧要件（RPO/RTO）と整合が必要 |
| ウイルス対策の除外最適化 | フィルタ負荷を減らす | 大量ファイル/圧縮/DB ファイルを扱う共有 | セキュリティポリシーとの調整が必要 |
| 冗長経路（MPIO）やスイッチの健全化 | 瞬断・輻輳の影響を低減 | パス切替/リンクエラーが見える | 構成変更のリスク評価が必要 |
暫定回避策：止められない場合の「被害を小さくする」設計
根本原因の特定と修正に時間がかかる場合、ビジネス影響を抑える暫定策が必要です。ただし今回の症状のように Server サービス自体が停止中で固まると、サービス再起動タスクが効かないこともあります。現実的な選択肢は次の通りです。
- 監視 → 自動リブート：深夜帯に限って自動再起動を許容し、停止時間を短縮する（運用設計が前提）
- 冗長化：DFS 名前空間＋レプリケーション、クラスタ/Scale-Out File Server などで「1 台固まっても全停止しない」構成へ
- 負荷の平準化：robocopy のスレッド数/帯域制御、コピー時間帯の分散で I/O スパイクを抑える
イベント ID 1020 をトリガーにアクションを起こす例（サービス再起動を試み、失敗時は運用手順にエスカレーションするなど）
# 例：イベントトリガーで実行する PowerShell（概念例）
try {
Restart-Service -Name LanmanServer -Force -ErrorAction Stop
} catch {
# ここで通知（監視サーバー連携等）や運用手順に誘導
exit 1
}注意：Stopping で固着している場合、上記は成功しないことがあります。あくまで「試せる範囲」の暫定策です。
正式サポート案件になりやすい理由と、準備しておくと早い情報
「ハングしてサービスが止まらない」タイプは、ドライバ層の待ちが絡むことが多く、最終的に カーネルダンプ解析や StorPort などのトレースが必要になることがあります。そのため、一般的な設定変更だけでは限界があり、再現頻度が高いほど Microsoft/ベンダーサポートへのエスカレーションが現実的です。
| 準備すると有効な情報 | 目的 | メモ |
|---|---|---|
| 1020 発生時刻の一覧（発生頻度・継続時間） | 再現性と相関の確認 | 「何時に多いか」は原因特定の近道 |
| System/Application/SMBServer の evtx | 同時刻解析 | ログは上書きされる前に保全 |
| ストレージ構成（SAN/NAS、MPIO、LUN、RAID） | 責任分界の整理 | ベンダー推奨構成との差分が重要 |
| バックアップ/VSS の方式とスケジュール | フリーズ要因の特定 | 製品名・バージョンも添える |
| 直近の変更（Windows Update、ドライバ更新、構成変更） | 発生増加の引き金特定 | 「いつから」が特に重要 |
よくある誤解と考え方のコツ
「Windows の更新が悪い気がする」
更新直後から増えたなら無視できませんが、SMB 共有のハングは、更新が直接の原因というより、更新をきっかけにドライバ互換や負荷条件が変わって 潜在していたストレージ問題が表面化することがあります。犯人探しをするなら、更新の有無だけでなく「同時刻の I/O 兆候」をセットで確認してください。
「robocopy を開始したら落ちた」
robocopy は大量のファイル I/O を発生させるため、ボトルネックがある環境ではトリガーになり得ます。しかし robocopy が SMB サービスを直接壊すというより、I/O スパイクで遅延が顕在化し、結果的に SMB が巻き添えで固まって見えることが多いです。スレッド数（/MT）やリトライ、帯域制御（/IPG）などで負荷を調整しつつ、根本原因（ストレージ/経路/フィルタ）を特定するのが現実的です。
「イベントログに何もない」
ログは「エラー」がなくても「警告」や「遅延」として出ることがあります。また既定のログサイズが小さいと上書きされます。SMBServer/Operational のログサイズ拡大、System/Application の保全を先に行うと、後追いできる確率が上がります。
まとめ：イベント ID 1020 は“SMBの犯人”ではなく“ストレージ遅延の煙”
Windows Server 2019 の SMB 共有が頻繁に固まり、Server サービスも再起動できず再起動しかない――このパターンは、SMB の設定調整よりも先に、ストレージ I/O 遅延・バックアップ/VSS・仮想基盤・経路を疑うのが定石です。1020 の発生時刻を軸にログと指標を揃え、原因レイヤーを絞り込むことで、場当たり的な再起動運用から抜け出せます。
コメント