كيف نسرّع فحص تطبيقات Windows بـ Windows Sandbox

في تطوير تطبيقات Windows، أسباب تباطؤ الفحص متشابهة في الغالب.

• جهاز التطوير لديك ملوَّث، فلا تتكرّر مشكلات التثبيت لأوّل مرّة
• شيء يحدث في بيئة العميل ولا يحدث على PC الخاصّ بك
• «يعمل عند تشغيله كمسؤول» يخفي الحدّ الحقيقيّ للصلاحيات المطلوبة
• تريد رؤية السلوك عند نقص الصلاحيات أو التبعيّات، دون كسر بيئتك المعتادة
• يسقط التطبيق في حالة أقرب إلى انخفاض الذاكرة أو غياب الـ GPU، لكن إنشاء VM كامل في كلّ مرّة مبالغة

في حالات كهذه، يكون Windows Sandbox عمليّاً جدّاً.

فهو أخفّ من VM كامل، ويبدأ بسرعة، ويختفي نظيفاً في كلّ مرّة تُغلقه. وهذا يجعله ملائماً للمتطلّب: «أريد إعادة بناء بيئة فحص نظيفة من نفس Windows build في دقائق».

ومع ذلك، فإنّ فتح Sandbox جديد تماماً في كلّ مرّة بلا تفكير لا يرفع الكفاءة بقدر ما يستطيع. ما ينفع فعلاً في العمل هو تشغيل ملفّ .wsb مثبت لكلّ سيناريو فحص، مع فصل مجلّد إدخال للقراءة فقط عن مجلّد استرداد للكتابة فقط، والتبديل عن قصد بين بروفيلات موجَّهة للمسؤول وللمستخدم القياسيّ وللقيود.

تنظّم هذه المقالة ذلك من منظور تطوير تطبيقات Windows تحديداً. يفترض النقاش معلومات Microsoft الرسميّة التي أمكن التأكّد منها حتّى أبريل 2026.

مقدّمات هذه المقالة

مصطلحات هذه المقالة

نرتّب أوّلاً المصطلحات التي تظهر بالإنجليزيّة كما هي.

جدول المحتويات

• الخلاصة أوّلاً
• لماذا يلائم Windows Sandbox فحص التطوير
• القيود التي ينبغي فهمها أوّلاً
• تخطيط مجلّدات يُسرِّع العمل إن أُعدّ مسبقاً
• اجعل smoke test للبيئة النظيفة نقرة مزدوجة واحدة
• إجراء عزل مشكلات صلاحيات المسؤول
• أنشئ عن قصد حالة نقص صلاحيات أو تبعيّات
• أنشئ بيئة أقرب إلى نقص الموارد
• من Windows 11 24H2 يسهل التشغيل عبر CLI أيضاً
• تنبيهات تشغيليّة لا ينبغي تخطّيها
• الخلاصة
• مقالات ذات صلة
• المراجع

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 22، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

الخلاصة أوّلاً

نضع الخلاصات أوّلاً.

• Windows Sandbox يناسب إعادة إنتاج بيئة نظيفة، وتأكيد التثبيت الأوّل، وعزل مشكلات صلاحيات المسؤول، وإظهار التبعيّات الناقصة.
• أسرع من تكرار العمل يدوياً في الواجهة في كلّ مرّة أن تقسّم ملفّات .wsb حسب الغرض.
• مشاركة المضيف تصبح أكثر أماناً إن كانت المدخلات read-only والمخرجات وحدها read-write.
• جلسة Sandbox الافتراضيّة لا تلائم فحص المستخدم القياسيّ كما هي. إن أردت فحصاً حقيقيّاً تحت مستخدم قياسيّ، فأنشئ مستخدماً آخر داخل Sandbox وشغّل التطبيق بهويّته.
• لفحص أقرب إلى نقص الذاكرة أو غياب الـ GPU، ينفع من .wsb MemoryInMB وتعطيل VGpu (مشاركة GPU الافتراضيّ).
• لكن إن أردت حصّة CPU، أو ضغط القرص بدقّة، أو عدّة instances متزامنة، أو إعادة إنتاج إصدار OS مختلف، فإنّ VM كامل أنسب من Windows Sandbox.

