Windows 服務 Error 1053 是什麼意思?服務沒有及時回應的原因與排查

⚡ 本文重點

• 文章屬性:疑難排除
• 適用系統:Windows 10、Windows 11 與 Windows Server(2026-09-28 查證)
• 難易度 / 耗時:⭐⭐⭐ 涉及登錄檔 / 定位約 15–30 分鐘,改設定後需重新開機
• 核心結論:事件 7009 代表服務程式沒連上 SCM,7011 代表連上後回應太慢,兩者要查的方向不同;別的服務卡在控制要求也會拖累你的服務。只在開機時逾時先試延遲自動啟動,影響全系統的 ServicesPipeTimeout 留到最後。
• 適用對象:啟動或停止服務時跳出 1053,或系統記錄有事件 7000、7009、7011 的人

📌 快速答案

一句話答案:Windows 服務 Error 1053 代表服務沒在時限內回應服務控制管理員,預設等 30 秒;先查事件 7009、7011 與相依服務,再決定改延遲啟動或調高 ServicesPipeTimeout。

🧰 開始前的準備

• 適用系統:Windows 10、Windows 11、Windows Server;ServicesPipeTimeout 的微軟疑難排解文件標示適用於受支援的 Windows Server 版本
• 權限需求:系統管理員(修改服務啟動類型與登錄檔都需要)
• 需要工具:事件檢視器(eventvwr.msc)、服務主控台(services.msc)、以系統管理員身分開啟的 PowerShell 或命令提示字元、登錄編輯程式(regedit)
• 預計耗時:定位約 15–30 分鐘;改完啟動類型或逾時值都要重新開機才看得到結果
• 動手前:Windows 10、Windows 11 先建立系統還原點,步驟可參考Win10/Win11 系統還原點完整教學;Windows Server 請改為先依貴單位的程序完成系統備份

🔍 症狀描述與錯誤訊息

在「服務」主控台按下啟動,進度條跑了一段時間後跳出錯誤;或是用 sc.exe、net start 啟動服務,等了一陣子才回報失敗。Windows 服務 Error 1053 對應微軟 System Error Codes 文件裡的 ERROR_SERVICE_REQUEST_TIMEOUT,十六進位是 0x41D,官方英文訊息的關鍵在 in a timely fashion,也就是「沒有及時」。

1053 (0x41D) The service did not respond to the start or control request in a timely fashion.

繁體中文介面顯示的是這句話的中譯,台灣使用者在 iT 邦幫忙貼出的畫面文字是「服務並未以適時的方式回應啟動或控制請求」,辨識時以錯誤編號 1053 為準。

注意訊息裡的 start or control request。1053 不只出現在啟動,停止、暫停這類控制要求沒按時回應,也會回報同一個錯誤。系統記錄也可能留下服務控制管理員(Service Control Manager)的事件 7000、7009 或 7011,這幾筆是後面判斷卡在哪一段的主要線索。

Windows 服務 Error 1053 與相鄰錯誤碼怎麼分

1053 附近還有幾個長得很像的服務錯誤碼,各自指向不同的處理方向,先認清楚可以少走冤枉路。

• 1053 是「等不到回應」的判定,訊息本身不說明服務為什麼慢,要靠事件記錄補上前因。
• 1068、1069 已經指出原因(相依服務、登入帳戶),照訊息處理比拉長逾時有效。
• 1067 代表處理程序已經結束,這時把等待時間拉長也等不到回應。
• 1063 在 StartServiceCtrlDispatcher 文件中的說明,是程式以主控台應用程式身分執行、而非以服務身分執行時的回傳值。

🔎 問題根因

Windows 服務 Error 1053 是一個逾時判定,代表服務控制管理員(SCM)在時限內沒有收到服務的回應,本身不指向特定元件損壞。SCM 啟動服務時會先等服務處理程序連線,再等服務回應 SCM 的交易要求;微軟 TechNet 對事件 7009 與 7011 的說明都寫明,預設逾時是 30000 毫秒,也就是 30 秒。所以排查時要問的是,這個服務為什麼 30 秒內沒有回應。

