[開始] 功能表疑難解答指引

適用於: Windows 10

啟動失敗可以組織成下列類別:

  • 部署/安裝問題 - 最容易識別但難以復原。 此失敗是一致的,而且通常是永久的。 重設、從備份還原或復原以復原。
  • 效能問題 - 較舊的硬體、低電源機器更常見。 徵兆包括:高 CPU 使用率、磁碟爭用、記憶體資源。 這會讓 \[開始\] 回應變慢。 行為是間歇性的,視可用的資源而定。
  • 當機 - 也很容易識別。 您可以在系統或應用程式事件記錄檔中找到Shell體驗主機或相關聯的損毀。 這可能是程式代碼缺失,或與程式遺失或變更檔案或登錄機碼的許可權或不正確的安全性設定有關。 判斷許可權問題可能很耗時,但 稱為 Procmon 的 SysInternals 工具 會顯示拒絕 存取。 另一個選項是取得程序當機時的傾印,並根據舒適度層級、在調試程式中檢閱傾印,或支援檢閱數據。
  • 停止回應 - 在 Shell 體驗主機中或相關。 這些是最難識別的問題,因為記錄的事件很少,但行為通常是間歇性,或在重新啟動時復原。 如果背景應用程式或服務停止回應,Start 將沒有資源可及時回應。 全新開機有助於識別問題是否與其他軟體相關。 在此案例中,Procmon 也很有用。
  • 其他問題 - 自定義、網域原則、部署問題。

基本疑難解答

針對基本的 [開始] 問題進行疑難解答 (,而且大部分的所有其他 Windows 應用程式) 時,有幾件事需要檢查它們是否未如預期般運作。 針對 [開始] 功能表或子元件無法運作的問題,您可以執行一些快速測試,以縮小問題所在位置的範圍。

檢查 OS 和更新版本

  • 系統是否執行最新的功能和累積每月更新?
  • 問題是否在更新之後立即開始? 檢查方式:
    • PowerShell:[System.Environment]::OSVersion.Version
    • 來自 CMD.exe 的 WinVer

檢查是否已安裝 Start

  • 如果在功能更新之後立即啟動失敗,請檢查應用程式套件是否無法成功安裝。

  • 如果 Start 正常運作,而且只是間歇性地失敗,則可能已正確安裝 Start,但問題會在下游發生。 檢查此問題的方式是尋找這兩個 PowerShell 命令的輸出:

    • get-AppXPackage -Name Microsoft.Windows.ShellExperienceHost
      
    • get-AppXPackage -Name Microsoft.Windows.Cortana
      

      Cmdlet 輸出範例的 Screeshot。

      如果未安裝失敗訊息,則會出現這些訊息

  • 如果未安裝 Start,則最快速的解決方式是還原為已知的良好設定。 這可以是復原更新、將計算機重設為預設值 (其中可以選擇儲存以刪除用戶數據) ,或從備份還原。 不支援安裝 Start Appx 檔案的方法。 結果通常會有問題且不可靠。

檢查 Start 是否正在執行

如果任一元件無法在開機時啟動,檢閱事件記錄檔中是否有錯誤或在開機期間當機,可能會釘選問題。 使用 MSCONFIG 開機並使用選擇性或診斷啟動選項,將會消除和/或識別來自其他應用程式的可能干擾。

  • get-process -name shellexperiencehost
    
  • get-process -name searchui
    

如果已安裝但未執行,請測試開機進入安全模式,或使用 MSCONFIG 來排除第三方或其他驅動程式和應用程式。

檢查系統是否為全新安裝或升級

  • 此系統是升級還是全新安裝?
    • 執行 test-path "$env:windir\panther\miglog.xml"
    • 如果該檔案不存在,系統會是全新安裝。
  • 您可以執行 來找到升級問題 test-path "$env:windir\panther\miglog.xml"

檢查 Start 是否已註冊或啟用

  • 將下列事件記錄檔匯出至 CSV,並在文字編輯器或電子表格中執行關鍵字搜尋:
    • Microsoft-Windows-TWinUI/Operational for Microsoft.Windows.ShellExperienceHost 或 Microsoft.Windows.Cortana
      • 「找不到套件」
      • 「登錄的值無效」
      • 「找不到元素」
      • 「無法註冊套件」