بكلمات أخرى، Windows Sandbox بيئة فحص خفيفة لكن للاستعمال مرّة واحدة، وسريعة لكنّها من نفس عائلة OS، ومحدودة لكنّها كافية للعمل الفعليّ. إن فهمت هذا الموقع أوّلاً، لا تخطئ موضع الاستعمال.

لماذا يلائم Windows Sandbox فحص التطوير

يلائم Windows Sandbox تطوير تطبيقات Windows لأربعة أسباب.

يمكنك إعادة كلّ شيء إلى الصفر في كلّ مرّة تُغلقه

هذه أكبر ميزة.

تجرّب المثبِّت مراراً، وتكسر الإعدادات، وتلمس السجلّ، وتُدخل المتطلّبات ثمّ تزيلها. إن فعلت ذلك على جهاز التطوير نفسه، تحوّل تدريجيّاً إلى بيئة لا أحد متأكّد ممّا هو مثبَّت فيها.

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

يمكنك الحصول بسرعة على بيئة نظيفة من نفس عائلة Windows

صُمِّم Windows Sandbox حول استعمال Windows من نفس عائلة المضيف. هذا قيد، لكنّه يعني أيضاً أنّك تستطيع الحصول بسرعة على بيئة نظيفة تطابق خطّ Windows 11 الذي تستعمله أصلاً.

إن كان العميل على Windows 11 24H2 وأنت أيضاً على Windows 11 24H2، فهذا إعداد عمليّ جدّاً.

أخفّ وأرخص في الإدارة من VM كامل

VM الكامل في Hyper-V أو VMware قويّ، لكن إن كانت المهمّة المتكرّرة شيئاً كالتالي:

• التأكّد من خطوات التثبيت
• فحص كيف تظهر مطالبات UAC
• رؤية ما يتعطّل عند نقص الصلاحيات
• جمع السجلّات حين تكون المتطلّبات المسبقة ناقصة
• إجراء smoke test في بيئة نظيفة

فإنّ VM كاملاً قد يكون أثقل ممّا تحتاجه.

يتيح لك Windows Sandbox التقدّم في فحوصات «أريد فقط إعادة إنتاج هذا بسرعة» دون جرّ إدارة ثقيلة للصور واللقطات.

تتيح ملفّات .wsb والـ CLI تثبيت السيناريو

القيمة الحقيقيّة لـ Sandbox ليست فقط أنّه آمن للتجربة، بل أنّك تستطيع إعادة المحاولة بالشروط نفسها مرّة بعد أخرى.

• الشبكة مفعَّلة أو معطَّلة
• مجلّدات مشتركة read-only / read-write
• ذاكرة أقلّ
• بلا مشاركة GPU
• بلا مشاركة الحافظة
• تشغيل سكربت معيَّن عند الـ logon

بمجرّد تثبيت تلك الشروط بملفّات .wsb أو بـ CLI من Windows 11 24H2 فما بعد، يتوقّف الفحص عن كونه عملاً ارتجاليّاً ويصبح إجراءً قابلاً للتكرار.

القيود التي ينبغي فهمها أوّلاً

هو مفيد، لكنّه ليس الأداة المناسبة لكلّ شيء. تستحقّ هذه القيود الفهم منذ البداية.

توجد قيود بحسب الإصدار

يتوفّر Windows Sandbox على إصدارات Windows Pro / Enterprise / Education. ولا يتوفّر على Home.

قد يكون جهاز التطوير Pro بينما يكون جهاز مندوب المبيعات أو الـ PC الشخصيّ Home، فيغدو ذلك عائقاً غير متوقَّع.

توجد متطلّبات للمحاكاة الافتراضيّة

تحتاج إلى تفعيل ميزات المحاكاة الافتراضيّة، مع قدر كافٍ من RAM ومساحة القرص ونوى CPU. هو خفيف، لكنّه ليس مجّانيّاً.

يبقى Sandbox في نفس عائلة OS الموجودة على المضيف

هذا يهمّ كثيراً في العمل الفعليّ.

Windows Sandbox غير مناسب للفحص مقابل إصدار OS مختلف.

• إن كان المضيف Windows 11، فلن يصبح بيئة إعادة إنتاج لـ Windows 10
• إن كان العميل يستعمل build أقدم، فلن يسدّ Sandbox تلك الفجوة

لذا إن احتجت فحوصات توافق بين الإصدارات أو مشكلات مرتبطة بـ builds أقدم، فعادةً من الأفضل البدء بـ VM كامل من الأساس.

