Windows Server vNext（Insider Preview）でDNS Server（dns.exe）が動的更新のたびにクラッシュし、例外0xc0000374（ntdll.dll）が記録されるケースがあります。Build 20257以降で起きやすいこの不具合について、確認方法、影響、暫定回避、修正ビルドへの更新手順を整理します。
Windows Server vNext（Insider Preview）でDNS Server（dns.exe）がクラッシュする症状
本件は、Windows Server vNext（Windows Server Insider Preview）の特定ビルドで、DNS Server サービス（実体プロセス：dns.exe）が異常終了する不具合です。特に厄介なのは、DNS の動的更新（Dynamic Update）要求を受けたタイミングで高確率にクラッシュすることです。参照系のクエリ（名前解決）だけを行っている間は「なんとなく動いている」ように見え、障害の発見が遅れがちです。
| 観点 | 内容（要点） |
|---|---|
| 発生ビルド | Build 20257（以降）で発生。Build 20251 は正常、Build 20262 でも継続、Build 20270 で修正報告あり |
| 影響を受けやすい役割 | AD DS のドメイン コントローラー（DC）上の DNS Server（物理／仮想問わず） |
| トリガー | DNS 動的更新（クライアントの登録、DHCP による登録、DC 自身の SRV 登録など） |
| イベントログ例 | Application Error：Faulting application dns.exe／Faulting module ntdll.dll／Exception code 0xc0000374 |
| 再現しやすい構成 | Hyper-V + SET（Switch Embedded Teaming）構成で再現報告 |
例外コード 0xc0000374 は、一般にヒープ破損（メモリ破損）で検出されやすい値として知られています。設定不備が原因の場合は「特定の設定を変えると改善する」ことが多いのに対し、ヒープ破損は「特定操作でほぼ必ず落ちる」「ビルドを境に突然発生する」ことが多く、Insider ビルド固有の不具合を疑う材料になります。
なぜ「動的更新で落ちる」とAD DS全体が不安定になるのか
Active Directory 環境における DNS の動的更新は、思っている以上に頻繁です。たとえば次のような更新は、ユーザー操作なしで繰り返し発生します。
- ドメイン コントローラー自身の SRV レコード登録（例：_ldap._tcp、_kerberos._tcp など）
- クライアントの A/AAAA レコードと PTR レコード登録（IP 変更、再起動、Wi-Fi 切替などで発生）
- DHCP サーバーがクライアント名を代理で更新（「常に動的に DNS A および PTR レコードを更新する」等の設定）
そのため、dns.exe が動的更新で落ちる状態だと、DNS の可用性が下がるだけでなく、AD の名前解決基盤そのものが不安定化します。典型的には次のような二次障害につながります。
- ログオン遅延、グループ ポリシー適用の失敗や遅延
- ドメイン参加や DC 探索（DC Locator）が失敗する
- アプリケーションが参照するバックエンド名解決が断続的に失敗し、障害が連鎖する
最初にやること：10分でできる切り分け
Insider Preview の検証では、まず「現象がビルド由来か」「本当に動的更新がトリガーか」を短時間で確認するのが効率的です。
| 確認項目 | 具体的な確認方法 | 判断の目安 |
|---|---|---|
| OS ビルド番号 | winver / systeminfo / レジストリ（CurrentBuild） | 20257 以降なら該当可能性が上がる |
| クラッシュ痕跡 | イベント ビューアー（Application Error / Windows Error Reporting） | dns.exe と 0xc0000374 が繰り返し出る |
| 動的更新がトリガーか | クライアントで ipconfig /registerdns を実行し、直後に落ちるか | 更新要求のたびに落ちるなら関連が濃厚 |
| 仮想化／SET の有無 | Hyper-V の有無、vSwitch が SET（Embedded Teaming）か | 同構成で再現するなら報告内容と整合 |
ビルド番号の確認例（PowerShell）：
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
Select-Object ProductName, DisplayVersion, CurrentBuild, UBRイベントログで見える典型パターン
証拠として最も強いのが、イベント ビューアーに記録される「Application Error（イベント ID 1000）」と「Windows Error Reporting（イベント ID 1001）」です。dns.exe が落ちた直後の時刻で、同じパターンが連続していないかを確認します。
ログに出やすいキーワード：
- Faulting application name：dns.exe
- Faulting module name：ntdll.dll
- Exception code：0xc0000374
PowerShell で直近の該当イベントを抽出する例：
$filter = @{
LogName = 'Application'
ProviderName = 'Application Error'
StartTime = (Get-Date).AddDays(-3)
}
Get-WinEvent -FilterHashtable $filter |
Where-Object { $*.Message -match 'dns.exe' -and $*.Message -match '0xc0000374' } |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List注意点として、Faulting module が ntdll.dll だからといって「ntdll.dll が壊れている」とは限りません。ntdll.dll は多くのプロセスが利用する共通コンポーネントであり、実際には dns.exe の処理中に起きたヒープ破損が ntdll.dll 側で検出されて落ちている、という見え方になることがあります。
「動的更新で落ちる」ことを最短で再現確認する
再現性が高いクラッシュは、検証と報告の質を上げる最大の材料です。動的更新が本当にトリガーか、次の手順で確認します（検証環境で実施してください）。
クライアントから更新を発生させる
- 影響を受けている DNS サーバー（DC）を、クライアントの参照 DNS として設定する
- クライアントで管理者権限のコマンド プロンプトを開く
ipconfig /registerdnsを実行する- DNS サーバー側で dns.exe が落ちる（またはイベントが追加される）か確認する
DC 自身の更新を意図的に走らせる
DC 側で更新を発生させたい場合は、次のコマンドで登録処理を促せます。
ipconfig /registerdns
nltest /dsregdns参照クエリだけでは判断できないことがある
この不具合は「更新が引き金」になりやすいため、参照（名前解決）テストだけでは見逃すことがあります。参照と更新を分けて試すのがポイントです。
# 参照（通常はこれだけでは落ちないことがある）
Resolve-DnsName example.local -Server <DNSサーバーIP>
# 更新（これがトリガーになりやすい）
ipconfig /registerdns緊急対応：サービスが落ちた直後に影響を抑える手順
検証中でも「DNS が止まった瞬間に検証が全部止まる」状況は珍しくありません。根本解決は後述の「修正ビルドへ更新」ですが、当面の影響を抑えるために、現場でよく使う対応を整理します。
| やること | 狙い | コマンド例 | 注意点 |
|---|---|---|---|
| DNS サービス状態の確認 | 停止／再起動ループの把握 | Get-Service DNS | 落ち方によっては自動再起動していることがある |
| DNS サービスの再起動 | 一時的に名前解決を復旧 | Restart-Service DNS | 動的更新が来ると再度落ちる可能性が高い |
| クライアント側の参照 DNS を冗長化 | 単一障害点を避ける | DHCP Option 006、NIC の DNS 設定 | AD 環境では「複数 DC/DNS」を前提に設計するのが安全 |
| 別の DNS へ一時退避 | 業務影響の最小化 | 別 DC/DNS、または安定 OS の DNS を追加 | ゾーンの複製／転送やクライアント設定変更が必要 |
Insider Preview のクラッシュは「再起動すれば直る」類の障害に見えて、すぐ再発することが多いです。緊急対応はあくまで時間稼ぎと割り切り、早めに修正ビルドへ上げる判断が重要です。
0xc0000374（ヒープ破損）をどう捉えるべきか
0xc0000374 は、典型的には STATUS_HEAP_CORRUPTION として扱われる例外です。ヒープ破損は「ある処理の中でメモリが壊れ、その少し後に別の場所で検出されて落ちる」ことが多く、設定変更で安定化できるケースは多くありません。
今回のように、
- 特定ビルドを境に突然発生し始める
- 前のビルド（Build 20251）では発生しない
- 役割（DNS Server）と操作（動的更新）で再現性が高い
という条件が揃う場合は、根本対処として修正版ビルドに更新するのが最短ルートです。
解決策：修正ビルド（Build 20270 以降）へ更新して挙動を確認する
Insider Preview の不具合は累積的に修正されることが多く、個別の修正が特定ビルドで入るケースがあります。本件は、Build 20262 でも継続した一方で、追記情報として Build 20270 で修正されたとの報告があります。まずは手元環境を Build 20270（またはそれ以降）へ更新し、動的更新でクラッシュしなくなるかを確認するのが基本方針です。
| ビルド | 状態 | 補足 |
|---|---|---|
| 20251 | 正常 | 比較対象として有用。再現しないなら「ビルド差分」が強い根拠になる |
| 20257 以降 | 発生 | 動的更新要求を受けると dns.exe が落ちる |
| 20262 | 継続 | 更新しても改善しないケースがある |
| 20270 | 修正報告あり | まずここ（またはそれ以降）へ上げて挙動確認 |
更新の進め方（現実的な手順）：
- DC が複数あるなら、まず 1 台を更新して検証し、問題が解消するか確認する
- 更新前にスナップショット（仮想）やフルバックアップ（物理）を取得し、戻せる状態を作る
- 更新後は「参照」「動的更新」「SRV 登録」の3点セットでテストし、再発の有無を判断する
暫定回避策：更新できない／検証が必要な場合の選択肢
修正ビルドへ上げられない事情がある場合は、業務影響や検証計画に応じて「止血」を検討します。ただし、Insider Preview を本番運用すること自体が高リスクである点は前提として判断してください。
| 回避策 | 効果 | メリット | 注意点 |
|---|---|---|---|
| 安定していたビルドへ戻す（例：20251） | 高 | 症状が消える可能性が高い | ロールバック可否は条件があり、DC では特に慎重な検証が必要 |
| リリース版 Windows Server を使う | 高 | 運用の安定性が高い | vNext 固有の検証が目的なら、検証対象から外れる場合がある |
| DNS を別サーバーへ逃がす | 中〜高 | ドメイン全体の影響を抑えられる | AD 統合ゾーン、転送、クライアント設定変更の設計が必要 |
| 動的更新の発生頻度を下げる | 低〜中 | 落ちる回数を減らせる場合がある | 根本解決にならず、AD の副作用（レコード欠落等）が出やすい |
「動的更新を止める／抑える」は一見効きそうですが、AD DS の正しい動作を壊しやすく、後追い障害（レコード欠落、ログオン遅延など）を招きがちです。切り分け目的で短時間だけ実施する場合も、必ず元に戻す前提で扱ってください。
Windows Server Insiders（Tech Community）で報告・追跡するのが近道
Insider Preview 固有の不具合は、一般的な Q&A よりも、Windows Server Insiders の Tech Community で扱われやすく、プロダクト チームが追いやすい傾向があります。再現性が高いクラッシュほど、情報が揃っていると修正や周知が進みやすくなります。
報告前に揃えると有用な情報を、チェックリストとしてまとめます。
| 情報 | 例 | 目的 |
|---|---|---|
| ビルド番号 | 20251 / 20257 / 20262 / 20270 など | 修正の有無や差分の特定 |
| 役割と構成 | AD DS + DNS、DHCP の有無、ゾーン種別（AD 統合など） | 依存関係の把握 |
| 再現手順 | クライアントで ipconfig /registerdns → DNS がクラッシュ | プロダクト側で再現できるか |
| イベントログ | Application Error / WER の該当イベント | クラッシュ原因の手掛かり |
| 仮想化と NIC 構成 | Hyper-V、SET、vSwitch 設定、NIC ドライバー | 特定構成依存の可能性を評価 |
実務で効く：dns.exe のクラッシュ ダンプを取って解析可能にする
「落ちる」という事実だけでは、原因追跡が進まないことがあります。再現性が高いなら、クラッシュ ダンプが取れるようにしておくと、調査の精度が上がります。ここでは Windows Error Reporting（WER）の LocalDumps を使う方法を示します。
注意：ダンプにはメモリ内容が含まれ得ます。機密情報の取り扱いルールに従い、保管・共有範囲を管理してください。
REM ダンプ保存先フォルダーを作成（例）
mkdir C:\Dumps
REM dns.exe の LocalDumps を有効化
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\dns.exe" /v DumpFolder /t REG_EXPAND_SZ /d "C:\Dumps" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\dns.exe" /v DumpType /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\dns.exe" /v DumpCount /t REG_DWORD /d 10 /f設定後に再現させると、指定フォルダーに dns.exe.*.dmp のようなファイルが生成されることがあります。プロダクト側へ提供する場合は、必要最小限の情報（再現手順、ビルド、イベントログ、ダンプ）をセットで揃えると話が早いです。
Hyper-V + SET（Switch Embedded Teaming）構成での確認ポイント
再現報告として挙がりやすいのが、Hyper-V の仮想スイッチで SET（Switch Embedded Teaming）を利用している構成です。SET は Hyper-V vSwitch に冗長性を組み込む方式で、NIC ドライバーやオフロード設定の影響を受けることがあります。
構成確認の例（PowerShell）：
# vSwitch の一覧（EmbeddedTeamingEnabled が True か確認）
Get-VMSwitch | Select-Object Name, SwitchType, NetAdapterInterfaceDescription, EmbeddedTeamingEnabled
# 物理 NIC の状態確認
Get-NetAdapter | Select-Object Name, Status, LinkSpeed, DriverDescriptionここで重要なのは、SET の有無だけで結論を出さず、次の観点で「再現条件」を整理することです。
- 同じビルドで SET を使わない構成でも再現するか
- 物理サーバーでも再現するか（仮想化依存か）
- NIC ドライバー更新で変化があるか
Insider Preview を安全に検証するための運用ポイント
クラッシュ系の不具合は、検証環境でも被害が大きくなりがちです。Insider Preview を扱うときは、次の運用を基本にすると検証が止まりにくくなります。
- 役割を分離する：DC/DNS を 1 台に集約せず、冗長構成にする
- 更新前後で戻せる状態にする：スナップショットとバックアップ、復元手順をセットで用意する
- 検証目的を明確にする：新機能検証なら、基盤障害が出た時点で「一旦リリース版に逃がす」判断も現実的
- 既知不具合の追跡先を決める：Tech Community のスレッドで修正ビルドを追い、更新判断の材料にする
まとめ
Windows Server vNext（Insider Preview）での DNS Server（dns.exe）クラッシュは、ビルド差分と再現性（動的更新で落ちる）から、設定というよりビルド固有の不具合である可能性が高い事象です。まずは OS ビルドを確認し、修正報告のある Build 20270 以降へ更新して改善するかを見ます。更新できない場合は、安定ビルドへのロールバックやリリース版への切り替え、別 DNS への退避などで影響を抑える判断が現実的です。再現手順とログ／ダンプを整理して報告できる形にしておくと、同様の障害に遭遇した際の対応速度も上がります。
コメント