There was a problem with WSL: توقف Docker أثناء نقل تطبيق

أثناء نقل ChatGPT إلى محرك آخر عبر إعدادات Windows، توقف Docker مع خطأ WSL. وسجلت السجلات إلغاء تحميل محرك الأقراص بالكامل أثناء إعداد موقع تخزين التطبيق. وأعادت إعادة تشغيل Docker وحده المحرك إلى العمل.

خطأ WSL الذي ظهر

بعد نقل ChatGPT، عرض Docker Desktop الخطأ التالي. وأوضحت التفاصيل أيضًا انتهاء عملية بدء WSL الخاصة بـDocker برمز الخروج 135.

There was a problem with WSL
An error occurred while running a WSL command.
Please check your WSL configuration and try again.

exit status 135

كان إصدار Docker Desktop هو 4.95.0 وإصدار WSL هو 2.7.14.0. وكان ملف بيانات Docker من نوع VHDX موجودًا على D قبل عملية النقل هذه، بحجم منطقي نحو 273GB. ولم ننقل بيانات Docker مع تطبيق ChatGPT.

اشتملت تفاصيل الخطأ الطويلة على سجلات بدء التشغيل من الليلة السابقة أيضًا. والتحذير الأول بشأن غياب componentsVersion.json سبق فترة عمل Docker اللاحقة التي بلغت نحو 11 ساعة. وبدل اعتبار أول تحذير بارز السبب المباشر، راجعنا الأحداث المحيطة بوقت توقف Docker فعليًا.

يغير هذا التمييز طريقة اختيار العلاج. فرغم أن الرسالة طلبت فحص إعدادات WSL، كانت المشكلة الأساسية فقدان الوصول إلى قرص افتراضي نشط، لا خطأ في إعداد WSL. وقبل تغيير الإعدادات أو إعادة تسجيل WSL، وحّدنا الأوقات وفحصنا أحداث Windows.

أُلغي تحميل D بالكامل أثناء تجهيز الوجهة

كانت الخطوة الحاسمة مقارنة سجلات NTFS وAppXDeploymentServer وVHDMP مع سجل System المعتاد. ويعرض الجدول التالي أوقات الأحداث المحفوظة مقربة إلى المللي ثانية بتوقيت اليابان.

أُلغي تحميل D قبل بدء نقل حزمة ChatGPT نفسها. شمل الإجراء المحرك كله بينما كان Windows يجهزه لاستخدامه موقعًا لتخزين التطبيقات. وحتى مع إغلاق التطبيق المنقول، كان Docker عرضة للتأثر إذا بقي قرصه الافتراضي على المحرك نفسه مفتوحًا.

كان مقدّم الطلب المسجل في NTFS هو svchost.exe. وبمطابقة معرّف العملية في الحدث مع العملية نفسها، التي كانت تعمل منذ ما قبل العطل، ومعلومات خدمات Windows، حُددت StorSvc، أي Storage Service. وكانت منفصلة عن عملية AppX التي تسجل موقع التخزين؛ ولم نعامل العمليتين باعتبارهما عملية واحدة.

انقضت نحو 3.3 ثانية من بدء إلغاء التحميل إلى اكتمال إعادة التحميل. أما المدة من نجاح إلغاء التحميل إلى اكتمال إعادة التحميل فكانت نحو 0.17 ثانية. لذلك لا يمكن القول إن D اختفى تمامًا لمدة 3.3 ثانية. كانت المشكلة أن إجراءً قصيرًا قد يقطع الوصول إلى ملفات مستخدمة ويمنع التطبيقات من متابعة العمل بعده.

ما كشفه 0xC000026E

في تعريفات NTSTATUS لدى Microsoft، يعني 0xC000026E الرمز STATUS_VOLUME_DISMOUNTED. وهو يشير إلى محاولة تنفيذ عملية على وحدة تخزين أُلغي تحميلها. وظهرت هذه القيمة أيضًا في فشل قراءة VHDX الخاص بـDocker.

