共用方式為

針對適用於Linux的 Windows 子系統進行疑難解答

我們已涵蓋下列與 WSL 相關聯的一些常見疑難解答案例，但請考慮在 GitHub 上搜尋 WSL 產品存放庫中提出的問題。

提出問題、錯誤報告、功能要求

WSL 產品存放庫問題 能夠讓您：

  • 搜尋現有問題，以查看是否有與您遇到的問題相關聯。

    請注意，在搜尋列中，您可以移除 “state:open”，以包含已在搜尋中解決的問題。

    請考慮在任何您希望優先推進的公開問題上發表評論或按讚，以表達您的興趣。

  • 提出新問題。 如果您發現 WSL 有問題，而且目前沒有問題，您可以選取綠色的 “New issue” 按鈕，然後選擇 []。WSL - Bug Report

    您需要提供以下資訊：

    • 問題標題
    • Windows 版本：請執行 cmd.exe /c ver 以取得您所開啟的 Windows 組建。
    • WSL 版本：如果您是從 Microsoft 市集執行適用於 Linux 的 Windows 子系統，請執行 wsl.exe -v。
    • 您是否使用 WSL 1 或 WSL 2：告訴我們問題是否在 WSL 2 和/或 WSL 1 上。 您可以藉由執行 wsl.exe -l -v來判斷。
    • 核心版本：請告訴我們您所使用的Linux核心版本，或使用自定義核心。 如果此指令可供您使用，或是在散發套件中執行，您可以 wsl.exe --status 執行 cat /proc/version 。
    • 散發版本：請告訴我們您所使用的散發版本（如果適用）。 您可以盡可能取得版本的其他資訊，例如在 Debian / Ubuntu 上。 run lsb_release -r
    • 其他軟體：如果您回報的 Bug 涉及 WSL 與其他應用程式的互動，請告訴我們。 哪些應用程式？ 哪些版本？
    • 重現步驟：請列出重現 Bug 的步驟。
    • 預期的行為：您預期會看到什麼？ 包含任何相關的範例或文件連結。
    • 實際行為：發生什麼事？
    • 診斷記錄：如有需要，請提供其他診斷。 如需如何收集意見反應中樞記錄、網路記錄等資訊，請參閱指引。

    如需詳細資訊，請參閱 參與 WSL。

  • 選取綠色的 “” 按鈕，然後選取 “New issue”，以Feature request。

    您需要回答幾個描述您的要求的問題。

您也可以：

