Windowsコマンドプロンプトでサービスを再起動する方法：net stop・net startと状態確認

Windowsサービスをコマンドプロンプトから再起動する基本は、net stopで停止し、停止を確認してからnet startで開始することです。ただし、2行のコマンドを書くだけでは、停止の失敗や起動途中の状態を見落とします。サービスがRUNNINGになったことと、アプリケーションの不具合が直ったことも別々に確認します。

本記事では、サービス名の調べ方、依存関係と状態の確認、終了コードの扱い、有限回の待機を入れたバッチ例を順に解説します。変更する例の対象は、管理者が用意し、停止・開始を許可した検証用の架空サービス名 LabDemoSvcに統一します。この名前のサービスはWindows標準では存在しません。本番サービスやWindowsの基盤サービスに、そのまま置き換えて実行しないでください。

サービスの再起動でできること・できないこと

再起動は、対象サービスを一度停止してから開始する操作です。一時的な不調から回復したり、製品の手順で再起動が必要な設定変更を反映したりできる場合があります。一方、設定ミス、ディスク不足、接続先の障害、プログラムの不具合まで解決する操作ではありません。原因調査用のログや発生時刻は、状態を変える前に記録します。

停止中はその機能を利用できず、処理中の作業や接続が中断される可能性があります。また、停止できても開始できるとは限りません。影響範囲、作業時間、利用者への連絡、失敗時の復旧手順を確認したうえで行います。再起動を定期実行すれば安定する、という前提にはしないでください。

実行前の準備と管理者権限

• 対象PCと対象サービスを確認し、停止・開始の許可を得ます。リモート接続や認証、セキュリティ機能を支えるサービスを、汎用的な復旧操作として停止しません。
• 製品の保守手順を確認し、実行中のジョブ、更新、バックアップなどと重ならないようにします。
• 必要な権限を持つアカウントで、スタートメニューから「cmd」を検索し、「管理者として実行」でコマンドプロンプトを開きます。サービスのアクセス許可によっては、管理者でも操作できない場合があります。
• 本記事の構文はCMD用です。PowerShellのGet-Serviceなどのコマンドレットを、そのままCMDに入力することはできません。

権限エラーを避ける目的で、サービスのアクセス権、実行アカウント、スタートアップの種類を変更する必要はありません。許可された操作かを管理者に確認します。権限の種類はMicrosoft Learnのサービスアクセス権で確認できます。

サービス名と表示名を区別する

「サービス」管理画面の一覧には、通常は読みやすい表示名が出ます。コマンドで扱うサービス名は別の値の場合があります。services.mscを開き、対象サービスのプロパティで両方を確認してください。表示名は言語や製品で異なる場合があるため、本記事では確認済みのサービス名を使います。

表示名が「Lab Demo Service」、サービス名が「LabDemoSvc」だった場合の読み取り専用の照会例です。getkeynameは表示名からサービス名、getdisplaynameは逆方向を調べます。スペースを含む名前は半角の二重引用符で囲みます。

sc.exe getkeyname "Lab Demo Service"
sc.exe getdisplayname "LabDemoSvc"

net startなどでは表示名を指定できる場合もありますが、sc.exe queryにはサービス名を指定します。名前を推測して操作せず、SERVICE_NAMEを確認します。sc.exeと拡張子まで書くことで、別のシェルの同名エイリアスとの混同も避けられます。

状態と依存関係を先に確認する

sc.exe query "LabDemoSvc"
sc.exe qc "LabDemoSvc"
sc.exe enumdepend "LabDemoSvc"

• query：現在の状態とサービスが報告する終了コードを表示します。
• qc：構成を表示します。DEPENDENCIESは、対象サービスが動くために必要なサービスやグループです。
• enumdepend：逆に、対象サービスに依存するサービスを列挙します。対象を停止すると影響を受ける側です。結果がバッファ不足で省略された場合は、必要サイズを確認して全件を読み取るまで操作しません。

依存関係は片方向だけを見れば十分ではありません。構成に登録されていないアプリケーション上の依存もあるため、利用者や製品の手順も確認します。net stopで他のサービスの停止確認が出たら、この例の範囲を超えます。続行せず、追加の影響範囲と復旧順序を確認してください。依存先をまとめて停止するための自動承認オプションは使いません。

対象だけを開始しても、停止させた依存サービスがすべて元どおりになるとは限りません。また、サービスの開始時には必要な依存先が開始されることがあります。検証例は、依存関係のない専用サービスを前提にします。enumdependの仕様も参照してください。

