وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

رفع خطای 0x800f0922 در آپدیت Windows Server؛ از کجا شروع کنیم؟

راهنمای بررسی CBS، فایل‌های سیستم و علت شکست نصب آپدیت ویندوز سرور با راه‌حل متناسب با خطا.

انتشار:
توسط تیم فنی نت‌آرام
۶ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله رفع خطای 0x800f0922 در آپدیت Windows Server؛ از کجا شروع کنیم؟ در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
آپدیت Windows Server تا بخشی از نصب پیش می‌رود، خطای 0x800f0922 می‌دهد یا بعد از ریبوت تغییرات را برمی‌گرداند. این کد می‌گوید یک بخش از نصب ناموفق شده است، اما به‌تنهایی مشخص نمی‌کند کدام بخش. خرابی یک وظیفه زمان‌بندی‌شده، خطای فایل‌های سیستم، مشکل دسترسی یا شرایط مخصوص همان به‌روزرسانی می‌تواند پشت آن باشد.
در این راهنما ابتدا شماره آپدیت و علت ثبت‌شده در لاگ را پیدا می‌کنیم؛ سپس فقط راه‌حلی را اجرا می‌کنیم که با همان علت سازگار است. تغییر تصادفی مجوزها، حذف پوشه‌های سیستمی یا دست‌کاری پارتیشن بوت برای همه خطاهای 0x800f0922 مناسب نیست. نمونه‌ها برای سرور مجازی ایران دارای Windows Server نوشته شده‌اند و پیش از تغییر باید پنجره نگه‌داری و نسخه پشتیبان قابل بازیابی داشته باشید.

۱. نسخه ویندوز، شماره آپدیت و زمان خطا را ثبت کنید

با حساب مدیر وارد کنسول یا Remote Desktop شوید و PowerShell را با Run as administrator باز کنید:
کد / دستورGet-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 HotFixID, InstalledOn
دستور اول نام و build را نشان می‌دهد. دستور دوم برخی آپدیت‌های ثبت‌شده را فهرست می‌کند؛ نبود یک KB در این فهرست همیشه به‌تنهایی وضعیت همه انواع بسته را مشخص نمی‌کند. در Settings یا پنجره Windows Update، Update history را باز کنید و شماره KB، تاریخ، زمان و مرحله شکست را یادداشت کنید. اگر سرور با WSUS یا ابزار سازمانی مدیریت می‌شود، نام همان منبع را هم ثبت کنید.
صفحه اطلاعات رسمی همان KB را از Microsoft بخوانید: پیش‌نیازها، مشکلات شناخته‌شده، معماری و سازگاری نسخه مهم‌اند. یک بسته مربوط به build یا معماری دیگر را نصب نکنید. اگر آپدیت بعد از ریبوت rollback می‌شود، زمان همان راه‌اندازی را برای بررسی CBS مشخص کنید.

۲. فضای سیستم و وضعیت قبلی را بررسی کنید

کد / دستورGet-Volume | Select-Object DriveLetter, FileSystemLabel, SizeRemaining, Size Get-Service wuauserv, bits, trustedinstaller | Select-Object Name, Status, StartType
فضای باقی‌مانده درایو ویندوز را با نیاز آپدیت و شرایط سرویس مقایسه کنید. فهرست volumeها تصویر اولیه است و همه جزئیات پارتیشن‌های بدون حرف را نشان نمی‌دهد. TrustedInstaller ممکن است در حالت عادی متوقف و شروع آن دستی باشد؛ متوقف‌بودن آن در یک لحظه الزاماً علت خطا نیست. اگر به ریبوت معلق یا عملیات ناتمام اشاره شده، در زمان مجاز یک ریبوت برنامه‌ریزی‌شده انجام دهید و وضعیت آپدیت را دوباره بخوانید. وسط نصب یا rollback، ماشین را به‌زور خاموش نکنید مگر مسئول سیستم روش بازیابی مشخصی داشته باشد.
اگر لاگ دقیقاً از کمبود فضای بخش بوت یا بازیابی نام می‌برد، تشخیص آن را با نوع پارتیشن، BitLocker و راهنمای ویژه همان به‌روزرسانی انجام دهید. اندازه پارتیشن یا همین کد خطا به‌تنهایی برای تغییر پارتیشن کافی نیست. حذف فونت‌ها یا فایل‌های EFI و تغییر اندازه آن بدون طرح بازگشت می‌تواند بوت را خراب کند.

۳. خطای اصلی را در CBS پیدا کنید

