There was a problem with WSL: ऐप स्थानांतरण में Docker रुका

Windows सेटिंग से ChatGPT को दूसरी ड्राइव पर स्थानांतरित करते समय Docker WSL त्रुटि के साथ रुक गया। लॉग में दर्ज था ऐप संग्रह स्थान की तैयारी के दौरान पूरी ड्राइव का डिसमाउंट होना। केवल Docker पुनः आरंभ करने से इंजन बहाल हो गया।

दिखी हुई WSL त्रुटि

ChatGPT के स्थानांतरण के बाद Docker Desktop ने नीचे दी त्रुटि दिखाई। विवरण में यह भी था कि Docker की WSL शुरुआत प्रक्रिया निकास कोड 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 ड्राइव डिसमाउंट हुई

निर्णायक कदम सामान्य System लॉग के साथ NTFS, AppXDeploymentServer और VHDMP लॉग की तुलना था। नीचे सहेजे इवेंट के समय जापान मानक समय में मिलीसेकंड तक गोल करके दिखाए गए हैं।

ChatGPT पैकेज का स्थानांतरण शुरू होने से पहले D ड्राइव डिसमाउंट हुई थी। Windows द्वारा ऐप संग्रह स्थान तैयार करते समय पूरी ड्राइव प्रभावित हुई। स्थानांतरित ऐप बंद होने पर भी उसी ड्राइव पर Docker की वर्चुअल डिस्क खुली रहने से उस पर असर पड़ सकता था।

NTFS में अनुरोधकर्ता svchost.exe था। इवेंट के प्रक्रिया ID को विफलता से पहले से चल रही उसी प्रक्रिया और Windows सेवा जानकारी से मिलाने पर वह StorSvc यानी Storage Service निकली। यह ऐप संग्रह स्थान पंजीकृत करने वाली AppX प्रक्रिया से अलग थी; हमने दोनों को एक प्रक्रिया नहीं माना।

डिसमाउंट शुरू होने से दोबारा माउंट पूरा होने तक लगभग 3.3 सेकंड लगे। सफल डिसमाउंट से दोबारा माउंट पूरा होने तक अंतर लगभग 0.17 सेकंड था। इसलिए यह नहीं कहा जा सकता कि D ड्राइव 3.3 सेकंड पूरी तरह गायब थी। समस्या यह थी कि छोटी प्रक्रिया भी उपयोग में चल रही फ़ाइलों की पहुँच तोड़ सकती है और ऐप का आगे काम जारी रहना रोक सकती है।

0xC000026E से क्या पता चला

Microsoft की NTSTATUS परिभाषाओं में 0xC000026E का अर्थ STATUS_VOLUME_DISMOUNTED है। यह डिसमाउंट हुए वॉल्यूम पर कार्य के प्रयास को दर्शाता है। Docker के VHDX की विफल रीड में भी यही मान दर्ज था।

WSL कर्नेल रिकॉर्ड में भी वर्चुअल संग्रह की READ विफलता, डिवाइस ऑफ़लाइन होना और signal 7 से containerd का क्रैश दर्ज था। Windows के वर्चुअल डिस्क रिकॉर्ड और WSL के अंतिम बंद होने का क्रम एक ही समयरेखा से जुड़ा।

Microsoft का वॉल्यूम डिसमाउंट करने का दस्तावेज़ बताता है कि उपयोग में चल रहे वॉल्यूम को भी डिसमाउंट करने का प्रयास हो सकता है और उसका उपयोग करने वाली प्रक्रियाओं पर अप्रत्याशित प्रभाव पड़ सकता है। इस मामले का व्यवहार उस सामान्य गुण से मेल खाता है। लेकिन हमने उस खास API के कॉल का स्टैक नहीं लिया, इसलिए Windows के भीतर किसी निश्चित कॉल मार्ग की पुष्टि नहीं की है।

इवेंट के कारण वाले फ़ील्ड में User request था। इसे किसी व्यक्ति द्वारा “Eject USB” क्लिक करने का प्रमाण नहीं माना गया। अनुरोधकर्ता सेवा और घटनाक्रम की जाँच से यह Windows द्वारा ऐप संग्रह स्थान तैयार करने की प्रक्रिया से जुड़ा।

उसी अवधि के जाँचे USB, PnP और संबंधित लॉग में भौतिक रूप से हटाने और दोबारा जोड़ने का प्रमाण नहीं मिला। जाँच के दौरान ड्राइव की स्थिति Healthy भी थी। इससे SSD के पूरी तरह दोषमुक्त होने की गारंटी नहीं मिलती, लेकिन यहाँ मिला प्रत्यक्ष विफलता मार्ग Storage Service का डिसमाउंट और उसके बाद VHDX पहुँच की विफलता था।

Microsoft द्वारा वर्णित PackageVolume ऐप सहेजने की समर्थित व्यवस्था है। फिर भी अंतर्निहित स्थानांतरण सुविधा का उपयोग और उसी ड्राइव के अन्य ऐप का बिना रुकावट चलते रहना एक बात नहीं थी।

उसी समय Unity में भी I/O विफलता हुई

