合同会社小村ソフト
日本語 English 한국어 繁體中文 العربية
相談する
メニュー

Windowsサービスの作り方と運用 ── タスクスケジューラとの使い分けからBackgroundServiceのサービス化まで

· · Windowsサービス, Windows, .NET, C#, BackgroundService, Generic Host, 常駐処理, 運用, 判断表, 技術相談

「5 分おきのタスクスケジューラでは間に合わなくなってきた」「装置からのデータを常時待ち受ける監視デーモンを常駐させたい」「フォルダーにファイルが置かれたら数秒以内に処理してほしい」。定期実行の相談を続けていると、要件が育った先で必ずこの話になります。

当ブログでは、Power Automate による業務自動化、タスクスケジューラの安全な運用設計と、自動化の話を続けて書いてきました。タスクスケジューラ記事の第 8 章で「分単位のポーリングや常時監視が必要になったら常駐プロセスの領域」という線引きに触れましたが、では実際に Windows サービスをどう作り、どう運用に乗せるのか。ここを曖昧なまま「とりあえずサービス化」すると、「止められないサービス」「落ちたまま誰も気づかないサービス」「LocalSystem で何でも動いているサービス」が生まれます。

この記事では、常駐処理を Windows サービスにすべきかどうかの判断表、サービスの仕組みの最小知識（SCM・開始の種類・セッション 0）、.NET 8 の Worker Service による実装、sc.exe での登録と回復オプション、実行アカウントの選択、そして安全な停止処理──を、実務で決める順に整理します。

1. まず結論

  • 使い分けの軸はシンプルです。数分おき以上の間隔の定期処理ならタスクスケジューラで十分。常時待ち受け（ソケット、名前付きパイプ、FileSystemWatcher）・秒単位の反応・落ちたときの自動回復が要件に入ったら Windows サービスです。
  • Windows Vista 以降、サービスはセッション 0 で動き、ユーザーと直接対話できません（UI を出せません）。UI が必要なら、サービスと UI アプリを分けてプロセス間通信で会話する設計にします。1
  • .NET での作り方は Worker Service テンプレート＋ Microsoft.Extensions.Hosting.WindowsServices の AddWindowsService（IHostBuilder 系なら UseWindowsService）が公式ルートです。コンソールアプリとしてそのまま実行できるので、開発・デバッグが従来のサービス開発より格段に楽になりました。2
  • .NET 6 以降、BackgroundService 内の未処理例外は既定でホストを停止させます（BackgroundServiceExceptionBehavior.StopHost）。ただしこれは「正常な停止」なので、SCM の回復オプションによる再起動が働きません。再起動させたい失敗は非 0 の終了コードでプロセスを落とします。32
  • 実行アカウントを惰性で LocalSystem にしないでください。sc.exe create の既定が LocalSystem なので、意識しないと最強権限で動き始めます。4 ローカル完結なら LocalService か仮想アカウント、ドメインで共有や DB に触るなら gMSA が本命です。5
  • 回復オプション（sc.exe failure）と停止処理（HostOptions.ShutdownTimeout、既定 30 秒6）は登録時に設計します。「停止に応答しないサービス」は運用で最も嫌われる存在です。

2. いつサービスにすべきか ── タスクスケジューラ・サービス・常駐アプリの判断表

常駐っぽい要件が出てきたときの選択肢は 3 つです。タスクスケジューラ、Windows サービス、そして「スタートアップ登録した常駐アプリ」（通知領域に常駐するタイプ）。素性を並べます。

