Claude Desktop 0x80070020: अपडेट के बाद लॉन्च नहीं होता

Claude Desktop (Windows) को अपडेट करने के तुरंत बाद जब आप ऐप लॉन्च करने की कोशिश करते हैं, तो "यह फ़ाइल किसी अन्य प्रोग्राम द्वारा उपयोग में है" लिखा एक डायलॉग आता है और ऐप शुरू नहीं होता — और PC रीस्टार्ट करने तक यह ठीक नहीं होता। यह Claude Desktop के Microsoft Store (MSIX) बिल्ड के लिए रिपोर्ट किया गया एक ज्ञात बग है (GitHub #53247 और अन्य)।

पहले निष्कर्ष बता देते हैं। पूरा PC रीस्टार्ट करना ज़रूरी नहीं है। कई मामलों में केवल Windows से साइन आउट करके वापस साइन इन करने से ही यह ठीक हो जाता है (PC रीस्टार्ट नहीं, और Claude से लॉग आउट भी नहीं)। नीचे हम क्या काम करता है, क्या नहीं, और एरर असल में क्या है इसे पुष्ट / अनुमानित / अपुष्ट में बाँटकर समझाते हैं। यह लेख एक ही मशीन (Windows 11 Home, 10.0.26200) के जाँच लॉग पर आधारित है, जिसे ज्ञात GitHub issues के साथ मिलाकर परखा गया है।

1. निष्कर्ष — रिकवरी के लिए पहले Windows से साइन आउट करें

इस बग से असली नुकसान "लॉन्च न होना" है, लेकिन इसे ठीक करने के लिए ज़रूरी नहीं कि पूरा PC रीस्टार्ट किया जाए। #53247 के विश्लेषण के अनुसार, समस्या के पीछे जो "अनाथ हैंडल" (orphaned handle) है वह प्रति Windows यूज़र सेशन बना रहता है, इसलिए केवल Windows से साइन आउट करके वापस साइन इन करने से ही वह साफ़ हो जाता है। ज़्यादातर लोग सहज रूप से पूरा PC रीस्टार्ट कर देते हैं, इसलिए इससे वह समय बचता है।

• ✅ अभी ठीक करना चाहते हैं: साइन आउट → साइन इन। ऐसे मामले रिपोर्ट हुए हैं जहाँ इससे ऐप फिर से लॉन्च होने लगा (#53247)।
• ✅ पक्का ठीक करना चाहते हैं: PC रीस्टार्ट करें। भारी, पर भरोसेमंद।
• ✅ दोबारा होने से रोकना चाहते हैं: MSIX बिल्ड छोड़कर Squirrel (इंस्टॉलर) बिल्ड पर स्विच करें (नीचे; #57221 रिपोर्टर के अनुसार)।

2. लक्षण — अपडेट के बाद लॉन्च करने पर दिखता है

सामान्य क्रम यह है: Claude Desktop का अपडेट लागू होने के बाद, ऐप खोलने पर Windows Explorer जैसा एक डायलॉग "यह फ़ाइल किसी अन्य प्रोग्राम द्वारा उपयोग में है" दिखाता है, और यह लॉन्च नहीं होता। बंद करके फिर खोलने पर भी वही होता है, और PC रीस्टार्ट (या साइन आउट) तक यह ठीक नहीं होता।

अहम बात यह है कि इस डायलॉग के शब्द असल में जो हो रहा है उसे सही तरह नहीं दर्शाते (विवरण §4 में)। साथ ही, अपडेट खुद सफल हुआ था — जो विफल होता है वह अपडेट नहीं बल्कि "ऐप का लॉन्च" है। यह Claude Desktop के Microsoft Store (MSIX) बिल्ड को प्रभावित करता है।

3. समाधान — क्या काम करता है और क्या नहीं

यही सबसे बड़ा जाल है। इंटरनेट पर आपको "सर्विस बंद करने से ठीक हो जाता है" जैसे दावे मिलेंगे, लेकिन इस बग के लिए वे काम नहीं करते, ऐसा रिपोर्ट हुआ है। आइए साफ़-साफ़ बाँटें कि क्या काम करता है और क्या नहीं।

दाईं ओर के आइटम #48003 और #53247 दोनों में आज़माए गए और विफल रहे के रूप में दर्ज हैं। ये समय बर्बाद करते हैं, इसलिए पहले साइन आउट आज़माना समझदारी है।

स्थायी समाधान: Squirrel (इंस्टॉलर) बिल्ड पर स्विच करें

अगर हर अपडेट पर यह झेलना असहनीय है, तो #57221 रिपोर्टर बताते हैं कि MSIX बिल्ड को अनइंस्टॉल करके इंस्टॉलर (Squirrel) बिल्ड पर स्विच करने से अपडेट और लॉन्च दोनों समस्याएँ हल हो गईं। चरणों का सार:

1. Claude Desktop के Store (MSIX) बिल्ड को पूरी तरह अनइंस्टॉल करें।
2. इंस्टॉलर बिल्ड को आधिकारिक Claude डाउनलोड से या winget के ज़रिए (जैसे winget install Anthropic.Claude) इंस्टॉल करें।
3. उसके बाद ऑटो-अपडेट इसे नवीनतम संस्करण तक ले आता है।

🟡 दिया गया तर्क यह है कि इससे C:\Program Files\WindowsApps और AppX कंटेनर लेयर की बाध्यताओं के बाहर निकल जाते हैं। व्यवहार परिवेश के अनुसार भिन्न हो सकता है, इसलिए स्विच करने से पहले अपने उपयोग-प्रसंग (एंटरप्राइज़ वितरण नीति आदि) की जाँच करें।

4. एरर की असल पहचान — यह फ़ाइल लॉक नहीं है (पुष्ट)

डायलॉग ऐसे पढ़ा जाता है जैसे "फ़ाइल उपयोग में है", लेकिन मशीन लॉग में विफलता कहीं और है। Microsoft-Windows-AppModel-Runtime/Admin इवेंट लॉग निम्नलिखित दर्ज करता है (✅ मशीन पर पुष्ट):

Event ID 215:
0x80070020: Cannot create the Desktop AppX container for package
            Claude_..._x64__pzs8sxrjxfjjc
            because an error was encountered converting the job.

Event ID 208:
0x80070020: Cannot create the process for package ... [LaunchProcess]

और ✅ यह सत्यापित हो चुका है कि "कोई फ़ाइल लॉक मौजूद नहीं है।" #53247 में, handle.exe और Process Explorer से जाँचने पर यूज़र-स्पेस में कोई फ़ाइल लॉक नहीं मिला। इसलिए "क्योंकि कोई अन्य प्रोग्राम फ़ाइल को पकड़े हुए है" यह गलत है, कम से कम यूज़र-स्पेस लॉक के रूप में। असली बात AppX/Desktop Bridge की कंटेनर लेयर (Job/Silo) में एक समस्या है।

5. दो प्रतिस्पर्धी व्याख्याएँ, अभी अनिर्णीत

"कंटेनर-लेयर की समस्या" पुष्ट है, लेकिन ट्रिगर को लेकर दो मत हैं, और यह तय नहीं हुआ है। हम किसी एक का दावा करने से बचते हैं और दोनों प्रस्तुत करते हैं।

इस विरोधाभास पर ध्यान दें: अगर मत A (सर्विस पकड़े रखना) सही होता, तो "सर्विस बंद करने" से ठीक हो जाना चाहिए — पर रिपोर्ट है कि ऐसा नहीं होता (§3)। इस अंतर्विरोध के कारण, कौन-सा प्रमुख है यह तय नहीं है। 🔴 फ़िलहाल, दोनों प्रस्तुत करना ही ईमानदार रुख है।

साथ ही, यह लक्षण कई भाषाओं में पुष्ट है। #53247 का रिपोर्टर पुर्तगाली परिवेश में है, जहाँ डायलॉग "Há um outro programa usando este arquivo no momento" (एक अन्य प्रोग्राम इस समय इस फ़ाइल का उपयोग कर रहा है) पढ़ा जाता है — यह अंग्रेज़ी/जापानी शब्दों जैसा ही लक्षण है।

6. अपनी मशीन पर खुद जाँचें (PowerShell)

आप जाँच सकते हैं कि आपकी समस्या इस लेख जैसी ही है या नहीं (एडमिन अधिकार की ज़रूरत नहीं)। अगर इवेंट 215/208 और 0x80070020 दिखते हैं, तो यह वही समस्या है।

Get-WinEvent -LogName 'Microsoft-Windows-AppModel-Runtime/Admin' |
  Where-Object { $_.Message -match 'Claude' } |
  Select-Object TimeCreated, Id, Message | Format-List

अपने अपडेट इतिहास से मिलान करने के लिए, और साथ आने वाली सर्विस की मौजूदा सेटिंग्स देखने के लिए:

Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' |
  Where-Object { $_.Message -match 'Claude' } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" |
  Select-Object Name, StartMode, State, PathName

7. आसानी से भ्रमित होने वाली अलग समस्याएँ

Claude Desktop (Windows) में मिलते-जुलते कोड वाले अन्य बग भी हैं जो आसानी से भ्रमित कर देते हैं। वे इस लेख के 0x80070020 (एक लॉन्च विफलता) से अलग हैं, इसलिए इन्हें अलग रखें।

साथ ही, जब Claude Code CLI (वह claude.exe जिसे डेस्कटॉप ऐप प्रबंधित करता है) अपडेट होता है, तो आपको EPERM: operation not permitted, unlink ... claude.exe दिख सकता है, पर वह केवल पुराने संस्करण को हटाने में विफलता है — नया ठीक से इंस्टॉल हो गया — और इस बग से असंबंधित है।

सारांश

• ✅ पहले Windows से साइन आउट → साइन इन करें: रिकवरी के लिए पूरा PC रीस्टार्ट ज़रूरी नहीं (#53247)। अगर वह विफल हो, तो PC रीस्टार्ट करें।
• 🔴 सर्विस बंद करना/पुनः-रजिस्टर करना काम नहीं करता, ऐसी रिपोर्ट है: यह समय बर्बाद करता है, इसलिए इससे बचें।
• ✅ असली कारण "फ़ाइल लॉक" नहीं है: यह AppX कंटेनर लेयर (Job→Silo रूपांतरण) में विफलता है। डायलॉग के शब्द वास्तविकता नहीं दर्शाते।
• 🔴 ट्रिगर की दो अनिर्णीत व्याख्याएँ हैं: सर्विस-पकड़ना (#57221) बनाम स्टार्टअप-क्रैश → अनाथ-हैंडल (#53247)। अभी कोई आधिकारिक फिक्स नहीं।
• ✅ स्थायी समाधान Squirrel बिल्ड पर स्विच करना है: अपडेट और लॉन्च दोनों समस्याएँ हल करने की रिपोर्ट है (#57221)।

यह लेख एक ही मशीन (Windows 11 Home, 10.0.26200) के जाँच लॉग को GitHub issues के साथ मिलाकर परखने पर आधारित है। कृपया इसे यह जानते हुए उपयोग करें, ईमानदारी से, कि यह हर उपयोगकर्ता के लिए एक जैसा पुनरुत्पन्न न हो और कारण के बारीक विवरण अभी अनिर्णीत हैं।

FAQ

Q1. इसे ठीक करने का सबसे तेज़ तरीका क्या है?

Windows से एक बार साइन आउट करके वापस साइन इन करें (Start → अपना यूज़र आइकन → "Sign out")। यह PC रीस्टार्ट नहीं है, और Claude ऐप/अकाउंट से लॉग आउट भी नहीं है। #53247 के अनुसार, इसके पीछे का अनाथ हैंडल प्रति Windows यूज़र सेशन बना रहता है, इसलिए पूरा PC रीस्टार्ट ज़रूरी नहीं हो सकता। अगर फिर भी ठीक न हो, तो PC रीस्टार्ट करें।

Q2. मैंने देखा "बस सर्विस बंद कर दो" — क्या वह काम करता है?

इस बग के लिए रिपोर्ट है कि यह काम नहीं करता (#48003, #53247)। Stop-Service CoworkVMService फिर से चालू हो जाती है और एरर दोबारा होता है, और Reset-AppxPackage तथा विभिन्न सर्विस को रीस्टार्ट करने से भी हल नहीं हुआ। पहले साइन आउट आज़माना ज़्यादा समझदारी है।

Q3. क्या फ़ाइल सचमुच लॉक है?

नहीं। डायलॉग ऐसे पढ़ा जाता है जैसे "फ़ाइल उपयोग में है", पर सत्यापन (handle.exe / Process Explorer) ने पुष्टि की कि यूज़र-स्पेस में कोई फ़ाइल लॉक नहीं है (#53247)। असली बात AppX/Desktop Bridge की कंटेनर लेयर (Job Object → Silo रूपांतरण) में विफलता है; सामान्य कोड 0x80070020 (ERROR_SHARING_VIOLATION) को बस उसी तरह दिखाया जाता है।

Q4. तो आख़िरकार कारण क्या है?

कंटेनर-लेयर की समस्या पुष्ट है, पर ट्रिगर की दो अनिर्णीत व्याख्याएँ हैं: (1) CoworkVMService (ऑटो-स्टार्ट) का Job Object को पकड़े रखना (#57221), और (2) स्टार्टअप क्रैश से Silo/Job सफ़ाई न होकर एक अनाथ हैंडल बचा रहना (#53247)। चूँकि सर्विस बंद करने से ठीक नहीं होता, जो (1) का खंडन करता है, इसलिए फ़िलहाल निश्चित रूप से नहीं कहा जा सकता।

Q5. क्या कोई आधिकारिक फिक्स है?

जाँच के समय, कोई आधिकारिक स्थायी फिक्स जारी नहीं हुआ है। केंद्रीय issue #53247 अभी भी Open है। issue पर सर्विस को ऑन-डिमांड (Manual) स्टार्ट में बदलने जैसे स्थायी फिक्स प्रस्ताव चरण में हैं।

Q6. क्या यह हर अपडेट पर होता है?

🔴 निश्चित रूप से नहीं कहा जा सकता। मशीन पर ऐसा एहसास था कि "यह हर अपडेट पर होता है", फिर भी इवेंट लॉग ने इसे 6 अपडेट में से केवल 2 में दिखाया (पुराने रिकॉर्ड लॉग की आकार-सीमा के कारण हट गए हो सकते हैं, इसलिए यह अनिर्धारित है)। आवृत्ति मशीन के अनुसार भिन्न हो सकती है।

Q7. इसे दोबारा होने से कैसे रोकूँ?

एक रिपोर्ट है कि MSIX (Store) बिल्ड छोड़कर Squirrel (इंस्टॉलर) बिल्ड पर स्विच करने से अपडेट और लॉन्च दोनों समस्याएँ हल हो गईं (#57221)। आप Store बिल्ड को पूरी तरह अनइंस्टॉल करते हैं, फिर आधिकारिक साइट से या winget के ज़रिए इंस्टॉलर बिल्ड इंस्टॉल करते हैं। अगर आपके पास एंटरप्राइज़ वितरण नीति जैसी बाध्यताएँ हैं, तो पहले जाँच लें।

संबंधित लेख

• Claude Code "Response stalled mid-stream" एरर — एक अन्य ज्ञात एरर का कारण और समाधान
• Claude Code "Output blocked" एरर — कंटेंट फ़िल्टर पर रुक जाना