ارتفاع IO في حاوية تطوير VS Code: شرح تكوين executeInWSL وتحليل السبب الجذري

تسجيل عملية التحقيق الكاملة لمشكلة ارتفاع IO الناتجة عن ملحق Dev Container في VS Code على Windows، من تحديد الأعراض إلى تحليل السبب الجذري، وأخيراً حل مشكلة اختناق اتصال Docker CLI عبر الحدود باستخدام dev.containers.executeInWSL كحل أساسي.

Friday, April 03, 2026

Categories:

عند استخدام ملحق Dev Container في VS Code للتطوير المبني على الحاويات على Windows، قد يواجه بعض المستخدمين تباطؤاً ملحوظاً في النظام. يمكن ملاحظة ارتفاع مستمر في CPU وIO القرص لعملية Extension Host في إدارة المهام، حتى في حالة عدم وجود أي نشاط نشط من المستخدم. يسجل هذا المستند عملية التحقيق الكاملة، بدءاً من الأعراض ووصولاً إلى تحديد السبب الجذري وإيجاد الحل الأساسي.

الأعراض

يحدث تباطؤ النظام بعد الاتصال بحاوية التطوير عبر الملحق. يمكن ملاحظة ارتفاع مستمر في IO القرص ومعدل استخدام CPU لعملية Extension Host في إدارة المهام، حتى عندما لا يقوم المستخدم بأي عمليات تحرير أو طرفية. في الحالات القصوى، تتأثر سرعة استجابة سطح مكتب Windows بالكامل، ويظهر مؤشر الماوس توقفات متقطعة.

عملية التحقيق

استخدام Process Monitor لتحديد مصدر IO

أداة Sysinternals Process Monitor هي الخطوة الأولى للتحقيق في مثل هذه المشكلات. بعد تشغيل procmon، قم بتعيين شروط التصفية لـ Process Name is Code.exe أو Process Name is Extension Host لمراقبة جميع عمليات ReadFile/WriteFile في الوقت الفعلي. في نتائج التصفية، تظهر عمليات named pipe التي تبدأ المسار بـ \\pipe\ بتردد غير طبيعي، عشرات المرات في الثانية. تمثل عمليات named pipe هذه الاتصال بين Docker CLI وDocker daemon، مما يشير إلى أن Extension Host يستدعي Docker CLI بشكل متكرر.

استخدام أدوات VS Code المدمجة للتأكيد

عبر فتح Chromium DevTools باستخدام Help > Toggle Developer Tools، وتسجيل ملف تعريف CPU في لوحة Performance، يمكن ملاحظة أن Extension Host يقضي معظم وقته في إنشاء العمليات الفرعية وقراءة أنابيب stdout. عند تعيين مستوى سجل “Dev Containers” في لوحة Output إلى “trace”، يمكن رؤية تسلسل الاستدعاءات الكامل: يتم تنفيذ أوامر docker inspect --type container، docker version --format، docker exec، docker ps بشكل متكرر. من بيانات السجل في issue #9194، يمكن تحديد تكلفة الاستدعاء الفردي: يستغرق docker inspect --type container حوالي 1800 مللي ثانية، وdocker version حوالي 620 مللي ثانية.

استخدام Windows Performance Analyzer لتحليل IO على مستوى النظام

للتحقيق الأعمق، ابدأ تسجيل ETW باستخدام wpr.exe -start GeneralProfile -filemode، ثم بعد إعادة إنتاج المشكلة، أوقف التسجيل باستخدام wpr.exe -stop capture.etl، ثم قم بتحميل النتائج في Windows Performance Analyzer. تؤكد طريقة عرض Disk I/O أن Extension Host هو المساهم الرئيسي في IO القرص، وتظهر طريقة عرض Process Life Cycle عدداً كبيراً من العمليات الفرقية قصيرة العمر التي يتم إنشاؤها وتدميرها بشكل متكرر، وهذه العمليات الفرعية هي حالات استدعاء Docker CLI.

تحليل السبب الجذري

بنية اتصال عمليات Dev Container

تشير نتائج التحقيق إلى بنية الاتصال متعددة العمليات في Dev Container. عندما يفتح المستخدم مساحة عمل حاوية عبر ملحق Dev Container على Windows، فإنه يبدأ فعلياً سلسلة اتصال متعددة العمليات تعبر حدود Windows وLinux.

