新しく構築したWindows Server 2025のドメインコントローラーで、UI要素を含むWindowsサービスを起動した際、ほかのSYSTEMアカウントで稼働中のプロセスを停止しようとするとハングが発生する…。一見単純な構成に思えても、ドメインコントローラー上でのUI付きサービス運用にはいくつか気を付けるポイントがあります。この記事では、実環境や開発現場での運用を踏まえながら、問題解決のための手がかりと回避策をじっくりと探っていきます。
WindowsサービスにUIを含めることの背景
Windowsサービスは、本来バックグラウンドで動作するよう設計されており、通常のユーザープロセスとは別のセッションや権限で運用されます。特にSYSTEMアカウントで実行する場合、最上位権限が付与されるため、セキュリティ上の観点での制限や制御も強化されます。そのため、UI要素（フォームなど）を含むサービスを設計する場合は、考慮すべき点が多いのです。
通常のWindowsサービスとUI要素の関係
一般的に、Windowsサービスはサーバーアプリケーション的な役割を担い、ユーザーとの対話を想定していません。サービスにUIを持たせること自体は技術的に不可能ではありませんが、以下のようなリスクがあります。
- セッション0分離：Vista以降のWindowsでは、サービスが動作するセッションとユーザーがログオンするセッションが分離されています。
- 権限管理の複雑化：SYSTEMアカウントでUIを扱う場合、表示先のデスクトップとのやり取りが制限されるなど、挙動が不安定になる可能性が高い。
- 操作や終了処理時の不具合：高い権限を持つプロセスがUIを介して待機状態になると、デッドロックや応答停止が生じやすい。
Windows Server 2025環境での変化
サーバーOSの新しいバージョンがリリースされるたびに、セキュリティとサービス制御の仕組みは強化される傾向にあります。Windows Server 2025では、従来のサーバーOS以上にサービスがUI関連の操作を行う際の制限が厳しくなっている可能性が考えられます。そのため、開発や運用の現場で従来の手法が通用しないケースが出てくるのです。
問題の現象と具体的な例
今回報告されている現象は、Windows Server 2025ドメインコントローラー上で、自動起動（Autostart）の設定でインストールされたUI付きのサービスが稼働中に、同一マシン内のSYSTEMアカウントで実行されている別プロセス（タスクスケジューラやPSExecなど）が終了できずハングするというものです。具体例として、以下のようなコードが挙げられています。
public partial class Service1 : ServiceBase {
public Service1() {
InitializeComponent();
}
protected override void OnStart(string[] args) {
using (var f = new Form1()) {
// フォームのインスタンス化のみ
}
}
protected override void OnStop() {
// 停止処理
}
}このように、サービスのOnStartメソッド内でWindowsフォームを生成しています。実際にはフォームを表示していないかもしれませんが、サービスとしてはUI要素（Form1）を扱っていることが問題の発端となります。
ハングが起きる状況
- ドメインコントローラーであること
- SYSTEMアカウントで動作するプロセスが複数あること
- UI要素を含むWindowsサービスが自動起動している状態で、ほかのSYSTEMアカウントプロセスを終了させようとする
こうした条件が重なった際に応答が途絶え、プロセスを強制終了するしか手段がなくなるケースがあるようです。
ハング時の状態把握方法
いきなり問題解決に踏み込む前に、まずは「何が原因でハングしているのか」を徹底的に調査するのがポイントです。具体的には以下の手法が挙げられます。
- Windowsのイベントビューア（アプリケーション、システムログ）を確認し、エラーや警告の有無を探る。
- Resmon（リソースモニター）やパフォーマンスモニターを使い、CPUやメモリ利用率、スレッド数などの動向を追う。
- デバッグツール（WinDbgなど）でミニダンプを取得し、問題が再現した際のスタックトレースを解析する。
問題への対策と検証手法
以下では、実際に現場で取りうる対策や検証手順を整理します。できるだけフェーズごとに分けて進めることで、問題の原因を切り分けていくことが重要です。
1. 物理マシンでの再現確認
まずは仮想化環境（XCP-ng）固有の問題かどうかを切り分けるために、物理サーバー上のWindows Server 2025ドメインコントローラーで同じサービスを実行してみます。もし物理マシン上でも現象が再現するなら、XCP-ngによる影響よりもOSやドメインコントローラー設定による影響が疑われます。
| 手順 | 内容 |
|---|---|
| 1-1 | 物理マシンにWindows Server 2025をインストール（ドメインコントローラー化） |
| 1-2 | 同一のサービスをインストールし、自動起動設定 |
| 1-3 | SYSTEMアカウントで動作する別プロセスを起動・終了させ、ハング再現を確認 |
2. メンバーサーバーでの再現確認
もしドメインコントローラーでしか起きない現象であれば、ドメインコントローラーに固有の役割やセキュリティポリシーの影響が考えられます。そこで、同じWindows Server 2025でもドメインコントローラー化していないメンバーサーバー上で同様のサービスを試し、状況を比較します。
- ドメインコントローラー以外のサーバー（メンバーサーバー）でサービスを同一手順でインストール
- ほかのSYSTEMアカウントプロセスを操作し、ハングが発生するか検証
3. リソースモニタリングとデバッグ
サービスの起動・停止時や、問題の発生タイミングでCPU、メモリ、ディスクI/O、ネットワークなどをモニタリングし、異常値がないかを確認します。特に、フォームを含むサービスの場合、UI周りのスレッドやGDIハンドルが過剰に生成されていないかなどをチェックします。
リソースモニター確認項目例：
- CPU使用率：サービスプロセスまたはSYSTEMプロセスが高騰していないか
- メモリ：非ページ プールが急増していないか
- ハンドル数：GDIハンドルやUSERハンドルが上限に達していないか4. サービスの設計見直し（UI要素の分離）
サービスにUIを含めること自体がWindowsの推奨設計から外れているため、UI要素を別プロセスとして切り離すのがベストプラクティスです。具体的には以下のようなパターンが考えられます。
- Windowsサービス（バックグラウンド処理のみ） + 通常のデスクトップアプリケーション（UI）
- Windowsサービス + Web UI（ブラウザからアクセスする管理画面）
- Windowsサービス + WPF/WinFormsアプリ（IPCで連携）
このようにUI部分を切り離すことで、サービスは基本的にコンソールやバックグラウンド処理に専念し、ユーザーが操作する必要のある画面は専用のアプリやWebベースの管理ツールで行う構成にするのが安全かつ安定的です。
IPC（プロセス間通信）の活用例
- Named Pipe
- WCF（Windows Communication Foundation）
- SignalRなどのHTTPベースの通信
- TCPソケット通信
これらを使ってサービスとUIアプリをやり取りさせることで、UI部分がサービス本体の制限から解放され、ハングやセッションの問題を回避しやすくなります。
5. サービスセッションの取り扱い
Windows Server 2025においては、サービスは通常セッション0で動作しますが、UIを表示するにはインタラクティブなセッションが必要です。セッション0分離が強化された背景にはセキュリティリスクの低減がありますが、その反面、UI付きサービスのような特殊なケースでは動作が阻害される可能性があります。
- ドメインコントローラーはセキュリティ設定が厳格に適用されるため、従来よりもUI関連の制御が厳しくなる傾向がある
- SYSTEMアカウントのアプリケーションがユーザーと直接対話すること自体、セキュリティ上リスクが高い
6. UI要素なしでのテスト
現象の切り分けには、フォーム生成部分をコメントアウトするか、あるいは単純なログ出力だけ行うサービスに書き換えて試すのが手っ取り早い方法です。もしUI要素を一切呼び出さない状態でハングが発生しないのであれば、フォームやUIを扱うコードが問題の根幹である可能性が高まります。
protected override void OnStart(string[] args) {
// using (var f = new Form1()) { }
// ↑ UI生成をコメントアウト
EventLog.WriteEntry("Service started without UI.");
}7. サービスを実行するアカウントの変更
SYSTEMアカウントではなく、ドメインユーザーアカウントなど適切な権限を持つアカウントでサービスを稼働させることで、セッションやセキュリティポリシーの違いにより問題が解決する場合があります。とはいえドメインコントローラーで常時稼働させるサービスを別のアカウントで動かす場合、そのアカウントのパスワード管理や権限設定に注意が必要です。
8. サービス依存関係やスタートアップ時の競合調査
サービスが起動するタイミングで、ほかのSYSTEMアカウントプロセスやサービスと衝突し、デッドロックを引き起こしている可能性も否定できません。特にドメインコントローラーはLDAP、DNS、Kerberos、SYSVOLレプリケーションなど多くの重要サービスが裏で動いているため、それらとの依存関係を整理しておくことが大切です。
| 依存サービス例 | 内容 |
|---|---|
| Netlogon | ドメインログオン機能を提供する重要サービス。起動/停止時にドメインコントローラー全体の動作に影響。 |
| DNS Server | Active Directory連携のDNS役割を果たす。DNSが停止するとAD全体の名前解決に支障をきたす。 |
| その他バックアップソフト | ドメインコントローラー上で稼働するバックアップエージェントがSYSTEMアカウントで動作していることが多い。 |
依存関係を正しく設定するためには、サービスコントロールマネージャ（SCM）で依存関係を確認し、不要な競合を防ぎながらスタートアップ順序を調整するなどの取り組みが必要となります。
総合的な解決策と推奨手順
今回の問題の最大の要因は、「ドメインコントローラー上でSYSTEMアカウントがUI要素を扱う」という点にあると考えられます。以下に総合的な解決策をまとめます。
- サービスからUI要素を切り離し、バックグラウンド動作のみとする。
- UIが必要であれば、別のデスクトップアプリやWebアプリからIPCを用いて連携する。
- どうしてもUI要素が必要な場合は、UIを起動するプロセスをユーザーセッションで動作させる。
- タスクスケジューラでログオン後に起動する設定にするなど。
- ドメインコントローラーでの動作は最小限に留め、必要であればメンバーサーバーにサービスを置く。
- 物理環境でも仮想環境でも、同じ挙動を示すか検証し、OS自体の設定や制限が影響しているか確認する。
- 定期的にイベントログやリソースモニターを確認し、問題の兆候を早期発見する。
まとめ
ドメインコントローラーという重要な役割を持つWindows Server 2025上で、UIを含むWindowsサービスを実行することはトラブルの種になりかねません。特にSYSTEMアカウントで動かしているほかのプロセスとの兼ね合いでハングや応答停止が起こる場合、セキュリティモデルやセッション分離の仕組みを正しく理解し、サービス設計を再検討する必要があります。
もし、サービスにUI要素を実装している現場に遭遇したら、「本当にサービスとしてUIが必要か」をまず見直し、代替手段やベストプラクティスを参考に設計することを強くおすすめします。
コメント