أظهرت سجلات نواة WSL أيضًا فشل READ للتخزين الافتراضي وخروج الجهاز من الاتصال وتعطل containerd بالإشارة signal 7. وشكلت سجلات القرص الافتراضي في Windows وتوقف WSL اللاحق تسلسلًا زمنيًا متسقًا.

توضح وثائق إلغاء تحميل وحدات التخزين لدى Microsoft إمكانية محاولة إلغاء تحميل وحدة حتى أثناء استخدامها، مع آثار غير متوقعة على العمليات التي تستخدمها. ويتسق السلوك هنا مع هذه الخاصية العامة. لكننا لم نلتقط مكدس استدعاءات يثبت استدعاء واجهة API المعينة؛ لذلك لم نحدد مسار استدعاء داخليًا بعينه في Windows.

كان حقل السبب في الحدث يقول User request. ولم نعد ذلك دليلًا على أن شخصًا نقر «إخراج USB». فقد ربط فحص الخدمة الطالبة والتسلسل الزمني الحدث بالمعالجة الجارية أثناء تجهيز Windows لموقع تخزين التطبيقات.

لم تتضمن سجلات USB وPnP والسجلات المرتبطة التي فحصناها للفترة نفسها دليلًا يؤيد فصلًا فعليًا وإعادة توصيل. وكانت حالة المحرك Healthy أثناء التحقيق أيضًا. لا يضمن هذا خلو SSD من الأعطال، لكن المسار المباشر الذي ظهر هنا هو إلغاء التحميل بواسطة Storage Service ثم فشل الوصول إلى VHDX.

تُعد آلية PackageVolume التي توثقها Microsoft وسيلة مدعومة لتخزين التطبيقات. ومع ذلك، لم يعنِ استخدام ميزة النقل المدمجة أن التطبيقات الأخرى على المحرك تستطيع الاستمرار بلا انقطاع.

حدث عطل I/O في Unity في الوقت نفسه أيضًا

كان مشروع Unity موجودًا على المحرك نفسه، وظهر Unity Bug Reporter. وأظهرت سجلات Application Error تعطل Unity Data Store في 13:20:47–49، قبل إعادة تشغيل Docker. كان الاستثناء 0xC0000006، وكانت حالة I/O الأساسية 0xC000026E.

تعرّف Microsoft القيمة 0xC0000006 بأنها STATUS_IN_PAGE_ERROR، وتعني تعذر إحضار بيانات لازمة إلى الذاكرة بسبب خطأ I/O. واحتوت الحالة الأساسية على قيمة إلغاء التحميل نفسها التي ظهرت في Docker. وهذا يدعم أن Unity تأثر بعدم إتاحة المحرك نفسه.

لكن حقل اسم الملف في الحدث كان فارغًا، فلم نحدد الملف الذي فشل Unity في الوصول إليه. ولم يكن ظهور Unity.dll في سجل تعطل لاحق كافيًا لإثبات تلف DLL أو الحاجة إلى إعادة التثبيت.

لم نعد تشغيل Unity فورًا. وحفظنا بشكل منفصل 5 ملفات، بمجموع نحو 8MB، بينها نسخة مشهد احتياطية موجودة وسجلات وتفريغات. كان وقت نسخة المشهد 08:31 من ذلك اليوم؛ وهذا لا يثبت حفظ العمل غير المحفوظ قبل التعطل مباشرة. ولم نستبدل المشروع الأصلي بالملفات المحفوظة أثناء التحقيق.

يستبعد هذا التسلسل أيضًا رواية أن إعادة تشغيل Docker سببت تعطل Unity أولًا. فقد سبق أول تعطل لـUnity Data Store إعادة تشغيل Docker. وكان يلزم فحص أوقات الأحداث في السجلات، لا الاعتماد على ترتيب ظهور الشاشات وحده.

إعادة تشغيل Docker وحده أعادت المحرك