flowchart LR
    subgraph Windows["المضيف Windows"]
        A["عميل VS Code<br/>(Electron)"]
        B["Extension Host<br/>(Node.js)"]
        C["Docker CLI<br/>(عملية فرعية)"]
    end

    subgraph WSL2["WSL2 / Docker Desktop"]
        D["Docker Daemon<br/>(dockerd)"]
    end

    subgraph Container["داخل الحاوية"]
        E["خادم VS Code"]
        F["Remote Extension Host"]
        G["عملية إعادة توجيه المنفذ<br/>(Node.js)"]
    end

    A e1@--> B
    B e2@--> C
    C e3@--> D
    B e4@--> E
    E e5@--> F
    F e6@--> G

    classDef win fill:#E3F2FD,stroke:#1565C0,stroke-width:1px,color:#0D47A1;
    classDef wsl fill:#FFF8E1,stroke:#EF6C00,stroke-width:1px,color:#E65100;
    classDef ctr fill:#E8F5E9,stroke:#2E7D32,stroke-width:1px,color:#1B5E20;
    classDef animate stroke:#EF6C00,stroke-width:2px,stroke-dasharray: 9\,5,stroke-dashoffset: 900,animation: dash 25s linear infinite;
    class A,B,C win;
    class D wsl;
    class E,F,G ctr;
    class e1,e2,e3,e4,e5,e6 animate;

يتواصل عميل VS Code المحلي (Electron) عبر IPC مع Extension Host المحلي (Node.js). يحتاج Extension Host إلى إنشاء اتصال مع خادم VS Code داخل الحاوية، ويعتمد هذا الاتصال على Docker CLI كوسيط. بعد تشغيل خادم VS Code داخل الحاوية، يتولى Remote Extension Host تنفيذ الملحقات، وتوفر عملية إعادة توجيه المنافذ نفق TCP للوصول إلى خدمات الحاوية من المتصفح المحلي. قد يصبح كل رابط في هذه السلسلة مصدراً لتضخيم IO.

آلية استطلاع Docker CLI

يحصل ملحق Dev Containers على حالة الحاوية ويحافظ عليها من خلال استدعاء أوامر Docker CLI بشكل متكرر. في مرحلة بدء الحاوية، ينفذ الملحق بالتتابع docker inspect --type container للحصول على بيانات الحاوية، وdocker version --format للتحقق من توفر Docker daemon، وdocker exec لتنفيذ أوامر استكشاف البيئة داخل الحاوية، وdocker ps لسرد الحاويات قيد التشغيل. لا يتم تنفيذ هذه الأوامر مرة واحدة فقط عند البدء، بل يتم استدعاؤها بشكل متكرر بتردد معين طوال دورة حياة الحاوية.

يتضمن كل استدعاء لـ Docker CLI إنشاء عملية فرعية جديدة، تتضمن سلسلة من عمليات IO مثل إنشاء العملية، وقراءة أنبوب stdout، وتحليل نتيجة JSON. في الوضع الافتراضي، تحتاج هذه العمليات إلى عبور حدود Windows/WSL، وأداء بروتوكول مشاركة ملفات 9P في WSL2 ضعيف عند التعامل مع IO للملفات الصغيرة والاتصالات القصيرة عالية التردد. وفقاً لـ وثائق Microsoft الرسمية، يجب تجنب عمليات الملفات العابرة للحدود قدر الإمكان، لكن تصميم بنية Dev Container يجعل من الصعب تجنب هذا الحمل تماماً.

sequenceDiagram
    participant EH as Extension Host
    participant CLI as Docker CLI
    participant DD as Docker Daemon

    EH->>CLI: spawn docker inspect
    CLI->>DD: طلب named pipe
    DD-->>CLI: استجابة JSON
    CLI-->>EH: مخرجات أنبوب stdout
    EH->>CLI: spawn docker version
    CLI->>DD: طلب named pipe
    DD-->>CLI: معلومات الإصدار
    CLI-->>EH: مخرجات أنبوب stdout
    EH->>CLI: spawn docker exec
    CLI->>DD: طلب named pipe
    DD-->>CLI: نتيجة التنفيذ
    CLI-->>EH: مخرجات أنبوب stdout

تسرب اتصال إعادة توجيه المنافذ