STATEの読み方と「起動中・停止中」の扱い

次は形式を説明するための出力例です。実際の検証結果ではありません。

SERVICE_NAME: LabDemoSvc
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

CHECKPOINTは長い処理中の進捗、WAIT_HINTはサービスが示す待機時間の目安です。待機時間は保証された締切ではありません。状態が変わらない場合は、数値やログを記録して手順を中断し、管理者や製品担当者に確認します。停止要求を繰り返したり、共有プロセスを強制終了したりする対処には進みません。状態値の定義はSERVICE_STATUS_PROCESSを参照してください。

net stop・net startで1段階ずつ再起動する

次の例は、事前確認済みで実行中の検証用サービスだけを対象にします。ブロックを一括で貼り付けるのではなく、各段階の結果を確認してから次へ進みます。

1. 停止し、直後の終了コードを確認する

net stop "LabDemoSvc"
echo %ERRORLEVEL%

停止に成功したメッセージが出たかを読み、直後の終了コードを確認します。非0ならエラー内容を記録して中断します。ほかのコマンドを実行すると終了コードが変わり得るため、後から読み直した値を停止結果として扱わないでください。

2. STOPPEDを確認する

sc.exe query "LabDemoSvc"

STATE : 1 STOPPEDを確認してから開始します。STOP_PENDINGなら保守手順に従い間隔と上限を決めて再照会します。停止の成否が不明なまま開始したり、停止コマンドを連打したりしません。

3. 開始し、直後の終了コードを確認する

net start "LabDemoSvc"
echo %ERRORLEVEL%

非0なら表示された理由を記録します。停止に成功したあと開始に失敗すると、機能が利用できない状態が残る可能性があります。自動的に再試行し続けるのではなく、事前に決めた復旧・連絡手順に進みます。

4. RUNNINGと実際の機能を確認する

sc.exe query "LabDemoSvc"

STATE : 4 RUNNINGを確認したあと、サービス固有のテストやログ確認を行います。たとえば検証用アプリケーションから正常に応答を得られることを確認します。一瞬だけ起動して終了するサービスもあるので、用途に応じてその後の状態も確認します。

1行でつなぐときの注意

net stop "LabDemoSvc" && net start "LabDemoSvc"

&&は、左のコマンドが成功したときだけ右を実行するCMDの書き方です。単に2行並べる方法や&でつなぐ方法では、停止に失敗しても開始へ進みます。ただし&&だけでは、依存関係、待機上限、状態の再確認、アプリケーションの復旧まで判定できません。初回は前述の段階的な手順を使ってください。

終了コードとサービスの状態を混同しない

区別する値は3種類あります。コマンドの終了コードはCMDの%ERRORLEVEL%で確認します。表示されたエラー番号は診断の手掛かりです。サービス自身の終了コードはsc.exe queryのWIN32_EXIT_CODEやSERVICE_EXIT_CODEです。これらを同じ番号として扱わないでください。

特にsc.exe queryのコマンドが成功しても、それは照会できたという意味です。サービスが実行中とは限りません。また、sc.exe stopやsc.exe startの成功は、要求後の目的の状態を必ず確認し終えたことを意味しません。必ずSTATEを調べます。

バッチではif errorlevel 1が「1以上」を表します。特定の値と等しいという意味ではありません。%ERRORLEVEL%は括弧でまとめた処理の中で古い値に展開される場合もあるため、次の例では結果を各コマンドの直後、括弧の外で保存します。参考：if、cmdのコマンド連結。

応用例：状態確認と有限回の待機を入れたバッチ

以下は、検証用に設計したCMDバッチ例です。ここで掲載しているバッチは実機Windowsでの動作検証済みではありません。本番の運用スクリプトとして配布する前に、管理者の許可のある隔離した検証環境で確認してください。サービスの作成・インストールは、この例には含みません。