بعد حفظ ما يكفي من السجلات محليًا لتتبع السبب، والتأكد من عودة الوصول إلى D، أعدنا تشغيل Docker Desktop وحده مرة واحدة. استخدمنا CLI الرسمي من Docker. ويؤثر الأمر التالي على أعمال Docker النشطة، لذلك افحص ما يحتاج إلى حفظ أو إيقاف قبل تنفيذه.

docker desktop restart --timeout 45

توضح وثائق restart الرسمية من Docker أن --timeout خيار يحد مدة انتظار الأمر. ولا يعني ضمان الاستعادة خلال 45 ثانية. واكتمل هذا التنفيذ برمز الخروج 0.

ثم استخدمنا docker version لفحص استجابة Server، وحصلنا على Engine 29.8.2. وأظهرت قائمة WSL أن docker-desktop عاد إلى Running. وبدأت الواجهة الخلفية الجديدة خلال الدقيقة 13:27.

احتوت القائمة المسترجعة على 108 حاويات: 1 قيد التشغيل، و106 بحالة exited، و1 بحالة created. ولم نشغّل الحاويات المتوقفة دفعة واحدة. فاستجابة المحرك لا تعني أن قواعد بيانات كل مشروع وخدماته تعمل كما كانت، ولذلك تُركت فحوص الوظائف للخدمات المطلوبة لمسؤوليها.

لم تتضمن الاستعادة إعادة ضبط المصنع أو حذف بيانات أو إلغاء تسجيل WSL أو إعادة التثبيت. ولم نوقف WSL كله، بما قد يؤثر على غير Docker، ولم نرفع مجموعة كاملة من بيانات التشخيص خارجيًا. والمهم أننا لم ننتقل مباشرة من شاشة الخطأ إلى إجراء قد يفقد البيانات المحفوظة.

سجلات ساعدت على تحديد السبب

لم يكشف النظر في سجل System وحده في البداية سجلات إلغاء التحميل الحاسمة. وغيابها عن System لا يعني عدم وجود سجل في Windows. فقد ربط ترتيب السجلات التالية زمنيًا بين تجهيز نقل التطبيق وأخطاء I/O في التطبيقات الأخرى.

يساعد تدوين وقت الإجراء ومحرك الوجهة وموقع قرص Docker الافتراضي ونص الخطأ أولًا على تضييق نطاق التحقيق في العرض نفسه. افحص قنوات السجل المتاحة على الكمبيوتر وابدأ بقراءة السجلات الموجودة. ولم نفعّل إعدادات تشخيص أو نكرر الإجراء المسبب للعطل في هذا التحقيق الإضافي.

لا ينشر المقال اسم المستخدم أو SID أو الأرقام التسلسلية للأجهزة أو بيانات الاعتماد أو متغيرات بيئة الحاويات. وعند مشاركة السجلات، يسهل فهم السبب أكثر باستخراج الأوقات وأكواد الخطأ وأسماء العمليات الضرورية فقط.

ما يجب تحديده قبل النقل إلى محرك آخر

كان قصورنا التركيز على إيقاف ChatGPT ونسخه احتياطيًا دون معالجة كافية لتأثير النقل على Docker وUnity اللذين كانا يعملان على D في الإرشادات السابقة للنقل. وفي عمل مشابه مستقبلًا، سنحدد ما يجب إيقافه على مستوى المحرك.