観点 タスクスケジューラ Windowsサービス 常駐アプリ（スタートアップ登録）
起動タイミング 時刻・イベント契機で都度起動 OS 起動時（ログオン前）から常駐 ユーザーのログオン時から
ログオン不要か 不要にできる（非対話実行） 不要 必要（ログオフで消える）
UI 出せない（非対話構成では） 出せない（セッション 0） 出せる（通知領域・ダイアログ）
常時か定期か 定期（時間単位〜日次が適所） 常時 常時（ただしユーザーセッション内）
権限 タスクごとに実行アカウント指定 サービスアカウント（第 6 章） ログオンユーザーの権限
監視・回復 履歴＋自前の通知 SCM の回復オプション（自動再起動） なし（自前で作る）
配布の手間 XML / PowerShell で登録 sc.exe / インストーラー Run キー等への登録

判断の軸はこうです。

  • 1 日数回〜時間単位の定期処理で、処理間で状態を持たないならタスクスケジューラ。ここをわざわざサービス化して自前でタイマー管理するのは過剰で、タスクスケジューラ記事で書いた運用設計のほうがずっと安く済みます。
  • 常時待ち受けが本質──TCP やパイプでの要求待ち、FileSystemWatcher によるフォルダー監視、キューの逐次処理、秒単位の反応──なら Windows サービスです。「5 分ごとのタスク」で細切れにポーリングし始めたら、それは常駐プロセスを劣化再実装しているサインです。
  • UI が本体（通知領域からの操作、ユーザーへのポップアップ）なら常駐アプリです。ただしログオンしていないと動かないので、サーバー的な用途には使えません。「バックグラウンド処理は常時要るが UI も要る」なら、次章のとおりサービスと UI アプリの 2 プロセスに分けます。

もうひとつ、見落とされがちな判断材料が回復です。タスクスケジューラのジョブは失敗しても次のスケジュールまで放置ですが、サービスは SCM が自動再起動を面倒見てくれます（第 5 章）。「夜間に落ちても朝までに自力で復帰していてほしい」という要件は、それ自体がサービス化の理由になります。

3. サービスの仕組みの最小知識 ── SCM・開始の種類・セッション0

3.1 SCMと開始の種類

Windows サービスの胴元はサービス制御マネージャー（SCM）です。サービスの登録簿を管理し、開始・停止の要求を仲介し、失敗時の回復動作を実行します。サービスプロセスは SCM と規約どおりに会話できる作りでなければなりませんが、この部分は .NET のライブラリが肩代わりしてくれるので（第 4 章）、私たちが設計として決めるのは「開始の種類」「実行アカウント」「回復」「停止」の 4 点です。

開始の種類（スタートアップの種類）は 4 択です。4

開始の種類 動作 使いどころ
自動（auto） OS 起動時に開始 常時稼働サービスの基本
自動・遅延開始（delayed-auto） 他の自動サービスの少し後に開始 業務サービスはまずこれ。起動直後の混雑と依存先未起動を避ける
手動（demand） 要求されたときだけ開始 他のアプリから起動される補助サービス
無効（disabled） 開始不可 停止措置・封印

業務サービスは遅延開始を既定にします。OS 起動直後はネットワークも DB も他のサービスも出そろっていないため、「自動」で最速起動すると初回接続に失敗しがちです。遅延開始で時間差をつけたうえで、接続失敗は後述の ExecuteAsync 内のリトライで吸収する、という二段構えが安定します。

もう 1 つ、開始のタイムアウトを知っておいてください。SCM はサービスの開始完了報告を無限には待ちません。既定のタイムアウト（ServicesPipeTimeout、30 秒）を超えるとイベント 7000 / 7011 が記録され、開始失敗扱いになります。7 つまり、DB への接続リトライや大きなキャッシュの構築のような重い初期化を「開始処理」の中でやってはいけません。開始はすぐに完了させ、重い処理は本体ループ側（ExecuteAsync）でやるのが鉄則です。

3.2 セッション0分離 ── サービスはUIを出せない

Windows Vista 以降、サービスはセッション 0 という隔離されたセッションで動き、ユーザーと直接対話できません。1 サービス内で MessageBox.Show やフォーム表示を呼んでも、ログオン中のユーザーの画面には何も出ません。それどころか、誰も押せない OK ボタンを待ち続けて処理全体が止まる、という古典的なハングの原因になります。古いコードをサービスに移植するときは、エラー表示のつもりのメッセージボックスが残っていないかを必ず確認してください。