• 初始化做太多事:服務在連上 SCM 之前做冗長的初始化(例如連線資料庫、載入大量設定),拖過了連線時限。StartServiceCtrlDispatcher 文件要求主執行緒在處理程序啟動後 30 秒內完成這個呼叫。
• 開機時資源競爭:自動啟動的服務在開機期間一起啟動。微軟提供延遲自動啟動,理由正是改善開機時的系統效能;服務手動啟動正常、只在開機時逾時,就優先往這個方向查。
• 相依服務拖慢:被依賴的服務還沒就緒,後面的服務只能等。KB 922918 提到,相依於 Windows Trace Session Manager 的服務可能需要超過 60 秒才能啟動。
• 程式本身不是服務程式:把一般的 .exe 直接註冊成服務,程式不會呼叫 StartServiceCtrlDispatcher。StartService 文件對 ERROR_SERVICE_REQUEST_TIMEOUT 的說明,第一種情形就是服務的處理程序已經啟動、卻沒有呼叫 StartServiceCtrlDispatcher。
• 被別的服務拖累:SCM 一次只處理一個服務控制通知。StartService 文件寫明,任何服務正忙著處理控制碼時,StartService 會阻塞 30 秒,時限到了那個服務仍未從處理常式返回,就以 ERROR_SERVICE_REQUEST_TIMEOUT 失敗;這時出錯的不一定是你要啟動的服務。
• 控制要求處理太久:停止或暫停時,服務的控制處理常式(HandlerEx)若 30 秒內沒有返回,SCM 會回報錯誤;文件要求耗時工作交給另一條執行緒處理。

🔬 底層機制:這個錯誤訊號從哪裡來?

SCM 啟動一個服務要經過兩段各自計時的等待,任何一段逾時都會變成 1053。把兩段拆開看,就知道事件 7009 與 7011 分別對應哪裡。

第一段:30 秒內連上 SCM

SCM 建立服務處理程序後,會等它的主執行緒呼叫 StartServiceCtrlDispatcher,讓這條執行緒成為服務的控制分派器。微軟文件寫明,這個呼叫應在處理程序啟動後 30 秒內完成;多個服務共用同一個處理程序時,共用的初始化可以放在呼叫之前,但同樣要少於 30 秒,否則就要另開執行緒處理。這一段逾時,系統記錄會出現事件 7009,封存文件列出的訊息格式是「Timeout (%1 milliseconds) waiting for the %2 service to connect.」。

第二段:回應 SCM 的控制要求

連上之後,控制分派器會建立新的執行緒執行該服務的 ServiceMain。StartService 文件說明,SCM 收到 ServiceMain 執行緒建立成功的通知就讓 StartService 返回,不等服務第一次回報;返回前 SCM 先把狀態預設為 SERVICE_START_PENDING、CheckPoint 為 0、WaitHint 為 2 秒。停止、暫停等控制要求由 HandlerEx 處理,文件要求它盡快返回,30 秒內沒返回 SCM 就回報錯誤;StartService 文件也把「呼叫 StartServiceCtrlDispatcher 的執行緒卡在控制處理常式裡」列為 ERROR_SERVICE_REQUEST_TIMEOUT 的情形之一。事件 7011 在封存文件列出的訊息格式是「Timeout (%1 milliseconds) waiting for a transaction response from the %2 service.」。

啟動期間的進度回報是另一套規則。服務要用 SetServiceStatus 回報 SERVICE_START_PENDING,並在 dwWaitHint 指定的毫秒數內遞增 dwCheckPoint 或改變狀態;SERVICE_STATUS 文件說明,等待提示的時間過了卻沒有任何進度,SCM 或服務控制程式可以認定發生錯誤。這種卡在啟動擱置狀態的情形,前面對照表中的 1070(ERROR_SERVICE_START_HANG)就是在描述它。

事件 7000 則是結果紀錄,格式為「The %1 service failed to start due to the following error: %2」,%2 會帶出 1053 那句訊息。KB 922918 說明,SCM 會等待 ServicesPipeTimeout 指定的時間,才記錄事件 7000 或 7011;事件 7009 與 7011 的封存文件也都以調整 ServicesPipeTimeout 作為處置,依這兩份文件的寫法推論,連線(7009)與交易回應(7011)這兩種等待都受這個登錄值控制。

