بعد تحديث Claude Desktop (على Windows) مباشرةً، تؤدي محاولة تشغيل التطبيق إلى ظهور مربّع حوار مكتوب فيه "يوجد برنامج آخر يستخدم هذا الملف حاليًا" ولا يبدأ التطبيق — ويبقى معطّلاً حتى تُعيد تشغيل الحاسوب. هذه علّة معروفة مُبلَّغ عنها في إصدار متجر Microsoft (MSIX) من Claude Desktop (GitHub #53247 وغيره).

لنبدأ بالخلاصة أولاً. إعادة تشغيل الحاسوب بالكامل ليست ضرورية بالضرورة. في كثير من الحالات يكفي تسجيل الخروج من Windows ثم الدخول مجدداً لاستعادة التشغيل (لا إعادة تشغيل الحاسوب، ولا تسجيل الخروج من Claude). في ما يلي نفصل ما ينفع، وما لا ينفع، وحقيقة الخطأ فعلاً، مقسّمةً إلى مؤكد / مُرجَّح / غير مؤكد. يستند هذا المقال إلى سجلّات فحص من جهاز واحد (Windows 11 Home، 10.0.26200) جرت مقارنتها بمشكلات GitHub المعروفة.

⚠️ مستويات الثقة في هذا المقال: ✅ مؤكد = تم التحقق منه مباشرةً في سجلّات الجهاز أو في مشكلة مُبلّغ عنها / 🟡 مُرجَّح = تفسير مبني على قرائن ظرفية / 🔴 غير مؤكد = لم يُحسم. لا نجزم بما لا نستطيع إثباته، مثل "السبب هو قفل ملف".

0x80070020 · APPMODEL-RUNTIME 215 / 208

ترتيب الاستعادة الذي يُجرَّب أولاً

① سجّل الخروج من Windows ← ثم الدخول
ابدأ ← أيقونة المستخدم ← "تسجيل الخروج". الأسرع؛ وقد لا تلزم إعادة تشغيل الحاسوب بالكامل (#53247)
② أعد تشغيل الحاسوب
موثوق لكنه ثقيل. عندما لا يُعيد ① التشغيل
③ انتقل إلى إصدار Squirrel
حل دائم يوقف التكرار (مُبلِّغ #57221)

1. الخلاصة — سجّل الخروج من Windows أولاً لاستعادة التشغيل

الضرر الفعلي من هذه العلّة هو "تعذّر التشغيل"، لكن استعادته لا تتطلب بالضرورة إعادة تشغيل الحاسوب بالكامل. وفق التحليل في #53247، فإن "المقبض المُعلَّق" الكامن وراء المشكلة يبقى لكل جلسة مستخدم Windows، لذا فإن مجرّد تسجيل الخروج من Windows ثم الدخول مجدداً يُزيله. معظم الناس يُعيدون تشغيل الحاسوب بالكامل بشكل انعكاسي، ولذلك يوفّر هذا وقتاً.

"تسجيل الخروج" يعني من Windows — لا إعادة تشغيل الحاسوب، ولا تسجيل الخروج من Claude

تسجيل الخروج المقصود هنا هو تسجيل الخروج من حساب مستخدم Windows (ابدأ ← أيقونة المستخدم أسفل اليسار ← "تسجيل الخروج"). تُغلَق التطبيقات المفتوحة، لكن لا يُطفأ الحاسوب، وهو أسرع من إعادة التشغيل. إنه ليس تسجيل الخروج من تطبيق/حساب Claude، وليس إعادة تشغيل التطبيق — فتلك لا تُصلح المشكلة.

  • ✅ تريد إصلاحه الآن: سجّل الخروج ← ثم الدخول. هناك حالات مُبلَّغ عنها يعود فيها التطبيق للعمل بهذا (#53247).
  • ✅ تريد إصلاحه بشكل مؤكّد: أعد تشغيل الحاسوب. ثقيل، لكنه موثوق.
  • ✅ تريد إيقاف تكراره: تخلَّ عن إصدار MSIX وانتقل إلى إصدار Squirrel (المُثبِّت) (أدناه؛ وفق مُبلِّغ #57221).

2. العَرَض — يظهر عند التشغيل بعد التحديث

التسلسل النموذجي: بعد تطبيق تحديث Claude Desktop، يؤدي فتح التطبيق إلى ظهور مربّع حوار على نمط مستكشف Windows مكتوب فيه "يوجد برنامج آخر يستخدم هذا الملف حاليًا"، ولا يبدأ التطبيق. الإغلاق وإعادة الفتح يعطيان النتيجة نفسها، ولا يعود إلى العمل حتى إعادة تشغيل الحاسوب (أو تسجيل الخروج).

والأهم أن صياغة مربّع الحوار هذا لا تعكس بدقّة ما يجري فعلاً (التفاصيل في §4). كذلك، فإن التحديث نفسه نجح — ما يفشل ليس التحديث بل "تشغيل التطبيق". يؤثر هذا في إصدار متجر Microsoft (MSIX) من Claude Desktop.

3. الحل — ما ينفع وما لا ينفع

هنا يكمن أكبر فخّ. تجد في أنحاء الويب ادّعاءات من نوع "إيقاف الخدمة يُصلحها"، لكن في هذه العلّة يُبلَّغ عن أنها لا تنفع. لنفصل بوضوح ما ينفع عمّا لا ينفع.

✅ ينفع (مُبلَّغ عنه)
  • سجّل الخروج من Windows ← ثم الدخول (الأسرع؛ وقد لا تلزم إعادة تشغيل الحاسوب)
  • أعد تشغيل الحاسوب (موثوق)
  • انتقل إلى إصدار Squirrel (دائم؛ يمنع التكرار)
🔴 مُبلَّغ عن أنه لا ينفع (لا يُنصَح به)
  • Stop-Service CoworkVMService (تُعاد تشغيلها ويتكرر الخطأ)
  • taskkill على جميع عمليات Claude/Cowork
  • Reset-AppxPackage / Add-AppxPackage -Register
  • إعادة تشغيل AppXSvc وClipSVC وvmcompute وغيرها

العناصر الموجودة على الجهة اليمنى مُسجَّلة على أنها جُرِّبت وفشلت في كلٍّ من #48003 و#53247. تميل إلى إهدار الوقت، لذا من المنطقي تجربة تسجيل الخروج أولاً.

حل دائم: الانتقال إلى إصدار Squirrel (المُثبِّت)

إن كان الاصطدام بهذا عند كل تحديث لا يُحتمَل، يذكر مُبلِّغ #57221 أن إلغاء تثبيت إصدار MSIX والانتقال إلى إصدار المُثبِّت (Squirrel) حلّ مشكلتَي التحديث والتشغيل معاً. خلاصة الخطوات:

  1. ألغِ تثبيت إصدار المتجر (MSIX) من Claude Desktop بالكامل.
  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]
العنصرالمعنى
0x80070020ERROR_SHARING_VIOLATION. الرمز الذي يصوغه Windows عموماً بعبارة "لا يمكن للعملية الوصول إلى الملف لأنه قيد الاستخدام من عملية أخرى". هذا هو ما يقوله مربّع الحوار حقاً.
[LaunchProcess]فشل في التشغيل، لا فشل في التحديث (فالتحديث نجح بالفعل).
موضع الفشلإنشاء حاوية Desktop AppX — وتحديداً الخطوة التي تحوّل Job Object إلى Silo.

و✅ تأكّد بالتحقّق أنه "لا وجود لقفل ملف". في #53247، أظهر الفحص باستخدام handle.exe وProcess Explorer عدم وجود قفل ملف في مساحة المستخدم. لذا فإن "لأن برنامجاً آخر يمسك بالملف" تفسير خاطئ، على الأقل كقفل في مساحة المستخدم. الحقيقة هي مشكلة في طبقة الحاوية (Job/Silo) لـ AppX/Desktop Bridge.

5. تفسيران متنافسان، لم يُحسم الأمر بعد

"مشكلة في طبقة الحاوية" أمر مؤكد، لكن هناك رأيان حول المُحفِّز، ولم يُحسم الأمر. نتجنّب الجزم بأحدهما ونعرض كليهما.

الرأي أ: الخدمة تمسك بـ Job Object (#57221)

الخدمة المُرفَقة CoworkVMService (حساب SYSTEM، تشغيل تلقائي) تمسك بـ Job Object الخاص بالحزمة وتمنع إنشاء حاوية الحزمة الجديدة. على الجهاز، وقع الخطأ في الثانية نفسها التي أُعيد فيها تثبيت الخدمة، وهو ما يتّسق مع هذا الرأي (🟡 قرينة ظرفية).

الرأي ب: تعطُّل عند البدء يتخطّى التنظيف (#53247)

إن تعطّلت عملية Claude عند البدء، لا يُنفَّذ تنظيف Silo/Job على جانب النواة ويبقى مقبض مُعلَّق. عندئذٍ تفشل عمليات التشغيل اللاحقة في تحويل مهمة الحزمة نفسها. وكون تسجيل الخروج يُصلحها يتّسق مع هذا الرأي.

لاحظ التوتّر: لو كان الرأي أ (إمساك الخدمة) صحيحاً، لوجب أن يُصلحها "إيقاف الخدمة" — لكن يُبلَّغ عن أنه لا يُصلحها (§3). بسبب هذا التناقض، لم يُحسم أيّهما الأساسي. 🔴 في الوقت الراهن، عرض الرأيين معاً هو الموقف الصادق.

كذلك، فإن هذا العَرَض مؤكَّد عبر لغات مختلفة. مُبلِّغ #53247 على بيئة بالبرتغالية، حيث يظهر مربّع الحوار مكتوباً فيه "Há um outro programa usando este arquivo no momento" (يوجد برنامج آخر يستخدم هذا الملف حاليًا) — وهو العَرَض نفسه الوارد في صياغة الإنجليزية/اليابانية.

🔴 حالة الإصلاح الرسمي: عند وقت الفحص، لم يُطلَق أي إصلاح رسمي دائم. المشكلة المحورية #53247 لا تزال مفتوحة (بلا مُكلَّف). في المشكلة، تُقترَح إصلاحات دائمة — تغيير CoworkVMService من التشغيل التلقائي إلى عند الطلب (Manual)، أو نقل ثنائي الخدمة إلى خارج WindowsApps — لكنها في مرحلة الاقتراح.

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 الوارد في هذا المقال (فشل تشغيل)، لذا افصل بينها.

العَرَضالرمزالفرق عن هذه العلّة
هذا المقال: لا يبدأ بعد التحديث0x80070020
فشل التحديث (#49655)0x80073CF6فشل تحديث، لا تشغيل. رمز مختلف.
تعثُّر إعادة التثبيت عند "Servicing" (#51132)0x80073D28، إلختعطُّل في النشر. رمز مختلف.

كذلك، عند تحديث Claude Code CLI (ملف claude.exe الذي يديره تطبيق سطح المكتب)، قد ترى EPERM: operation not permitted, unlink ... claude.exe، لكن ذلك مجرّد فشل في حذف الإصدار القديم — فالإصدار الجديد ثُبِّت بنجاح — وهو غير مرتبط بهذه العلّة.

الخلاصة

  • ✅ سجّل الخروج من Windows ← ثم الدخول أولاً: الاستعادة لا تتطلب بالضرورة إعادة تشغيل الحاسوب بالكامل (#53247). إن فشل ذلك، أعد تشغيل الحاسوب.
  • 🔴 إيقاف الخدمة أو إعادة تسجيلها مُبلَّغ عن أنه لا ينفع: يميل إلى إهدار الوقت، لذا تجنّبه.
  • ✅ السبب الحقيقي ليس "قفل ملف": إنه فشل في طبقة حاوية AppX (تحويل Job ← Silo). صياغة مربّع الحوار لا تعكس الواقع.
  • 🔴 للمُحفِّز تفسيران لم يُحسما: إمساك الخدمة (#57221) مقابل تعطُّل عند البدء ← مقبض مُعلَّق (#53247). لا إصلاح رسمي بعد.
  • ✅ الحل الدائم هو الانتقال إلى إصدار Squirrel: مُبلَّغ عن أنه يحلّ مشكلتَي التحديث والتشغيل (#57221).

يستند هذا المقال إلى سجلّات فحص من جهاز واحد (Windows 11 Home، 10.0.26200) جرت مقارنتها بمشكلات GitHub. استخدمه واضعاً في الحسبان، بصراحة، أنه قد لا يتكرر بالطريقة نفسها لدى كل مستخدم وأن التفاصيل الدقيقة للسبب تبقى غير محسومة.

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

س1. ما أسرع طريقة لإصلاحه؟

سجّل الخروج من Windows مرّةً ثم ادخل مجدداً (ابدأ ← أيقونة المستخدم ← "تسجيل الخروج"). إنه ليس إعادة تشغيل للحاسوب، وليس تسجيل خروج من تطبيق/حساب Claude. وفق #53247، فإن المقبض المُعلَّق الكامن وراءه يبقى لكل جلسة مستخدم Windows، لذا قد لا تلزم إعادة تشغيل الحاسوب بالكامل. إن ظلّ لا يعود، أعد تشغيل الحاسوب.

س2. رأيت "فقط أوقف الخدمة" — هل ينفع ذلك؟

في هذه العلّة يُبلَّغ عن أنه لا ينفع (#48003، #53247). Stop-Service CoworkVMService تُعاد تشغيلها ويتكرر الخطأ، كما أن Reset-AppxPackage وإعادة تشغيل الخدمات المختلفة لم تحلّها أيضاً. من الأجدى تجربة تسجيل الخروج أولاً.

س3. هل الملف مقفول فعلاً؟

لا. يُقرأ مربّع الحوار وكأن "الملف قيد الاستخدام"، لكن أكّد التحقّق (handle.exe / Process Explorer) عدم وجود قفل ملف في مساحة المستخدم (#53247). الحقيقة فشل في طبقة الحاوية (تحويل Job Object ← Silo) لـ AppX/Desktop Bridge؛ والرمز العام 0x80070020 (ERROR_SHARING_VIOLATION) يُصاغ ببساطة بتلك الطريقة.

س4. فما السبب في نهاية المطاف؟

مشكلة طبقة الحاوية مؤكدة، لكن للمُحفِّز تفسيران لم يُحسما: (1) إمساك CoworkVMService (التشغيل التلقائي) بـ Job Object (#57221)، و(2) تعطُّل عند البدء يترك تنظيف Silo/Job دون تنفيذ فيبقى مقبض مُعلَّق (#53247). وبما أن إيقاف الخدمة لا يُصلحها، وهو ما يناقض (1)، لا يمكن الجزم في الوقت الراهن.

س5. هل هناك إصلاح رسمي؟

عند وقت الفحص، لم يُطلَق أي إصلاح رسمي دائم. المشكلة المحورية #53247 لا تزال مفتوحة. في المشكلة، تُقترَح إصلاحات دائمة مثل تغيير الخدمة إلى التشغيل عند الطلب (Manual)، لكنها في مرحلة الاقتراح.

س6. هل يحدث عند كل تحديث؟

🔴 لا يمكن الجزم. على الجهاز كان هناك انطباع بأنه "يحدث عند كل تحديث"، ومع ذلك أظهره سجلّ الأحداث في تحديثين فقط من أصل 6 (ربما محيت السجلّات الأقدم بسبب حدّ حجم السجلّ، فبقي الأمر غير محدَّد). قد يتفاوت التكرار بحسب الجهاز.

س7. كيف أمنع تكراره؟

هناك تقرير بأن التخلّي عن إصدار MSIX (المتجر) والانتقال إلى إصدار Squirrel (المُثبِّت) حلّ مشكلتَي التحديث والتشغيل معاً (#57221). تُلغي تثبيت إصدار المتجر بالكامل، ثم تُثبّت إصدار المُثبِّت من الموقع الرسمي أو عبر winget. إن كانت لديك قيود مثل سياسة توزيع مؤسسية، فتحقّق أولاً.

مقالات ذات صلة