共用方式為


Windows Update 問題疑難解答

適用於: Windows 10

試用我們的虛擬代理程式 - 它可協助您快速找出並修正常見的 Windows Update 問題

如果您在使用 Windows Update 時遇到問題,請從下列步驟開始:

  1. 執行內建 Windows Update 疑難解答員以修正常見問題。 流覽至 [設定>更新與安全性>疑難解答>Windows Update]。

  2. 從 Microsoft 更新目錄安裝符合您 Windows 版本的最新服務堆疊更新。 如需服務堆疊更新的詳細資訊,請參閱 維護堆棧更新

  3. 請確定您安裝最新的 Windows 更新、累積更新和彙總更新。 若要確認更新狀態,請參閱系統的適當更新歷程記錄:

進階使用者也可以參考 Windows Update 所產生的記錄 檔,以進行進一步調查。

使用 Windows Update 時,可能會遇到下列案例。

為什麼我提供較舊的更新?

提供給裝置的更新取決於數個因素。 以下是一些最常見的屬性:

  • 作業系統組建
  • OS 分支
  • OS 地區設定
  • OS 架構
  • 裝置更新管理設定

如果您提供的更新不是最新的可用更新,可能是因為您的裝置正由WSUS 伺服器管理,而且您正在該伺服器上提供可用的更新。 如果您的裝置是部署群組的一部分,系統管理員可以刻意減緩更新的推出速度。 由於部署速度很慢,且測量為開頭,因此所有裝置都不會在同一天收到更新。

我的裝置在掃描時已凍結。 為什麼?

[設定] UI 會與更新 Orchestrator 服務通訊,而更新協調器服務接著會與 Windows Update 服務通訊。 如果這些服務意外停止,您可能會看到此行為。 在這種情況下,請遵循下列步驟:

  1. 關閉 [設定] 應用程式,然後重新開啟它。

  2. 啟動 Services.msc,並檢查下列服務是否正在執行:

    • 更新狀態 Orchestrator
    • Windows Update

其他更新未提供功能更新

執行 Windows 10 版本 1709 到 Windows 10 版本 1803 的裝置,這些 裝置已設定為從 Windows Update 更新(包括商務用 Windows Update )可以安裝服務和定義更新,但絕不會提供功能更新。

檢查WindowsUpdate.log會顯示下列錯誤:

YYYY/MM/DD HH:mm:ss:SSS PID  TID  Agent           * START * Finding updates CallerId = Update;taskhostw  Id = 25
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Agent           Online = Yes; Interactive = No; AllowCachedResults = No; Ignore download priority = No
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Agent           ServiceID = {855E8A7C-ECB4-4CA3-B045-1DFA50104289} Third party service
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Agent           Search Scope = {Current User}
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Agent           Caller SID for Applicability: S-1-12-1-2933642503-1247987907-1399130510-4207851353
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            Got 855E8A7C-ECB4-4CA3-B045-1DFA50104289 redir Client/Server URL: https://fe3.delivery.mp.microsoft.com/ClientWebService/client.asmx""
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            Token Requested with 0 category IDs.
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            GetUserTickets: No user tickets found. Returning WU_E_NO_USERTOKEN.
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            *FAILED* [80070426] Method failed [AuthTicketHelper::GetDeviceTickets:570]
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            *FAILED* [80070426] Method failed [AuthTicketHelper::GetDeviceTickets:570]
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            *FAILED* [80070426] GetDeviceTickets
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            *FAILED* [80070426] Method failed [AuthTicketHelper::AddTickets:1092]
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            *FAILED* [80070426] Method failed [CUpdateEndpointProvider::GenerateSecurityTokenWithAuthTickets:1587]
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            *FAILED* [80070426] GetAgentTokenFromServer
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            *FAILED* [80070426] GetAgentToken
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            *FAILED* [80070426] EP:Call to GetEndpointToken
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Misc            *FAILED* [80070426] Failed to obtain service 855E8A7C-ECB4-4CA3-B045-1DFA50104289 plugin Client/Server auth token of type 0x00000001
YYYY/MM/DD HH:mm:ss:SSS PID  TID  ProtocolTalker  *FAILED* [80070426] Method failed [CAgentProtocolTalkerContext::DetermineServiceEndpoint:377]
YYYY/MM/DD HH:mm:ss:SSS PID  TID  ProtocolTalker  *FAILED* [80070426] Initialization failed for Protocol Talker Context
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Agent           Exit code = 0x80070426
YYYY/MM/DD HH:mm:ss:SSS PID  TID  Agent           * END * Finding updates CallerId = Update;taskhostw  Id = 25

