Microsoft แนะนำให้ใช้คำสั่งบรรทัดคำสั่งเพื่อจัดการการติดตั้งอัปเดต Windows 10

 (theregister.com)
1 คะแนน โดย GN⁺ 2024-01-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • KB5034441 สำหรับ Windows 10 เป็นอัปเดตความปลอดภัยเพื่อปิดช่องโหว่การข้าม BitLocker แต่ในพีซีบางเครื่องล้มเหลวในขั้นตอนการติดตั้ง
  • แกนของปัญหาอยู่ที่ พาร์ทิชันกู้คืน WinRE โดยขนาดพาร์ทิชันในสภาพแวดล้อมติดตั้ง Windows 10 มาตรฐานอาจไม่เพียงพอสำหรับจัดการอัปเดตนี้
  • เมื่อการติดตั้งล้มเหลว อาจแสดง 0x80070643 แต่สาเหตุจริงอาจเป็น ความล้มเหลวของบริการสภาพแวดล้อมกู้คืน ซึ่งตรงกับ CBS_E_INSUFFICIENT_DISK_SPACE
  • วิธีแก้ชั่วคราวของ Microsoft คือปิด WinRE จาก Command Prompt แบบผู้ดูแลระบบ แล้วลบและสร้างพาร์ทิชันกู้คืนใหม่ ซึ่งมีความเสี่ยงสำหรับผู้ใช้ทั่วไป
  • ผู้ใช้ตอบสนองว่าขั้นตอนนี้ “เป็นเทคนิคเกินไปและน่ากลัว” และความไม่พอใจเพิ่มขึ้นว่า Microsoft ควรออกแพตช์แก้ไขเอง

การติดตั้ง KB5034441 ล้มเหลวและปัญหาพาร์ทิชันกู้คืน

  • Microsoft เผยแพร่ KB5034441 สำหรับ Windows 10 21H2 และ 22H2 เมื่อวันที่ 9 มกราคม 2024
    • จุดประสงค์คือเพื่อปิดช่องโหว่ที่สามารถใช้ Windows Recovery Environment หรือ WinRE เพื่อข้ามการเข้ารหัส BitLocker ได้
  • ผู้ใช้บางรายพบข้อผิดพลาด 0x80070643 ระหว่างติดตั้งอัปเดต
    • รหัสนี้ใกล้เคียงกับข้อความการติดตั้งล้มเหลวทั่วไป และตามข้อมูลของ Microsoft อาจไม่ได้แสดงสาเหตุจริงอย่างถูกต้อง เนื่องจาก “ข้อผิดพลาดในรูทีนจัดการรหัสข้อผิดพลาด”
  • สาเหตุจริงอาจเป็น พื้นที่พาร์ทิชันกู้คืนไม่เพียงพอ
    • ข้อความข้อผิดพลาดจริงที่ Microsoft ระบุคือ Windows Recovery Environment servicing failed. (CBS_E_INSUFFICIENT_DISK_SPACE)
    • พาร์ทิชันกู้คืนของพีซีที่ติดตั้ง Windows 10 แบบมาตรฐานอาจมีขนาดไม่ใหญ่พอสำหรับจัดการอัปเดตนี้