UI が必要な場合の正解は、サービス（セッション 0）と UI アプリ（ユーザーセッション）にプロセスを分け、プロセス間通信（IPC）で会話する構成です。これは Microsoft 自身が案内している設計で、名前付きパイプなどの IPC を使い、UI 側が結果をサービスに返します。1 どの IPC 手段を選ぶかは、同日公開の姉妹記事「プロセス間通信の判断表」で整理しています。UI アプリ側も Generic Host に載せておくと、両プロセスで DI・ログ・設定の作りを揃えられます（「Generic HostとBackgroundServiceをデスクトップアプリで使う」参照）。

4. .NETでの作り方 ── Worker ServiceとAddWindowsService

4.1 テンプレートとProgram.cs

.NET でのサービス開発は、Worker Service テンプレートから始めます。SDK に同梱されているので dotnet new worker で雛形ができ、そこに Microsoft.Extensions.Hosting.WindowsServices パッケージを追加して AddWindowsService を呼ぶだけで、Windows サービスとして動く準備が整います。2 土台になっている Generic Host の仕組みは「.NET Generic Hostとは」で解説しています。

using App.MonitorService;
using Microsoft.Extensions.Hosting;

HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);

// Windowsサービスとして起動されたときにSCMと会話するライフタイムを組み込む。
// コンソールとして起動されたときは通常のConsoleLifetimeのまま動く
builder.Services.AddWindowsService(options =>
{
    options.ServiceName = "KsMonitor";
});

builder.Services.AddSingleton<MeasurementQueue>();
builder.Services.AddHostedService<MonitorWorker>();

IHost host = builder.Build();
host.Run();

Host.CreateDefaultBuilder を使う従来スタイルのプロジェクトなら、代わりに IHostBuilder 拡張の UseWindowsService() を呼びます。役割は同じです。

1 つ、タスクスケジューラ記事の「開始（オプション）」問題と同型の罠があります。サービスとして起動されたときのカレントディレクトリは C:\Windows\System32 です。appsettings.json などを相対パス前提で読んでいると「コンソールでは動くのにサービスだと設定が読めない」になります。設定ファイルは実行ファイル基準で解決するか、公式チュートリアルが案内しているとおり登録時の binpath に --contentRoot を渡してコンテンツルートを明示してください。2

4.2 ExecuteAsync ── stoppingTokenと例外の設計

本体は BackgroundService を継承した ExecuteAsync に書きます。ここで決めるべきことは「停止要求への応答」と「例外をどう扱うか」の 2 点に尽きます。

namespace App.MonitorService;

public sealed class MonitorWorker(
    MeasurementQueue queue,
    ILogger<MonitorWorker> logger) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        try
        {
            while (!stoppingToken.IsCancellationRequested)
            {
                try
                {
                    // キューから1件取り出して処理する。待ちにも必ずトークンを渡す
                    var item = await queue.DequeueAsync(stoppingToken);
                    await ProcessAsync(item, stoppingToken);
                }
                catch (Exception ex) when (ex is IOException or TimeoutException)
                {
                    // 継続してよい失敗: 記録したうえで間隔を空けて再試行する
                    logger.LogError(ex, "処理に失敗しました。30秒後に再試行します。");
                    await Task.Delay(TimeSpan.FromSeconds(30), stoppingToken);
                }
            }
        }
        catch (OperationCanceledException) when (stoppingToken.IsCancellationRequested)
        {
            // SCMからの停止要求。正常な流れなので何もしない。
            // when句でstoppingToken起因に限定しているのは、内部処理のタイムアウト等が
            // 投げたキャンセルを「正常停止」と誤認し、ワーカーだけが静かに
            // 止まったままホストが生き続けるのを防ぐため
        }
        catch (Exception ex)
        {
            // 想定外の失敗: 既定のStopHostではホストが「正常に」停止してしまい、
            // SCMの回復オプション（自動再起動）が発動しない。
            // 非0の終了コードで落とし、SCMに「失敗した」と伝える
            logger.LogCritical(ex, "回復不能なエラーのためサービスを終了します。");
            Environment.Exit(1);
        }
    }

    private Task ProcessAsync(Measurement item, CancellationToken token)
        => throw new NotImplementedException();
}
  • stoppingToken をすべての待ちに渡す。 Task.Delay、I/O、キュー待ち。1 か所でもトークンを無視した長い待ちがあると、そこが「停止に応答しないサービス」の温床になります（第 7 章）。
  • 継続可能な失敗と回復不能な失敗を分ける。 ネットワーク断や一時的なタイムアウトはループ内で捕まえ、記録して再試行します。握りつぶして continue するだけの catch (Exception) は、静かに空回りするサービスを作るだけです。どちらに分類するかの考え方は「想定外の例外で終了するか継続するかの判断表」で整理しています。
  • 未処理例外の既定動作を知っておく。 .NET 6 より前は ExecuteAsync から漏れた例外は闇に消え、サービスは動いているように見えて何もしない「ゾンビ」になりました。.NET 6 以降は既定が BackgroundServiceExceptionBehavior.StopHost になり、例外がログに記録されたうえでホストが停止します。3 ただしこの停止は「正常停止」なので、回復オプションを設定していても再起動されません。回復オプションで復帰させたい失敗は、上のコードのように Environment.Exit(1) で明示的に異常終了させるのが公式チュートリアルどおりの作法です。2

4.3 コンソールのまま実行できる ── 開発が楽になった最大の理由

AddWindowsService は、Windows サービスとして起動されたときだけサービス用のライフタイムに切り替わります。つまり同じ exe が、Visual Studio の F5 や dotnet run では普通のコンソールアプリとして動きます。ブレークポイントも刺さり、Ctrl+C を押せば停止要求からの StopAsync の流れまでローカルで検証できます。

ただし、コンソールで動いたからサービスでも動く、とは限りません。実行アカウントの違い（第 6 章）、セッション 0、カレントディレクトリ──この 3 点だけはサービスとして実機で確認が必要です。「コンソールでは動くのにサービスだと動かない」の原因は、ほぼこの 3 点に収束します。

5. 登録と運用 ── sc.exe・回復オプション・イベントログ

5.1 sc.exe createでの登録

発行（dotnet publish、単一ファイル発行が扱いやすいです）した exe を、sc.exe create で SCM に登録します。管理者の PowerShell で実行します。

sc.exe create "KsMonitor" binpath= "C:\Services\KsMonitor\KsMonitor.exe" start= delayed-auto obj= "NT AUTHORITY\LocalService" displayname= "KS 計測データ取り込みサービス"
sc.exe description "KsMonitor" "計測データを取り込みDBへ登録する常駐サービス（担当: 情報システム部）"

古典的な罠を先に言います。binpath= や start= の等号の後には空白が必要です。等号までがオプション名で、値との間の空白が構文上必須、という sc.exe 独特の仕様です（省略すると失敗します）。4 また obj= を省略した場合の既定は LocalSystem です。4 何も考えずに登録すると最強権限で動き始めるので、第 6 章の選択を登録時に済ませてください。

description の設定は地味に重要です。数年後に services.msc を開いた誰かが「これは何のサービスで、止めてよいのか、誰に聞けばよいのか」を判断できる情報を残しておくと、後の調査コストが消えます。削除は停止させてから sc.exe delete "KsMonitor" です。2

配布先が複数台ある、あるいは更新（ファイル差し替え）が定期的にあるなら、sc.exe の手作業ではなくインストーラー（MSI / WiX の ServiceInstall など）で登録・更新・削除をセットで面倒を見る構成に早めに寄せてください。手作業の登録手順書は、手順を 1 つ飛ばした端末を必ず生みます。