0x80070426錯誤碼會轉譯為:

ERROR_SERVICE_NOT_ACTIVE - # The service has not been started.

Microsoft帳戶登入小幫手 (MSA 或 wlidsvc) 是有問題的服務。 DCAT 正式發行前小眾測試版服務 (ServiceId: 855E8A7C-ECB4-4CA3-B045-1DFA50104289) 依賴 MSA 來取得裝置的全域裝置標識符。 若未執行 MSA 服務,用戶端將不會產生並傳送全域裝置標識碼,而且搜尋功能更新永遠不會順利完成。

若要解決此問題,請將 MSA 服務重設為預設的 StartType“manual”。

Windows Update 使用 WinHttp 搭配部分範圍要求 (RFC 7233) 從 Windows Update 伺服器或內部部署 WSUS 伺服器下載更新和應用程式。 因此,網路上的 Proxy 伺服器必須支援 HTTP RANGE 要求。 如果在 Internet Explorer 中設定 Proxy(用戶層級),但在 WinHTTP(系統層級)中未設定 Proxy,則 Windows Update 的連線將會失敗。

若要修正此問題,請使用下列 netsh 命令在 WinHTTP 中設定 Proxy:

netsh winhttp set proxy ProxyServerName:PortNumber 

注意

您也可以使用下列命令,從 Internet Explorer 匯入 Proxy 設定: netsh winhttp import proxy source=ie

如果透過 Proxy 伺服器下載失敗,並發生0x80d05001 DO_E_HTTP_BLOCKSIZE_MISMATCH錯誤,或您在下載更新時注意到高 CPU 使用量,請檢查 Proxy 組態以允許 HTTP RANGE 要求執行。

您可以選擇套用規則以允許下列 URL 的 HTTP RANGE 要求:

  • *.download.windowsupdate.com
  • *.dl.delivery.mp.microsoft.com
  • *.delivery.mp.microsoft.com

如果您不允許 RANGE 要求,您將會下載更新中所需的內容(因為差異修補無法運作)。

更新不適用於您的電腦

下表說明此錯誤最常見的原因:

原因 說明 解決方法
更新已被取代 隨著元件的更新發行,更新的元件將會取代系統上已有的舊元件。 發生此問題時,先前的更新會標示為已取代。 如果您嘗試安裝的更新已在系統上有較新版本的承載,您可能會收到此錯誤訊息。 檢查您要安裝的套件是否包含較新版本的二進位檔。 或者,檢查套件是否已由另一個新套件取代。
已經安裝更新 如果您嘗試安裝的更新先前已安裝,例如,由攜帶相同承載的另一個更新,您可能會遇到此錯誤訊息。 確認您嘗試安裝的套件先前未安裝。
架構的更新錯誤 更新是由 CPU 架構發布。 如果您嘗試安裝的更新不符合 CPU 的架構,您可能會遇到此錯誤訊息。 確認您嘗試安裝的套件符合您所使用的 Windows 版本。 在各項更新文章的「適用」一節中可以找到 Windows 版本資訊。 例如,Windows Server 2012 僅限更新無法安裝在 Windows Server 2012 R2 型電腦上。
此外,請確認您要安裝的套件符合您使用之 Windows 版本的處理器架構。 例如,以 x86 為基礎的更新無法安裝於 Windows 的 x64 型安裝上。
遺漏必要的更新 某些更新需要必要條件更新,才能套用至系統。 如果您缺少必要條件更新,可能會遇到此錯誤訊息。 例如,KB 2919355必須安裝在 Windows 8.1 和 Windows Server 2012 R2 計算機上,才能安裝 2014 年 4 月之後發行的許多更新。 請檢查Microsoft知識庫中套件的相關文章(KB),以確定您已安裝必要條件更新。 例如,如果您在 Windows 8.1 或 Windows Server 2012 R2 上遇到錯誤訊息,您可能必須安裝 2014 年 4 月更新2919355作為必要條件,以及一或多個必要維護更新 (KB 2919442 和 KB 3173424)。
若要判斷是否已安裝這些必要條件更新,請執行下列 PowerShell 命令:
get-hotfix KB3173424,KB2919355, KB2919442.
如果已安裝更新,命令會傳 InstalledOn 回輸出區段中的已安裝日期。