لا يمكنك واقعيّاً تشغيل عدّة instances في وقت واحد

في الوقت الحاضر، Windows Sandbox ليس الخيار الطبيعيّ لتشغيل عدّة instances بالتوازي.

إن أردت تشغيل مصفوفة اختبار جنباً إلى جنب، فإنّ Hyper-V أو إعداد VM كامل آخر أنسب.

الشبكة ومشاركة الحافظة مفعَّلتان افتراضيّاً

من السهل التغافل عن هذه النقطة.

يفعِّل Windows Sandbox الاتّصال بالشبكة افتراضيّاً. ومشاركة الحافظة مفعَّلة افتراضيّاً أيضاً.

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

بعض تطبيقات الـ inbox غير متوفّرة على Windows 11 24H2 فما بعد

على Windows 11 24H2 فما بعد، لا يوفّر Sandbox بعض تطبيقات Store الـ inbox مثل Notepad أو Terminal أو Calculator أو Photos.

لذلك، الأكثر أماناً بناء الأتمتة وخطوات المساعدة حول cmd.exe وpowershell.exe وexplorer.exe.

تخطيط مجلّدات يُسرِّع العمل إن أُعدّ مسبقاً

بدلاً من تقرير المجلّدات المشتركة في كلّ مرّة، من الأسهل بكثير أن تنشئ مكاناً ثابتاً واحداً لأصول الفحص مسبقاً.

مثلاً:

C:\SandboxFixtures\
├─ AppUnderTest\
│  ├─ MyAppInstaller.msi
│  ├─ MyApp.exe
│  └─ sample-data\
├─ Scripts\
│  └─ Prep-StandardUser.ps1
├─ Outbox\
├─ 00-clean-smoke.wsb
├─ 10-standard-user.wsb
├─ 20-restricted-runtime.wsb
└─ 30-low-resource.wsb

دور كلّ مجلّد بسيط:

• AppUnderTest: الهدف الذي يُفحص، يُشارَك للقراءة فقط
• Scripts: سكربتات البدء، تُشارَك للقراءة فقط
• Outbox: السجلّات والـ dumps والنتائج المُصدَّرة، تُشارَك للقراءة والكتابة

عندما تُهيكل الأمر هكذا، يكون المكان الوحيد الذي يستطيع Sandbox الكتابة فيه على المضيف هو Outbox، وهذا أكثر أماناً بكثير.

كذلك يمكنك تثبيت ملفّات .wsb بحسب السيناريو:

ذلك وحده يُقلِّل تكلفة بدء الفحص كثيراً.

اجعل smoke test للبيئة النظيفة نقرة مزدوجة واحدة

أوّل ما يستحقّ الإنشاء هو بروفيل Sandbox لـ smoke test في بيئة نظيفة.

مثال: 00-clean-smoke.wsb

<Configuration>
  <Networking>Disable</Networking>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

النقاط المهمّة لهذا الاستخدام أربع:

• ضع المُنتَج في AppUnderTest
• اكشف ذلك المجلّد للقراءة فقط
• اكتب السجلّات والنتائج فقط في Outbox
• عطّل الشبكة منذ البداية إن لم ترد سلوكاً متوقّفاً عليها

بذلك الإعداد، تستطيع استبدال المُنتَج والنقر مزدوجاً على ملفّ .wsb للحصول على فحص أوّل نظيف في كلّ مرّة.

ما الذي يُعرض إن نجح البدء

عند الاستعمال الأوّل، أصعب ما يُفهم هو «إلى أين يكفي أن تصل لتعدّ الأمر ناجحاً». نرتّب زوايا التأكيد.

عند النقر المزدوج على .wsb، يُفتح سطح مكتب منفصل عن المضيف كنافذة واحدة. المحتوى Windows في حالته الابتدائيّة: الخلفية الافتراضيّة وسطح مكتب فارغ. لا تُورَّث خلفية المضيف، ولا التطبيقات المثبَّتة، ولا الحساب المسجَّل دخوله. إن وصلت إلى هنا، فالبدء نفسه نجح.

ثمّ يُنفَّذ الأمر المكتوب في LogonCommand. في 00-clean-smoke.wsb أعلاه، يُفتح Explorer داخل Sandbox ويعرض محتويات C:\Work\AppUnderTest.