🛠️ 解決方案

⚠️ 高風險操作提醒:方法二會改服務的啟動類型,方法四會改登錄檔。動手前請先建立系統還原點(Windows Server 則先完成系統備份),並以系統管理員身分操作。遇到下列任一情況請先停下,不要繼續:不確定要改的是哪一個服務、還沒建立還原點或完成備份、公司或學校管理的電腦沒有 IT 授權、BitLocker 已啟用卻找不到修復金鑰、指令輸出與本文描述不符。

方法一:用事件記錄與相依鏈定位卡在哪一段

先分清楚是哪一段逾時、有沒有相依服務卡住,後面的處置才不會打錯地方。這一步只讀取資訊,不改任何設定。

步驟 1:找出服務名稱。 sc.exe 與 PowerShell 要用的是服務名稱,不一定等於畫面上的顯示名稱。在 PowerShell 用顯示名稱的關鍵字搜尋,Name 欄就是服務名稱。

Get-Service -DisplayName "*關鍵字*"

步驟 2:撈出服務控制管理員的相關事件。 在事件檢視器可以到「Windows 記錄 → 系統」,用「篩選目前的記錄」(Filter Current Log)輸入 7000,7009,7011;事件檢視器的基本操作可參考用事件檢視器讀懂當機紀錄。改用 PowerShell 可以一次撈出三種事件;下表的訊息格式取自封存文件,實際顯示的句型可能不同,比對時以事件識別碼為準。

$f = @{
  LogName      = 'System'
  ProviderName = 'Service Control Manager'
  Id           = 7000, 7009, 7011
}
Get-WinEvent -FilterHashtable $f -MaxEvents 20 |
  Format-List TimeCreated, Id, Message

• 同一次啟動先出現 7009、再出現 7000,代表處理程序連 SCM 都沒連上。用步驟 3 的 sc.exe qc 看這個服務設定的執行檔是哪一支程式;如果是把一般程式直接註冊成服務,依 StartService 文件的說明推論,調高逾時也等不到它連線,要改用軟體廠商提供的安裝方式,或照方法三把程式改寫成服務程式。
• 出現 7011,代表連線成功但服務沒在時限內回應 SCM 的交易要求,重點放在服務的控制處理常式是否卡住,以及是否有其他服務同時忙碌。
• 7000 的錯誤不是 1053 時,依錯誤碼回到「症狀描述與錯誤訊息」一節的對照表處理。
• 7000 的封存文件提到,同一個服務若同時記錄 7011,延長服務逾時也能一併解決 7000。

步驟 3:看服務設定與結束碼。 把「服務名稱」換成步驟 1 查到的名稱,名稱含空格時要加上雙引號。

sc.exe qc 服務名稱
sc.exe queryex 服務名稱
net helpmsg 1053

sc.exe qc 會顯示服務目前的設定;sc.exe queryex 會列出 STATE、WIN32_EXIT_CODE、CHECKPOINT、WAIT_HINT 與 PID 等延伸狀態。依微軟封存文件,服務成功啟動時 WIN32_EXIT_CODE 應為 0;net helpmsg 可以把四位數的錯誤碼轉成說明文字。

步驟 4:追相依鏈。 列出這個服務依賴的服務,逐一確認都在執行。

Get-Service -Name 服務名稱 -RequiredServices

-RequiredServices 取回的是服務的 ServicesDependedOn 屬性。清單裡只要有一個服務停著或同樣啟動失敗,就先修它;這種情況也可能直接得到 1068。

方法二:改成延遲自動啟動,避開開機搶資源

服務手動啟動正常、只在開機時逾時,而且不需要在開機第一時間就可用,可以改成延遲自動啟動。SERVICE_DELAYED_AUTO_START_INFO 文件說明,這類服務會在其他自動啟動服務啟動後,再經過一小段延遲才啟動。