您可能會在 Windows Update 記錄中看到的錯誤:

DownloadManager    Error 0x800706d9 occurred while downloading update; notifying dependent calls. 

Or

[DownloadManager] BITS job {A4AC06DD-D6E6-4420-8720-7407734FDAF2} hit a transient error, updateId = {D053C08A-6250-4C43-A111-56C5198FE142}.200 <NULL>, error = 0x800706D9 

Or

DownloadManager [0]12F4.1FE8::09/29/2017-13:45:08.530 [agent]DO job {C6E2F6DC-5B78-4608-B6F1-0678C23614BD} hit a transient error, updateId = 5537BD35-BB74-40B2-A8C3-B696D3C97CBA.201 <NULL>, error = 0x80D0000A 

移至 Services.msc,並確定已啟用 Windows 防火牆服務。 Microsoft不支援停止與具有進階安全性的 Windows 防火牆相關聯的服務。 如需詳細資訊,請參閱 我需要停用 Windows 防火牆

因設定衝突原則而產生的問題

Windows Update 提供廣泛的設定原則,以控制受管理環境中 Windows Update 服務的行為。 雖然這些原則可讓您在細微層級設定設定,但設定錯誤或設定衝突的原則可能會導致非預期的行為。

如需詳細資訊,請參閱 如何使用組策略或登錄設定來設定自動更新。

裝置無法存取更新檔案

確定裝置可以透過防火牆連線到必要的 Windows Update 端點。 例如,針對 Windows 10 版本 2004,下列通訊協議必須能夠連線到這些各自的端點:

通訊協定 端點 URL
TLS 1.2 *.prod.do.dsp.mp.microsoft.com
HTTP emdl.ws.microsoft.com
HTTP *.dl.delivery.mp.microsoft.com
HTTP *.windowsupdate.com
HTTPS *.delivery.mp.microsoft.com
TLS 1.2 *.update.microsoft.com
TLS 1.2 tsfe.trafficshaping.dsp.mp.microsoft.com

注意

請務必不要針對指定 HTTP 的端點使用 HTTPS,反之亦然。 線上將會失敗。

特定端點可能會因 Windows 用戶端版本而異。 例如, 請參閱 Windows 10 2004 企業版連線端點。 其他 Windows 用戶端版本的類似文章可在附近的目錄中取得。

更新不會從內部網路端點下載 (WSUS 或 Configuration Manager)

Windows 用戶端裝置可以從各種來源接收更新,包括 Windows Update Online、Windows Server Update Services 伺服器和其他來源。 若要判斷目前在裝置上使用的 Windows Update 來源,請遵循下列步驟:

  1. 以系統管理員身分啟動 PowerShell。

  2. 執行 Cmdlet:

    
    $MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
    
  3. 執行 Cmdlet:

    $MUSM.Services
    

檢查 Name 和 OffersWindowsUPdates 參數的輸出,您可以根據下表加以解譯。

輸出 意義
- 名稱:Microsoft更新
-OffersWindowsUpdates: True
- 更新來源是Microsoft Update,這表示除了操作系統之外,其他Microsoft產品的更新也可以傳遞。
- 指出客戶端已設定為接收所有Microsoft產品的更新(Office 等)
- 名稱:DCat 正式發行前小眾測試版
- OffersWindowsUpdates: True
- 從 Windows 10 版本 1709 開始,功能更新一律會透過DCAT服務傳遞。
- 指出客戶端已設定為從 Windows Update 接收功能更新。
- 名稱:Windows 市集 (DCat Prod)
- OffersWindowsUpdates: False
-更新來源是市集應用程式的測試人員更新。
- 指出用戶端不會接收或未設定為接收這些更新。
- 名稱:Windows Server Update Service
- OffersWindowsUpdates: True
- 來源是 Windows Server Updates Services 伺服器。
- 客戶端已設定為從 WSUS 接收更新。
- 名稱:Windows Update
- OffersWindowsUpdates: True
- 來源為 Windows Update。
- 客戶端已設定為從 Windows Update Online 接收更新。

環境中設定不正確