هل بدأ بالتكوين المقصود يتبيّن يقيناً بتشغيل أوامر داخل Sandbox. افتح powershell.exe من قائمة Start داخل Sandbox، ونفّذ التالي بالترتيب.

# 1) 共有フォルダが意図した場所に見えているか
Get-ChildItem C:\Work

# 2) 入力側は読み取り専用のはず。エラーになれば意図どおり
New-Item -Path C:\Work\AppUnderTest\write-test.txt -ItemType File

# 3) 出力側は書き込めるはず。成功すれば意図どおり
New-Item -Path C:\Work\Outbox\write-test.txt -ItemType File

# 4) ネットワークを切ったつもりなら、通信は失敗するはず
Test-NetConnection -ComputerName www.microsoft.com -Port 443

# 5) いま誰として動いているか。既定のセッションでは管理者アカウント
whoami
whoami /groups

ملفّ write-test.txt في الخطوة 3 يظهر أيضاً على المضيف في C:\SandboxFixtures\Outbox. إن رأيته هناك، فتأكيد أنّ مسار جمع السجلّات والـ dumps مفتوح.

إن لم يسر الأمر، انظر بهذا الترتيب.

• النقر المزدوج لا يفعل شيئاً، أو يظهر خطأ ← قد يكون XML في .wsb تالفاً. اجعل أسماء العناصر مطابقة لوثائق ملفّ الإعداد في Microsoft Learn.
• لا شيء تحت C:\Work ← المسار المحدَّد في HostFolder غير موجود على المضيف. مسار المجلّد المشترك يجب أن يكون موجوداً فعلاً على المضيف.
• لا يظهر «Windows Sandbox» في قائمة Start ← لم تُستوفَ الشروط المسبقة، أو لم تُفعَّل ميزة Windows. راجع جدول المقدّمات في هذه المقالة.

المشكلات التي يميل هذا إلى كشفها

في هذه المرحلة، تلتقط غالباً أشياء مثل:

• DLL أو runtime موجود على جهاز التطوير لكنّه ليس على البيئة الهدف
• WebView2 أو حزمة VC++ القابلة لإعادة التوزيع مفترَضان ضمنيّاً
• مجلّد أو ملفّ إعداد يُنشَأ فقط عند التشغيل الأوّل يُكتب في المكان الخطأ
• بيانات وقت التشغيل تُكتب تحت Program Files فتفشل
• شهادة أو خطّ أو إعداد صدَف وجوده على جهاز المطوِّر فأصبح متطلّباً مسبقاً غير معلَن

النقطة الأساسيّة هي أن تكتب دائماً ما حدث في Sandbox خارجاً إلى Outbox. بمجرّد إغلاق Sandbox، يختفي كلّ ما بداخله، فلا ينبغي أن تبقى السجلّات والـ dumps داخل الجلسة فقط.

احتفظ بنسخة متّصلة بالشبكة في ملفّ منفصل أيضاً

إن كان الهدف web installer أو تطبيقاً بمصادقة عبر الإنترنت، فإنّ ترك الشبكة معطَّلة قد يعني أنّك ترى صنفاً آخر فقط من المشكلات.

في هذه الحالة، الأنظف إنشاء ملفّ آخر مثل 01-clean-online.wsb بنفس الشكل الأساسيّ والإبقاء على «إعادة الإنتاج دون شبكة» و«إعادة الإنتاج مع شبكة» سيناريوين منفصلين.

إجراء عزل مشكلات صلاحيات المسؤول

في تطوير تطبيقات Windows، تختلط أحاديث صلاحيات المسؤول كثيراً.

• هل الرفع مطلوب فقط للتثبيت؟
• هل هو مطلوب أيضاً وقت التشغيل؟
• هل تغيير إعداد محدَّد واحد فقط هو ما يحتاج صلاحيات؟
• أم أنّ المشكلة الحقيقيّة مجرّد اختيار سيّئ لمكان الحفظ؟

الموضوع الأوسع نفسه مُغطّى في هاتين المقالتين:

• متى يصبح Windows admin privilege ضرورياً - UAC والمناطق المحميّة وكيفيّة التمييز على مستوى التصميم
• كيف تعزل العمل الذي يحتاج إلى المسؤول فقط داخل تطبيقات Windows

هنا، التركيز أضيق: كيف نستعمل Sandbox لتسريع ذلك الفحص.

ما يجب فحصه أوّلاً