安裝問題

  • 安裝失敗，發生錯誤0x80070003

    • 適用於 Linux 的 Windows 子系統只會在系統磁碟驅動器上執行（通常是您的 C: 磁碟驅動器）。 請確定發行版儲存在您的系統磁碟上：
    • 在 Windows 10 上開啟 設定 ->系統 ->記憶體 ->更多記憶體設定： 變更儲存新內容的位置，系統設定圖片以在 C： 磁碟驅動器上安裝應用程式 （Windows 10）
    • 在 Windows 11 上開啟 設定 ->系統 ->儲存器 ->進階記憶體設定 ->儲存新內容系統設定圖片，以在 C： 磁碟驅動器上安裝應用程式 （Windows 11）

  • WslRegisterDistribution 失敗，錯誤0x8007019e

    • 未啟用適用於 Linux 的 Windows 子系統選用元件：
    • 開啟 [控制面板->程式和功能 ->開啟或關閉 Windows 功能 -> 檢查適用於 Linux 的 Windows 子系統，或使用步驟 1 中所述的 PowerShell Cmdlet。

  • 安裝失敗，錯誤0x80070003或錯誤0x80370102

    • 請確定您的電腦 BIOS 內已啟用虛擬化。 如何執行這項操作的指示會因每台計算機而有所不同，而且很可能在 CPU 相關選項中。
    • WSL2 需要您的 CPU 支援第二層地址轉換 （SLAT） 功能，此功能是在 Intel Nehalem 處理器 （Intel Core 1st Generation） 和 AMD Opteron 中引進的。 舊版 CPU（例如 Intel Core 2 Duo）將無法執行 WSL2，即使虛擬機器平臺已成功安裝也一樣。

  • 嘗試升級時發生錯誤，無效的命令列選項： wsl --set-version Ubuntu 2

    • 請確定您已啟用適用於Linux的 Windows 子系統，而且您使用的是 Windows 組建版本 18362 或更新版本。 若要在具有系統管理員許可權的 PowerShell 提示字元中啟用 WSL，請執行此命令：

      Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

  • 因為虛擬磁碟系統限制，所以無法完成要求的作業。 虛擬硬碟檔案必須未壓縮、未加密且非稀疏。

    • 開啟 Linux 發行版的設定檔資料夾，以取消選取 [壓縮內容] （以及核取 [加密內容]。 它應該位於 Windows 檔案系統上的資料夾中，例如：%LocalAppData%\Packages\CanonicalGroupLimited...
    • 在此 Linux 散發套件設定檔中，應該會有 LocalState 資料夾。 以滑鼠右鍵按下此資料夾以顯示選項選單。 選取 [屬性>進階 ]，然後確定 [壓縮內容以節省磁碟空間] 和 [加密內容以保護資料] 複選框未選取（未核取）。 如果系統詢問要將此套用至目前資料夾或所有子資料夾和檔案，請選取 [僅此資料夾]，因為您只會清除壓縮旗標。 在此之後，wsl --set-version 命令應該可以運作。

    WSL 發行版本屬性設定的螢幕快照

    注意

    在我的案例中，Ubuntu 18.04 發行版的LocalState資料夾位於 C:\Users\<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc

    查看 WSL Docs GitHub 討論串 #4103，以追蹤此問題並獲得更新資訊。

  • 'wsl' 一詞無法辨識為 Cmdlet、函式、腳本檔案或可作程序的名稱。

    • 請確定已安裝適用於 Linux 的 Windows 子系統 選用元件。 此外，如果您使用ARM64裝置並從PowerShell執行此命令，您會收到此錯誤。 請改為從 wsl.exe或命令提示字元執行 。

  • 錯誤：適用於Linux的 Windows 子系統沒有已安裝的發行版。

    • 如果您在已安裝 WSL 散發套件之後收到此錯誤：
    1. 在從命令列執行發行套件之前，請至少跑一次。
    2. 檢查您是否正在使用個別的用戶帳戶。 以提升許可權執行您的主要用戶帳戶（在管理員模式中）不應該產生此錯誤，但您應該確定您不會意外執行 Windows 隨附的內建系統管理員帳戶。 這是個別的使用者帳戶，根據設計不會顯示任何已安裝的 WSL 發行版。 如需詳細資訊，請參閱 啟用和停用內建系統管理員帳戶。
    3. WSL 可執行檔只會安裝到原生系統目錄。 當您在 64 位 Windows 上執行 32 位進程（或在 ARM64 上執行任何非原生組合），裝載的非原生進程實際上會看到不同的 System32 資料夾。 （x64 Windows 上看到的 32 位進程儲存在磁碟上，%SystemRoot%\SysWOW64。您可以透過查看虛擬資料夾，從託管進程存取 「原生」系統32： \Windows\sysnative。 它實際上不會出現在磁碟上，但文件系統路徑解析程式會發現它。

  • 錯誤：此更新僅適用於具有適用於Linux的 Windows 子系統的電腦。

    • 若要安裝 Linux 核心更新 MSI 套件，必須先啟用 WSL。 如果失敗，您會看到訊息：此更新僅適用於具有適用於Linux的Windows子系統的電腦。
    • 您看到此訊息有三個可能的原因：

    1. 您仍在舊版的 Windows 中，不支援 WSL 2。 請參閱 步驟 2 - 檢查執行 WSL 2 的需求。

    2. WSL 未啟用。 您必須返回 步驟 1 ，並確定電腦上已啟用選擇性 WSL 功能。

    3. 啟用 WSL 之後，需要重新啟動，才能生效、重新啟動電腦，然後再試一次。

  • 錯誤：WSL 2 需要更新其核心元件。 如需詳細資訊，請造訪 步驟 4

    • 如果資料夾中遺漏 %SystemRoot%\system32\lxss\tools Linux 核心套件，您將會遇到此錯誤。 在安裝指示 的步驟 4 中安裝 Linux 核心更新 MSI 套件來解決此問題。 您可能需要從 「新增或移除程式」卸載 MSI，然後再安裝一次。

常見問題

我在 Windows 10 版本 1903 上，我仍然看不到 WSL 2 的選項

這可能是因為您的計算機尚未取得 WSL 2 的反向移植。 若要解決此問題，最簡單的方式是移至 [Windows 設定 ]，然後按兩下 [檢查更新]，在您的系統上安裝最新的更新。 請參閱 取得backport的完整指示。

如果您按 「檢查更新」，但仍未收到更新，您可以 手動安裝 KB KB4566116。

錯誤：wsl --set-default-version 2 時0x1bc

當 [顯示語言] 或 [系統地區設定] 設定不是英文時，可能會發生這種情況。

PS C:\> wsl.exe --set-default-version 2
Error: 0x1bc
For information on key differences with WSL 2 please visit https://aka.ms/wsl2

的實際錯誤 0x1bc 是：WSL 2 需要更新其核心元件。 如需詳細資訊，請造訪 https://aka.ms/wsl2kernel

如需詳細資訊，請參閱問題 #5749

無法從 Windows 存取 WSL 檔案

9p 通訊協定檔伺服器提供 Linux 端的服務，以允許 Windows 存取 Linux 檔案系統。 如果您無法在 Windows 上使用 \\wsl$ 存取 WSL，可能是因為 9P 未正確啟動。

若要檢查此問題，您可以使用：dmesg | grep 9p來檢查啟動記錄，這會顯示任何錯誤。 成功的結果如下所示：

[    0.363323] 9p: Installing v9fs 9p2000 file system support
[    0.363336] FS-Cache: Netfs '9p' registered for caching
[    0.398989] 9pnet: Installing 9P2000 support

如需此問題的進一步討論，請參閱問題 #5307 。

無法啟動 WSL 2 發行版，輸出中只會看到「WSL 2」

如果您的顯示語言不是英文，您可能會看到錯誤文字的截斷版本。

PS C:\> wsl.exe
WSL 2

若要解決此問題，請參閱 步驟 4 ，並依照該文件頁面上的指示手動安裝核心。

在 Linux 中執行 Windows .exe 時的 command not found

使用者可以直接從Linux執行 windows 可執行檔，例如 notepad.exe。 有時候，您可能會遇到 "command not found" 的錯誤。

$ notepad.exe
-bash: notepad.exe: command not found

如果您的$PATH中沒有 Win32 路徑，Interop 就不會找到 .exe。 您可以在 Linux 中執行 echo $PATH 來驗證它。 預期您會在輸出中看到 Win32 路徑 （例如 ， /mnt/c/Windows）。 如果您看不到任何 Windows 路徑，則您的 PATH 很可能被 Linux 殼層覆寫。

以下是 Debian 上造成問題的範例 /etc/profile ：

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi

Debian 上的正確方式是移除上述幾行。 您也可以在如下的工作分派期間附加$PATH，但這會導致 WSL 和 VSCode.某些 其他問題。

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:$PATH"
fi

如需詳細資訊，請參閱問題 #5296 和問題 #5779。

「錯誤：0x80370102無法啟動虛擬機，因為未安裝必要的功能。

請啟用虛擬機平臺 Windows 功能，並確定 BIOS 中已啟用虛擬化。

  1. 檢查 Hyper-V 系統需求

  2. 如果您的機器是 VM，請手動啟用 巢狀虛擬化。 使用系統管理員啟動 powershell，然後執行下列命令，以主機系統上的虛擬機名稱取代 <VMName> （您可以在 Hyper-V Manager 中找到名稱）：

    Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

  3. 請遵循計算機製造商關於如何啟用虛擬化的指導方針。 一般而言，這可能需要使用系統 BIOS 來確保 CPU 上已啟用這些功能。 此程式的指示可能會因計算機而異，請參閱 在 Windows 上啟用虛擬化。

  4. 啟用 虛擬機平台選用元件之後，請重新啟動電腦。

  5. 請確定您的開機設定中已啟用 Hypervisor 啟動。 您可以執行提升權限的 Powershell 來驗證此問題：

    bcdedit /enum | findstr -i hypervisorlaunchtype

    如果您看到 hypervisorlaunchtype Off，則會停用 Hypervisor。 若要在提升權限的 PowerShell 中啟用它：

    bcdedit /set hypervisorlaunchtype Auto

  6. 此外，如果您已安裝第三方 Hypervisor（例如 VMware 或 VirtualBox），請確保您使用的版本是具有支援 HyperV 的最新版本（VMware 15.5.5+ 和 VirtualBox 6+），或者請將它們關閉。

  7. 如果您在 Azure 虛擬機上收到此錯誤，請檢查以確定已停用 信任啟動。 信任啟動的 Azure 虛擬機不支援巢狀虛擬化。

深入瞭解如何在虛擬機中執行 Hyper-V 時，設定巢狀虛擬化。

WSL 在我的工作機器或企業環境中沒有網路連線

商務或企業環境可能已設定 Windows Defender 防火牆設定 封鎖未經授權的網路流量。 如果 本機規則合併 設定為 「否」，則 WSL 網路功能預設將無法運作，而且您的系統管理員必須新增防火牆規則以允許它。

您可以遵循下列步驟來確認地方規則合併的設定：

Windows 防火牆設定螢幕快照

  1. 開啟 [具有進階安全性的 Windows Defender 防火牆] （這與控制面板中的 [Windows Defender 防火牆] 不同）
  2. 以滑鼠右鍵點擊 [本機計算機上具有進階安全性的 Windows Defender 防火牆] 標籤
  3. 選擇 [屬性]
  4. 在開啟的新視窗中選取 [公眾檔案] 索引標籤
  5. 在 [設定] 區段下選取 [自定義]
  6. 在開啟的 [公用個人檔案的自訂設定] 視窗中檢查，查看 [規則合併] 是否設定為 [否]。 這會封鎖對 WSL 的存取。

您可以在設定 Hyper-V 防火牆中找到如何變更此防火牆設定的指示。

停用 IPv6 時 WSL 沒有網路連線

如果使用登錄值 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters (REG_DWORD) DisabledComponents停用 IPv6，則 WSL 網路連線可能會失敗。 請參閱 在 Windows 中設定進階使用者 IPv6 的指引。

如果必須在主機系統上停用 IPv6，建議您直接移除 IPv6 通訊協定系結，以使用 Powershell 來執行此動作。 例如：Disable-NetAdapterBinding -Name "<MyAdapter>" -ComponentID ms_tcpip[6]。

一旦連線到 VPN，WSL 就沒有網路連線能力

如果在 Windows 上連線到 VPN 之後，bash 會失去網路連線能力，請從 bash 內嘗試此因應措施。 此因應措施可讓您透過 /etc/resolv.conf手動覆寫 DNS 解析。

  1. 請記下 VPN 的 DNS 伺服器，以執行下列動作：

    ipconfig.exe /all

  2. 建立現有 resolv.conf的複本：

    sudo cp /etc/resolv.conf /etc/resolv.conf.bak

  3. 取消連結目前的 resolv.conf：

    sudo unlink /etc/resolv.conf

  4. 請執行：

    sudo mv /etc/resolv.conf.bak /etc/resolv.conf

  5. 編輯 /etc/wsl.conf 並將此內容新增至檔案。 （如需此設定的詳細資訊，請參閱 進階設定設定）

    [network]
generateResolvConf=false

  6. 開啟 /etc/resolv.conf 和

    1. 從檔案中刪除第一行，其中包含描述自動產生之批注。
    2. 將上述的 DNS 專案新增為 DNS 伺服器清單中的第一個專案。
    3. 關閉檔案。

中斷 VPN 連線之後，您必須將變更還原為 /etc/resolv.conf。 若要這樣做，請執行：

sudo mv /etc/resolv.conf /etc/resolv.conf.bak
sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

與 WSL 相關的 Global Secure Access Client 問題

全域安全存取用戶端（/entra/global-secure-access/how-to-install-windows-client）可能會影響 WSL 連線能力，因為它具有在解析名稱時傳回暫時位址的功能。 然後，當建立網路連線時，位址會交換至實際位址。 這可能會中斷 WSL，因為 WSL 流量轉送至大部分 GSA 用戶端勾點下方。

建議您停用 DNS 通道 （dnsTunneling=false） 或停用鏡像模式 （networkingMode=nat）。

Cisco Anyconnect NAT 模式中 WSL 的 VPN 問題

Cisco AnyConnect VPN 會以防止 NAT 運作的方式修改路由。 WSL 2 有特定的解決方法：請參閱 Cisco AnyConnect Secure Mobility Client Administrator Guide，Version 4.10 - 針對 AnyConnect進行疑難解答。

鏡像網路模式開啟時，VPN 的 WSL 連線問題

鏡像網路模式目前是 WSL 組態 中的實驗性設定。 WSL 的傳統NAT網路架構可以更新為稱為「鏡像網路模式」的全新網路模式。 當實驗性 networkingMode 設定為 mirrored時，您在 Windows 上的網路介面會複製到 Linux，以提高相容性。 在命令列部落格中深入了解更多訊息：WSL 2023 年 9 月更新。

某些 VPN 已經過測試並確認與 WSL 不相容，包括：

  • “Bitdefender” 26.0.2.1 版
  • “OpenVPN” 2.6.501 版
  • “Mcafee Safe Connect” 2.16.1.124 版

在 WSL 中使用 autoProxy 進行 HttpProxy 鏡像處理時的考量

您可以使用 WSL 組態檔 autoProxy實驗區段中的 設定來設定 HTTP/S Proxy 鏡像。 套用此設定時，請注意下列考慮：

  • PAC Proxy：WSL 會藉由設定環境變數來設定Linux中的 WSL_PAC_URL 設定。 Linux 預設不支援 PAC Proxy。
  • 與 WSLENV 的互動：使用者定義的環境變數優先於此功能所指定的環境變數。

啟用時，下列內容會套用至 Linux 發行版上的 Proxy 設定：

  • Linux 環境變數 HTTP_PROXY會設定為 Windows HTTP Proxy 組態中所安裝的一或多個 HTTP Proxy。
  • Linux 環境變數 HTTPS_PROXY會設定為 Windows HTTPS Proxy 設定中所安裝的一或多個 HTTPS Proxy。
  • Linux 環境變數 NO_PROXY會設定為略過 Windows 組態目標中找到的任何 HTTP/S Proxy。
  • 除了 WSL_PAC_URL之外，每個環境變數都會設定為小寫和大寫。 例如：HTTP_PROXY 與 http_proxy。

ZScaler 設定會造成已知問題，其中 ZScaler 會重複啟用和停用 Windows Proxy 設定，導致 WSL 重複顯示「主機上偵測到 Http Proxy 變更」通知。

在命令列部落格中深入了解更多訊息：WSL 2023 年 9 月更新。

DNS 隧道的網路考量

當 WSL 無法連線到因特網時，可能是因為 Windows 主機的 DNS 呼叫遭到封鎖。 這是因為 WSL VM 傳送至 Windows 主機的 DNS 網路封包遭到現有網路設定封鎖。 DNS 通道修正此問題，方法是使用虛擬化功能直接與 Windows 通訊，以允許解析 DNS 名稱而不傳送網路封包。 這項功能應改善網路相容性，並可讓您取得更好的因特網連線能力，即使您有 VPN、特定防火牆設定或其他網路設定。

您可以使用 WSL 組態檔 dnsTunneling實驗區段中的 設定來設定 DNS 通道。 套用此設定時，請注意下列考慮：

  • 如果您使用 VPN 搭配 WSL，請開啟 DNS 通道。 許多 VPN 會使用 NRPT 原則，這些原則只會在啟用 DNS 通道時套用至 WSL DNS 查詢。
  • Linux 發行版中的 /etc/resolv.conf 檔案有 3 部 DNS 伺服器的最大限制，而 Windows 可能會使用超過 3 部 DNS 伺服器。 使用 DNS 通道可移除這項限制 – Linux 現在可以使用所有 Windows DNS 伺服器。
  • WSL 會依下列順序使用 Windows DNS 後綴（類似於 Windows DNS 用戶端所使用的順序）：
    1. 全域 DNS 後綴
    2. 補充的 DNS 後綴
    3. 個別介面 DNS 後綴
    4. 如果在 Windows 上啟用 DNS 加密 （DoH，DoT），加密將會套用至來自 WSL 的 DNS 查詢。 如果使用者想要在Linux內啟用DoH、DoT，則必須停用 DNS 通道。
  • 來自 Docker Desktop 所管理 Docker 容器的 DNS 查詢將會略過 DNS 通道。 Docker Desktop 有它自己的方式（不同於 DNS 通道），將主機 DNS 設定和原則套用至來自 Docker 容器的 DNS 查詢。
  • 為了讓 DNS 通道能夠成功啟用，不應該停用 wsl.conf 檔案中的 generateResolvConf 選項。
  • 啟用 DNS 信道時， generateHosts 會忽略 wsl.conf 檔案中的選項（Linux /etc/hosts 檔案中不會複製 Windows DNS 主機檔案）。 Windows 主機檔案中的原則會套用至來自 Linux 的 DNS 查詢，而不需要在 Linux 中複製檔案。

在命令列部落格中深入了解更多訊息：WSL 2023 年 9 月更新。

將 Windows 主機接收到的入站流量引導至 WSL 虛擬機所面臨的挑戰

使用鏡像網路模式時（實驗性 networkingMode 設定為 mirrored），Windows 主機收到的一些輸入流量永遠不會導向 Linux VM。 此流量如下所示：

  • UDP 連接埠 68 （DHCP）
  • TCP 連接埠 135 （DCE 連接點解析）
  • TCP 連接埠 1900 （UPnP）
  • TCP 連接埠 2869 （SSDP）
  • TCP 連接埠 5004 （RTP）
  • TCP 連接埠 3702 （WSD）
  • TCP 連接埠 5357 （WSD）
  • TCP 連接埠 5358 （WSD）

WSL 會在使用鏡像網路模式時自動設定特定的 Linux 網路設定。 使用鏡像網路模式時，不支援任何用戶對這些設定的配置。 以下是 WSL 將設定的設定清單：

設定名稱 價值
https://sysctl-explorer.net/net/ipv4/accept_local/ 已開啟 （1）
https://sysctl-explorer.net/net/ipv4/route_localnet/ 已開啟 （1）
https://sysctl-explorer.net/net/ipv4/rp_filter/ 已停用（0）
https://sysctl-explorer.net/net/ipv6/accept_ra/ 已停用（0）
https://sysctl-explorer.net/net/ipv6/autoconf/ 已停用（0）
https://sysctl-explorer.net/net/ipv6/use_tempaddr/ 已停用（0）
地址生成模式 已停用（0）
關閉IPv6 (disable_ipv6) 已停用（0）
https://sysctl-explorer.net/net/ipv4/arp_filter/ 已開啟 （1）

啟用鏡像網路模式並在預設網路命名空間下執行的 WSL2 Docker 容器問題

有一個已知問題，即無法建立具有已發佈埠的 Docker Desktop 容器（docker run –publish/–p） 。 WSL 小組正與 Docker Desktop 小組合作，以解決此問題。 若要解決此問題，請在 Docker 容器中使用主機的網路命名空間。 透過 --network host 命令中使用的 docker run 選項來設定網路類型。 替代的因應措施是在 WSL 組態檔 ignoredPorts實驗性區段的 設定中列出已發佈的通訊埠號碼。

當 Network Manager 正在運行時，Docker 容器出現問題

Docker 容器執行網路管理員服務時發生已知問題。 症狀包括在嘗試與主機建立回送連線時的失敗。 建議停止網路管理員服務，讓 WSL 網路設定正確。

sudo systemctl disable network-manager.service

解析 WSL 中的 .local 名稱

若要將主機名解析為局域網路內的IP位址，而不需要傳統的 DNS 伺服器，通常會使用 .local 名稱。 這是透過 mDNS（多播 DNS） 通訊協定來達成，該通訊協議依賴多播流量運作。

networkingMode 設定為 NAT：

目前，啟用 DNS 通道時不支援此功能。 若要啟用 .local 名稱的解析，建議您使用下列解決方案：

  • 停用 DNS 通道。
  • 使用鏡像網路模式。

networkingMode 設定為 Mirrored：

注意：您必須在 WSL 組建 2.3.17 或更高版本上，才能具備下列功能。

由於鏡像模式支援多播流量，因此 mDNS （多播 DNS） 通訊協定可用來解析 .local 名稱。 Linux 必須設定為支援 mDNS，因為它預設不會這麼做。 設定它的其中一種方式是使用下列兩個步驟：

  1. 安裝 libnss-mdns 套件

    sudo apt-get install libnss-mdns

    *套件 libnss-mdns 是 GNU C 連結庫 （glibc） 之 GNU 名稱服務交換器 （NSS） 功能的外掛程式，可透過多播 DNS （mDNS） 提供主機名解析。 此套件能有效讓一般 Unix/Linux 程式在隨選的 mDNS 網域 .local 中解析名稱。

  2. 配置檔案/etc/nsswitch.conf以啟用 區段中的mdns_minimalhosts設定。 檔案的範例內容：

    />cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat systemd
group:          compat systemd
shadow:         compat
gshadow:        files

hosts:          files mdns_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

WSL 中的 DNS 後綴

根據 .wslconfig 檔案中的組態，WSL 將會依據 DNS 後綴的不同，展現以下處理方式：

當 設定為 networkingMode時NAT：

案例 1：Linux 中預設不會設定 DNS 後綴

案例 2：如果已啟用 DNS 通道（dnsTunneling在 .wslconfig 中設定為 true ）所有 Windows DNS 後綴都會在 Linux 中設定，在 /etc/resolv.conf 的設定中search

後綴會依下列順序以 /etc/resolv.conf 進行設定，類似於 Windows DNS 用戶端在解析名稱時嘗試後綴的順序：先全域 DNS 後綴，再補充 DNS 後綴，再依介面 DNS 後綴。

當 Windows DNS 後綴有所變更時，該變更會自動反映在 Linux 中

案例 3：如果 DNS 通道已停用，且已停用 SharedAccess DNS Proxy（dnsTunneling 且 dnsProxy 在 .wslconfig 中設定為 false ）。 在 Linux 中設定單一 DNS 後綴，在 /etc/resolv.conf 的 「網域」設定中

當 Windows DNS 後綴有變更時，該變更不會反映在 Linux 中

在 Linux 中設定的單一 DNS 後綴是從個別介面 DNS 後綴中選擇的 （會忽略全域和補充後綴）

如果 Windows 有多個介面，則會使用啟發學習法來選擇將在 Linux 中設定的單一 DNS 後綴。 例如，如果 Windows 上有 VPN 介面，則會從該介面選擇後綴。 如果沒有 VPN 介面，則會從最有可能提供因特網連線的介面中選擇後綴。

當 設定為 networkingMode時Mirrored：

所有 Windows DNS 後綴都是在 Linux 中設定的 /etc/resolv.conf 設定中search

後綴是在 /etc/resolv.conf 中設定，並且順序與 NAT 模式中的案例 2 相同。

當 Windows DNS 後綴有所變更時，該變更會自動反映在 Linux 中

注意

補充 DNS 後綴可以在 Windows 中使用 來設定。

SetInterfaceDnsSettings 函式 （netioapi.h），並在 參數中DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST設定旗標Settings。

WSL 中 DNS 的疑難排解

WSL 在 NAT 模式中啟動容器時的預設 DNS 設定是讓 Windows 主機上的 NAT 裝置做為 WSL 容器的 DNS「伺服器」。 當 DNS 查詢從 WSL 容器傳送至 Windows 主機上的 NAT 裝置時，DNS 封包會從 NAT 裝置轉送至主機上的共用存取服務;回應會以反向方向傳送回 WSL 容器。 此封包轉送至共用存取的過程需要一個防火牆規則，以允許該輸入的 DNS 封包，該封包是當 WSL 最初要求 HNS 為其 WSL 容器建立 NAT 虛擬網路時，由 HNS 服務建立的。

由於此 NAT - 共用存取設計，有幾個已知設定可能會中斷 WSL 的名稱解析。

  1. 企業可以推送不允許本機定義的防火牆規則的原則，只允許企業原則定義的規則。

    當企業設定此規則時，會忽略 HNS 建立的防火牆規則，因為它是本機定義的規則。

    若要讓此組態運作，企業必須建立防火牆規則，以允許UDP埠53到共用存取服務，或WSL可以設定為使用 DNS 通道。

    您可以執行下列命令，確認是否設定為不允許本機定義的防火牆規則。 請注意，這會顯示所有 3 個配置檔的設定：網域、私人和公用。 如果在任何配置檔上設定，則如果 WSL vNIC 指派該配置檔，封包將會遭到封鎖（預設值為 Public）。 這隻是 Powershell 中傳回之第一個防火牆配置檔的代碼段：

    PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name                    : Domain
Enabled                 : True
DefaultInboundAction    : Block
DefaultOutboundAction   : Allow
AllowInboundRules       : True
AllowLocalFirewallRules : False
...

    AllowLocalFirewallRules: False 表示本機定義的防火牆規則，就像 HNS 一樣，將不會套用或使用。

  2. 而企業可以向下推送封鎖所有輸入規則的組策略和 MDM 原則設定。

    這些設定會覆寫任何 Allow-Inbound 防火牆規則。 因此，此設定會封鎖 HNS 建立的 UDP 防火牆規則，因此會防止 WSL 解析名稱。

    若要讓此設定能夠運作，WSL 必須設定為使用 DNS 通道。 此設定一律會封鎖 NAT DNS Proxy。

    來自組策略：

    計算機設定 \ 系統管理範本 \ 網络 \ 網络連線 \ Windows Defender 防火牆 \ 網域配置檔 |標準配置檔

    「Windows Defender 防火牆：不允許例外狀況」- 已啟用

    從 MDM 原則 ：

    ./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/Shielded

    ./Vendor/MSFT/Firewall/MdmStore/DomainProfile/Shielded

    ./Vendor/MSFT/Firewall/MdmStore/PublicProfile/Shielded

    您可以執行下列命令來查看這是否設定為不允許任何輸入防火牆規則（請參閱上述防火牆配置檔注意事項）。 這隻是 Powershell 中傳回之第一個防火牆配置檔的代碼段：

    
PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name                  : Domain
Enabled               : True
DefaultInboundAction  : Block
DefaultOutboundAction : Allow
AllowInboundRules     : False
...

    AllowInboundRules: False 表示不會套用任何輸入防火牆規則。

  3. 用戶通過 Windows 安全性設定應用程式，並檢查控制件是否有「封鎖所有連入連線，包括允許應用程式清單中的連線」。

    Windows 支援使用者選擇啟用與上述第2點所參考的企業版相同的設定。 用戶可以開啟 [Windows 安全性] 設定頁面、選取 [防火牆與網络保護] 選項、選取他們想要設定的防火牆配置檔（網域、私人或公用），然後在 [傳入連線] 底下檢查標示為 [封鎖所有連入連線] 的控件，包括允許應用程式清單中的防火牆配置檔。

    如果這是針對公用配置檔設定的 （這是 WSL vNIC 的預設配置檔），則 HNS 所建立的防火牆規則將會封鎖 UDP 封包進行共用存取。

    您必須取消勾選NAT DNS代理設定，這樣才能從WSL使用。或 WSL 可以設定為使用 DNS 隧道。

  4. 允許 DNS 封包共用存取的 HNS 防火牆規則可能會變成無效，參考先前的 WSL 介面識別碼。

    這是 HNS 中已使用最新 Windows 11 版本修正的缺陷。 在舊版中，如果發生這種情況，則不容易發現，但它有簡單的應對方法：

    • 停止 WSL

      wsl.exe –shutdown

    • 刪除舊的 HNS 防火牆規則。 在大部分情況下，此 Powershell 命令應該可以運作：

      Get-NetFirewallRule -Name "HNS*" | Get-NetFirewallPortFilter | where Protocol -eq UDP | where LocalPort -eq 53 | Remove-NetFirewallRule

    • 拿掉所有 HNS 端點。 注意：如果使用 HNS 來管理其他容器，例如 MDAG 或 Windows 沙箱，也應該停止這些容器。

      hnsdiag.exe delete all

    • 重新啟動 HNS 服務

      Restart-Service hns

    • 重新啟動 WSL 時，HNS 會建立新的防火牆規則，正確地以 WSL 介面為目標。

針對 Windows 上的網路存取問題進行疑難解答

如果您沒有網路存取權，可能是因為設定錯誤。 請參閱 FSE 驅動程式是否正在執行：

Get-Service FSE

如果這未顯示 FSE 正在執行，請檢查登錄值是否 PortTrackerEnabledMode 在此登入機碼下結束：

Get-ItemProperty HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters

如果 FSE 未執行或安裝，且 PortTrackerEnabledMode 存在，請刪除該登錄值並重新啟動

手動刪除虛設配接器的方式

Ghost 配接器或虛構的即插即用（PnP）裝置，是指那些出現在您系統清單中但實際上未連接的硬體元件。 這些「准刪除」裝置可能會導致系統設定中的混淆和雜亂。 如果您在虛擬機 （VM） 中執行 WSL 時，看到鬼魂適配器，請遵循這些手動步驟來尋找和刪除這些幽靈 PnP 裝置。 Microsoft正在處理不需要手動介入的自動化解決方案。 更多信息即將推出。

  1. 開啟設備管理員

  2. 檢視 > 顯示隱藏的裝置

    [設備管理器] 的螢幕快照顯示隱藏的裝置功能表

  3. 開啟網路適配器

    網路適配器清單 的螢幕快照

  4. 以滑鼠右鍵按兩下准刪除網路適配器，然後選取 [卸載裝置

    以滑鼠右鍵按兩下網路清單中的虛設 pnp 並選取卸載裝置的螢幕快照

啟動 WSL 或安裝發行版時會傳回錯誤碼

請遵循指示，在 GitHub 上的 WSL 存放庫中 收集 WSL 記錄，以收集 GitHub 上的詳細記錄和提出問題。

更新 WSL

適用於Linux的 Windows 子系統有兩個元件需要更新。

  1. 若要更新適用於Linux的 Windows 子系統本身，請使用下列命令。

    wsl.exe --update

  2. 若要更新特定的 Linux 發行版使用者二進位檔，請在您想要更新的 Linux 發行版中使用下列命令。

    apt-get update | apt-get upgrade

Apt-get 升級錯誤

有些套件使用我們尚未實作的功能。 例如，udev尚不支援，並導致數個 apt-get upgrade 錯誤。

若要修正與 udev相關的問題，請遵循下列步驟：

  1. 將下列內容寫入 /usr/sbin/policy-rc.d 並儲存你的變更。

    #!/bin/sh
exit 101

  2. 將執行權限新增至 /usr/sbin/policy-rc.d：

    chmod +x /usr/sbin/policy-rc.d

  3. 執行下列命令：

    dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl

安裝時發生「錯誤：0x80040306」

這與我們不支援舊版控制台的事實相同。 若要關閉舊版主控台：

  1. 開啟 cmd.exe
  2. 在標題列上按右鍵 -> 屬性 -> 取消選取 [使用舊版控制台]
  3. 按兩下 [確定]

Windows 更新之後的「錯誤：0x80040154」

Windows Update 期間可能會停用適用於 Linux 的 Windows 子系統功能。 如果發生這種情況，則必須重新啟用 Windows 功能。 如需啟用適用於 Linux 的 Windows 子系統的指示，請參閱 手動安裝指南。

變更顯示語言

WSL 安裝會嘗試自動變更 Ubuntu 地區設定，以符合 Windows 安裝的地區設定。 如果您不想要此行為，您可以在安裝完成之後執行此命令來變更 Ubuntu 地區設定。 您必須重新啟動 bash.exe，此變更才會生效。

下列範例會將地區設定變更為 en-US：

sudo update-locale LANG=en_US.UTF8

Windows 系統還原之後的安裝問題

  1. 刪除 %SystemRoot%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux 資料夾。

    警告

    如果您的選用功能已完全安裝且正常運作，請勿這麼做。

  2. 開啟 WSL 選用功能（如果尚未開啟）

  3. 重新啟動

  4. lxrun /卸載 /full

  5. 安裝 bash

WSL 中沒有因特網存取

有些用戶回報了特定防火牆應用程式在 WSL 中封鎖因特網存取的問題。 報告的防火牆如下：

  1. 卡巴斯基
  2. AVG
  3. Avast
  4. 賽門鐵克端點保護

在某些情況下，關閉防火牆允許存取。 在某些情況下，只要安裝防火牆，就會封鎖存取。

如果您使用 Microsoft Defender 防火牆，取消勾選 [封鎖所有連入連線，包括允許的應用程式清單中的連線] 選項將允許存取。

使用 ping 時的許可權拒絕錯誤

針對 Windows 年度更新版本 1607，Windows 中的 系統管理員許可權 必須在 WSL 中執行 ping 。 若要執行 ping，請以系統管理員身分在 Windows 上的 Ubuntu 上執行 Bash，或以系統管理員許可權從 PowerShell 提示字元執行 bash.exe 。

針對較新版本的 Windows，組建 14926+，不再需要系統管理員權限。

Bash 已無回應

如果在使用 bash 時，您發現 bash 卡住（或死機）且未回應輸入，請收集並報告記憶體傾印檔案，以協助我們診斷問題。 請注意，這些步驟會當機您的系統。 如果您對此不滿意，請勿這麼做，或者在執行此動作之前先儲存工作。

若要收集記憶體轉儲：

  1. 將記憶體轉儲類型變更為「完整記憶體轉儲」。 變更傾印類型時，請務必記下您當前的類型。

  2. 使用 步驟，透過鍵盤控件設定當機配置。

  3. 重現程式無回應或死結。

  4. 使用（2）的鍵盤序列使系統崩潰。

  5. 系統會當機並收集記憶體轉儲。

  6. 系統重新啟動之後，請將 回報 memory.dmp 為 secure@microsoft.com。 傾印檔案的預設位置是 %SystemRoot%\memory.dmp ，如果 C:\Windows\memory.dmpC: 是系統磁碟驅動器，則為 。 在電子郵件中，請注意轉儲是針對 Windows 上的 WSL 或 Bash 團隊。

  7. 將記憶體轉儲類型還原至原始設定。

檢查組建編號

若要尋找計算機的架構和 Windows 組建編號，請開啟 [設定>系統>

尋找 [OS 組建] 和 [系統類型] 字段。 [建置和系統類型] 字段 螢幕快照

若要尋找您的 Windows Server 組建編號，請在 PowerShell 中執行下列命令：

systeminfo | Select-String "^OS Name","^OS Version"

確認已啟用 WSL

您可以在提升權限的 PowerShell 視窗中執行下列命令，以確認已啟用適用於 Linux 的 Windows 子系統：

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

OpenSSH-Server 連線問題

嘗試連線 SSH 伺服器失敗，發生下列錯誤：「連線被 127.0.0.1 埠 22 關閉」。

  1. 請確定您的 OpenSSH 伺服器正在執行：

    sudo service ssh status

    您已遵循本教學課程：https://ubuntu.com/server/docs/service-openssh

  2. 停止 sshd 服務，並在偵錯模式中啟動 sshd：

    sudo service ssh stop
sudo /usr/sbin/sshd -d

  3. 檢查啟動記錄，並確定 HostKey 可供使用，而且您看不到記錄訊息，例如：

    debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: key_load_private: incorrect passphrase supplied to decrypt private key
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_rsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_dsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_ed25519_key

如果您看到這類訊息，且在 /etc/ssh/下的密鑰遺失，您必須重新產生密鑰，或先清除&然後安裝 openssh-server：

sudo apt-get purge openssh-server
sudo apt-get install openssh-server

啟用 WSL 選用功能時，無法找到參考組件。

此錯誤與處於不良安裝狀態有關。 請完成下列步驟以嘗試並修正此問題：

  • 如果您是從 PowerShell 執行啟用 WSL 功能命令，請改為開啟 [開始] 功能表，搜尋 [開啟或關閉 Windows 功能]，然後在清單中選取 [適用於 Linux 的 Windows 子系統]，以安裝選用元件。

  • 移至 [設定]、[更新]，然後按兩下 [檢查更新] 來更新您的 Windows 版本

  • 如果這兩者都失敗，而且您需要存取 WSL，請考慮使用安裝媒體原地升級，重新安裝 Windows，然後選取 [保留所有專案]，以確保您的應用程式和檔案會保留下來。 您可以在 重新安裝 Windows 10 頁面找到如何執行此作業的指示。

如果您看到此錯誤：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/user/.ssh/private-key.pem' are too open.

若要修正此問題，請將下列內容附加至 /etc/wsl.conf 檔案：

[automount]
enabled = true
options = metadata,uid=1000,gid=1000,umask=0022

請注意，新增此命令將會包含元數據，並修改 WSL 所見 Windows 檔案上的檔案許可權。 如需詳細資訊，請參閱 文件系統許可權。

無法在 Windows 上透過 OpenSSH 遠端使用 WSL

如果您在 Windows 上使用 openssh-server 並嘗試從遠端存取 WSL，則許多人會看到此錯誤：系統無法存取檔案。

使用 WSL 的市集版本時，這是 已知問題。 您可以使用 WSL 1，或使用 Windows 內部版本的 WSL 來解決此問題。 如需詳細資訊，請參閱 Microsoft Store 中的 WSL 。

在發行版中執行 Windows 命令失敗

某些在 Microsoft 市集 中的發行版 仍無法開箱即用地執行 Windows 命令。 如果您收到錯誤 “-bash： powershell.exe： 找不到命令”執行 powershell.exe /c start . 或任何其他 Windows 命令，您可以遵循下列步驟加以解決：

  1. 在您的 WSL 發行版中，執行 echo $PATH。 如果不包含 /mnt/c/Windows/system32，則可能是某些因素正在重新定義標準的 PATH 變數。
  2. 使用 cat /etc/profile檢查設定檔設定。 如果其中包含對 PATH 變數的指派，請編輯該檔案，使用 # 字元將 PATH 指派區塊註解掉。
  3. 檢查 wsl.conf 是否存在 cat /etc/wsl.conf，並確定不包含 appendWindowsPath=false，否則請將其註解掉。
  4. 輸入 wsl -t <Distro> 後接散發名稱，或在PowerShell中執行 wsl --shutdown ，以重新啟動散發。

安裝 WSL 2 之後無法開機

我們瞭解會影響使用者在安裝 WSL 2 之後無法開機的問題。 雖然我們完全診斷這些問題，但用戶回報 變更緩衝區大小 或 安裝正確的驅動程式， 有助於解決此問題。 請檢視此 GitHub 問題，以查看此問題的最新更新。

停用ICS時發生WSL 2錯誤

因特網聯機共用 （ICS） 是 WSL 2 的必要元件。 主機網路服務 (HNS) 使用 ICS 服務來建立 WSL 2 依賴的基礎虛擬網路，該網路提供 NAT、DNS、DHCP 和主機連線共用功能。

停用ICS服務 （SharedAccess） 或透過組策略停用ICS會防止建立WSL HNS 網路。 建立新的 WSL 第 2 版映射時，這會導致失敗，而且嘗試將第 1 版映像轉換成第 2 版時發生下列錯誤：端點對應程式沒有其他可用的端點。

需要 WSL 2 的系統應該將 ICS 服務 （SharedAccess） 保留為預設的啟動狀態、手動（觸發程序啟動），以及停用 ICS 的任何原則都應該遭到覆寫或移除。 停用ICS服務會中斷WSL 2，但不建議停用ICS，但使用這些指示 可以停用ICS的部分

使用舊版 Windows 和 WSL

如果您執行舊版的 Windows 和 WSL，例如 Windows 10 Creators Update（2017 年 10 月、組建 16299） 或年度更新版（2016 年 8 月，組建 14393），則有幾個差異。 建議您 更新為最新的 Windows 版本，但如果不可能，我們已概述以下的一些差異。

互作性命令差異：

  • bash.exe 已取代為 wsl.exe。 Linux 命令可以從 PowerShell 執行，但針對舊版 Windows，您可能需要使用 bash 命令。 例如：C:\temp> bash -c "ls -la"。 傳入 bash -c 的 WSL 命令會轉送至 WSL 程序，而不需修改。 檔案路徑必須以 WSL 格式指定，且必須小心逸出相關的字元。 例如：C:\temp> bash -c "ls -la /proc/cpuinfo" 或 C:\temp> bash -c "ls -la \"/mnt/c/Program Files\""。
  • 若要檢視特定散發版可用的命令，請執行 [distro.exe] /?。 例如，使用 Ubuntu：C:\> ubuntu.exe /?。
  • Windows 路徑包含在 WSL $PATH中。
  • 在較舊版本的 Windows 10 中，從 WSL 發行版呼叫 Windows 工具時，您必須指定目錄路徑。 例如，若要從 WSL 命令行呼叫 Windows 記事本應用程式，請輸入：/mnt/c/Windows/System32/notepad.exe
  • 若要將預設使用者變更為 root 請在 PowerShell 中使用此指令：C:\> lxrun /setdefaultuser root，然後執行 Bash.exe 以登入：C:\> bash.exe。 使用發行版的密碼命令重設您的密碼：$ passwd username，然後關閉 Linux 命令列：$ exit。 從 Windows 命令提示字元或 Powershell，將預設使用者重設為一般 Linux 使用者帳戶：C:\> lxrun.exe /setdefaultuser username。

卸載舊版 WSL

如果您在 Creators 更新之前的 Windows 10 版本上安裝 WSL （2017 年 10 月，組建 16299），建議您將任何必要的檔案、數據等從您安裝的舊版 Linux 發行版移轉至透過 Microsoft 市集安裝的較新發行版。 若要從您的電腦中移除舊版散發套件，請從命令行或 PowerShell 實例執行下列命令：wsl --unregister Legacy。 您也可以選擇手動移除舊版散發套件，方式是使用 Windows 檔案總管或 PowerShell 刪除 %LocalAppData%\lxss\ 資料夾（以及其所有的子內容）：Remove-Item -Recurse $env:localappdata/lxss/。

錯誤碼0x8000FFFF非預期的失敗

此錯誤碼通常表示嘗試安裝或使用 Linux 解構 （例如 Ubuntu） 與 WSL 時，系統作業期間發生非預期或「災難性」失敗。 有許多原因可能會導致此失敗。 從檢查下列項目開始：

  • 這是許可權問題嗎？ 檢查您是否以命令行上預期的使用者身分登入，並在使用 WSL 安裝 Linux 解構時具有必要的系統管理員許可權。 （以滑鼠右鍵按兩下終端機或命令行任務列圖示，以選取 [以系統管理員身分執行]。
  • 您是否已將 WSL 更新為最新版本？ 使用 命令： wsl --update 更新為最新版本。 您可能也想要 更新為最新版本的 Windows。
  • 請確定您正確使用 wsl --install 命令，並指定您想要安裝的Linux解構。
  • 嘗試使用 下列命令關閉 WSL 並重新啟動： wsl --shutdown。
  • 如果您使用 Windows Server，請確定您的版本是最新的，並遵循 Windows Server 安裝指南。
  • 如果您懷疑這可能與遺失或損毀的系統檔案有關，請從提升許可權的命令提示字元 （以系統管理員身分執行），掃描和修復系統檔案及/或修復 Windows作系統映射。 若要掃描並修復損毀或遺失的 Windows 系統檔案，請使用 命令： SFC /SCANNOW。 若要修復 Windows 映射本身，請使用 命令： DISM /Online /Cleanup-Image /RestoreHealth。
  • 請參閱相關的 WSL 產品存放庫問題 9420。
  • Last updated on