如果找到這些事件,則啟動未正確啟動。 每個事件在描述中都會有更多詳細數據,而且應該進一步調查。 事件訊息可能會有所不同。

其他要考慮的事項

問題何時開始?

  • 觸發 [開始] 功能表失敗的常見問題
    • 更新之後
    • 安裝應用程式之後
    • 加入網域或套用網域原則之後
  • 許多這類問題都發現為
    • 登錄機碼或資料夾的許可權變更
    • 啟動或相關元件當機或停止回應
    • 自訂失敗

若要進一步縮小問題範圍,最好注意:

  • 什麼是安裝背景?

    • 這是部署,是否從媒體安裝,其他
    • 使用自訂嗎?
      • DISM
      • 群組原則 或 MDM
      • copyprofile
      • Sysprep
      • 其他
  • 已加入網域

    • 將存取權或許可權限制在資料夾或登錄機碼的組策略設定,可能會導致啟動效能發生問題。
    • 某些適用於 Windows 7 或更舊版本的組策略已知會造成 Start 問題
    • 未測試的 [開始] 功能表自定義通常不會完成 [開始] 失敗,而導致非預期的行為。
  • 環境是否已虛擬化?

    • Vmware
    • Citrix
    • 其他

檢查記錄開始問題的事件記錄檔:

  • 系統事件記錄檔

  • 應用程式事件記錄檔

  • Microsoft/Windows/Shell-Core*

  • Microsoft/Windows/Apps/

  • Microsoft-Windows-TWinUI*

  • Microsoft/Windows/AppReadiness*

  • Microsoft/Windows/AppXDeployment*

  • Microsoft-Windows-PushNotification-Platform/Operational

  • Microsoft-Windows-CoreApplication/Operational

  • Microsoft-Windows-ShellCommon-StartLayoutPopulation*

  • Microsoft-Windows-CloudStore*

  • 檢查可能與啟動 (explorer.exe、任務欄等相關的損毀)

    • 應用程式記錄事件 1000、1001
    • 檢查 WER 報告
      • C:\ProgramData\Microsoft\Windows\WER\ReportArchive\
      • C:\ProgramData\Micrt\Windowsosof\WER\ReportQueue\

如果 Start 的元件持續損毀,請擷取可由 Microsoft 支援服務 檢閱的傾印。

常見錯誤和緩和措施

下列清單提供您可能使用 [開始] 功能表遇到之常見錯誤的相關信息,以及協助您減輕這些錯誤的步驟。

徵兆:使用 Office API 且已安裝 Office 隨選即用的應用程式,可能會導致 [開始] 功能表和其他殼層元件失敗

您可能會在執行 Office 隨選即用的裝置上遇到與 Windows Shell 相關的各種問題,以及一些使用 Office API 的第三方應用程式:

  • 事件 1000 會記錄在應用程式事件記錄檔中。 事件記錄檔會報告 StartMenuExperienceHost.exe、ShellExperienceHost.exe、SearchUI.exe 的應用程式損毀,錯誤碼0xc000027b / -1073741189。

  • Microsoft-Windows-AppModel-State 事件記錄檔中的錯誤,其中提及具有各種套件名稱的下列錯誤:

    已觸發狀態位置的修復,因為對套件進行設定初始化作業Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy發生錯誤 -2147024891。

  • Windows [開始] 選單不會響應滑鼠點選或 Windows 鍵。

  • Windows 搜尋不會回應按下 [搜尋] 按鈕或 Windows+S 鍵時的滑鼠按鍵。

原因

受影響的裝置可能會有損毀的登錄機碼或數據,這可能會影響使用 Microsoft Office API 與 Windows、Microsoft Office、Microsoft Outlook 或 Outlook 行事曆 整合的應用程式。 如果從下列登入路徑移除應用程式套件許可權,就可能發生這種情況:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

因應措施

注意事項

Barco 回報已修正此問題,從其應用程式 4.27.2 版開始。 不過,受影響的裝置可能需要遵循因應措施一節中所述的步驟。