عند البدء في Sandbox، الحدود الأولى التي تستحقّ الفحص أشياء مثل:

• هل يكتب المثبِّت تحت Program Files أو HKLM
• هل يتورَّط تسجيل خدمات أو تثبيت تعريفات أو تغيير قواعد جدار الحماية
• هل يفترض المحدِّث استبدالاً على مستوى الجهاز
• هل تُكتب إعدادات وقت التشغيل أو سجلّات أو ذاكرة مؤقّتة في مواقع محميّة
• هل يوجد تكامل OS مثل Shell Extension أو تسجيل COM

النقطة هي فصل «العمليّات التي تتطلّب فعلاً صلاحيات المسؤول» عن «العمليّات التي تفشل فقط لأنّ مواقع الكتابة وقت التشغيل اختيرت بصورة سيّئة».

حالة Sandbox الافتراضيّة ليست فحصاً تحت مستخدم قياسيّ

هذه النقطة تهمّ.

أوامر logon لـ Windows Sandbox تعمل في حساب مستخدم الـ container. كذلك يصف Microsoft Learn أنّ مستخدم الـ container ينبغي أن يكون حساب مسؤول.

لذلك، جلسة Sandbox الافتراضيّة ليست بيئة طبيعيّة لإعادة إنتاج مستخدم قياسيّ.

إن أردت عزل مشكلات صلاحيات المسؤول كما يجب، فالأنظف إنشاء مستخدم قياسيّ آخر داخل Sandbox وتشغيل التطبيق بهويّته.

مثال: 10-standard-user.wsb

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Scripts</HostFolder>
      <SandboxFolder>C:\Work\Scripts</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>powershell.exe -NoExit -ExecutionPolicy Bypass -File C:\Work\Scripts\Prep-StandardUser.ps1</Command>
  </LogonCommand>
</Configuration>

مثال: Prep-StandardUser.ps1

$UserName = 'wsbuser'
$Password = 'P@ssw0rd-For-Test-Only!'

$existing = Get-LocalUser -Name $UserName -ErrorAction SilentlyContinue
if (-not $existing) {
    $secure = ConvertTo-SecureString $Password -AsPlainText -Force
    New-LocalUser -Name $UserName -Password $secure -AccountNeverExpires | Out-Null
}

try {
    Remove-LocalGroupMember -Group 'Administrators' -Member $UserName -ErrorAction Stop
}
catch {
}

try {
    Add-LocalGroupMember -Group 'Users' -Member $UserName -ErrorAction Stop
}
catch {
}

Write-Host ''
Write-Host 'Standard user has been prepared.'
Write-Host "User     : $UserName"
Write-Host "Password : $Password"
Write-Host ''
Write-Host 'Run your app as the standard user with:'
Write-Host 'runas /user:wsbuser "C:\Work\AppUnderTest\MyApp.exe"'
Write-Host ''

Start-Process explorer.exe 'C:\Work\AppUnderTest'

بذلك الإعداد، يكون المستخدم القياسيّ جاهزاً بمجرّد بدء Sandbox، فتستطيع فوراً تجربة التالي:

runas /user:wsbuser "C:\Work\AppUnderTest\MyApp.exe"

ما الذي يُسهِّل هذا رؤيته

غالباً ما يُسهِّل هذا النهج رؤية مشكلات مثل التالية بكثير:

• تُحفَظ إعدادات وقت التشغيل بجانب الـ EXE فتفشل
• يحاول التطبيق الكتابة على HKLM فيفشل
• يفترض المحدِّث نموذجاً على مستوى الجهاز
• تُكتب السجلّات تحت Program Files
• زرّ واحد فقط يحتاج فعلاً رفعاً، لكنّ التطبيق كلّه مصمَّم حول التشغيل المرفوع

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

أنشئ عن قصد حالة نقص صلاحيات أو تبعيّات

الأمر ليس فقط «ألا تكون مسؤولاً». إن أزلت عن قصد بعض راحة البيئة، صار من الأسهل اكتشاف التبعيّات الخفيّة.

مثال: 20-restricted-runtime.wsb

<Configuration>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <PrinterRedirection>Disable</PrinterRedirection>
  <ProtectedClient>Enable</ProtectedClient>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

ما الذي تريد رؤيته بهذا البروفيل

هذا البروفيل المقيَّد مفيد لفحص أمور مثل:

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