1. 先用 sc.exe qc 服務名稱 查看啟動類型(START_TYPE)並記下來,回退時要照原值改回去。sc.exe config 的 start= delayed-auto 會把啟動類型直接改成延遲的自動啟動,所以只有原本就是自動啟動、而且開機後不會馬上被手動或其他程式啟動的服務才往下做;原本是手動或停用的服務,就停在這一步,不要套用本方法。
2. 確認符合條件後,以系統管理員身分執行下面的指令,start= 後面必須空一格。

sc.exe config 服務名稱 start= delayed-auto

執行後重新開機,這項設定在下次開機才生效。

• 微軟文件寫明,延遲啟動沒有保證確切的啟動時間;開機後馬上就要用到這個服務的程式,呼叫可能會失敗。
• ServiceMain 執行緒會以最低優先權(THREAD_PRIORITY_LOWEST)起跑,回報 SERVICE_RUNNING 後才升回一般優先權。依這項說明推論,延遲啟動改善的是開機搶資源,服務自身初始化太慢的問題不會因此消失。
• 文件也建議,開機後不久就經常被手動或其他程式啟動的服務,不要標成延遲自動啟動。

方法三:自己寫的服務,把初始化移出關鍵路徑

服務是自家開發的,根本解法是讓程式在時限內回應,不必要求每台電腦調高逾時。

• 主執行緒啟動後立刻呼叫 StartServiceCtrlDispatcher;共用初始化會超過 30 秒,就交給另一條執行緒。
• ServiceMain 一開始就呼叫 RegisterServiceCtrlHandlerEx 註冊控制處理常式。
• 初始化期間回報 SERVICE_START_PENDING,每完成一步遞增 dwCheckPoint,並在 dwWaitHint 到期前再次呼叫 SetServiceStatus。SCM 預設的 WaitHint 只有 2 秒,依等待提示的規則推論,初始化較久的服務應盡早回報並給出足夠的 dwWaitHint。
• HandlerEx 只記下要求並立即返回,耗時的停止工作交給另一條執行緒,避免 30 秒內沒返回。
• .NET 的 ServiceBase 可以在 OnStart、OnStop 等方法中呼叫 RequestAdditionalTime,把等待提示傳給 SCM,避免服務被標成沒有回應。

偵錯時若直接執行服務程式,StartServiceCtrlDispatcher 會回傳 ERROR_FAILED_SERVICE_CONTROLLER_CONNECT(1063)。微軟建議把服務專屬的程式碼包在判斷裡,收到這個錯誤時跳過這些程式碼。另外,Debugging a Service 文件提醒,要偵錯自動啟動服務的初始化程式碼,得暫時把它安裝成手動啟動(demand-start)的服務來執行。

方法四:調整 ServicesPipeTimeout(最後手段)

確認服務只是慢、最終能完成啟動,才考慮拉長 SCM 的等待時間。這是全系統設定,會影響所有服務;微軟也把它定位為因應措施,並建議同時研究問題是否為其他狀況的症狀。

1. 開啟登錄編輯程式(regedit),找到 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control。
2. 在右側窗格找 ServicesPipeTimeout。如果已經存在,先按兩下開啟、選「十進位」,把原本的數值抄下來;如果不存在,記下「原本沒有這個值」,回退時要照這份紀錄處理。
3. 不存在時,從「編輯」→「新增」建立 DWORD 值,名稱輸入 ServicesPipeTimeout。
4. 對 ServicesPipeTimeout 按右鍵選「修改」,選「十進位」,輸入以毫秒計的數值,例如微軟範例的 60000(60 秒)。
5. 重新開機。

微軟對數值的建議是一次只增加一點,直到服務能夠啟動為止。KB 922918 的適用範圍標示為受支援的 Windows Server 版本;在 Windows 10、Windows 11 上照做前,更要先完成還原點與原值紀錄。想先把登錄檔整體備份起來,可參考Windows 11 登錄檔備份與還原完整教學。

✅ 驗證修復結果

服務能跑起來還不夠,重開機後要確認狀態、事件與控制要求三者都正常。

