Windows Server 2012 R2でSMB共有がランダム切断・固まる原因と対策（LanmanServer停止ハング/LiveKernelReports）

Windows Server 2012 R2のファイルサーバー（VM）で、業務時間中にSMB共有だけが突然切断・固まり、RDPやpingは生きているのに共有が復旧しない――しかも「Server（LanmanServer）サービス再起動が停止中でハング」「OS再起動も終わらず、ハイパーバイザーから強制リセットが必要」という厄介な症状の原因候補と、現場で使える切り分け手順を整理します。

まず押さえる：この障害は「ネットワーク断」ではなく「SMBサーバーのハング」に近い

今回のようにping（ICMP）やRDPは通るのに、\\server\share だけが開けない症状は、単純なネットワーク断やDNS不具合よりも、SMBサーバー側（ファイルサーバー側）の処理が詰まっている状態を疑うのが近道です。Microsoftの解説でも、SMBの受信トラフィックはカーネル内で srv2.sys（SMB2/3）や srv.sys（SMB1） が処理し、SMBレベルで応答不能になる場合はこれらのスレッドが一時的/恒久的にブロックされていることが多い、とされています。

この状態だと、表面上は「サーバーは生きている」ため、運用者が陥りがちな罠があります。

観測される現象	意味合い（疑う方向）	次にやるべきこと
RDPでログオンできる / pingは通る	OSとネットワークスタック全体は生存している	SMB関連ログ・ストレージ・フィルタドライバへ視点を移す
共有だけ開けない（エクスプローラーが固まる/タイムアウト）	srv2.sys側の待ちやI/O詰まりを疑う	SMBServer/Operational、イベント1020/1031/1032、ダンプ確認
Explorerからデータドライブが消えることがある	ストレージI/Oの停止・リセット・一時切断の可能性	ゲスト/ホスト双方のディスク・ストレージ関連イベントを突合
Server（LanmanServer）サービス停止が「停止中」でハング	サービス制御では止められない層（カーネル・I/O待ち）で詰まっている	強制再起動の前に証拠（ログ/トレース/ダンプ）を回収する設計へ
OSから再起動が完了しない／結局ハイパーバイザーから強制リセット	シャットダウン処理がI/O待ちで完了できない典型	原因特定にはダンプ（LiveKernelReports含む）が最重要

症状の“再現しにくさ”が最大の敵：まずは「証拠が残る運用」に寄せる

この系統の障害は、フォーラムでも「環境要因が大きく、再現が不定期でログ解析が必要。フォーラムの範囲では難しいためサポートケースを」と案内されがちです。実際、Microsoft Q&Aのスレッドでも有償サポート（Professional Support）での調査を勧める回答が出ています。

とはいえ、現場では「毎回ハードリセットして終わり」になりがちです。そうすると原因が永遠に掴めません。ポイントは次の2つです。

• 止まった瞬間の“痕跡”を最優先で回収できる仕組み（イベントログのエクスポート、ネットワークトレース、LiveKernelReportsのダンプ）
• 原因の当たりを付けるための分類（ストレージ、フィルタドライバ、SMBリース、更新プログラム、RDMAなど）

原因候補を大きく分類する（Windows Server 2012 R2／VMで特に多い）

ストレージI/Oの停止・遅延（VMの“中”ではなく“外”が原因のことも）

「共有の一部だけ落ちる」「エクスプローラーから特定のデータドライブが消える」という挙動は、SMB以前にファイルシステムが裏側のI/O待ちで詰まっている可能性を示唆します。VMの場合、ゲストOSのイベントログだけでは見えないホスト側のストレージ遅延（RAID・コントローラ・バックエンド）が根因になることがあります。

• ホスト側：RAIDコントローラ/ストレージのログ、I/O遅延、再試行、ファーム/ドライバ
• ゲスト側：SystemログのDisk/NTFS/volsnap/Storport系イベント、ボリュームのOnline/Offline

このタイプは「何をしても直らない」ように見えやすいので、後述のパフォーマンスカウンターで“詰まった瞬間のディスク待ち時間”を観測できるようにします。

SMBリース（Leasing）/Oplocksまわりの既知不具合・相性

Windows Server 2012/2012 R2では、共有ファイルは見えるが開けない／エクスプローラーがフリーズする／Serverサービス再起動が停止中で固まる／Accessデータベースが壊れる／Excelが「別ユーザーがロック」になるといった症状が報告されており、Microsoftのサポート記事では更新プログラム（ロールアップ）適用が案内されています。さらに回避策として、ファイルサーバー側でLeasingを無効化（DisableLeasing）する方法が掲載されており、「SMB2 leaseは付与されなくなるが oplocks は残る。主にトラブルシュート用途」と明記されています。