उसी ड्राइव पर Unity प्रोजेक्ट था और Unity Bug Reporter दिखाई दिया। Application Error रिकॉर्ड में Docker पुनः आरंभ से पहले 13:20:47–49 पर Unity Data Store का क्रैश था। अपवाद 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 एक बार पुनः आरंभ किया। Docker का आधिकारिक CLI इस्तेमाल हुआ। नीचे का कमांड सक्रिय Docker काम को प्रभावित करता है, इसलिए पहले जाँचें कि क्या सहेजना या बंद करना है।

docker desktop restart --timeout 45

Docker का आधिकारिक restart दस्तावेज़ बताता है कि --timeout कमांड के इंतज़ार की अवधि सीमित करने का विकल्प है। इसका अर्थ 45 सेकंड में बहाली की गारंटी नहीं है। इस बार कमांड निकास कोड 0 के साथ पूरा हुआ।

इसके बाद docker version से Server का जवाब जाँचा और Engine 29.8.2 मिला। WSL सूची में भी docker-desktop Running पर लौट आया। नया बैकएंड 13:27 के दौरान शुरू हुआ।

मिली सूची में 108 कंटेनर थे: 1 running, 106 exited और 1 created। बंद कंटेनरों को एक साथ शुरू नहीं किया। इंजन जवाब देना और हर प्रोजेक्ट के डेटाबेस व सेवाएँ पहले जैसे चलना अलग बातें हैं, इसलिए आवश्यक सेवाओं की कार्यात्मक जाँच उनके जिम्मेदारों के लिए छोड़ी गई।

बहाली में फ़ैक्टरी रीसेट, डेटा हटाना, WSL का पंजीकरण हटाना या पुनः इंस्टॉलेशन नहीं किया गया। पूरे WSL को भी बंद नहीं किया, जिससे Docker के बाहर भी असर होता। निदान डेटा का पूरा संग्रह बाहर अपलोड नहीं किया। महत्वपूर्ण बात थी कि त्रुटि स्क्रीन देखते ही सहेजा डेटा खोने वाले उपाय की ओर नहीं बढ़े।

कारण पता करने में उपयोगी लॉग

पहले केवल System लॉग देखने से निर्णायक डिसमाउंट रिकॉर्ड नहीं मिला। System में न मिलना, Windows में रिकॉर्ड ही न होना नहीं है। नीचे के लॉग समय के अनुसार रखने से ऐप स्थानांतरण की तैयारी और दूसरे ऐप की I/O विफलता जुड़ी।

ऐसे लक्षण जाँचने वाले पाठक पहले कार्य का समय, गंतव्य ड्राइव, Docker वर्चुअल डिस्क का स्थान और त्रुटि संदेश लिख लें, तो दायरा सीमित करना आसान है। कंप्यूटर पर उपलब्ध लॉग चैनल जाँचें और मौजूदा रिकॉर्ड पढ़ने से शुरुआत करें। इस अतिरिक्त जाँच में निदान सेटिंग सक्षम नहीं की गई और समस्या पैदा करने वाला कार्य दोहराया नहीं गया।

लेख में उपयोगकर्ता नाम, उपयोगकर्ता SID, डिवाइस सीरियल, प्रमाणीकरण जानकारी या कंटेनर पर्यावरण चर प्रकाशित नहीं हैं। लॉग साझा करते समय केवल आवश्यक समय, त्रुटि कोड और कार्य नाम निकालने से कारण समझना भी आसान होता है।

दूसरी ड्राइव पर जाने से पहले क्या तय करें

हमारी कमी यह थी कि ChatGPT रोकने और बैकअप पर ध्यान रहा, लेकिन D ड्राइव पर पहले से चल रहे Docker और Unity पर असर को स्थानांतरण से पहले के निर्देशों में पर्याप्त जगह नहीं मिली। भविष्य के ऐसे काम में बंद करने का दायरा पूरी ड्राइव के स्तर पर जाँचा जाएगा।

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 दोबारा स्थापित या उसका पंजीकरण नहीं हटाया गया। पहले विफलता के समय के लॉग जाँचना सहेजे डेटा की सुरक्षा के लिए बेहतर है।

क्या इसका अर्थ D ड्राइव की SSD खराब हो गई?

हमें Storage Service द्वारा D ड्राइव डिसमाउंट करने का प्रत्यक्ष रिकॉर्ड मिला। उसी समय भौतिक डिस्क हटने के रिकॉर्ड नहीं मिले। इस मामले को SSD खराब होने का प्रमाण मानने का आधार नहीं है।

क्या Windows की अंतर्निहित ऐप स्थानांतरण सुविधा से बचना चाहिए?

पैकेज दूसरी वॉल्यूम पर ले जाना Windows की समर्थित सुविधा है। इस अनुभव के आधार पर उसी गंतव्य वाले ऐप चालू छोड़ने के बजाय उन्हें रोकने, बैकअप और कामकाज जाँचने का समय रखा जाएगा।

Docker शुरू हो जाए तो क्या सब कुछ बहाल मान सकते हैं?

इंजन का जवाब और प्रत्येक कंटेनर की सेवाएँ व डेटाबेस सामग्री अलग बातें हैं। हमने इंजन बहाली और सूची प्राप्त करना जाँचा; आवश्यक प्रोजेक्ट की कार्यात्मक जाँच अलग है।