• 執行 sc.exe queryex 服務名稱,STATE 應顯示 RUNNING,WIN32_EXIT_CODE 為 0。
• 重跑方法一的 Get-WinEvent,比對 TimeCreated,確認這次開機之後,訊息中含這個服務名稱或顯示名稱(sc.exe qc 輸出的 SERVICE_NAME 與 DISPLAY_NAME)的 7000、7009、7011 沒有再出現;事件訊息帶的可能是顯示名稱,不一定是 sc.exe 指令用的服務名稱。
• 服務允許中斷時,手動停止再啟動一次,確認控制要求也能在時限內完成。
• 調過 ServicesPipeTimeout 的電腦,依 KB 922918 的說明,SCM 會等到這個時間才記錄 7000 或 7011,真正卡死的服務也要更久才會被判定失敗;開機後若明顯變慢,要回頭檢查這個值。

🔙 萬一翻車:回退步驟

本文會改動兩處設定:服務的啟動類型與 ServicesPipeTimeout 登錄值,依重開機後的狀況選擇下面對應的回退方式。

情境一:設定生效但效果不如預期

• 延遲自動啟動:用 sc.exe config 服務名稱 start= 原本的類型 改回,例如原本是自動啟動就填 auto、手動就填 demand;一律照你記下的 START_TYPE 還原,不要全部改成 auto。
• ServicesPipeTimeout:回到登錄編輯程式的同一位置。原本沒有這個值,就對它按右鍵刪除;原本有值,就改回抄下的十進位原值。重新開機後生效。
• 不要假設這個值原本就不存在,電腦上的軟體或管理員可能早就設定過,所以回退一律照動手前的紀錄。

情境二:設定後系統出現錯誤

開機後出現大量服務異常或登入明顯變慢,情境一的方式又來不及處理時,Windows 10、Windows 11 可用系統還原回到動手前的還原點。微軟支援文件說明,系統還原會把系統檔案、登錄設定與已安裝的程式還原到建立還原點當時的狀態,個人檔案不受影響;在 Windows 中按 Win+R 輸入 rstrui.exe 即可開啟。Windows Server 則用貴單位的系統備份還原。

情境三:系統無法開機(最壞情況)

Windows 10、Windows 11 進入 Windows 復原環境(Windows RE),依序選「疑難排解」→「進階選項」→「系統還原」(英文介面為 Troubleshoot → Advanced options → System Restore),再選動手前建立的還原點。開不了機時進入 Windows RE 的方式,見微軟的Windows 復原環境說明。裝置有 BitLocker 加密時,這一步需要 BitLocker 修復金鑰。Windows Server 則依貴單位的系統備份與復原程序處理。

💡 總結:預防再次發生

Error 1053 描述的是症狀,病因要另外找。它只說明 SCM 在時限內等不到回應,真正的原因要從事件 7009、7011 與相依鏈拼出來。編輯部建議的處理順序是先定位,再處理開機資源競爭與相依服務,最後才動全系統的 ServicesPipeTimeout;這個值一旦調高,所有服務卡住時被判定失敗的時間都會跟著變長。

• 自家開發的服務,把冗長初始化移到背景執行緒,並用 SetServiceStatus 或 RequestAdditionalTime 回報進度。
• 開機時不急著用的第三方服務,優先考慮延遲自動啟動。
• 調過 ServicesPipeTimeout 的電腦,把原值、新值與調整日期記在維運紀錄;服務更新或換掉之後,重新評估是否改回。
• 軟體更新後又出現 1053,先比對事件時間點與更新時間,再聯絡軟體廠商並附上 7000、7009、7011 的事件內容。

❓ 常見問題

Q:Error 1053 是服務壞了嗎?

不一定。1053 只代表 SCM 在時限內沒收到回應,服務可能只是初始化太慢、正在等相依服務,或開機時搶不到資源。先看事件 7009、7011 分辨卡在哪一段,再決定處置。

Q:服務啟動的逾時秒數可以調嗎?

可以。逾時由 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control 底下的 ServicesPipeTimeout 控制,單位是毫秒,改完要重新開機。這是全系統設定,微軟建議一次只增加一點,並同時追查根本原因。

Q:要怎麼看是哪個相依服務失敗?

在 PowerShell 執行 Get-Service -Name 服務名稱 -RequiredServices,列出它依賴的服務,逐一確認狀態。相依服務沒有啟動時,可能會直接得到 1068「相依的服務或群組無法啟動」,先修好被依賴的服務。