ここで重要なのは、DisableLeasingが“万能の改善策”ではなく、原因切り分けのためのレバーだという点です。効いた場合、リース/キャッシュ絡み（クライアント側のオフライン/キャッシュ、古いアプリ、MDB系など）に原因が寄っている可能性が高まります。

ファイルシステム・フィルタドライバ（ウイルス対策/バックアップ/監査）の影響

SMBサーバーの処理は最終的にディスクI/Oに到達しますが、その間にミニフィルタドライバ（AV、バックアップエージェント、DLP、暗号化、監査など）が挟まります。これらがI/Oを遅延・ブロックすると、結果的にsrv2.sys側の処理が詰まり「SMBだけ死ぬ」状態になります。Microsoftのパフォーマンスチューニング文脈でも、非効率なサードパーティフィルタドライバがI/Oに影響する場合にスレッド設定を変えるより、まずフィルタドライバの更新を優先すべき旨が示されています。

実例として、類似症状の報告スレッドでは、Kaspersky Endpoint Security（KES）を疑い、削除やサーバー向け製品に変更したところ安定した、という体験談も出ています（あくまで一例ですが「フィルタドライバ影響」の典型パターンです）。

RDMA（SMB Direct）や特殊NIC環境の不具合

もし環境にRDMA（InfiniBandなど）やSMB Directが絡む場合、srv2.sys自体が破損/異常動作するケースがMicrosoftサポート記事として存在し、更新プログラム（2975719）の適用が案内されています。VMの通常の仮想NICではRDMAは直接露出しないことが多い一方、ホスト/クラスタの設計によっては周辺が影響するため、「RDMA要素があるか」を確認する価値はあります。

SMB2/SMB3を無効化して回避…は“最後の手”になりやすい

同様の症状に対して、「SMB2/SMB3を無効化」「Windows Server 2019へ更改」という現実的な選択肢が挙げられている報告もあります。

ただし、SMB2/3を無効化すると実質的にSMB1へ寄せることになり、セキュリティ面のデメリットが極めて大きいため、恒久対策として推奨しづらいのが正直なところです。Microsoftの公式ドキュメントでも、SMBv1には重大な脆弱性があり「使わないことを強く推奨」と明記されています。

最優先の確認事項：Windows Server 2012 R2はサポート終了済み

Windows Server 2012 / 2012 R2 は2023年10月10日にサポート終了（以後は原則としてセキュリティ更新・不具合修正・技術サポートが提供されない）となっています。継続するにはESU（延長セキュリティ更新）を最大3年（2026年10月13日まで）利用する必要がある、という整理です。

この点は、今回のような「根が深いOS/カーネル起因のハング」に対して最終的に“OS更改が現実解”になりやすい理由でもあります。後述する切り分けをやっても原因が潰れない場合、2019以降（可能なら2022/2025）への移行を“根本対策の第一候補”に置くのが、セキュリティと運用の両面で合理的です。

切り分け手順：止まった瞬間の“証拠”を取り切る

SMB関連イベントログの場所を把握する

まず、SMBの詳細ログは「アプリケーション」や「システム」だけでは足りません。以下のチャンネルを確認します（イベントビューアー → アプリケーションとサービスログ → Microsoft → Windows）。SMBのトラブルシュート用に、SMBClient/SMBServer配下に複数のチャンネルがあることが案内されています。

• Microsoft-Windows-SMBServer/Operational
• Microsoft-Windows-SMBServer/Connectivity
• Microsoft-Windows-SMBClient/Operational（クライアント側の状況確認に有効）

障害が起きたら、再起動前に最低限これらをエクスポートして保全できるようにします（GUIが厳しい場合はwevtutilでevtxを書き出す）。

mkdir C:\Temp\SMBLogs
wevtutil epl "Microsoft-Windows-SMBServer/Operational" C:\Temp\SMBLogs\SMBServer_Operational.evtx
wevtutil epl "Microsoft-Windows-SMBServer/Connectivity" C:\Temp\SMBLogs\SMBServer_Connectivity.evtx
wevtutil epl "System" C:\Temp\SMBLogs\System.evtx
wevtutil epl "Application" C:\Temp\SMBLogs\Application.evtx

イベント1020/1031/1032を見逃さない（LiveKernelReportsが残る可能性）