تنشئ آلية إعادة توجيه المنافذ في VS Code عملية فرعية Node.js مستقلة لكل منفذ يتم إعادة توجيهه. تتصل هذه العمليات بـ net.createConnection بالمنفذ المستهدف داخل الحاوية، وتعيد توجيه البيانات بشكل ثنائي بين المنفذ المحلي والمنفذ في الحاوية. المشكلة هي أنه عند قطع اتصال المتصفح أو العميل الآخر الذي يصل إلى المنفذ المعاد توجيهه، إذا لم تكن هناك آلية تنظيف في الوقت المناسب، ستستمر هذه العمليات في الوجود بدلاً من الإنهاء الطبيعي.

وفقاً لتحليل microsoft/vscode-remote-release#5767، تستهلك كل عملية إعادة توجيه منفذة تسرب حوالي 26 MiB من الذاكرة. في بيئة تطوير مكونة من عدة منافذ معادة التوجيه ويكثر فيها الوصول، يمكن أن ينمو عدد العمليات من 2 طبيعي إلى عشرات في فترة قصيرة. يوضح مقطع الكود التالي النمط الأساسي لعملية إعادة توجيه المنافذ، حيث يكون حدث client.on('close') هو المفتاح لإنهاء العملية بشكل طبيعي.

const net = require('net');
process.stdin.pause();
const client = net.createConnection({ port: 36187 }, () => {
    client.pipe(process.stdout);
    process.stdin.pipe(client);
});
client.on('close', function (hadError) {
    console.error(hadError ? 'Remote close with error' : 'Remote close');
    process.exit(hadError ? 1 : 0);
});
client.on('error', function (err) {
    process.stderr.write(err && (err.stack || err.message) || String(err));
});

عندما تنتهي عملية docker exec بشكل غير طبيعي بينما لا تزال عملية Node.js داخل الحاوية قيد التشغيل، لا يمكن إعادة تدوير هذه العمليات اليتيمة بشكل طبيعي، مما يؤدي إلى نمو مستمر في الذاكرة. تم إصلاح هذه المشكلة جزئياً في الإصدار VS Code 1.62، لكنها قد تتكرر في ظروف网络 معينة. من الجدير بالذكر أن تسرب إعادة توجيه المنافذ ليس مرتبطاً مباشرة بـ executeInWSL، بل هو خلل برمجي في آلية إعادة توجيه المنافذ في VS Code نفسها.

حلقة إعادة الاتصال لـ Extension Host

وفقاً لتسجيل microsoft/vscode-remote-release#6178، عند فقدان الاتصال بالحاوية البعيدة بسبب انقطاع الشبكة أو أسباب أخرى، يوجد خلل في منطق إعادة الاتصال في Extension Host: تستدعي دالة async نفسها بشكل متكرر في كتلة catch، مما يؤدي إلى دوران CPU فارغ. يُظهر استدعاء المكدس تكرار هذه الدالة في processTicksAndRejections بشكل متكرر دون شرط خروج.

flowchart TD
    A["فقدان الاتصال"] e1@--> B["دالة إعادة الاتصال async"]
    B e2@--> C{"هل الاتصال ناجح؟"}
    C e3@-->|نعم| D["العودة للوضع الطبيعي"]
    C e4@-->|لا| E["كتلة catch"]
    E e5@--> B

    classDef start fill:#FFEBEE,stroke:#C62828,stroke-width:1px,color:#B71C1C;
    classDef work fill:#E8F5E9,stroke:#2E7D32,stroke-width:1px,color:#1B5E20;
    classDef check fill:#FFF8E1,stroke:#EF6C00,stroke-width:1px,color:#E65100;
    classDef animate stroke:#EF6C00,stroke-width:2px,stroke-dasharray: 9\,5,stroke-dashoffset: 900,animation: dash 25s linear infinite;
    class A start;
    class B,D work;
    class C,E check;
    class e1,e2,e3,e4,e5 animate;

في الوقت نفسه، تنمو ذاكرة Extension Host بمعدل حوالي 1 ميجابايت في الدقيقة، لأن كل استدعاء متكرر يتراكم فيه سياق غير مُحرر على استدعاء المكدس. تم إصلاح هذه المشكلة في إصدار Remote-Containers 0.221.0-pre-release، لكن للمستخدمين الذين لم يقوموا بتحديث الملحق في الوقت المناسب، يكفي محاكاة انقطاع الشبكة (مثل إيقاف WiFi) لتحفيز هذه المشكلة، ولن يظهر مربع حوار提示 أبداً. هذه مشكلة خلل برمجي مستقلة غير مرتبطة بتكوين executeInWSL، لكنها ستتفاقم في تباطؤ النظام الذي يختبره المستخدم.