1. حدد كل ما يستخدم الوجهة. افحص أقراص Docker وVM الافتراضية وقواعد البيانات ومشاريع المحررات والعمليات الأخرى التي تبقي ملفات D مفتوحة.
2. احفظ العمل غير المحفوظ والبيانات اللازمة للاستعادة. اجعل العمل الجاري قابلًا للاستعادة، بدلًا من الاكتفاء بنسخ التطبيق نفسه.
3. اختر وقتًا يمكن فيه إيقاف العمليات المستخدمة للمحرك. أدرج أعمال المحادثات الأخرى والمسؤولين الآخرين، وامنع بدء عمليات جديدة أثناء النقل.
4. استخدم ميزة النقل المدعومة من Windows. لا تغير ملكية WindowsApps أو WpSystem وأذوناتهما لتنقل المجلدات وحدها يدويًا.
5. افحص النقل والتطبيقات الأخرى بشكل منفصل. تحقق من الوظائف المطلوبة فعلًا، بدءًا بتشغيل التطبيق والعناصر المحفوظة والمتصفح ومحرك Docker ثم الخدمات اللازمة بهذا الترتيب.

أكدت السجلات أن هذا كان أول تسجيل لـD كموقع لتخزين التطبيقات. لكن ذلك لا يثبت استحالة تكرار العطل بعد اكتمال التسجيل. ولم نكرر التسجيل أو إلغاء تحميل المحرك المستخدم للعمل الحقيقي لاختباره، بل احتفظنا بالإعداد الذي يعمل حاليًا.

كما أن نقل التطبيق إلى D لا يجمع كل ملفاته المرتبطة هناك. في هذه الحالة، انتقل التطبيق وبياناته الرئيسية إلى D، وبقيت CLI المستخدمة ومكونات أخرى على C. وللاطلاع على صورة التخزين العامة والأحجام، راجع سجل نقل ChatGPT وCodex بين محركات الأقراص.

نجاح النقل لا يعني سلامة التطبيقات الأخرى

نُقل تطبيق ChatGPT نفسه إلى D بنجاح، وفحصنا عمليات المتصفح والعناصر المحفوظة بعد ذلك. وفي الوقت نفسه، أُلغي تحميل D بالكامل أثناء تجهيز الوجهة، ما سبب أعطالًا في Docker وتطبيقات أخرى تستخدم أقراصًا افتراضية على المحرك نفسه. ولم يكن حدث نجاح النقل وحده دليلًا على عدم تأثر التطبيقات المحيطة.

تشرح السجلات المسار المباشر للعطل في هذه الحالة. ولم نحدد فرع الاستدعاء الداخلي في Windows الذي طلب إلغاء التحميل، ولا ما إذا كان السلوك نفسه يحدث على أجهزة أو إصدارات Windows أخرى. والاحتياط العملي الذي تدعمه الحالة هو إيقاف العمليات النشطة على D، إلى جانب التطبيق المنقول، قبل البدء.

الأسئلة الشائعة

هل تصلح إعادة تثبيت WSL رسالة «There was a problem with WSL»؟

كان مسار العطل هنا فقدان الوصول إلى قرص افتراضي. وأعادت إعادة تشغيل Docker وحده المحرك؛ ولم نعد تثبيت WSL أو نلغ تسجيله. وفحص سجلات وقت العطل أولًا أفضل لحماية البيانات المحفوظة.

هل يعني ذلك تعطل SSD على D؟

وجدنا سجلًا مباشرًا لإلغاء تحميل D بواسطة Storage Service. ولم نجد سجلات تثبت فصلًا فعليًا في الوقت نفسه. ولا تقدم هذه الحالة أساسًا للجزم بتعطل SSD.

هل ينبغي تجنب ميزة نقل التطبيقات المدمجة في Windows؟

نقل حزمة إلى وحدة تخزين أخرى ميزة مدعومة في Windows. واستنادًا إلى هذه التجربة، سنخصص وقتًا لإيقاف التطبيقات الأخرى على الوجهة نفسها ونسخ البيانات وفحص العمل، بدلًا من إبقائها قيد التشغيل أثناء النقل.

إذا بدأ Docker، فهل يمكن افتراض عودة كل شيء؟

استجابة المحرك منفصلة عن خدمات كل حاوية ومحتويات قواعد بياناتها. تحققنا من عودة المحرك وجلب القائمة، وتبقى فحوص وظائف المشاريع المطلوبة منفصلة.