5.2 回復オプション ── 「落ちたら再起動」はSCMに任せる

サービス化の大きな利点が、SCM 標準の回復オプションです。プロセスが異常終了したときの動作を宣言的に設定できます。2

sc.exe failure "KsMonitor" reset= 86400 actions= restart/60000/restart/60000/restart/300000

この例は「1 回目・2 回目の失敗は 60 秒後に再起動、3 回目以降は 5 分後に再起動、失敗カウンターは 24 時間でリセット」です。GUI（services.msc のプロパティ →「回復」タブ）でも同じ設定ができます。自前の「見張りタスク」や監視スクリプトを作り込む前に、まずこの標準機能を使ってください。

2 点だけ注意します。第一に、前章のとおりプロセスが非 0 で終了しなければ発動しません。StopHost による正常停止は回復の対象外です。第二に、起動直後に必ず落ちる状態（設定ミス、DB 不達）だと再起動ループになります。3 回目以降の間隔を長めにしておくのはそのためで、あわせて「なぜ落ちたか」がイベントログに残っている状態（次節）を先に作っておきます。

5.3 イベントログとファイルログの併用

Host.CreateApplicationBuilder は Windows では EventLog ロガープロバイダーを自動追加します。そしてイベントログに届くのは既定で Warning 以上だけです。2 「サービスにしたら Information ログが全部消えた」と混乱しがちですが、消えたのではなくイベントログの既定フィルターに掛かっています。開始・停止のような運用イベントも記録したいなら、appsettings.json で EventLog プロバイダーのレベルを明示します。

{
  "Logging": {
    "EventLog": {
      "SourceName": "KsMonitor",
      "LogLevel": {
        "Default": "Warning",
        "Microsoft.Hosting.Lifetime": "Information"
      }
    }
  }
}

1 点注意があります。イベントソースは事前に登録されていないと書き込めず、登録には管理者権限が必要です。SourceName を省略しても逃げられません──AddWindowsService の既定ではアプリケーション名がソース名になるため2、いずれにせよ「未登録のソース」から始まります。LocalService のような最小権限アカウントは実行時にソースを作成できず、作成に失敗するとイベントログには何も書かれないまま運用が始まってしまいます。登録はインストーラー（または管理者権限のセットアップ処理）側で済ませてください。タスクスケジューラ記事の 6 章で書いた「CreateEventSource はセットアップ側へ分離する」と同じ話です。

使い分けの目安は、イベントログには「運用者が見るべきこと」だけ（開始・停止・失敗・回復）、処理の詳細トレースは自前のファイルログです。ファイルログを自前で持つ場合の最小要件（ローテーション、書き込み失敗時の振る舞い）は「自作ロガーの最小要件」に、プロセスごと落ちたときに証拠を残す設計は「クラッシュ時にログとダンプを残す設計」にまとめています。回復オプションで自動再起動する構成では、落ちた瞬間の記録がその場に残っていることが唯一の手がかりになるためです。

6. 実行アカウント ── LocalSystemを惰性で選ばない

サービスは指定したアカウントのセキュリティコンテキストで動き、SCM が開始時にそのアカウントでログオンしてプロセスにトークンを付けます。8 タスクスケジューラ記事の第 3 章で書いた「誰として実行されるか」の話の、サービス版です。選択肢を並べます。

アカウント 権限 ネットワーク上の身元 パスワード管理 使いどころ
LocalSystem 極めて強い（OS 相当） コンピューターアカウント 不要 原則避ける。sc.exe create の既定なので注意
LocalService 最小限 匿名（共有にアクセス不可） 不要 ローカル完結の処理の第一候補
NetworkService 最小限 コンピューターアカウント 不要 ドメイン内リソースに触る軽い処理
仮想アカウント（NT SERVICE\サービス名） 付与した分だけ コンピューターアカウント 不要 サービス単位で ACL を付与できる。ローカル資源への最小権限
gMSA 付与した分だけ gMSA 自身 DC が自動管理 ドメインで共有・DB に触るサービスの本命