تضخيم IO للملفات العابرة للحدود في WSL2

عند استخدام Docker Desktop مع الواجهة الخلفية WSL2 على Windows، توجد مشكلة أداء جوهرية في IO للملفات العابرة للحدود. يتواصل ملحق VS Code على جانب Windows مع Docker daemon في WSL2 عبر pipe، وإذا تضمنت عمليات نظام الملفات داخل الحاوية الوصول إلى مسار /mnt/c (أي الوصول إلى أقراص Windows)، فإنها تحتاج إلى التحويل عبر بروتوكول مشاركة ملفات 9P. أداء بروتوكول 9P في WSL2 أقل بشكل ملحوظ من نظام الملفات الأصلي في سيناريوهات IO للملفات الصغيرة، ويمكن أن يصل زمن العملية الواحدة إلى 3-5 أضعاف المسار الأصلي.

بالإضافة إلى ذلك، وفقاً لتقرير microsoft/vscode-remote-release#9372، عند تشغيل حاوية x86 على ARM Mac عبر Rosetta، يتم تعيين قناع CPU affinity لعملية خادم VS Code بشكل غير طبيعي لاستخدام نواة واحدة فقط، مما يؤدي إلى إرجاع nproc لـ 1 بدلاً من عدد الأنوية الفعلية. على الرغم من أن هذه المشكلة تظهر بشكل رئيسي على منصة macOS، إلا أنها تكشف عن عدم اتساق في تحكم Dev Container في معلمات جدولة العمليات عبر المنصات، وقد تظهر مشاكل مماثلة في بيئة WSL2 على Windows بأشكال مختلفة. يحرك executeInWSL: true موقع تنفيذ Docker CLI إلى داخل WSL، مما يقلل من تكرار IO للملفات العابرة للحدود، لكنه لا يمكنه إزالة حمل 9P الناتج عند وصول الحاوية إلى مسار /mnt/c.

الحلول

تبسيط تكوين إعادة توجيه المنافذ

يمكن لتقليص تكوين forwardPorts في devcontainer.json للاحتفاظ فقط بالمنافذ المطلوبة فعلياً تقليل عدد عمليات إعادة توجيه المنافذ بشكل ملحوظ، مما يقلل من مخاطر تسرب العمليات الموصوف في issue #5767. إغلاق نوافذ Dev Container غير المستخدمة يمكن أن يحرر موارد Extension Host وإعادة توجيه المنافذ المقابلة فوراً.

تحسين Docker Desktop

في لوحة Settings > Resources في Docker Desktop، قم بضبط تخصيص CPU والذاكرة بشكل مناسب لتجنب قيام Docker daemon بجمع البيانات المهملة بشكل متكرر أو عمليات swap بسبب عدم كفاية الموارد. تأكد من استخدام أحدث إصدار من Docker Desktop، حيث تم تحسين أداء الواجهة الخلفية WSL2 في كل إصدار. للسيناريوهات التي تتطلب أداءً عالياً،可以考虑 تثبيت Docker Engine مباشرة داخل WSL2، تجاوز طبقةvirtualization الخاصة بـ Docker Desktop، مما يقلل بشكل أكبر من الحمل الإضافي لحدود Windows/WSL.

تحسين تكوين VS Code

يمكن لتعطيل الملحقات غير الضرورية تقليل حمل Extension Host، خاصة تلك التي تعمل في الحاوية البعيدة وتتميز بوظائف مراقبة الملفات (مثل خدمة لغة TypeScript، وESLint وما إلى ذلك). تعيين files.watcherExclude في settings.json لاستبعاد الأدلة الكبيرة مثل node_modules و.git وdist يمكن أن يقلل من IO الناتج عن مراقبة نظام الملفات. تعيين extensions.autoUpdate: false يمكن أن يمنع تحديثات الملحقات الخلفية من تحفيز عمليات الشبكة والقرص الإضافية في بيئة الحاوية.

البدائل

إذا لم تتمكن الإجراءات المذكورة أعلاه من تلبية متطلبات الأداء، يمكن النظر في استخدام ملحق VS Code Remote-SSH للاتصال بـ WSL2، واستخدام Docker CLI مباشرة داخل WSL2 لإدارة الحاويات. يحول هذا الأسلوب استدعاءات Docker CLI من اتصال عابر للحدود بين Windows/WSL إلى اتصال محلي داخل WSL2. طريقة أخرى هي استخدام Docker Compose لإدارة دورة حياة الحاويات، عبر docker compose up -d لبدء الخدمات، ثم استخدام Remote-SSH فقط للاتصال بالحاوية للتطوير، مما يتجاوز تماماً آلية استطلاع ملحق Dev Container.