Q:改 ServicesPipeTimeout 登錄檔安全嗎?

操作本身只是新增或修改一個 DWORD 值,風險在於它影響所有服務,而且會讓真正卡死的服務更晚被判定失敗。動手前在 Windows 10、Windows 11 建立還原點(Windows Server 先完成系統備份)、抄下原值,照方法四小幅調整,回退時照原值還原,可以降低出錯時的影響。

Q:停止服務時也跳 1053 怎麼辦?

停止屬於控制要求,服務的控制處理常式 30 秒內沒返回,SCM 就會回報錯誤。先用 sc.exe queryex 看 STATE 是否停在 STOP_PENDING,並檢查事件 7011;第三方服務就把事件內容交給廠商。自家服務則照方法三,把停止時的耗時工作交給另一條執行緒,並持續回報 SERVICE_STOP_PENDING 與等待提示。

Q:修完之後又復發怎麼辦?

比對復發時間與最近的更新、安裝紀錄,重跑方法一確認這次是哪個事件。調過逾時仍復發,代表服務的回應時間還在變長,應該回頭處理服務本身或它的相依服務;持續加大數值,只會延後失敗被記錄的時間。

🔗 延伸閱讀

• 乾淨開機 Clean Boot 教學:找出害電腦卡頓、當機的背景服務
• ETW 事件追蹤是什麼?用 Windows Performance Recorder(WPR)抓效能問題完整教學
• MSI 安裝出現 Error 1603 怎麼辦?Windows Installer 完整排查
• Side-by-Side Configuration Incorrect 怎麼辦?用 sxstrace 找真正缺什麼

📎 參考資料來源

📖 第一級|廠商官方:

• System Error Codes (1000-1299)(Microsoft Learn) — 2026-09-28 查證
• A slow service does not start due to time-out error in Windows(Microsoft Learn,KB 922918) — 2026-09-28 查證
• StartServiceCtrlDispatcherA function(Microsoft Learn) — 2026-09-28 查證
• StartServiceA function(Microsoft Learn) — 2026-09-28 查證
• LPHANDLER_FUNCTION_EX callback function(Microsoft Learn) — 2026-09-28 查證
• SERVICE_STATUS structure(Microsoft Learn) — 2026-09-28 查證
• SERVICE_DELAYED_AUTO_START_INFO structure(Microsoft Learn) — 2026-09-28 查證
• Debugging a Service(Microsoft Learn) — 2026-09-28 查證
• Event ID 7009 — Basic Service Operations(Microsoft Learn 封存文件) — 2026-09-28 查證
• Event ID 7011 — Basic Service Operations(Microsoft Learn 封存文件) — 2026-09-28 查證
• Windows Server 2008: Event ID 7000 — Service Start Operations(Microsoft Learn 封存文件) — 2026-09-28 查證
• sc.exe config(Microsoft Learn) — 2026-09-28 查證
• Get-Service(Microsoft Learn) — 2026-09-28 查證
• Creating Get-WinEvent queries with FilterHashtable(Microsoft Learn) — 2026-09-28 查證
• ServiceBase.RequestAdditionalTime Method(Microsoft Learn) — 2026-09-28 查證
• System Restore(Microsoft 支援) — 2026-09-28 查證
• Windows recovery environment(Microsoft 支援) — 2026-09-28 查證

📖 社群案例|使用者提問(僅用於辨識中文介面文字):

• IIS無法啟動,服務並未以適時的方式回應啟動或控制請求?(iT 邦幫忙) — 2026-09-28 查證

⚠️ 本文核心事實以第一級微軟官方文件為準,社群案例僅用於辨識中文介面顯示的文字。事件 7000、7009、7011 的說明取自 Microsoft Learn 封存的 TechNet 文件,當時標示的適用版本為 Windows Server 2008 與 Windows Server 2008 R2。

📅 本文查證戳記:2026-09-28 依據上列微軟官方文件查證撰寫,內容為官方文件整理,非實機操作紀錄。

若你在後續版本遇到步驟失效,歡迎在留言區回報。