SMBサーバー側で極端な遅延が発生すると、イベント1020の警告が出たり、状況によってはライブカーネルダンプが採取されます。その有無を示すのが、SMBServer/Operationalのイベント1031（ダンプ取得できた）とイベント1032（取得できなかった）です。ダンプファイルは %SystemRoot%\LiveKernelReports に保存されます。

ポイントはここです。「SMBだけ死ぬ」障害の核心はカーネル側で起きていることが多く、ログだけでは確定できないことがあります。Microsoftの別資料でも、SMBサーバーがpingに応答していてもSMBが無応答ならsrv/srv2がブロックされている可能性があり、原因調査にはメモリダンプが有効だとされています。

つまり、1031/1032が出ているなら「運良く証拠（ダンプ）が取れている」可能性があります。障害対応のたびに強制リセットする前に、必ず次を確認してください。

• C:\Windows\LiveKernelReports 配下に新しい.dmpがないか
• Systemドライブの空き容量（ダンプ出力に必要）
• ダンプを別媒体へコピーして保全できるか

「Serverサービス再起動がハング」なら、DisableLeasingは有力な切り分けレバー

症状が強く一致する場合、Microsoftのサポート記事にある回避策（DisableLeasing）を短期検証として試す価値があります。特に次が揃うときは相性が良いです。

• Explorerが固まる／共有ファイルが開けない
• Serverサービス再起動が停止中で固まる
• Access（.mdb）やExcelなどのファイルロック/破損が絡む

DisableLeasingは「SMB2 leasesは付与されなくなるが oplocks は残る」「主にトラブルシュート用途」とされているため、恒久運用に入れる前提ではなく、まず効くかどうかを見ます。

REG ADD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters ^
 /v DisableLeasing /t REG_DWORD /d 1 /f

効いた場合に次へ進む“実務的な流れ”は以下です。

• OS更新（ロールアップ）状況を再確認し、該当修正を含むレベルまで引き上げる
• フィルタドライバ（AV/バックアップ）を更新・入れ替え・除外設定見直し
• 可能ならAccess系はDBサーバーへ移行（ファイル共有上のMDB運用は事故りやすい）
• 最終的にOS更改で構造的にリスクを下げる

SMB2/SMB3の無効化は「原因の切り分け」には使えるが、恒久対策にはしない

Habrの報告では「SMB2/SMB3を無効化」「WS2019にする」という選択肢が挙げられています。

一方で、SMB1は推奨されず、公式にも「SMBv1は重大な脆弱性があるため使わないことを強く推奨」とされています。よって、どうしても試すなら短時間の検証に限り、影響範囲を限定し、即座に戻せる手順を用意した上で実施してください。

SMBプロトコルの状態確認と切り替えは、Set-SmbServerConfiguration（サーバー側）で行えます。SMB2を無効化するとSMB3も同時に無効化される（同じスタックを共有する）点も公式に説明されています。

Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

# SMB2/SMB3 を無効化（検証用途。影響が大きいので慎重に）
Set-SmbServerConfiguration -EnableSMB2Protocol $false

# もとに戻す
Set-SmbServerConfiguration -EnableSMB2Protocol $true

ログだけでは詰む：VMでできる「軽量トレース」と「監視」を仕込む

ネットワークトレース（ETW）を事前に準備しておく

再現が不定期のときは、発生後に「何も残っていない」が最悪のパターンです。Windows標準のnetsh traceを、障害発生時にすぐ取れるようにしておくと、SMB交渉や切断の前後関係を追いやすくなります（ディスクI/O詰まりだとトレースも取りづらいので、早めに開始しておく発想も重要です）。

mkdir C:\Temp\Trace
netsh trace start capture=yes tracefile=C:\Temp\Trace\smbtrace.etl maxsize=1024

# 取得を止める
netsh trace stop

パフォーマンスカウンターで「止まる前兆」を拾う

体感として「突然死」に見えても、裏ではディスク待ちやキューの肥大が進行しているケースがあります。SMBのパフォーマンスカウンターはWindows Server 2012で導入され、SMB2以上の監視の基礎セットとされています。

見るべきカウンター例	意味	見方の目安
PhysicalDisk\Avg. Disk sec/Read / Write	ディスク待ち時間（遅延の直撃指標）	平常時の基準を作り、障害前にスパイクしていないか比較
Server Work Queues\Queue Length（SMB2関連）	SMB要求処理の詰まり具合	継続的な高止まりはボトルネック示唆（フィルタ/ストレージ）
SMB Server Sessions / SMB Server Shares	セッション数・要求状況	急な増加や偏り（特定クライアント/特定共有）を発見

SMBサーバー側カウンターは高I/O環境で負荷になり得る点も注意が必要です。必要最小限から始め、重いと感じたら収集間隔を伸ばすなど調整してください。