في تطبيقات الأعمال خصوصاً، ترى غالباً حالات «عمل بشكل جيّد على جهازي»، لكن طرفيّة الميدان الفعليّة تكون فيها:

• شبكة مقيَّدة
• مشاركة حافظة مقيَّدة
• بلا طابعة
• وصول كتابة مقيَّد إلى المجلّدات المشتركة

إن قرَّبت البيئة من ذلك الواقع في Sandbox أوّلاً، يقلّ كثيراً احتمال تعطّلك لاحقاً عبر استفسارات العملاء.

لا تعرض المجلّدات المشتركة بشكل مفرط

هذا أيضاً مهمّ.

المجلّدات المرتبطة في Sandbox مريحة، لكنّ التغييرات على مجلّد مشترك بصلاحية كتابة تبقى على المضيف حتّى بعد إغلاق Sandbox.

لذا الأكثر أماناً تجنّب أمور مثل:

• مشاركة كامل C:\Users
• كشف المستودع بأكمله بصلاحية كتابة
• مشاركة Downloads أو Documents اعتباطاً بصلاحية كتابة

النمط الأساسيّ الأكثر أماناً هو:

• مجلّدات ضيّقة للقراءة فقط للمدخلات
• Outbox مخصَّص واحد للقراءة والكتابة للمخرجات

أنشئ بيئة أقرب إلى نقص الموارد

لا يمنحك Windows Sandbox درجة عالية من حرّيّة التحكّم في الموارد. ومع ذلك، فهو مفيد لـ فحوصات أخفّ بقيود الموارد.

مثال: 30-low-resource.wsb

<Configuration>
  <VGpu>Disable</VGpu>
  <MemoryInMB>2048</MemoryInMB>
  <Networking>Disable</Networking>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

المشكلات التي يُسهِّل هذا رؤيتها

هذا البروفيل مفيد لاكتشاف مشكلات مثل:

• بدء تشغيل يستهلك ذاكرة أكثر ممّا ينبغي
• مسارات تحميل ملفّات كبيرة تفترض مساحة ذاكرة أكبر ممّا تملكه فعلاً
• الرسم يصبح بطيئاً بصورة غير متناسبة بلا دعم GPU مشترك
• سلوك fallback ضعيف في WPF أو WebView2 أو معالجة الصور أو معالجة الفيديو
• مشكلات واجهة بقيت غير مرئيّة فقط لأنّ جهاز التطوير كان به GPU قويّ

في مواصفات Microsoft للإعداد، تُرفَع قيم MemoryInMB الأقلّ من 2048 MB تلقائيّاً إلى الحدّ الأدنى اللازم للبدء. لذا في الواقع، من المعقول اعتبار حوالي 2 GB كنقطة مرجعيّة دنيا عمليّة لفحوصات الذاكرة المنخفضة في Windows Sandbox.

حالات لا يكفي فيها Sandbox

من ناحية أخرى، يكون Windows Sandbox ضعيفاً قليلاً في حالات كهذه:

• تريد تقييد استخدام CPU بشدّة
• تريد إنشاء ضغط دقيق على سعة القرص
• تريد إدخال تأخير I/O
• تريد تشغيل مصفوفة بأحجام ذاكرة عبر حالات متعدّدة
• تريد soak test طويلة الأمد في بيئة دائمة

لتلك الحالات، عادةً يكون أبسط الانتقال إلى VM كامل من البداية.

Sandbox جيّد للـ «بيئات بقيود خفيفة»، لكنّه ليس منصّة اختبار حمل دقيقة.

من Windows 11 24H2 يسهل التشغيل عبر CLI أيضاً

في Windows Sandbox الأحدث على Windows 11 24H2 فما بعد، تستطيع أيضاً استعمال CLI.

تشمل الأوامر المتاحة، مثلاً:

• wsb start
• wsb list
• wsb connect
• wsb exec
• wsb share
• wsb stop

في أصغر مقياس، قد يبدو الأمر كذا:

wsb start --config "<Configuration><Networking>Disabled</Networking></Configuration>"
wsb list

علماً بأنّ أمثلة CLI الرسميّة لـ Windows Sandbox تستعمل Disabled، بينما دليل مخطّط ملفّ إعداد .wsb يذكر Disable / Enable / Default. إن أدخلت --config المضمَّن في التشغيل، فتأكّد على الجهاز المستهدف من Windows 11 24H2 فما بعد أيّ كتابة تُقبَل.

