كيف نستعمل Windows Sandbox لتسريع التحقّق من تطبيقات Windows - صلاحيّات المسؤول والبيئات النظيفة وإعادة إنتاج حالات نقص الصلاحيّات أو الموارد

تطوير تطبيقات Windows يتباطأ عادةً للأسباب نفسها المألوفة:

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

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

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

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

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

الإجابة المختصرة

إن أردت النسخة المختصرة أوّلاً، فالخلاصات العمليّة عادةً كالتالي:

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

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

لماذا يلائم Windows Sandbox تحقّق التطوير

يعمل Windows Sandbox جيّداً لتحقّق تطبيقات Windows لأربعة أسباب رئيسة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• networking مُفعَّل أو مُعطَّل
• مجلّدات مشتركة للقراءة فقط أو للقراءة والكتابة
• ذاكرة أقلّ
• بدون GPU مشترك
• بدون مشاركة الحافظة
• تشغيل سكربت معيَّن عند الـ logon

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

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

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

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

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

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

توجد متطلّبات للـ virtualization

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

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

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

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

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

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

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

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

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

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

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

يُفعِّل 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 tests للبيئة النظيفة إلى نقرة مزدوجة واحدة

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

مثال: 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
• عطّل الـ networking منذ البداية إن لم ترد سلوكاً متوقّفاً على الشبكة

بذلك الإعداد، تستطيع استبدال build artifact والنقر مزدوجاً على ملفّ .wsb للحصول على تحقّق first-run جديد في كلّ مرّة.

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

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

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

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

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

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

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

كيف تعزل مشكلات صلاحيّات المسؤول

في تطوير تطبيقات Windows، تميل النقاشات حول صلاحيّات المسؤول إلى الاختلاط:

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

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

• متى يحتاج تطبيق Windows فعلاً صلاحيّات المسؤول؟
• كيف نفصل فقط الجزء الذي يحتاج صلاحيّات المسؤول من تطبيق Windows

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

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

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

• هل يكتب الـ installer تحت Program Files أو HKLM
• هل يتورَّط تسجيل خدمات أو تثبيت drivers أو تغييرات قواعد جدار الحماية
• هل يفترض الـ updater استبدالاً على مستوى الجهاز
• هل تُكتب إعدادات runtime أو سجلّات أو caches في مواقع محميّة
• هل يوجد تكامل OS مثل Shell Extensions أو تسجيل COM

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

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

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

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

لذلك، جلسة 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"

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

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

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

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

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

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

مثال: 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
• هل التنفيذ يفترض اعتباطاً أنّه يستطيع الكتابة في أيّ مكان داخل المجلّدات المشتركة

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

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

إن قرَّبت البيئة من ذلك الواقع في 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>

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

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

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

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

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

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

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

لتلك الحالات، عادةً يكون أبسط الانتقال إلى 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>Disable</Networking></Configuration>"
wsb list

بمجرّد معرفة معرّف الـ 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 فعلاً صلاحيّات المسؤول؟
• كيف نفصل فقط الجزء الذي يحتاج صلاحيّات المسؤول من تطبيق Windows
• كيف نختار طريقة توزيع تطبيقات Windows - MSI وMSIX وClickOnce وxcopy و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

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

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

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

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

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

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

غو كومورا

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

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