「更新を当てても直らない」ケースで見落としがちな視点

“最新の更新”とは限らない：ESU/ロールアップの適用方針を確認

2012 R2は既にサポート終了済みなので、「Windows Updateを回しているつもり」でも、ESU契約や適用方式次第で必要な修正が入っていないことがあります。まずはサーバーがESU対象になっているか、毎月のロールアップが継続的に適用されているかを確認します。

フィルタドライバの棚卸し（障害対応のたびに見直す価値がある）

ファイルサーバーに入っているフィルタドライバを棚卸しして、更新/除外/削除を判断します。特に次のようなものは影響が出やすいです。

• アンチウイルス（リアルタイムスキャン）
• バックアップエージェント（変更監視、スナップショット連携）
• 暗号化、DLP、監査系

fltmc filters

「ある製品が悪い」と決めつけるのではなく、該当OS/ロール（2012 R2のファイルサーバー）に対するベンダーサポートが継続しているか、既知の不具合が出ていないか、そして除外設定が適切かを軸に判断するのが安全です。

Access（MDB）や古いアプリの運用形態そのものを疑う

Habrのスレッドでも「MS Access 2003」「長いパス」などが疑われる要素として挙がっていました。

AccessのようなファイルベースDBを共有上で多数ユーザーが使う構成は、SMBのリース/ロック/遅延の影響を受けやすく、障害時に破損が顕在化しやすいです。アプリ要件が許すなら、バックエンドをSQLなどへ移行する、最低でも配置や排他の設計を見直す、という“業務側の対策”も並行すると再発率が下がります。

最終的な着地点：現場で現実的な「対策の優先順位」

この障害は「これが原因」と断定できないまま長期化しやすい一方、運用を止められないのが実情です。そこで、優先順位を明確にして動くのがポイントです。

優先度	対策	狙い	注意点
高	SMBServer/Operational等のログ保全運用（wevtutil）＋LiveKernelReports確認	原因特定の材料を残す	強制リセット前に回収できる手順化が必要
高	フィルタドライバ棚卸し（AV/バックアップ）・更新・除外見直し	I/Oブロック要因を減らす	無効化はセキュリティ要件とセットで判断
中	DisableLeasingで切り分け（短期検証）	リース/ロック相性の切り分け	恒久運用ではなく検証用途を基本に
中	ストレージ/ホスト側のI/O遅延調査（ホストログ含む）	“VMの外”が原因のケースを潰す	関係者（仮想基盤/ストレージ担当）連携が必須
低（最終手）	SMB2/SMB3無効化（短時間の検証）	プロトコルスタック切り分け	SMB1寄りになり危険。長期運用しない
最優先の根本策	Windows Server 2019以降へ更改（可能なら2022/2025）	サポート/セキュリティ/安定性を取り戻す	移行計画と検証が必要だが、長期的には最も安い

今回の報告スレッドに見る「現実解」

Microsoft Q&A側では、再現が不定で環境要因の切り分けが必要なため、ログ採取・監視を前提にサポートケースでの調査が推奨されていました。

一方で、類似症状の経験者からは「SMB2/SMB3無効化」「Windows Server 2019へ移行」といった回避・更改が現実策として提示され、また別の報告ではOS再構築やセキュリティ製品（フィルタドライバ）見直しで安定した、という流れも見えます。

つまり、着地は大きく2つです。

• 原因を突き止める：ログ・トレース・LiveKernelReports（必要ならメモリダンプ）でカーネル/ドライバまで追う（サポート活用が現実的）
• 運用を守る：更改（2019以降）・再構築・フィルタドライバ整理で再発率を下げる（2012 R2の延命はリスクが大きい）

参考リンク（一次情報）

• Microsoft Q&A：Windows Server 2012 R2でSMB共有が不定期に切断される
• Habr Q&A：類似症状（SMB切断、Serverサービス停止ハング、強制リセット）
• Microsoft：Windows SMB server is unresponsive（srv2.sys/srv.sysがブロックされる可能性）
• Microsoft：イベント1020とLiveKernelReports（1031/1032）のトラブルシュート
• Microsoft Support：共有ファイルが開けない/Explorerフリーズ/Serverサービス停止中ハング（DisableLeasingの回避策）
• Microsoft：SMBv1/SMBv2/SMBv3の有効/無効手順（SMBv1非推奨）
• Microsoft Lifecycle：Windows Server 2012/2012 R2 サポート終了とESU
• Microsoft：SMBファイルサーバーのパフォーマンスチューニング（監視カウンター/レジストリ）