بمجرّد معرفة معرّف الـ Sandbox الجاري،

wsb connect --id <sandbox-id>

يتيح لك الاتّصال به.

أين يلائم الـ CLI

الـ CLI مفيد في حالات مثل:

• تريد تضمين بدء Sandbox في سكربت إعادة الإنتاج المحلّيّ
• تريد استدعاء إعدادات مشتركة من ملفّات batch أو من PowerShell
• تريد إضافة مجلّدات مشتركة إلى Sandbox جارٍ
• تريد أتمتة جزء صغير من إجراء الفحص المحلّيّ

لماذا لا يزال من الأفضل الاحتفاظ بملفّات .wsb

ومع ذلك، من الأفضل عدم التخلّي عن ملفّات .wsb بعد.

السبب بسيط: هي أسماء سيناريوهات مقروءة.

• 00-clean-smoke.wsb
• 10-standard-user.wsb
• 20-restricted-runtime.wsb
• 30-low-resource.wsb

بأسماء كهذه، يستطيع أيّ شخص فهم الغرض من كلّ منها.

الـ CLI مريح، لكن من الناحية التشغيليّة، التقسيم الأسهل عادةً: «عرّف الشروط في .wsb، ولفّ الإطلاق في الـ CLI عند الحاجة».

تنبيهات الـ CLI

في الوقت الحاضر، لـ wsb exec قيود حول التقاط I/O للعمليّة، وعند التشغيل في سياق المستخدم المسجَّل دخوله، يتطلّب أيضاً جلسة مستخدم نشطة.

لذا من الأفضل ألّا تتوقّع منه منصّة اختبار آليّ headless تماماً. هو مفيد لأتمتة إعادة الإنتاج المحلّيّ، لكنّه ليس من النوع الذي تُسقطه كبديل CI مباشر.

تنبيهات تشغيليّة لا ينبغي تخطّيها

أخيراً، إليك النقاط التي تميل إلى التسبّب بالمتاعب في العمل الحقيقيّ.

اجعل المجلّدات المشتركة في الحدّ الأدنى

Sandbox معزول، لكنّ المجلّدات المرتبطة تتّصل بالعودة إلى المضيف. المجلّد المشترك القابل للكتابة يستطيع التأثير في المضيف.

لا تشارك بشكل واسع، واحصر المشاركة القابلة للكتابة في Outbox فقط. تلك هي القاعدة الأساسيّة.

اجمع السجلّات والـ dumps قبل الإغلاق

هذا بديهيّ، لكن بمجرّد إغلاق Sandbox، يختفي. ولهذا بالضبط ينبغي تثبيت وجهة الإخراج على Outbox منذ البداية.

لا تعامل «جلسة Sandbox الافتراضيّة» فحصاً تحت مستخدم قياسيّ

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

لا تسرف في استخدامه لفروق إصدارات OS

Sandbox جيّد للفحص النظيف داخل نفس عائلة OS، لكنّه ليس معيداً لإنتاج إصدارات Windows الأقدم. إن احتجت إصدار OS آخر، فابدأ بـ VM كامل بدلاً منه.

الأجهزة الخاضعة لإدارة الشركة قد تفرض قيود السياسات

الإعدادات الخاضعة لتحكّم Group Policy قد لا تكون قابلة للتغيير عبر .wsb. إن «لم يأخذ الإعداد مفعولاً» على جهاز شركة مُدار بصرامة، فإنّ فحص تحكّم السياسة أوّلاً غالباً أسرع طريق.

الخلاصة

يستطيع Windows Sandbox تسريع فحص تطوير تطبيقات Windows بشكل ملحوظ في مجالات مثل:

• عزل مشكلات صلاحيات المسؤول
• فحص التثبيت لأوّل مرّة في بيئة نظيفة
• إظهار التبعيّات على الشبكة أو على المشاركة
• إعادة إنتاج ظروف نقص الصلاحيات أو نقص التبعيّات
• إجراء فحوصات أخفّ منخفضة الذاكرة أو أقرب إلى غياب الـ GPU

إن أردت تنظيمه في سير عمل عمليّ، فالشكل المعتاد هو:

1. أنشئ مواقع AppUnderTest وScripts وOutbox ثابتة
2. قسّم ملفّات .wsb بحسب السيناريو
3. أبقِ المدخلات للقراءة فقط والمخرجات للقراءة والكتابة
4. أجرِ الفحص تحت مستخدم قياسيّ بمستخدم آخر
5. ارتقِ إلى VM كامل عند الحاجة لفحوصات CPU أو القرص أو OS قديم

قوّة Sandbox ليست أنّه شامل. هي أنّك تستطيع إبقاء الإعداد قبل الفحص صغيراً مع إعادة البيئة إلى نظافتها في كلّ مرّة.

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

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

• متى يصبح Windows admin privilege ضرورياً - UAC والمناطق المحميّة وكيفيّة التمييز على مستوى التصميم
• كيف تعزل العمل الذي يحتاج إلى المسؤول فقط داخل تطبيقات Windows
• كيف تختار نموذج توزيع تطبيق Windows - MSI و MSIX و ClickOnce و xcopy والـ custom updaters
• جمع crash dumps لتطبيقات Windows: متى تبدأ بـ WER أو ProcDump أو WinDbg

مواضيع ذات صلة

• مواضيع Windows التقنيّة

الخدمات المتّصلة بهذا الموضوع

• تطوير تطبيقات Windows
• الاستشارة التقنيّة ومراجعة التصميم
• للتواصل

المراجع

1. Microsoft Learn, Windows Sandbox
2. Microsoft Learn, Install Windows Sandbox
3. Microsoft Learn, Use and configure Windows Sandbox
4. Microsoft Learn, Windows Sandbox sample configuration files
5. Microsoft Learn, Windows Sandbox frequently asked questions (FAQ)
6. Microsoft Learn, Windows Sandbox versions
7. Microsoft Learn, Windows Sandbox command line interface

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

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

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

أسئلة شائعة حول موضوع هذه المقالة.

لأيّ فحص يناسب Windows Sandbox؟

يناسب تأكيد التثبيت الأوّل في بيئة نظيفة، وعزل مشكلات صلاحيات المسؤول، وإظهار الاعتماد على الشبكة أو المشاركة، وإعادة إنتاج نقص الصلاحيات أو التبعيّات، وفحصاً خفيفاً أقرب إلى انخفاض الذاكرة أو غياب الـ GPU. هو أخفّ من VM كامل، ويبدأ بسرعة، ويختفي نظيفاً في كلّ مرّة تُغلقه. في المقابل، لإعادة إنتاج إصدار OS مختلف، أو تشغيل عدّة instances معاً، أو محاكاة حصّة CPU أو ضغط القرص بدقّة، يناسب VM كامل أكثر.

ما شروط استعمال Windows Sandbox؟

يتوفّر على إصدارات Windows Pro / Enterprise / Education. لا يتوفّر على Home. كذلك يُشترَط تفعيل ميزات المحاكاة الافتراضيّة، وقدر كافٍ من RAM والقرص ونوى CPU. يعمل على Windows من نفس عائلة المضيف، فإن كان المضيف Windows 11 فلن يصبح بيئة إعادة إنتاج لـ Windows 10.

ماذا يمكن ضبطه في ملفّ .wsb؟

يمكن تثبيت تفعيل الشبكة أو تعطيلها، والمجلّد المشترك read-only / read-write، وحدّ الذاكرة (MemoryInMB)، وتعطيل vGPU، وتعطيل مشاركة الحافظة، والأمر الذي يُنفَّذ عند الـ logon (LogonCommand). إن فصلت .wsb حسب الغرض، أعَدت بناء بيئة الفحص نفسها بنقرة مزدوجة. علماً بأنّ MemoryInMB دون 2048MB يُرفَع تلقائيّاً إلى الحدّ الأدنى اللازم للبدء، لذا من الواقعيّ اعتبار نحو 2GB حداً أدنى لفحص الذاكرة المنخفضة.

هل يمكن فحص سلوك المستخدم القياسيّ في Windows Sandbox؟

جلسة Sandbox الافتراضيّة لا تلائم فحص المستخدم القياسيّ كما هي. أمر الـ logon يعمل بحساب مستخدم الـ container، ويُفترَض أن يكون ذلك المستخدم حساب مسؤول. إن أردت إعادة إنتاج نقص الصلاحيات تحت مستخدم قياسيّ، فالأوضح إنشاء مستخدم قياسيّ داخل Sandbox عند البدء، ثمّ تشغيل التطبيق بأمر runas بهويّته.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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