判断のポイントは 3 つです。

  • LocalSystem は「動くから」で選ばない。 サービスの脆弱性がそのままマシン全体の乗っ取りに直結します。管理者相当の権限が本当に必要なのかは、「管理者特権が必要になるのはいつか」の整理がそのまま使えます。多くの場合、必要なのは「特定フォルダーへの書き込み」程度で、それは仮想アカウント（NT SERVICE\KsMonitor）にフォルダーの ACL を付与すれば足ります。仮想アカウントは作成もパスワード管理も不要です。5
  • ネットワーク共有の罠。 LocalService はネットワーク上では匿名になるため、\\server\share へのアクセスは失敗します。NetworkService・仮想アカウント・LocalSystem はコンピューターアカウント（DOMAIN\マシン名$）としてネットワークに出るので5、共有側でコンピューターアカウントに対して共有と NTFS の両方の許可が必要です。「ユーザーには許可を出したのにサービスからだけ読めない」の正体はたいていこれです。「誰としてネットワークに出るか」を先に決めてから、共有側の設定をします。
  • 通常のユーザーアカウントで動かすなら、パスワード運用込みで。 専用アカウントを使う場合は「サービスとしてログオン」の権利が必要なうえ、パスワードが期限切れになるとログオンに失敗してサービスは開始できなくなります。8 「パスワード変更でタスクが黙って死ぬ」問題のサービス版です。ドメイン環境なら、パスワードをドメイン側が自動管理する gMSA でこの問題ごと消すのが正解です（タスクスケジューラ記事 3.2 節と同じ結論です）。

7. 安全な停止 ── ShutdownTimeoutと仕掛かり処理

停止の流れを押さえます。services.msc や sc.exe stop、OS シャットダウンで SCM が停止要求を出すと、.NET のサービスライフタイムがホストの停止（StopApplication）に変換し、stoppingToken がキャンセルされ、ExecuteAsync が抜け、各サービスの StopAsync が呼ばれます。ホストがこの一連の停止処理を待つ時間が HostOptions.ShutdownTimeout で、既定は 30 秒です。69 間に合わなければ後始末の完了を待たずに停止が強行されます。

仕掛かり中の 1 件を書き切るのに 30 秒で足りないなら、時間から逆算して延長します。

builder.Services.Configure<HostOptions>(options =>
{
    // 仕掛かり中の処理を書き切るのに必要な最大時間から逆算する
    options.ShutdownTimeout = TimeSpan.FromSeconds(90);
});

そのうえで、停止処理の設計は次の 3 点です。

  • 停止要求後にやることを順序として決めておく。 新規の受付をやめる → 仕掛かり中の処理を完了させる（または安全な区切りで中断し、再開できる形で記録する） → 接続・一時ファイルの後始末。この順序を決めていないと、トークンを見た瞬間に全部を放り出すか、全部やり切ろうとして時間切れになるかの両極端になります。
  • 「停止に応答しないサービス」を作らない。 トークンを無視した長いループや待ちが 1 か所あるだけで、SCM 上「停止中」のまま固まるサービスになります。これは Windows Update の再起動を妨げ、サーバーの計画停止のたびに手作業の kill を要求する、運用で最も嫌われる不具合です。第 4 章のとおり、処理の区切りごとにトークンを確認し、長い I/O には CancellationToken を渡してください。コンソール実行なら Ctrl+C でこの停止フローをそのまま試せるので、「Ctrl+C から何秒で終了するか」をリリース前のテスト項目に入れておくことをおすすめします。
  • kill されても壊れない設計を、停止処理の丁寧さより優先する。 電源断や強制終了は、どれだけ停止処理を作り込んでも起こります。トランザクション、アトミックなファイル書き込み、リラン可能な処理単位──「途中で死んでも次回起動時に整合が取れる」作りが本体で、丁寧な停止処理はあくまで行儀の問題です。