تمكين executeInWSL (الحل الأساسي)

يمكن للتجراءات المذكورة أعلاه تخفيف مشكلة ارتفاع IO بدرجات متفاوتة، لكنها إما تقلل فقط من تردد IO (تبسيط إعادة توجيه المنافذ)، أو تحسن فقط تخصيص الموارد (تحسين Docker Desktop)، دون لمس السبب الجذري للمشكلة: حمل الاتصال عبر named pipe الناتج عن استدعاءات Docker CLI العابرة للحدود بين Windows/WSL. يعد dev.containers.executeInWSL حلاً مباشراً لهذا السبب الجذري.

وفقاً لتوضيح عضو فريق VS Code chrmarti في microsoft/vscode-remote-release#9194، يحدد هذا الإعداد ما إذا كان أمر docker يعمل على جانب Windows أم داخل WSL. بعد تعيينه إلى true، ستُنفذ جميع استدعاءات Docker CLI (بما في ذلك docker inspect وdocker version وdocker exec وdocker ps وما إلى ذلك) داخل WSL، وتتصل بـ Docker daemon عبر Unix socket، 从而تجاوز حمل تحويل named pipe وبروتوكول 9P على حدود Windows/WSL.

أضف التكوين التالي في settings.json للتمكين:

{
  "dev.containers.executeInWSL": true
}

لفهم سبب تحسن أداء IO بشكل ملحوظ مع هذا الإعداد، يجب مقارنة اختلاف مسارات الاتصال بين النمطين. في الوضع الافتراضي (executeInWSL: false أو غير محدد)، يعمل VS Code Extension Host على Windows، وفي كل مرة يحتاج إلى التفاعل مع Docker daemon، يقوم بـ spawn لإنشاء عملية فرعية docker.exe على Windows. تتواصل هذه العملية الفرعية عبر named pipe (المسار يبدأ بـ \\pipe\) عبر حدود Windows/WSL مع Docker daemon. يتضمن هذا المسار ثلاث مراحل: إنشاء عملية Windows، وIO named pipe العابر للحدود، وإعادة أنبوب stdout، وكل مرحلة تقدم تأخيراً وحمل IO إضافياً. عندما يكون executeInWSL: true، يقوم Extension Host بتنفيذ Docker CLI داخل WSL عبر wsl -d <distro> -e docker. يعمل Docker CLI بشكل أصلي داخل WSL، ويتواصل مع Docker daemon في نفس مثيل WSL عبر Unix socket (IPC محلي). يكتمل هذا المسار بالكامل داخل مساحة نواة Linux، مما يتجنب حمل العابر للحدود لـ named pipe.

flowchart TB
    subgraph Default["الوضع الافتراضي (executeInWSL: false)"]
        direction LR
        A1["Extension Host<br/>(Windows)"]
        A2["docker.exe<br/>(عملية فرعية لـ Windows)"]
        A3["named pipe<br/>(\\\\pipe\\\\)"]
        A4["Docker Daemon<br/>(WSL2)"]
        A1 e1@--> A2
        A2 e2@--> A3
        A3 e3@--> A4
    end

    subgraph Optimized["الوضع المحسّن (executeInWSL: true)"]
        direction LR
        B1["Extension Host<br/>(Windows)"]
        B2["wsl -e docker<br/>(داخل WSL)"]
        B3["Unix socket<br/>(IPC محلي)"]
        B4["Docker Daemon<br/>(WSL2)"]
        B1 e4@--> B2
        B2 e5@--> B3
        B3 e6@--> B4
    end

    Default ~~~ Optimized

    classDef win fill:#E3F2FD,stroke:#1565C0,stroke-width:1px,color:#0D47A1;
    classDef wsl fill:#FFF8E1,stroke:#EF6C00,stroke-width:1px,color:#E65100;
    classDef fast fill:#E8F5E9,stroke:#2E7D32,stroke-width:1px,color:#1B5E20;
    classDef animate stroke:#EF6C00,stroke-width:2px,stroke-dasharray: 9\,5,stroke-dashoffset: 900,animation: dash 25s linear infinite;

    class A1,A2 win;
    class A3,A4 wsl;
    class B1 win;
    class B2,B3,B4 fast;
    class e1,e2,e3,e4,e5,e6 animate;