如需詳細資訊,請參閱 ClickShare 應用程式行事曆整合的無回應 Windows 任務列或使用者殼層資料夾許可權問題

若要因應此問題,請遵循下列步驟:

  1. 下載 腳本 以在發生問題時修正問題,但腳本無法防止問題重新發生。

  2. 在受影響的使用者身分識別下開啟 Powershell 提示字元,然後執行

.\FixUserShellFolderPermissions.ps1
  • 如果文稿因為已抹除登錄許可權而無法存取登錄機碼,請開啟提升許可權的 Powershell 提示字元並執行下列命令:

    • FixUserShellFolderPermissions.ps1 -allprofiles
      
  • 如果應用程式無法運作,您可能需要從受影響的使用者執行 命令來註冊殼層套件

    • FixUserShellFolderPermissions.ps1 -register
      

防止問題重複發生

  • 確定 ClickShare 應用程式已更新為 4.27.2 版或更新版本。
  • 確定已停用行事曆整合 (從 4.27.2 版起預設停用) 。
  • 防止應用程式在啟動時執行,或將應用程式設定為隨選啟動。

狀態

Microsoft 已瞭解此問題,並致力於在即將推出的 Office 更新中解決此問題。 當本文可供使用時,我們會在本文中張貼更多資訊。

徵兆:開始功能表不會在 Windows 2012 R2、Windows 10 或 Windows 2016 上回應

原因

未啟動背景工作基礎結構服務 (BrokerInfrastructure) 服務。

解決方案

確定背景工作基礎結構服務已設定為在 Services MMC 中自動啟動。

如果背景工作基礎結構服務無法啟動,請確認 Power Dependency Coordinator Driver (PDC) 驅動程式和登錄機碼未停用或刪除。 如果遺失,請從備份或安裝媒體還原。

若要驗證 PDC 服務,請 C:\>sc query pdc 在命令提示字元中執行 。 結果會如下所示:

SERVICE_NAME: pdc
TYPE          : 1 KERNEL_DRIVER
STATE          : 4 RUNNING
  (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE     : 0 (0x0)
SERVICE_EXIT_CODE    : 0 (0x0)
CHECKPOINT       : 0x0
WAIT_HINT        : 0x0

PDC 服務會使用位於 %WinDir%\system32\drivers 的 pdc.sys

PDC 登入機碼為:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pdc Description=“@%SystemRoot%\system32\drivers\pdc.sys,-101” DisplayName=“@%SystemRoot%\system32\drivers\pdc.sys,-100” ErrorControl=dword:00000003 Group=“開機總線擴充項” ImagePath=hex (2) :73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,
72,00,69,00,76,00,65,00,72,00,73,00,5c,00,70,00,64,00,63,00,2e,00,73,00,79,
00,73,00,00,00
Start=dword:000000000
Type=dword:00000001

除了列出的服務相依性之外,背景工作基礎結構服務還需要載入 Power Dependency Coordinator Driver。 如果 PDC 未在開機時載入,背景工作基礎結構服務將會失敗並影響 [開始] 選單。

PDC 和背景工作基礎結構服務的事件都會記錄在事件記錄檔中。 PDC 不應停用或刪除。 BrokerInfrastructure 是自動服務。 所有執行中的操作系統都需要此服務,才能有穩定的 [開始] 功能表。

注意事項

當機器執行 (C:\windows\system32\svchost.exe -k DcomLaunch -p) 時,您無法停止此自動服務。

徵兆:從 1511 版升級至 1607 版 Windows 之後,群組原則[從開始功能表移除所有程式] 清單可能無法運作

原因

Windows 10 版本 1511 與 1607 之間的 [所有應用程式] 清單有所變更。 這些變更表示原始 群組原則和對應的登錄機碼不再適用。

解決方案

此問題已在 2017 年 6 月的更新中解決。 將 Windows 10 1607 版更新為最新的累積或功能更新。

注意事項

啟用 群組原則 時,也必須選取所需的行為。 根據預設,它會設定為 [無]

徵兆:[開始] 功能表中遺漏 [警示]、[計算機] 和 [Edge] 等應用程式磚,且在刪除本機使用者配置檔時,無法在 Windows 10 版本 1709 上開啟 [設定] 應用程式

在應用程式磚和遺漏應用程式磚上顯示下載圖示的螢幕快照。

原因

此問題已知。 未偵測到第一次登入體驗,也不會觸發某些應用程式的安裝。

解決方案

此問題已針對 KB 4089848 2018 年 3 月 22 日 Windows 10 1709 版 —KB4089848 (OS 組建 16299.334)

徵兆:嘗試自定義 [開始] 功能表配置時,不會套用自定義專案,或預期不會產生結果

原因

此問題有兩個主要原因:

  • 格式不正確:新增額外的空間或空格、輸入不正確的字元,或以錯誤的格式儲存,不正確地編輯 xml 檔案。

    • 若要判斷格式是否不正確,請在 “Applications and Services\Microsoft\Windows\ShellCommon-StartLayoutPopulation\Operational” 記錄中檢查 「事件標識符:22」。
    • 當 xml 格式不正確時會記錄事件標識碼 22,這表示指定的檔案只是無效的 xml。
    • 編輯 xml 檔案時,應該以 UTF-8 格式儲存。
  • 未預期的信息:當您可能嘗試透過未預期或未記載的方法來新增磚時,就會發生這種情況。

    • 當 xml 有效但具有非預期的值時,會記錄 「事件標識碼:64」。
    • 例如:剖析設定 xml 檔案時發生下列錯誤:

      元素 '{' 上的屬性 'http://schemas.microsoft.com/Start/2014/LayoutModification}DefaultLayoutOverrideLayoutCustomizationRestrictiontype' 未定義於 DTD/架構中。

XML 檔案可以在 Hyper-V 或其他虛擬機上本機測試,然後再透過 群組原則

徵兆:在計算機於啟動期間使用 F12 重新整理之後,[開始] 功能表就無法再運作

描述

如果使用者遇到計算機的問題,可以重新整理、重設或還原計算機。 重新整理計算機是一個實用的選項,因為它會維護個人檔案和設定。 當使用者無法啟動電腦時,無法存取 [設定] 中的 [變更計算機設定]。 因此,若要存取系統重新整理,用戶可以在啟動時使用 F12 金鑰。 重新整理電腦完成,但無法存取 [開始] 功能表。

原因

此問題已知且已在 2018 年 8 月 30 日發行的累積更新中解決。

解決方案

安裝更正更新;修正程式包含在 2018 年 9 月 11 日KB4457142版中。

徵兆:[開始] 功能表中遺漏 [所有應用程式] 清單

原因

已啟用 [從開始] 功能表移除所有程式清單 群組原則。

解決方案

停用 [從開始] 功能表移除所有程式清單 群組原則。

徵兆:使用 Windows 10、版本 1703 或更舊版本、Windows Server 2016,以及具有 [開始] 配置的漫遊使用者策略檔時,[開始] 功能表中遺漏圖格

描述

Windows 10 中有兩個不同的 [開始] 功能表問題:

  • 系統管理員在開始配置中設定的磚無法漫遊。
  • 用戶起始的開頭版面配置變更不會漫遊。

具體而言,行為包括

  • (釘選到 [開始] 功能表的應用程式或圖示) 遺失。
  • 整個磚視窗消失。
  • [開始] 按鈕無法回應。
  • 如果建立新的漫遊使用者,第一次登入會正常顯示,但在後續的登入時,會遺失磚。

工作配置範例的螢幕快照。

新漫遊使用者配置檔第一次登入時的工作配置

失敗版面配置範例的螢幕快照。

後續登入時配置失敗

原因

在本機從漫遊使用者策略檔提取數據之前,[開始] 功能表已就緒,就會發生計時問題。 問題不會發生在新漫遊使用者的第一次登入,因為程式代碼路徑不同且速度較慢。

解決方案

自 2017 年 3 月起,Windows 10 1703 和 1607 版累積更新中已解決此問題。

徵兆:升級至 Windows 10 版本 1703 之後,[開始] 功能表配置自定義專案會遺失

描述

升級之前:

已套用自定義專案的 [開始] 畫面範例螢幕快照。

注意事項

在螢幕快照中, 公司應用程式公用程式 會受到組策略控制,而且這些專案底下的磚是使用者釘選的。

升級之後,使用者釘選的磚遺失:

[開始] 畫面範例的螢幕快照,其中遺漏先前釘選的磚。

此外,如果嘗試在沒有網路連線的情況下登入,使用者可能會看到空白磚。

空白磚範例的螢幕快照。

解決方案

此問題已在 2017 年 10 月更新中修正。

徵兆:從 Windows 10 版本 1607 升級至版本 1709 之後,針對已啟用 RU) P (RUP (使用者策略文件的使用者,以及已啟用部分鎖定的受控 [開始] 功能表配置,會遺失磚

解決方案

使用者登入之前,2018 年 4 月 LCU 必須套用至 Windows 10 1709 版。

徵兆:如果在 Sysprep 期間於響應檔案中使用 CopyProfile 選項,則不會套用 [開始] 功能表和/或任務欄配置自定義

解決方案

嘗試使用 layoutmodification.xml 自定義 [開始] 功能表或任務欄時,不再支援 CopyProfile。

徵兆:磚數據層損毀的開始功能表問題

原因

Windows 10,版本 1507 到版本 1607 會使用資料庫來取得磚影像資訊。 這稱為磚數據層資料庫。 (功能在 Windows 10 1703.) 中已被取代

解決方案

您可以採取一些步驟來修正圖示,首先是確認是需要解決的問題。

  1. 當您選取磚時,應用程式或應用程式可以正常運作。
  2. 磚是空白的、具有泛型佔位元圖示、具有錯誤或奇怪的標題資訊。
  3. 應用程式遺失,但列為透過PowerShell安裝,且可在您透過URI啟動時運作。
    • 範例:windows-feedback://
  4. 在某些情況下,Start 可以是空白的,而且控制中心和 Cortana 不會啟動。

注意事項

損毀復原會從 [開始] 移除任何手動釘選。 應用程式應該仍然可見,但您必須將任何次要磚和/或釘選應用程式磚重新釘選到主要的 [開始] 檢視。 不過,您已安裝且完全遺失「所有應用程式」的 Aps 是非預期的。 這表示重新註冊無法運作。

開啟命令提示字元,然後執行下列命令:

C:\Windows\System32\tdlrecover.exe -reregister -resetlayout -resetcache

雖然不需要重新啟動,但在執行命令之後,它可能有助於清除任何殘差問題。

徵兆:安裝 Symantec Endpoint Protection 之後,[開始] 功能表和應用程式無法在升級至 Windows 10 1809 版之後啟動

描述

將執行 Windows 7 且已安裝 Symantec Endpoint Protection 的電腦升級至 Windows 10 1809 版之後,不會啟動 [開始] 功能表、搜尋和應用程式。

原因

發生此問題的原因是無法載入 sysfer.dll。 在升級期間,安裝程式不會在 sysfer.dll 和其他 Symantec 模組上設定許可權群組「所有應用程式套件」。

解決方案

此問題已由 2018 年 12 月 5 日發行的 Windows 累積更新修正,KB4469342 (操作系统组建 17763.168) 。

如果您已經遇到此問題,請使用下列兩個選項之一來修正此問題:

選項 1:從 system32 檔 夾移除sysfer.dll並複製回來。 Windows 會自動設定許可權。

選項 2:

  1. 找出 目錄 C:\Windows\system32
  2. 以滑鼠右鍵按兩下 [sysfer.dll ],然後選擇 [ 屬性]
  3. 切換至 [ 安全性] 索引 標籤。
  4. 確認遺漏 [所有應用程式套件 ] 群組。
  5. 選取 [編輯],然後選取 [新增 ] 以新增群組。
  6. 測試開始和其他應用程式。

協力廠商資訊免責聲明

本文提及的協力廠商產品是由與 Microsoft 無關的獨立廠商所製造。 Microsoft 不以默示或其他方式,提供與這些產品的效能或可靠性有關的擔保。