8. まとめ

判断はシンプルです。定期処理はタスクスケジューラ、常時待ち受け・秒単位の反応・自動回復が要るなら Windows サービス、UI が本体なら常駐アプリ。サービスにすると決めたら、.NET の Worker Service と AddWindowsService で「コンソールとして開発し、サービスとして配る」形にするのが現在の標準ルートです。

登録時に設計として決めるのは 4 点──開始の種類（業務サービスは遅延開始）、実行アカウント（LocalSystem を避け、仮想アカウントか gMSA）、回復オプション（sc.exe failure と Environment.Exit(1) のセット）、停止（ShutdownTimeout と仕掛かり処理の後始末）。この 4 点と、stoppingToken を尊重する ExecuteAsync の書き方さえ押さえれば、Windows サービスは「作るのが特別に難しいもの」ではなくなっています。逆に、この 4 点を決めずに動き始めたサービスは、数年後に「止められない・落ちても気づかない・権限が強すぎて触れない」の三重苦で返ってきます。既存サービスの立て直しも、この 4 点の棚卸しから始めるのが近道です。

関連記事

関連する相談領域

合同会社小村ソフトでは、常駐処理の設計レビュー（タスクスケジューラからの移行判断を含む）や、「停止に応答しない」「いつの間にか落ちている」Windows サービスの調査・立て直しの相談を扱っています。

参考リンク

  1. Microsoft Learn, Interactive Services. Windows Vista 以降サービスはユーザーと直接対話できないこと、サービスはセッション 0 で実行されること、UI が必要な場合は別プロセスの GUI アプリと IPC で連携する設計が推奨されることについて。 ↩ ↩2 ↩3

  2. Microsoft Learn, Create Windows Service using BackgroundService. Worker Service を Windows サービスにする公式チュートリアル。AddWindowsService、EventLog プロバイダーの既定が Warning であること、sc.exe による登録・回復・削除、回復オプションには非 0 終了コードが必要なことについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  3. Microsoft Learn, .NET 6 breaking change: Exception handling in hosting. .NET 6 以降、BackgroundService.ExecuteAsync の未処理例外がログに記録されたうえで既定でホストを停止させること（BackgroundServiceExceptionBehavior.StopHost）について。 ↩ ↩2

  4. Microsoft Learn, sc.exe create. start=（auto / demand / delayed-auto 等）や obj=（既定は LocalSystem）の仕様と、オプションの等号の後に空白が必須であること（省略すると失敗する）について。 ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, Service Accounts in Windows Server. 仮想アカウント（NT SERVICE\サービス名）がパスワード管理不要でコンピューターアカウントの資格情報でネットワークにアクセスすること、gMSA のパスワードをドメイン側が自動管理することについて。 ↩ ↩2 ↩3

  6. Microsoft Learn, .NET Generic Host. ホストのシャットダウン処理の流れと、停止時に構成可能なシャットダウンタイムアウト（既定 30 秒）で待つことについて。 ↩ ↩2

  7. Microsoft Learn, A service does not start, and events 7000 and 7011 are logged. SCM が ServicesPipeTimeout で指定された時間だけサービスの開始を待ち、超過するとイベント 7000 / 7011 を記録すること、既定タイムアウトの引き上げ手順について。 ↩

  8. Microsoft Learn, Service User Accounts. サービスが指定アカウントのセキュリティコンテキストで実行されること、SCM が開始時にログオンを行い、パスワードが期限切れだとサービスが開始できないこと、LocalService / NetworkService / LocalSystem という特殊アカウントについて。 ↩ ↩2

  9. Microsoft Learn, HostOptions.ShutdownTimeout Property. StopAsync の既定タイムアウトを制御するプロパティの定義について。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る