• 管理者が準備したLabDemoSvcだけを対象とし、停止・開始の許可、依存関係が両方向ともないこと、復旧手順を事前に確認します。初期状態がRUNNING以外なら変更せず終了します。
• 待機部分では、停止・開始それぞれで状態を最大30回照会します。期待した移行中状態の場合だけ1秒待ちます。待機は各段階で最大29回ですが、コマンド自体の処理時間を含む厳密な30秒の制限ではありません。
• この応用例では、net stopの依存サービス停止の対話を避けるため、停止・開始要求にsc.exeを使います。動作中の依存サービスが原因で停止が拒否された場合は中断し、依存サービスを自動停止しません。
• STATE : 数値という出力形式を前提にします。言語・形式が異なる、値を読めない、複数行ある、照会に失敗する場合は、成功扱いせず終了します。汎用の多言語対応ツールではありません。
• 設定、アクセス権、サービスの回復処理は変更しません。失敗時に強制終了や自動の再実行はせず、取得したログを残します。

@echo off
setlocal EnableExtensions DisableDelayedExpansion
set "ERRORLEVEL="
set "SVC=LabDemoSvc"
set "SC=%SystemRoot%\System32\sc.exe"

rem Only use after approval and the manual preflight checks.
if /i not "%~1"=="CONFIRMED-LAB" (
    echo No changes. Usage: restart_lab.cmd CONFIRMED-LAB
    exit /b 2
)
set "WORK=%TEMP%\LabDemoSvc-%RANDOM%-%RANDOM%"
mkdir "%WORK%" >nul 2>&1
if errorlevel 1 exit /b 3
set "LOG=%WORK%\operations.log"
echo Target: %SVC%
echo Logs: "%WORK%"

call :ReadState
set "RC=%ERRORLEVEL%"
if not "%RC%"=="0" goto Failed
if not "%STATE%"=="4" (
    echo No changes: initial state is not RUNNING.
    exit /b 4
)

"%SC%" stop "%SVC%" >>"%LOG%" 2>&1
set "RC=%ERRORLEVEL%"
>>"%LOG%" echo stop_exit=%RC%
if not "%RC%"=="0" goto Failed
call :WaitFor 1 3
set "RC=%ERRORLEVEL%"
if not "%RC%"=="0" goto Failed

"%SC%" start "%SVC%" >>"%LOG%" 2>&1
set "RC=%ERRORLEVEL%"
>>"%LOG%" echo start_exit=%RC%
if not "%RC%"=="0" goto Failed
call :WaitFor 4 2
set "RC=%ERRORLEVEL%"
if not "%RC%"=="0" goto Failed

echo STOPPED then RUNNING observed. Check application health next.
exit /b 0

:Failed
echo Not completed. Code=%RC%. See "%LOG%".
echo The service may be stopped or still changing state.
echo Do not retry blindly. Follow the approved recovery procedure.
exit /b 1

:ReadState
set "STATE="
set "COUNT=0"
"%SC%" query "%SVC%" >"%WORK%\state.txt" 2>&1
set "QUERY_RC=%ERRORLEVEL%"
type "%WORK%\state.txt" >>"%LOG%"
>>"%LOG%" echo query_exit=%QUERY_RC%
if not "%QUERY_RC%"=="0" exit /b 10
for /f "usebackq tokens=1,2,3" %%A in ("%WORK%\state.txt") do (
    if "%%A"=="STATE" if "%%B"==":" (
        set "STATE=%%C"
        set /a COUNT+=1 >nul
    )
)
if not "%COUNT%"=="1" exit /b 11
if "%STATE%"=="1" exit /b 0
if "%STATE%"=="2" exit /b 0
if "%STATE%"=="3" exit /b 0
if "%STATE%"=="4" exit /b 0
if "%STATE%"=="5" exit /b 0
if "%STATE%"=="6" exit /b 0
if "%STATE%"=="7" exit /b 0
exit /b 11

:WaitFor
set "TRIES=0"
:Poll
call :ReadState
if errorlevel 1 exit /b 10
if "%STATE%"=="%~1" exit /b 0
if not "%STATE%"=="%~2" exit /b 12
set /a TRIES+=1 >nul
if %TRIES% GEQ 30 exit /b 13
"%SystemRoot%\System32\timeout.exe" /t 1 /nobreak >nul
if errorlevel 1 exit /b 14
goto Poll

コードをrestart_lab.cmdとして保存し、事前確認が済んだ検証環境の管理者CMDで次のように実行します。引数は誤操作を減らす確認用の文字列で、権限を与えたり、安全性を検証したりする仕組みではありません。

restart_lab.cmd CONFIRMED-LAB
echo %ERRORLEVEL%

