BizTalk Server 2016 を2台ファーム＋2ノードSQLクラスタで運用していると、特定Host Instanceだけが停止→自動再起動を繰り返し、起動できなくなることがあります。イベントログに30000msのトランザクション待ちタイムアウトが出る場合の、現場で効く切り分け手順を整理します。
現象：特定のHost Instanceが再起動ループになり起動しない
今回のケースは、次のような構成・状況を前提にしています。
- BizTalk Server 2016 を2台構成（ファーム）で運用
- バックエンドは2ノードのSQLクラスタ
- 同一サービスアカウントでインプロセスHost Instanceが多数（例：15個）稼働
- そのうち特定ホスト（例：ETAT_x64_ProcessHost）だけが両方のBizTalkサーバーで起動できず、停止→自動再起動を繰り返す
イベントログでは、概ね次のパターンが混在しがちです（文言は環境や更新プログラムで多少揺れます）。
- トランザクション応答待ちのタイムアウト（30秒／30000ms）
- 一度「実行中」になった直後に異常終了（サービスが予期せず終了した、など）
- 原因候補として「メモリ不足（Out of memory）」や「BizTalk DBへの接続不可／接続断」が示唆される
- SQLクラスタ／BizTalkサーバーを再起動しても改善しない
ログの読み方：停止→自動再起動は「原因」ではなく「結果」
多くの環境では、Windowsサービスの回復オプション（障害時の動作）が「サービスを再起動する」になっています。つまり根本原因は「サービスが落ちていること」で、再起動ループは回復設定がそれを繰り返している状態です。まずは「落ちた原因の手掛かりを取る」ことが最短ルートになります。
| 観点 | 見る場所 | ポイント |
|---|---|---|
| サービス異常終了の痕跡 | システムログ（Service Control Manager）、アプリケーションログ | 「予期せず終了」「例外コード」「障害モジュール名」など、落ちた直後のイベントを拾う |
| BizTalk側の起動・停止理由 | アプリケーションログ（BizTalk関連イベント） | 30000msタイムアウト、構成読込、アダプター初期化、SSO、DB接続などの流れを追う |
| DB側の異常 | SQL Server エラーログ、クラスタログ、待機/ブロック状況 | 「接続できない」よりもロック/待機で返ってこないケースが多い |
Microsoft Q&Aでの扱い：BizTalkは対象外になりやすい
質問を投げた先がMicrosoft Q&Aの場合、内容やタグによっては「BizTalkはサポート対象外（スコープ外）」として、具体的な原因特定や対処案の提示が難しいことがあります。この場合は、BizTalk専用の情報源（公式ドキュメント、Tech Community、旧MSDNフォーラム系の移行先など）へ誘導されてクローズされる流れになりがちです。
ただし、現場でのトラブルシューティングは待ってくれません。以降では「特定ホストだけ」「両ノードで同じ」という条件を強いヒントとして、切り分けの優先順位を整理します。
ポイントは「特定ホストだけ」「両方のBizTalkノードで同じ」
この2条件は、原因の当たりを付けるうえで非常に強力です。
- 両ノードで同じ：マシン固有（片側だけのOS破損、片側だけのパッチ差、片側だけのローカル設定差）よりも、共有要素（BizTalk DB、SSO、SQLクラスタ、共有ファイル、共通のアプリ資産、共通のアダプター依存関係）を疑いやすい。
- 特定ホストだけ：BizTalkグループ全体ではなく、そのホストに紐づくアダプター・受信/送信・オーケストレーション・パイプライン・カスタムコンポーネント、あるいはホスト固有の設定（32/64bit、スレッド/インスタンス設定、追跡設定など）に絞り込みやすい。
| 状況 | 疑う範囲 | 例 |
|---|---|---|
| 全Hostが落ちる | グループ全体・DB・SSO・SQLクラスタ | MessageBox/SSO障害、SQL全体の停止、広範囲なネットワーク断 |
| 特定Hostだけ落ちる（両ノードで） | ホスト固有の資産・依存 | 特定アダプター、特定パイプライン/コンポーネント、特定送受信ポート群、特定証明書 |
| 片ノードだけで落ちる | マシン固有の要因 | ローカルファイル欠損、GAC差分、更新プログラム差、ローカルFW/ウイルス対策 |
まずやること：証拠を取りやすい状態にして「落ちる瞬間」を掴む
再起動ループ中はログが流れて追いづらいので、以下のように短時間だけ「再起動を止めて」観察すると原因が見えやすくなります（本番影響が出る場合は、関係者合意のうえで実施してください）。
- 対象Host InstanceのWindowsサービス回復設定（障害時の動作）を一時的に「何もしない」に変更
- イベントログ（アプリケーション／システム）をクリアせず、発生時刻をメモして相関が取れるようにする
- 手動でサービスを起動し、起動から停止までの間に出るイベントを時系列で並べる
- アプリケーションログに「Application Error（イベントID 1000）」や「Windows Error Reporting（イベントID 1001）」が出ていないか確認
コマンドで回復設定を確認したい場合は、管理者権限で次のように実行します（サービス名は環境で異なります）。
sc qfailure "BizTalk Service BizTalk Group : ETAT_x64_ProcessHost"
sc qc "BizTalk Service BizTalk Group : ETAT_x64_ProcessHost"切り分け優先順位：30000msタイムアウトは「DB/トランザクション」から疑う
「30秒のトランザクション応答待ちタイムアウト」が出る場合、現場で最優先に当たるのはDB接続・トランザクション・MSDTC周りです。理由は単純で、BizTalkのHost起動時は構成情報の読込、アダプター初期化、インスタンス回復などでDBアクセスが集中し、そこで待たされると連鎖的に異常終了へ繋がりやすいからです。
| 疑う領域 | 典型的な症状 | すぐできる確認 | よくある対処 |
|---|---|---|---|
| SQL側のロック/待機 | 接続はできるが応答が遅い／タイムアウトする | SQL側でブロックチェーン、待機統計、ディスクI/O、tempdbの逼迫を確認 | 原因クエリの特定、インデックス/統計更新、I/O改善、メンテナンスジョブの見直し |
| MSDTC疎通/設定不整合 | DTC関連のイベント、分散トランザクションで失敗 | BizTalk/SQL双方でDistributed Transaction Coordinatorサービス稼働、ネットワークDTCアクセス設定、FWポート | 設定整合、認証レベル調整、FW開放、クラスタDTCリソース見直し |
| ネットワーク/名前解決 | 断続的な接続断、フェイルオーバー後に不安定 | SQL仮想名への疎通、DNS、ルーティング、NICチーミング設定、FW/IPSログ | DNS/TTL調整、仮想名/リスナー設定確認、ネットワーク機器ログの突合 |
| BizTalk DBのメンテ不足 | バックログ増、追跡DB肥大、ジョブ失敗 | SQL Agentジョブ（DTA Purge/Archive等）の失敗有無、DB容量、ログ肥大 | ジョブ復旧、追跡設定の見直し、アーカイブ方針策定 |
MSDTCのチェックポイント（BizTalkサーバー側）
- サービス「Distributed Transaction Coordinator」が起動している
- コンポーネントサービスで「ネットワークDTCアクセス」「受信/送信許可」「リモートクライアント許可」などが環境方針に合っている
- 認証レベル（相互認証/受信認証/認証不要）がBizTalk側とSQL側で整合している
- ファイアウォールでRPC Endpoint Mapper（135）およびDTCで使用する動的ポートが阻害されていない
特にSQLがクラスタの場合、クラスタDTC（DTCリソース）を使う構成か、ローカルDTCで足りる構成かで設計が異なります。環境設計書や運用手順に従って「正しい前提」で確認してください。
次に疑う：ホスト固有の資産（アダプター／パイプライン／カスタム）
DB/DTCに明確な異常が見えない場合でも、「特定ホストだけ落ちる」なら、そのホストで初期化される何かが原因で落ちている可能性が高いです。典型的には次のようなものです。
- 特定ホストにだけ紐づく受信場所（Receive Location）・送信ポート（Send Port）
- 特定アダプター（例：SFTP、HTTP、MQ、SAP、WCF系など）の初期化
- カスタムパイプラインコンポーネントやカスタムアセンブリ（GAC展開、依存DLL、ネイティブDLL）
- 証明書（期限切れ／秘密鍵アクセス権／ストア配置ミス）や外部接続先の資格情報
実務で効く切り分け：対象ホストに紐づく処理を「段階的に外す」
再現性のある障害ほど、段階的に負荷・依存を外すと原因が浮きます。例えば次の順で「何を外したら起動するか」を確認します。
- 対象ホストに紐づく送受信を一時的に無効化（受信場所の無効化、送信ポートの停止など）
- 対象ホストを起動できるか確認（起動できたら、外した範囲に原因がある可能性が高い）
- 無効化した設定を小分けに戻し、再度起動確認（原因のポート/アダプター/資産を特定）
「本番で受信を止められない」場合は、フェイルオーバーやメンテナンス時間を活用し、影響範囲を最小化した検証手順として準備しておくと、復旧が早くなります。
| 対象 | 外し方の例 | 得られる示唆 |
|---|---|---|
| 受信（Receive Location） | 対象ホストに紐づく受信場所を無効化 | 受信アダプター初期化や受信時処理が原因の可能性 |
| 送信（Send Port） | 対象ホストに紐づく送信ポートを停止 | 送信アダプターや外部接続先が原因の可能性 |
| カスタム資産 | 直近で導入/更新したDLL・ネイティブ依存の差分確認 | ロード時例外、依存解決失敗、バージョン不整合の可能性 |
メモリ不足（Out of memory）を疑うときの現実的な見方
イベントに「Out of memory」と出ても、実際には物理メモリ枯渇だけが原因とは限りません。BizTalkのHost Instance（BTSNTSvc.exe）は、カスタムコードやアダプター、依存DLLの影響も受けます。次の観点で「本当にメモリが原因か」を見極めます。
- 急に落ちる：例外でクラッシュしている可能性が高い（Application Error / WERを確認）
- 徐々に不安定：リークやハンドル枯渇、バックログ蓄積、追跡DB肥大など長期要因の可能性
- 特定ホストだけ：そのホストで使うアダプター/カスタム資産のリークを疑う
PerfMonで最低限見るカウンター
| カテゴリ | カウンター | 見方 |
|---|---|---|
| Process（BTSNTSvc.exe） | Private Bytes / Working Set / Handle Count | 起動直後に急増して落ちる、時間と共に右肩上がり、などを確認 |
| .NET CLR Memory（該当プロセス） | # Bytes in all Heaps / Gen 2 Collections | カスタム.NETコンポーネントが疑わしい場合に参考 |
| Memory / Paging | Available MBytes / Pages/sec | OS全体の逼迫、ページング過多の有無を確認 |
もしクラッシュが疑わしい場合、ダンプ取得（例：Procdumpで例外時に採取）を行うと、原因DLLや例外箇所が特定しやすくなります。運用ポリシー上ダンプ取得が難しい場合でも、少なくともWERイベントの「障害モジュール名」「例外コード」は控えておくと、調査が進みます。
「再起動しても治らない」時に見落としがちなチェック
サーバーやSQLクラスタの再起動で改善しない場合、単なる一時的なハングではなく、設定・資産・データ状態の問題が残っていることが多いです。以下は見落としがちなポイントです。
そのホストだけの構成差
- ホストが32bitか64bitか（依存アダプターやCOMが32bit前提の場合に問題化）
- ホストのスレッド数、プロセスモデル、追跡設定（Tracking）などの差
- ホストにだけ割り当てられているアプリケーション（バインド）や依存アセンブリ
サービスアカウント周り（「他が動く」でも油断しない）
同じアカウントで他ホストが動いていても、以下のような「ホスト固有の差分」で失敗することがあります。
- アクセスする共有フォルダや証明書秘密鍵のACLが、特定ホストの処理だけに影響している
- 外部接続先（SFTP/SAP/DB等）の資格情報変更が、特定送受信だけに影響している
- GPOで「サービスとしてログオン」が制限され、再起動後に反映されている
データ滞留・ロック・待機（メッセージボックスの状態）
BizTalkは稼働が続くほど、追跡DB（DTA）やメッセージボックス周りのメンテナンスが重要になります。ジョブ失敗やDB肥大があると、起動時の構成読込や回復処理が遅くなり、タイムアウトの引き金になります。
- SQL Agentジョブが落ちていないか（特にDTA Purge/Archive）
- Trackingを必要以上に有効化していないか（本番は最小限が原則）
- サスペンドが大量に溜まっていないか（Group Hubで確認）
実務向け：時系列で追う「最短ルート」の手順
現場で「何から手を付けるか」を迷わないために、よく効く順に手順をまとめます。
- 発生時刻を固定してログを集める
- アプリケーションログ：BizTalk関連イベント、Application Error、WER
- システムログ：Service Control Manager、ネットワーク系
- SQL側：エラーログ、クラスタ関連、待機/ブロック状況
- DB疎通の「接続できる」ではなく「応答が返る」を確認
- SQLへのログインは成功するか
- 同時間帯に重いメンテナンスやバックアップが走っていないか
- ブロック（ロック待ち）が連鎖していないか
- MSDTCの稼働・設定・FWを確認
- BizTalkとSQLの双方で設定が揃っているか
- クラスタ構成に合ったDTC設計になっているか
- セキュリティ強化（FW/GPO）直後に発生していないか
- 対象ホストに紐づく送受信を一旦止めて起動確認
- 起動できたら、その範囲のアダプター/資産を絞り込み
- 起動できないなら、DB/SSO/共通基盤側の疑いを強める
- クラッシュが疑わしいならダンプ取得を検討
- 障害モジュールがカスタムDLLなら、まずそこから
- Microsoft提供DLLやアダプターなら、適用CU/Hotfixの確認へ
フォーラムに相談するなら：最初に揃える情報テンプレ
BizTalk専用フォーラムやMicrosoftサポートへ問い合わせる場合、初動で情報が揃っているほど回答が早くなります。以下を埋められる形で準備しておくのが実務的です。
| 項目 | 例 | 目的 |
|---|---|---|
| BizTalkのバージョン/更新レベル | BizTalk Server 2016 + 適用CU（番号） | 既知不具合や修正有無の判断材料 |
| 対象Host名と種別 | ETAT_x64_ProcessHost / インプロセス / 64bit | ホスト固有要因の切り分け |
| イベントログの抜粋 | 発生時刻前後の関連イベント（ID/メッセージ） | 時系列で原因候補を絞る |
| SQL構成 | SQLクラスタ種別、仮想名/リスナー、DB配置 | 接続経路・DTC構成の確認 |
| MSDTC設計/設定 | 認証レベル、FW、クラスタDTCの有無 | 分散トランザクション要因の確認 |
| 最近の変更 | Windows Update、GPO変更、証明書更新、アプリ更新 | 発生トリガー（変更点）に当たりを付ける |
再発防止：ホスト障害を「起きてもすぐ戻せる」運用に寄せる
原因が何であれ、Host Instanceの停止はメッセージ遅延や外部連携停止に直結します。再発防止としては、次のような運用設計が効きます。
- 監視：Host Instanceの停止・再起動回数・メッセージ滞留を監視し、一定回数でアラート
- 隔離：重いアダプターや不安定なカスタム処理は専用ホストへ分離し、他へ波及させない
- DBメンテ：SQL Agentジョブの監視、DTAの適正運用、容量監視、I/O監視
- 変更管理：証明書更新、GPO/FW変更、Windows Updateは事前検証とロールバック手順をセットで
- ログ/ダンプ戦略：障害時に取るログのテンプレ、必要なら短時間でダンプ取得できる手順を整備
まとめ：最初の一手は「DB/トランザクション」と「ホスト固有資産」の二正面
BizTalk Server 2016で特定Host Instanceだけが両ノードで再起動ループになる場合、経験上はDB応答遅延（ロック/待機）やMSDTC、そしてそのホスト固有のアダプター/カスタム資産が上位候補です。再起動を繰り返しても改善しないときほど、ログを時系列で揃え、依存を段階的に外していく手順が効果的です。焦って闇雲に再起動を重ねるより、「落ちる瞬間の証拠」を掴むことが、最短で復旧と再発防止に繋がります。
コメント