在此範例中,根據透過登錄設定的組策略,系統會設定為使用WSUS 下載更新(請注意第二行):

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] 
"UseWUServer"=dword:00000001

從 Windows Update 記錄檔:

2018-08-06 09:33:31:085  480 1118 Agent ** START **  Agent: Finding updates [CallerId = OperationalInsight  Id = 49] 
2018-08-06 09:33:31:085  480 1118 Agent ********* 
2018-08-06 09:33:31:085  480 1118 Agent   * Include potentially superseded updates 
2018-08-06 09:33:31:085  480 1118 Agent   * Online = No; Ignore download priority = No 
2018-08-06 09:33:31:085  480 1118 Agent   * Criteria = "IsHidden = 0 AND DeploymentAction=*" 
2018-08-06 09:33:31:085  480 1118 Agent   * ServiceID = {00000000-0000-0000-0000-000000000000} Third party service 
2018-08-06 09:33:31:085  480 1118 Agent   * Search Scope = {Machine} 
2018-08-06 09:33:32:554  480 1118 Agent   * Found 83 updates and 83 categories in search; evaluated appl. rules of 517 out of 1473 deployed entities 
2018-08-06 09:33:32:554  480 1118 Agent ********* 
2018-08-06 09:33:32:554  480 1118 Agent **  END  **  Agent: Finding updates [CallerId = OperationalInsight  Id = 49] 

在上述記錄代碼段中,我們看到 Criteria = "IsHidden = 0 AND DeploymentAction=*"。 “*” 表示伺服器未指定任何專案。 因此,掃描會發生,但沒有下載或安裝代理程式的方向。 因此,它只會掃描更新並提供結果。

如下列記錄所示,自動更新會執行掃描,並找不到核准的更新。 因此,它報告沒有安裝或下載的更新。 這是因為設定不正確。 WSUS 端應該核准 Windows Update 的更新,以便擷取更新,並根據原則在指定的時間安裝更新。 由於此案例不包含 Configuration Manager,因此無法安裝未核准的更新。 您預期操作深入解析代理程式會執行掃描,並自動觸發下載和安裝,但這不會發生此設定。

2018-08-06 10:58:45:992  480 5d8 Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates  Id = 57] 
2018-08-06 10:58:45:992  480 5d8 Agent ********* 
2018-08-06 10:58:45:992  480 5d8 Agent   * Online = Yes; Ignore download priority = No 
2018-08-06 10:58:45:992  480 5d8 Agent   * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1" 
   
2018-08-06 10:58:46:617  480 5d8 PT   + SyncUpdates round trips: 2 
2018-08-06 10:58:47:383  480 5d8 Agent   * Found 0 updates and 83 categories in search; evaluated appl. rules of 617 out of 1473 deployed entities 
2018-08-06 10:58:47:383  480 5d8 Agent Reporting status event with 0 installable, 83 installed,  0 installed pending, 0 failed and 0 downloaded updates 
2018-08-06 10:58:47:383  480 5d8 Agent ********* 
2018-08-06 10:58:47:383  480 5d8 Agent **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates  Id = 57] 

Windows Update 在 Windows 用戶端上的高頻寬使用量

使用者可能會看到 Windows 正在系統內容下的不同辦公室取用所有頻寬。 這是依照設計的行為。 可能耗用頻寬的元件會擴充到 Windows Update 元件之外。

下列組策略可協助減輕這種情況:

線上到因特網的其他元件:

大量負載或網路壅塞所造成的暫時性錯誤

使用者可能會從 Windows Update 收到下列錯誤。 這些錯誤是暫時性錯誤,發生在服務暫時處於負載過重或網路擁擠時。 使用者不需要採取任何動作,因為裝置稍後會重試作業。

錯誤碼 錯誤值 詳細資料
WU_S_SEARCH_LOAD_SHEDDING 0x248001 搜尋作業已順利完成,但一或多個服務正在捨入負載。
WU_E_PT_LOAD_SHEDDING 0x8024402d 伺服器正在捨去負載。

在這些情況下,以程式設計方式呼叫 Windows Update 代理程式 API 以 擷取搜尋作業結果 的使用者會取得 orcFailedorcSucceededWithErrors。 稍後重試作業應該會成功。

資料收集

若您需要 Microsoft 支援,建議您按照使用 TSS 收集部署相關問題的資訊所述步驟來收集資訊。