バッチの終了コード0は「停止状態を確認した後、実行状態を確認した」ことだけを示します。アプリケーションの正常性までは判定しません。1は途中失敗、2は確認用引数なし、3はログ用フォルダー作成失敗、4は初期状態が対象外です。途中失敗時はログ内の実コマンドの終了コードと、10〜14の例独自の判定コードを区別します。10は照会関連、11は状態形式、12は想定外の移行、13は照会回数上限、14は待機コマンド失敗です。

この例は成功を最後に無条件表示せず、停止完了を確認できない限り開始へ進みません。失敗しても状態を元に戻す保証はなく、ログは一時フォルダー配下に残ります。タスクスケジューラによる定期再起動や、多数のサービスへの一括適用には、そのまま流用しないでください。サービス回復機能や他の管理ツールによる同時操作がある場合も、専用の運用設計が必要です。

よくあるエラーと確認する場所

次は代表的なWindowsのエラー番号です。netの表示文、ヘルプ番号、CMDに返される終了コードは一致しない場合があります。画面のメッセージを含めて記録し、番号だけで処置を決めないでください。

必要に応じてsc.exe queryex "LabDemoSvc"でPIDなどを含む状態を記録し、イベントビューアーの「Windowsログ」→「システム」でService Control Managerのイベントと発生時刻を照合します。PIDは記録のために使い、プロセス終了の指示には使いません。Microsoftのエラーコード一覧で意味を確認できます。

トラブル別の応用で注意すること

ネットワーク：DHCP・DNSを一括再起動しない

通信できないという症状だけで、DhcpやDnscacheをまとめて停止する方法は勧めません。DHCP Clientの停止はIPアドレス取得・更新などに影響し得ますし、サービスによっては停止要求を受け付けない構成もあります。遠隔管理中は作業経路を失う可能性も考慮します。

まず、問題が特定のアプリケーションだけか、端末全体か、名前解決か接続自体かを切り分けます。状態照会とエラーの記録を行い、対象バージョン・構成に合ったネットワークの診断手順へ進みます。サービス停止、DNSキャッシュ操作、IP設定の変更は同じ処置ではありません。サービスの役割についてはMicrosoftのサービス一覧も参考になりますが、Windows Server 2016向け資料の推奨設定を別のOSへそのまま適用しません。

印刷：Spoolerの再起動とジョブ削除は別操作

Print Spoolerの再起動で一時的な不調が改善する場合はありますが、再起動するだけですべての印刷ジョブが削除される、とはいえません。ジョブの取り消しやスプールファイルの削除は別操作です。印刷サーバーでは他の利用者にも影響するため、対象キューと保守時間を確認します。

Microsoftの印刷キューが詰まった場合の手順でも、ジョブの取り消し、サービス再起動、スプールフォルダーの消去は区別されています。ジョブを失う処置を、サービス再起動の一部として自動実行しないでください。

IIS：W3SVCとIIS全体の再起動を区別する

W3SVCはWorld Wide Web Publishing Serviceです。IISにはWAS（Windows Process Activation Service）、アプリケーションプールなどの別の構成要素もあります。W3SVCの停止・開始だけを「IIS全体を再起動した」と表現するのは不正確です。

サイトやアプリケーションプールだけに問題があるのか、HTTPサービス全体かを調べ、製品の保守手順で必要な範囲を選びます。広範囲な停止は複数サイトや利用者を巻き込むため、汎用バッチの対象にはしません。構成の違いはIISアーキテクチャの概要を参照してください。

定期再起動より、原因と復旧条件を明確にする

同じ症状が繰り返される場合は、再起動の周期を短くする前に、イベント、製品ログ、資源使用量、更新や設定変更の履歴を調べます。定期実行が必要な製品でも、ベンダーの根拠、作業時間、二重起動防止、失敗通知、停止後に開始できない場合の対応を決めてから設計します。

まとめ

CMDによるサービス再起動は、net stopとnet startが基本です。対象のサービス名と依存関係を確かめ、停止要求の結果、STOPPED、開始要求の結果、RUNNINGの順に確認します。最後に実際の機能を検証し、起動状態だけを復旧の証拠にしないことが重要です。

自動化する場合も、失敗時に中断する分岐と有限回の状態確認を入れます。停止できないサービス、想定外の依存関係、待機上限を超えた状態に対して、強制終了や設定変更を自動で追加せず、記録を残して個別の復旧手順につなげてください。

参考資料

• Microsoft Learn：Sc.exe query
• Microsoft Learn：Configuring a Service Using SC
• Microsoft Learn：Stopping a Service
• Microsoft Learn：timeout