يمكن التحقق من هذا التحسن من بيانات التحديد الكمي في مرحلة التحقيق: في الوضع الافتراضي، يستغرق استدعاء docker inspect --type container الفردي حوالي 1800 مللي ثانية، واستدعاء docker version حوالي 620 مللي ثانية،comes mainly from named pipe communication and process creation overhead on the Windows/WSL boundary. After enabling executeInWSL: true, Docker CLI runs inside WSL and communicates with the daemon via Unix socket, reducing single call latency to millisecond level, with particularly significant cumulative effect improvement.

المشاكل المعروفة والملاحظات

على الرغم من أن dev.containers.executeInWSL يمكن أن يحسن أداء IO بفعالية، إلا أنه يجب الانتباه للمشاكل المعروفة التالية عند استخدامه.

مشكلة البدء التلقائي لـ Docker Desktop: تم الإبلاغ في issue #9695 أنه عند executeInWSL: true لا يبدأ Docker Desktop تلقائياً. تم إصلاح هذه المشكلة في إصدار Dev Containers 0.353.0-pre-release، ويجب على المستخدمين الذين يستخدمون الإصدارات الأحدث عدم مواجهة هذه المشكلة بعد الآن.

إعادة توجيه خدمات WSL: تم الإبلاغ في issue #9194 أنه حتى عند تعيين executeInWSL إلى false، لا يزال الملحق يحاول الاتصال بـ WSL (لإعادة توجيه display/ssh-agent/gpg-agent). تم التحكم في هذا السلوك في إصدار 0.337.0-pre-release من خلال إضافة عنصر إعداد جديد dev.containers.wslServiceForwarding، ويمكن للمستخدمين إيقاف إعادة توجيه خدمات WSL بشكل مستقل.

توافق Rancher Desktop: تم الإبلاغ في issue #10722 أنه عند استخدام Rancher Desktop بدلاً من Docker Desktop، سيؤدي executeInWSL: true إلى ظهور خطأ WSL1. هذه المشكلة لا تزال في حالة open، وقد يحتاج مستخدمو Rancher Desktop إلى تعطيل هذا الإعداد مؤقتاً.

التنشيط غير المتوقع: تم الإبلاغ في issue #11005 أن executeInWSL: true سيؤدي إلى تنشيط غير متوقع لعملية تهيئة Dev Container في مستودع Windows المحلي. هذه المشكلة أيضاً في حالة open،可以考虑 تحديد هذا الإعداد لمساحة عمل معينة بدلاً من التكوين العام للمستخدمين المتأثرين.

ملخص

يتطلب التحقيق في مشكلة ارتفاع IO لـ Dev Container في VS Code على Windows البدء من الأعراض وتتبع السبب الجذري تدريجياً. من خلال Process Monitor يمكن التأكد من أن المصدر الرئيسي لـ IO هو اتصال named pipe لـ Docker CLI، ومن خلال أدوات VS Code المدمجة وWindows Performance Analyzer يمكن تحديد تردد الاستدعاء والتأخير بشكل أكبر. يكشف تحليل السبب الجذري عن أربعة عوامل متراكمة: استطلاع Docker CLI المتكرر العابر للحدود هو اختناق الأداء الرئيسي، وتسرب اتصال إعادة توجيه المنافذ ودورة إعادة الاتصال لـ Extension Host هي أخطاء برمجية مؤكدة، وتضخيم IO للملفات العابرة للحدود في WSL2 هو القيد المتأصل على مستوى المنصة.

في الحلول، dev.containers.executeInWSL: true هو الإجراء الأكثر جوهرية، حيث يقوم بإزالة مباشرة لحمل اتصال named pipe لـ Docker CLI العابر لحدود Windows/WSL، وينقل موقع تنفيذ استدعاءات CLI عالية التردد من Windows إلى داخل WSL، ويكمل IPC المحلي عبر Unix socket. serve as auxiliary measures to varying degrees in mitigating impacts from other factors. للمستخدمين المتأثرين بهذه المشكلة، يُنصح باتباع عملية التحقيق في هذا المستند لتأكيد السبب الجذري، ثم تمكين executeInWSL: true كأولوية، ثم اختيار استراتيجيات التحسين المساعدة المناسبة بناءً على السيناريو الفعلي.