ขั้นตอนเลี่ยงปัญหาแบบแมนนวลที่มีความเสี่ยง

  • Microsoft แนะนำให้ผู้ใช้ที่เจอปัญหาพื้นที่ดิสก์ ปรับพาร์ทิชันกู้คืนด้วยตนเองตาม KB5028997
    • ต้องเปิด Command Prompt ด้วยสิทธิ์ผู้ดูแลระบบ
    • ต้องปิดใช้งาน WinRE แล้วรันคำสั่งเพื่อลบและสร้างพาร์ทิชันกู้คืนใหม่
    • เป็นขั้นตอนที่ผู้ใช้ที่ไม่คุ้นเคยอาจทำพลาดได้ง่าย
  • บนโซเชียลมีเดีย ปัญหานี้เกิดขึ้นอย่างกว้างขวาง และผู้ใช้มีท่าทีลังเลที่จะใช้วิธีเลี่ยงปัญหาของ Microsoft
    • ผู้ใช้บางรายบอกว่าขั้นตอนนี้ “เป็นเทคนิคเกินไปและน่ากลัว”
    • ผู้ใช้รายอื่นกล่าวว่าเป็น “ปัญหาที่ Microsoft ควรแก้เอง”
    • ผู้ใช้อีกรายกล่าวว่าผู้ใช้ไม่จำเป็นต้องแก้ความผิดพลาดของ Microsoft และหากระงับอัปเดตไว้ Microsoft จะปล่อยแพตช์แก้ไขในอนาคต
  • Microsoft อัปเดตเอกสารสาธารณะที่เกี่ยวข้องเมื่อวันที่ 16 มกราคม
    • อย่างไรก็ตาม ตัวคำแนะนำไม่ได้เปลี่ยนแปลง
    • ระบุว่า “กำลังดำเนินการแก้ไข และจะให้อัปเดตในรุ่นถัดไป”

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-16
ความคิดเห็นใน Hacker News

  • ผู้ใช้บางรายเห็นข้อผิดพลาด 0x80070643 ระหว่างติดตั้งอัปเดต แต่ Microsoft ระบุว่าเพราะ “ข้อผิดพลาดในรูทีนจัดการรหัสข้อผิดพลาด” จึงอาจไม่ใช่ข้อผิดพลาดจริงก็ได้
    เท่ากับว่าโค้ดรหัสข้อผิดพลาดสำหรับข้อผิดพลาด แสดงรหัสข้อผิดพลาดของข้อผิดพลาดผิดไปเพราะมีข้อผิดพลาด
    สงสัยว่าโค้ดจัดการรหัสข้อผิดพลาดถูกแตะต้องบ่อยแค่ไหน ถึงยังมีข้อผิดพลาดที่ไม่ได้แก้มานานขนาดนี้หลงเหลืออยู่ เดิมทีดูเหมือนเป็นงานประเภทที่ทำครั้งเดียวแล้วลืมได้เลย แต่ถ้ามันมีมานานแล้วแค่ไม่สะดุดตา ก็คงแปลว่าการประกันคุณภาพของโค้ดรหัสข้อผิดพลาดก็มีข้อผิดพลาดด้วย

    • เพราะอย่างนั้น เวลาเขียนหรือรีวิวโค้ดที่จัดการ exception และเส้นทางข้อผิดพลาด ผมจะดูให้ เข้มงวดและละเอียดรอบคอบ กว่าเดิม
      ผมคิดว่ามันควรเรียบง่ายกว่าโค้ดในเส้นทางปกติ เข้าใจง่ายแบบสุด ๆ และมี coupling ต่ำ ไม่ควรมีทั้ง inheritance หรือ abstraction และ dependency tree ก็ควรตื้น
      เจอระบบล่มเพราะบั๊กในโค้ดจัดการ exception มาบ่อยเกินไป เส้นทาง exception มักแทบไม่ได้ทดสอบ หรือถูกข้ามไปตั้งแต่แรก และโดยนิยามแล้ว exception ก็มักโผล่มาจากที่ที่คาดไม่ถึง
    • อาจฟังดูบอกอายุ แต่ บิลด์ OS/2 ที่เคยใช้เมื่อก่อน บางครั้งจะแสดงว่า “ข้อความข้อผิดพลาดนี้ถูกลบแล้ว”
    • บั๊กที่ผมรับผิดชอบเมื่อราวหนึ่งปีก่อน สุดท้ายเกิดจาก exception ในโค้ด logging
      โค้ด logging เกิด exception ซ้ำเฉพาะกรณีที่ต้องบันทึก exception ที่โค้ดจัดการ exception โยนออกมาเท่านั้น เป็นเครื่องมือภายใน เลยแกล้งเขียนรายการ changelog ให้ชวนสับสนสุด ๆ เพื่อความสนุก
    • ข้อความที่ผมชอบที่สุดคือข้อความตัวเล็ก ๆ ว่า “Something Happened” แล้วก็ “Something Happened” อีกครั้ง

  • ผมลองทำตามคำแนะนำแล้ว และเข้าใจว่ามันอาจดูเป็นภาระสำหรับผู้ใช้บางรายพอสมควร
    ผมใช้ Windows Disk Management ย่อพาร์ทิชันและสร้างพื้นที่ที่ต้องการแทนการใช้ command line
    น่าแปลกที่ไม่มีสคริปต์สำหรับกระบวนการนี้ ซึ่งดูเหมือนหมายความว่ามันซับซ้อนและมีโอกาสพลาดได้มาก นั่นจึงน่าจะเป็นเหตุผลที่ไม่มีสคริปต์แบบดับเบิลคลิกแล้วจบ เพราะตัวงานเองทำยาก
    การหวังให้ Windows Update แก้แบบรวดเร็วตามที่หลายคนคาดก็คงมองโลกสวยเกินไป แต่คิดว่าอีกไม่นานนักพัฒนาภายนอกคงออกสคริปต์หรือโปรแกรมมา automate กระบวนการนี้

    • การเปลี่ยนแปลงดิสก์และพาร์ทิชันอัตโนมัติ น่าจะมีความเสี่ยงข้อมูลสูญหายร้ายแรงค่อนข้างสูง
    • ตอนนี้ดูเหมือนมี PowerShell script ออกมาแล้ว แต่ดูไม่ได้เปลี่ยนขนาดพาร์ทิชัน อยากรู้ว่ามีใครลองใช้แล้วหรือยัง
      https://support.microsoft.com/en-us/topic/kb5034957-updating...

  • มีส่วนที่ว่า “ช่องโหว่ที่ผู้โจมตีสามารถใช้ Windows Recovery Environment (WinRE) เพื่อเลี่ยงการเข้ารหัส BitLocker” ซึ่งผมรู้สึกแปลกมาตลอด เพราะตั้งแต่ก่อนแล้ว recovery environment ดูเหมือนจะเปิดให้เข้าถึงไดรฟ์ระบบที่ถูกถอดรหัสอัตโนมัติด้วยสิทธิ์ SYSTEM
    เป็นแบบนั้นมาหลายปี และยังใช้ dump เนื้อหาในเครื่องที่ลืมรหัสผ่านล็อกอินได้ด้วย อาจไม่ใช่พฤติกรรมที่ตั้งใจไว้แต่แรก

    • เรื่องนั้นจะเป็นจริงเฉพาะกรณีที่ไม่ได้ใช้ TPM PIN หรือ TPM ต่ำกว่า 2.0
      วิธี TPM ของ BitLocker ที่ใช้ PIN ร่วมด้วย ไม่มีทางรู้คีย์ฮาร์ดไดรฟ์ได้โดยไม่ถาม TPM และ TPM ก็จะร้องขอ PIN มีการป้องกัน brute force และการล็อกในตัว
    • เท่าที่จำได้ WinRE ไม่ได้ขอรหัสผ่านผู้ดูแลระบบภายในก่อนทำงานกู้คืนหรือ?
      ดังนั้น “auto-unlock” โดยทั่วไปจึงเป็นฟีเจอร์ที่มีเงื่อนไขใหญ่ ๆ ติดมาด้วย และเป็นหนึ่งในเหตุผลที่แนะนำให้ใช้ PIN, รหัสผ่าน หรือ network unlock ถ้าเป็นไปได้ แต่ข้อเสียคือทุกครั้งที่อัปเดต ต้องคอยดูแลแล็ปท็อปและปลดล็อกทุกครั้งที่รีสตาร์ต

  • Microsoft สร้างแผนกประกันคุณภาพจริง ๆ กลับมาไม่ได้หรือ แทนที่จะฝากไว้กับ Insiders ที่ไม่ได้รับค่าจ้าง? ดูเหมือนพึ่งพาคนที่ดื่ม Flavor-Aid แล้วเชื่อว่า Microsoft ไม่มีทางเขียนโค้ดผิดเลย

    • ถ้าดูชุมชน feedback แล้ว การมอง Insiders ทั้งหมดแบบนั้นคงไม่ถูกนัก
      แต่ก็จริงที่แผนกประกันคุณภาพแบบดั้งเดิมถูกยุบไปเกือบ 10 ปีแล้ว และแผนกนั้นทำมากกว่าแค่ใช้การตรวจสอบจากผู้ใช้ภายนอก พูดตรง ๆ ก็คงบอกได้ยากว่า Windows พังบ่อยกว่ายุค 10 ปีก่อนหน้านั้น แต่ผมอยากเห็นตัวเลขจริงของสถิติ outage ที่เกิดจากปัญหา patch ในช่วง 20 ปีที่ผ่านมา ตามสถานที่อย่างระบบการแพทย์

  • ถึงวิธีแก้จะดูน่ากลัว แต่ก็ยังขอบคุณที่อย่างน้อยออกอะไรบางอย่างมาให้
    เมื่อไม่กี่ปีก่อน ตอนอัปเดตหนึ่งทำให้ อาร์เรย์ ReFS ของคนจำนวนไม่น้อยพัง เราไม่ได้รับวิธีแก้อะไรนอกจาก rollback และท้ายที่สุดอัปเดตนั้นก็กลายเป็นอัปเดตบังคับ ถอนออกไม่ได้อีก จนต้องสร้างอาร์เรย์ใหม่ตั้งแต่ศูนย์

    • ใช่ เขาออกอะไรบางอย่างมา แต่ก็ยังเป็นเหตุการณ์ใหญ่
      ไม่ใช่เรื่องที่ควรขอบคุณเพราะผลิตภัณฑ์ที่เสียเงินซื้อโยนเศษอะไรมาให้ ถ้าผมอ่านเจตนาคุณผิดก็ขอโทษ
      Microsoft ควรถูกเรียกรับผิดชอบที่ทำให้การติดตั้งพัง แล้วออกวิธีแก้แบบครึ่ง ๆ กลาง ๆ มาให้ แม้จะเป็นปัญหาซับซ้อน แต่ถ้าเป็นผู้นำตลาดระบบปฏิบัติการเดสก์ท็อปและทำเงินมหาศาลจากมัน ก็ควรทำได้ดีกว่านี้

  • ปัญหาคือไม่มี recovery partition หรือมันใหญ่ไม่พอ
    ใน VM Win10 ผมลบ recovery partition หลังติดตั้ง เพราะไม่จำเป็นต้องใช้ แต่ตอนนี้กลายเป็นว่าอัปเดตการติดตั้งนั้นไม่ได้แล้ว

    • ผมทำตามคำแนะนำเพื่อปิดใช้งาน recovery partition และดูเหมือนตั้งแต่แรกก็ไม่ได้จัดสรรพื้นที่ไว้
      หลังรีบูต ผมอัปเกรดเป็น Windows 11 ได้ และหวังว่าจะไม่เกิดปัญหาใหญ่กว่านี้ภายหลัง ขั้นตอนถัดไปที่ให้ปรับขนาด system partition นั้นผมไม่อยากแตะจริง ๆ
      คงแล้วแต่กรณี แต่ก็น่าสนใจที่บั๊กนี้ซึ่งบังเอิญเจอขึ้นไปอยู่หน้าแรกของ Hacker News

  • มีคำพูดว่า “ที่ใช้ Windows ก็เพราะไม่อยากไปใช้ command line แค่เพื่อแก้ปัญหาง่าย ๆ เรื่องเดียว” แต่จริง ๆ ก็เหมือนเราเข้าไปอยู่ในชมรมนั้นแล้ว
    หลายปีก่อน Windows อยู่ ๆ ก็ตัดสินว่าผมไม่มีสิทธิ์เข้าถึงไดเรกทอรีผู้ใช้ของตัวเอง ทำให้ Explorer กับทาสก์บาร์พังแบบประหลาดทั้งระบบ
    วิธีแก้คือต้องเข้าคอนโซลผู้ดูแลระบบ สร้างผู้ใช้ใหม่ ย้ายไฟล์จากบัญชีเดิมไปบัญชีใหม่ แล้วเปลี่ยน owner กับ permission ดังนั้นความคิดที่ว่า Windows ใช้ง่ายเพราะเป็นกราฟิกจึงเป็นเรื่องเหลวไหล
    ถ้ายังไงก็ต้องตกไปอยู่ในโหมดล้มเหลวแปลก ๆ แล้วพิมพ์คำสั่งกู้สถานการณ์อยู่ดี ผมขอใช้ Linux กับ NetBSD ต่อไปดีกว่า

  • ในฐานะอดีตนักพัฒนา Windows ผมจำได้ว่าเคยหงุดหงิดมากกับ การอัปเกรด Windows
    โฟลเดอร์ติดตั้งกลายเป็นที่ที่เขียนลงไปได้ไม่เสถียรอีกต่อไป แล้วก็ถูกบังคับให้ไปเขียนใน registry จากนั้นก็ให้แยกเขียนไปยังโฟลเดอร์ข้อมูลและตำแหน่งอื่น ๆ เลยต้องหั่นการติดตั้งออกเป็น “สิบทาง” เพื่อจัดการตำแหน่งข้อมูล ต้องจัดการกับ HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER ฯลฯ แล้วค่อยขอการยกระดับสิทธิ์ในการติดตั้ง
    ยังพอจำลาง ๆ ได้ว่าเคย debug บั๊กที่ลบไฟล์ในโฟลเดอร์ติดตั้งไปแล้ว แต่ Windows กลับกู้คืนไฟล์เวอร์ชันเก่ากลับมาในเบื้องหลังด้วย c:\program files ถูก virtualize จนไม่ทำงานเหมือนไดเรกทอรีจริงอีกต่อไป

    • การที่เขียนลงโฟลเดอร์ติดตั้งได้ไม่เสถียรน่าจะเป็นการเปลี่ยนแปลงที่เข้ามาตอน Windows XP และผมคิดว่าเป็นการเปลี่ยนแปลงที่ดี
      การปล่อยให้โปรแกรมของผู้ใช้เขียนลงในโฟลเดอร์ที่เต็มไปด้วยไฟล์ executable นั้นเลวร้ายมากในแง่ความปลอดภัย

  • ก็อาจตัดสินได้ว่าไม่ควรติดตั้งทุกอัปเดตทันทีที่ปล่อยออกมา

    • บน macOS กับ iOS ผมใช้วิธีรอสักพัก แต่บน Windows ผมหาวิธีบอกว่าไม่ต้องการ auto update ไม่เจอ
      โดยเฉพาะถ้ามันอัปเดตกลางงานคำนวณที่รันข้ามคืนอยู่ก็ลำบาก
    • Microsoft เปลี่ยนเรื่องนั้นแล้วหรือยัง หรือ Windows 10 Home ยังบังคับให้ผู้ใช้ติดตั้งอัปเดตล่าสุดทันทีอยู่?
    • Microsoft ได้กินอาหารหมาของตัวเองกับอัปเดตพวกนี้ภายในบริษัทก่อน เหมือนที่ Google ทำกับ Android และ Chrome OS ไหม?

  • ถ้านักข่าวเคยลองใช้ Linux ก็คงรู้ว่ามันแสดง ข้อความผิดพลาด ที่ดีกว่ารหัสผิดพลาดที่ดูเหมือนเลขสุ่มมาก

    • นี่ไม่ใช่สถานการณ์ที่มันแสดงข้อความผิดพลาดผิดไปตรง ๆ หรอกหรือ?
      ตามที่ Microsoft ระบุ “เนื่องจากข้อผิดพลาดในรูทีนจัดการรหัสผิดพลาด” ข้อผิดพลาดนี้อาจไม่ใช่ข้อผิดพลาดที่ถูกต้องก็ได้
    • สิ่งที่ทำให้ Windows ใช้งานได้ดีไม่ใช่ข้อความผิดพลาด แต่คือ การแก้ได้ด้วยคลิกเดียว
    • exit code 139 เหรอ อืม
    • ถูก แต่บางครั้งข้อความที่มีประโยชน์ก็หาได้เฉพาะใน dmesg เท่านั้น