در PowerShell مدیر اجرا کنید:
کد / دستورSelect-String -Path "$env:windir\Logs\CBS\CBS.log" -Pattern '0x800f0922','Error','Failed' | Select-Object -Last 40
این دستور آخرین خط‌های دارای عبارت‌های نمونه را نشان می‌دهد. خروجی ممکن است طولانی و شامل نام‌ها یا مسیرهای خصوصی باشد. صرف دیدن یک Failed قدیمی دلیل قطعی نیست؛ خط‌های اطراف زمان همان نصب و شماره KB را در فایل باز کنید و خطای ریشه‌ای نزدیک‌تر را پیدا کنید. اگر لاگ چرخیده است، فایل‌های آرشیوشده CBS و لاگ DISM همان بازه را نیز با روش مناسب بررسی کنید.
در Event Viewer نیز به Windows Logs و سپس Setup یا System بروید و رخدادهای همان زمان را ببینید. اگر لاگ نام یک task، فایل یا پکیج را مشخص کرده است، قبل از تغییر آن نام دقیق و کد خطای همراه را ثبت کنید. Microsoft یک سناریوی خاص را مستند کرده که خرابی task مربوط به Secure Boot باعث همین کد می‌شود؛ این تشخیص برای همه سرورها برقرار نیست.

۴. اگر شواهد به خرابی فایل‌های سیستم اشاره دارند

در پنجره مدیر، ابتدا بررسی و سپس تعمیر پیشنهادی Microsoft را اجرا کنید:
کد / دستورDISM.exe /Online /Cleanup-Image /ScanHealth DISM.exe /Online /Cleanup-Image /RestoreHealth sfc.exe /scannow
ScanHealth مخزن مؤلفه‌ها را بررسی می‌کند. RestoreHealth برای تعمیر ممکن است به فایل سالم از Windows Update یا منبع مجاز سازمان نیاز داشته باشد؛ در محیط WSUS یا بدون اینترنت منبع مناسب را باید طبق سیاست سازمان تعیین کنید. sfc فایل‌های محافظت‌شده سیستم را بررسی و در صورت امکان ترمیم می‌کند. این دستورها ممکن است طول بکشند؛ نتیجه و کد خطا را بخوانید و اجرای آن‌ها را وسط کار قطع نکنید.
اگر DISM با 0x800f081f از نبود منبع گفت، تکرار فرمان بدون تأمین منبع هم‌نسخه مشکل را حل نمی‌کند؛ راهنمای منبع تعمیر ویندوز سرور را دنبال کنید. بعد از تعمیر موفق و ریبوت لازم در پنجره مجاز، نصب همان KB را دوباره امتحان کنید. مستند Microsoft درباره تعمیر خرابی Windows Update جزئیات و محل لاگ را شرح می‌دهد.

۵. اگر لاگ به یک task خراب اشاره می‌کند

Task Scheduler را باز کنید و مسیر و نامی را که در CBS ثبت شده با متن راهنمای Microsoft برای همان خطای خاص تطبیق دهید. Microsoft برای سناریوی مشخص SecureBootEncodeUEFI روش بازیابی task و بسته‌های در وضعیت staged را شرح داده است. آن راهکار شامل تغییر حساس رجیستری و بسته‌های سیستم است؛ ابتدا تطبیق کامل لاگ، نسخه سیستم، نسخه پشتیبان و روش بازیابی را تأیید کنید و سپس با مسئول ویندوز دقیقاً مراحل اختصاصی Microsoft را اجرا کنید.
برای خطای دیگری که فقط همین کد مشترک را دارد، آن کلید رجیستری را حذف نکنید. اگر CBS خطای مجوز در مسیر دیگری می‌دهد، حساب، فایل و عملیات ردشده را از همان رویداد مشخص کنید و مجوز را فقط طبق راهنمای سازنده و سیاست سازمان اصلاح کنید؛ دادن دسترسی نوشتن عمومی به پوشه‌های سیستمی راه‌حل امن نیست.

۶. نتیجه را چطور تأیید کنیم؟

پس از رفع علت، دوباره نصب همان KB را در زمان مجاز شروع کنید و تا پایان، ریبوت و rollback احتمالی صبر کنید. در Update history وضعیت موفق را ببینید و build سیستم را با مستند همان KB مقایسه کنید. سرویس‌های مهم، ورود، وب‌سایت یا پایگاه داده را نیز آزمایش کنید. اگر خطا تکرار شد، زمان تلاش جدید و بخش مرتبط CBS را با تلاش قبل مقایسه کنید؛ تغییر علت یا شماره خطا یعنی باید عیب‌یابی را از شواهد جدید ادامه دهید.
اگر نیاز به پشتیبانی دارید، نسخه و build، شماره KB، زمان خطا، مرحله شکست و چند خط مرتبط CBS را پس از حذف اطلاعات حساس آماده کنید. ارسال فقط کد 0x800f0922 برای انتخاب یک تعمیر دقیق کافی نیست.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام