WINDOWSサービスの起動トラブル

windows環境で構築や開発を行っているとたまにサービスが起動できないことがある。
たいていサービスの起動ユーザなんてSYSTEMユーザが担当するものですが、開発環境によってはローカルユーザでコントロールすることもあるでしょう。
その場合はサービス起動のトラブルに悩まされることも多いかと思います。

windowsのサービスも複雑で色々な絡みがあるので環境によって一概にこれが原因とは言い切れないものです。
開発側で独自に生成しているものであればその仕様書を解読することで可能になるかもしれませんが、多きシステムだとひとつのプロジェクトでもなかなか疎通し合えない部分があるのも確かです。

原因として考えられるのは大きく分けると3つでしょうか。
1つ目が依存関係。
2つ目が権限関係。
3つ目がそれ以外のトラブル。

1つ目ですが、依存関係なのでそのサービスが単体では役目を果たせない場合です。
いくつかのサービスが連動して稼動する場合、サービス起動順序や、依存対象サービスが起動していることを確認します。
どのようなサービスに依存しているかは
windowsキー-ファイル名を指定して実行-services.msc-対象サービスのプロパティ-依存関係タブをみます。
でもホントに主流の依存状態しか表示されませんが。
ミドルウェアベンダーに多く見られますね。
または複数のサーバでひとつのシステムを構築している場合(まぁ、単発のサーバ運用というほうが珍しいでしょうね)は、依存対象サーバが稼動していないと、起動できない場合もあります。
その場合はサーバの起動順序も確認しておきます。
よくわからない場合はトラブルサーバを最後に起動してみるのも良いと思います。
特にoracleと連携をとったサービスの開発も多いと思います。
その場合はDBサーバを起動後立ち上げてみるとか･･･

2つ目が権限関係。
サービスを起動するにもどのユーザで起動するのか指定できます。
windowsキー-ファイル名を指定して実行-services.msc
このサービスの一覧にログオンという項目があります。
たいていローカルシステムなのですが、独自開発系はローカルユーザでないと動かない場合があります。
その場合もサービスのプロパティからログオンで適正に代えてあげる必要があります。
またドメインユーザでもこの設定は有効なため、ドメインユーザで設定することも可能です。
このパターンの場合気をつけなければいけないのがドメインコントローラに変化があったときです。
ドメインコントローラではユーザを一意に位置づけるためにIDを保有します。
何らかのトラブルでドメインコントローラに変更が加わった場合、ユーザが有効にならず、起動に失敗する可能性があります。
対処としてはドメインから一度離脱し、再度参加することと、ユーザの再登録で解消できると思います。
ローカルシステムないでサービスの起動停止を行う権限があるかどうかも重要になります。
こちらは以下の手順を踏みます。
windowsキー-ファイル名を指定して実行-gpedit.msc-ローカルコンピュータポリシー-コンピュータの構成-Windowsの設定-ローカルポリシー-ユーザ権利の割り当て
の中にあるオペレーティングシステムの一部として機能に当該ユーザを登録します。

3つ目のその他ですが、これはホントにいろいろなことが考えられます。
サービス起動対象ファイルのバグやウィルス感染。
依存対象も同様。
セキュリティを高めたつもりがサービスの障害にも該当してしまったとか。
色々あると思います。
また、何かあれば追記したいと思います。