Windows 11 on kenji.blog

دليل إنشاء حزم MSIX لنظام Windows 11 وفخ شهادة التوقيع الذاتي

Sat, 12 Sep 2026 22:00:00 +0900

في عصر Windows 11، أصبح “MSIX” هو الخيار القياسي لتنسيق توزيع التطبيقات. على الرغم من أن المثبتات التقليدية مثل MSI و EXE كانت تعاني من العديد من المشاكل، إلا أنه من المتوقع أن يحل MSIX هذه المشاكل كتقنية حزم من الجيل التالي. ومع ذلك، عندما يحاول المطورون إنشاء حزمة MSIX وإجراء التحميل الجانبي (Sideloading) في بيئة تنظيمية أو اختبارية، غالباً ما يقعون في “فخ شهادة التوقيع الذاتي”.

في هذه المقالة، سنشرح بالتفصيل التفاصيل الفنية لـ MSIX، وكيفية إنشاء الحزم باستخدام Visual Studio وأدوات سطر الأوامر، بالإضافة إلى أسباب وحلول الأخطاء المتعلقة بشهادة التوقيع الذاتي التي يواجهها العديد من المطورين. نأمل أن يكون هذا دليلاً لا غنى عنه لمطوري تطبيقات Windows، ومسؤولي البنية التحتية، والمسؤولين عن الحزم.

1. ما هو MSIX؟ مقارنة مع MSI/EXE التقليدية

MSIX هو أحدث تنسيق لحزم التطبيقات لنظام Windows تقدمه Microsoft. يجمع بين جميع الميزات والمفاهيم الممتازة من MSI (Microsoft Installer) التقليدي، والمثبتات المخصصة المستندة إلى .exe، و App-V (Application Virtualization)، و AppX (حزم تطبيقات Universal Windows Platform) التي تم تقديمها منذ Windows 8، بالإضافة إلى تطوره ليتناسب مع متطلبات الأمان والنشر الحديثة.

مشاكل المثبتات التقليدية (MSI/EXE)

كانت لـ MSI و EXE، اللتين استخدمتا كصيغ تثبيت قياسية في Windows لسنوات عديدة، مشاكل جذرية كما يلي:

ظاهرة Win Rot (تدهور Windows): أثناء تكرار تثبيت وإلغاء تثبيت التطبيقات، تبقى مفاتيح غير ضرورية في السجل، وتُترك ملفات DLL في مجلدات النظام (مثل C:\Windows\System32). يؤدي هذا إلى إبطاء نظام التشغيل نفسه تدريجياً وحدوث ظاهرة عدم الاستقرار.
جحيم DLL (DLL Hell): عندما تحاول تطبيقات متعددة تثبيت ملف DLL يحمل نفس الاسم (ولكن بإصدارات مختلفة) في دليل النظام المشترك، فإن التطبيق المثبت لاحقاً يستبدل ملف DLL الموجود، مما يؤدي إلى توقف التطبيق المثبت مسبقاً عن العمل بشكل صحيح.
عدم الاستقرار بسبب الإجراءات المخصصة: في حزم MSI، يمكن تنفيذ نصوص أو تعليمات برمجية تعسفية تسمى “الإجراءات المخصصة” بصلاحيات النظام أثناء التثبيت أو إلغاء التثبيت. تسبب هذا في خطر انهيار المثبت في منتصف العملية أو التسبب في تغييرات غير متوقعة في إعدادات النظام.

الحل من خلال بنية الحاويات في MSIX

يحل MSIX هذه المشكلات عن طريق تشغيل التطبيق داخل “حاوية” خفيفة الوزن. يحتوي نهج الحاويات هذا على المزايا الهائلة التالية:

إلغاء التثبيت النظيف: التطبيقات المثبتة عبر MSIX تقوم بالكتابة على نظام الملفات والسجل بشكل افتراضي (VFS: Virtual File System، VReg: Virtual Registry). لذلك، عند إلغاء التثبيت، يتم حذف هذه الحاوية الافتراضية بأكملها، مما لا يترك أي بقايا (قمامة) في النظام. هذا يمنع ظاهرة Win Rot تماماً.
العزل والأمان (Isolation): يعمل كل تطبيق داخل بيئته الخاصة ولا يدمر مباشرة ملفات DLL أو الموارد الخاصة بالتطبيقات الأخرى. هذا يحررك من جحيم DLL.
تحسين النطاق الترددي للشبكة: آلية التحديث في MSIX ممتازة جداً، حيث تدعم التحديثات التفاضلية على مستوى الكتلة (Differential Update). نظراً لأنه يتم تنزيل الكتل القليلة المعدلة فقط من البيانات الثنائية، فإنه يقلل الحمل على الشبكة إلى الحد الأدنى حتى عند تحديث التطبيقات الكبيرة.
حالة تثبيت موثوقة: تحتوي الحزمة على ملف بيان (AppxManifest.xml)، وتتم إدارة معاملات التثبيت بدقة على مستوى نظام التشغيل. في حالة الفشل، يتم التراجع تماماً إلى الحالة الأصلية.

2. النظرة العامة على إنشاء حزمة MSIX وسلسلة الأدوات

هناك طريقتان رئيسيتان لإنشاء حزمة MSIX. الأولى هي استخدام بيئة التطوير المتكاملة (IDE) لـ Visual Studio، والثانية هي الاستفادة من أدوات سطر الأوامر (مثل MakeAppx.exe و SignTool.exe) المرفقة مع Windows SDK.

يوضح مخطط Mermaid التالي العملية منذ ملفات المصدر وحتى إنشاء حزمة MSIX النهائية الموقعة.

flowchart TD
A["الملفات المصدرية (EXE, DLL, الموارد, إلخ)"] --> B["AppxManifest.xml (تعريف البيان)"]
B --> C["MakeAppx.exe (منشئ حزم MSIX)"]
C --> D["حزمة MSIX غير موقعة (.msix)"]
E["شهادة رقمية (.pfx)"] --> F["SignTool.exe (المُوَقِّع الرقمي)"]
D --> F
F --> G["حزمة MSIX موقعة (جاهزة للنشر)"]
style A fill:#f9f9f9,stroke:#333
style B fill:#e6f7ff,stroke:#333
style D fill:#ffcccb,stroke:#333
style G fill:#d4edda,stroke:#333

كما يتضح من هذه العملية، لا يكفي مجرد جمع الملفات وحزمها، بل يجب المرور بخطوة “التوقيع الرقمي”. لأسباب أمنية، لا يسمح Windows 11 بتثبيت حزم MSIX غير الموقعة على الإطلاق.

3. النهج أ: إنشاء MSIX باستخدام Visual Studio

الطريقة الأسهل والأكثر شيوعاً هي استخدام “مشروع حزم تطبيقات Windows (Windows Application Packaging Project - WAP)” في Visual Studio. باستخدام قالب المشروع هذا، يمكنك بسهولة تحزيم تطبيقات WPF، Windows Forms، WinUI 3، وحتى تطبيقات Win32 القديمة المكتوبة بـ C++ إلى MSIX.

دليل خطوة بخطوة

إضافة مشروع WAP: انقر بزر الماوس الأيمن على حل (Solution) Visual Studio الحالي، واختر “إضافة مشروع جديد”، ثم حدد “مشروع حزم تطبيقات Windows”.
اختيار النظام الأساسي المستهدف: حدد الإصدار الأدنى والإصدار المستهدف لنظام التشغيل Windows 10/11 الذي يدعمه التطبيق.
الإشارة إلى التطبيق: انقر بزر الماوس الأيمن على عقدة “التطبيقات” في مشروع الحزمة، واختر “إضافة مرجع”، ثم حدد المشروع الرئيسي الذي تريد حزمه (مثل مشروع WPF).
إعداد البيان (Manifest): انقر نقراً مزدوجاً فوق ملف Package.appxmanifest لفتح المصمم المرئي. هنا، قم بتعيين اسم عرض التطبيق، الوصف، صورة الشعار، والأهم من ذلك “اسم الحزمة (Identity Name)” و"الناشر (Publisher)".
إنشاء الحزمة: انقر بزر الماوس الأيمن على المشروع، واختر “نشر” -> “إنشاء حزم التطبيقات”. اختر “للتحميل الجانبي (Sideloading)” وحدد البنية (مثل x64، ARM64)، وسيقوم Visual Studio تلقائياً بالترجمة، الحزم باستخدام MakeAppx، وحتى إنشاء شهادة توقيع ذاتي والتوقيع عليها.

هذا سلس للغاية، ولكن إذا استخدمت شهادة التوقيع الذاتي (Test Certificate) التي تم إنشاؤها تلقائياً بواسطة Visual Studio، فستقع في “الفخ” الموصوف لاحقاً.

4. النهج ب: الإنشاء باستخدام سطر الأوامر (MakeAppx.exe)

لأتمتة العملية في مسار CI/CD، أو لإعادة حزم مجموعة من الملفات يدوياً من مثبت موجود، ستحتاج إلى أدوات سطر الأوامر. إذا كانت بيئة Windows SDK مثبتة، يمكنك الوصول إلى الأدوات التالية من موجه أوامر المطور.

1. إعداد ملف البيان

قم بإنشاء ملف AppxManifest.xml يحتوي على الحد الأدنى من المعلومات في الدليل الجذر للحزمة.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
 xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
 xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities">

 <Identity Name="MyCompany.AwesomeApp"
 Publisher="CN=MyCompany Self-Signed, O=MyCompany"
 Version="1.0.0.0"
 ProcessorArchitecture="x64" />

 <Properties>
 <DisplayName>Awesome App</DisplayName>
 <PublisherDisplayName>My Company</PublisherDisplayName>
 <Logo>Assets\StoreLogo.png</Logo>
 </Properties>

 <Resources>
 <Resource Language="en-us" />
 <Resource Language="ja-jp" />
 </Resources>

 <Dependencies>
 <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22000.0" />
 </Dependencies>

 <Capabilities>
 <rescap:Capability Name="runFullTrust" />
 </Capabilities>

 <Applications>
 <Application Id="AwesomeApp" Executable="AwesomeApp.exe" EntryPoint="Windows.FullTrustApplication">
 <uap:VisualElements DisplayName="Awesome App"
 Description="The best app ever."
 BackgroundColor="transparent"
 Square150x150Logo="Assets\Square150x150Logo.png"
 Square44x44Logo="Assets\Square44x44Logo.png">
 </uap:VisualElements>
 </Application>
 </Applications>
</Package>

الشيء المهم هنا هو أن قيمة <Identity Publisher="..." /> يجب أن تتطابق تماماً مع اسم الكيان (Subject) في الشهادة التي ستُستخدم للتوقيع لاحقاً.

2. الحزم باستخدام MakeAppx

في موجه الأوامر، قم بتشغيل الأمر التالي لضغط الدليل إلى ملف MSIX.

1

MakeAppx.exe pack /d "C:\Path\To\AppFolder" /p "C:\Path\To\Output\AwesomeApp_1.0.0.0_x64.msix"

هذا يكمل ملف MSIX غير الموقّع، ولكن في هذه الحالة، لا يمكن تثبيته على نظام Windows.

5. التوقيع الرقمي والخلفية الرياضية لتكنولوجيا التشفير

لفهم سبب الحاجة إلى التوقيع على حزم MSIX بعمق، من الضروري فهم الآليات التشفيرية وراء التوقيعات الرقمية. يضمن التوقيع الرقمي أن الحزمة “تم إنشاؤها بالتأكيد بواسطة الناشر المحدد (المصادقة)” وأنها “لم يتم العبث بها من قبل طرف ثالث من وقت الإنشاء وحتى الآن (النزاهة)”.

يستخدم التوقيع لـ MSIX عادةً مزيجاً من تشفير RSA و SHA-256 (خوارزمية التجزئة الآمنة 256 بت).

تطبيق دالة التجزئة

أولاً، لنجعل البيانات الثنائية (المحتويات) لحزمة MSIX بأكملها هي الرسالة $M$. تقوم أداة التوقيع (SignTool.exe) بتطبيق دالة التجزئة التشفيرية SHA-256 على هذه الرسالة $M$ لحساب قيمة تجزئة بطول ثابت (256 بت) $H(M)$.

إنشاء التوقيع (الناشر)

بعد ذلك، يستخدم الناشر “مفتاحه الخاص (Private Key)” $d$ لتشفير قيمة التجزئة، ويولد توقيعاً رقمياً $\sigma$. في سياق خوارزمية RSA، يتم التعبير عن هذا كعملية أسية نموذجية على النحو التالي:

$$ \sigma \equiv (H(M))^d \pmod n $$

حيث $n$ هو معامل RSA (حاصل ضرب عددين أوليين ضخمين). يتم تضمين هذه الشهادة (بصيغة X.509) التي تحتوي على التوقيع $\sigma$ و “المفتاح العام (Public Key)” $e$ الخاص بالناشر كجزء من حزمة MSIX (في AppxSignature.p7x).

التحقق من التوقيع (نظام تشغيل Windows)

عندما يحاول المستخدم تثبيت MSIX، يستخرج نظام التشغيل Windows المفتاح العام $e$ من الشهادة الموجودة داخل الحزمة، ويقوم بالحساب التالي لاستعادة قيمة التجزئة $H'(M)$.

$$ H'(M) \equiv \sigma^e \pmod n $$

في نفس الوقت، يقوم نظام التشغيل نفسه بإعادة حساب قيمة التجزئة $H(M)$ لحزمة MSIX بأكملها التي تم تنزيلها $M$. في النهاية، يتحقق مما إذا كانت قيمة التجزئة المستردة وقيمة التجزئة المعاد حسابها متساويتين ($H(M) = H'(M)$). إذا صحت هذه المعادلة، فقد تم إثبات رياضياً أن “الملف لم يتم العبث به ولو بت واحدة بعد التوقيع”.

6. العائق الأكبر: “فخ شهادة التوقيع الذاتي”

حتى لو كان الإثبات الرياضي أعلاه مثالياً، فإن Windows 11 لا يسمح بالتثبيت بمجرد ذلك. لأن هناك حاجة للتحقق من “سلسلة الثقة (Chain of Trust)” لمعرفة: “هل صاحب ذلك المفتاح العام (الشهادة) هو حقاً المنظمة أو الشخص الآمن الذي يدعي أنه هو؟”

إذا كانت الشهادة صادرة عن مرجع مصدق جذري عام (Root CA) موثوق به مسبقاً من قبل نظام التشغيل، مثل VeriSign أو DigiCert، فيمكن تثبيته دون مشاكل (التطبيقات الموزعة عبر Microsoft Store موثوق بها بالمثل بواسطة شهادة جذر Microsoft).

ومع ذلك، إذا لم تتمكن من تحمل تكلفة شراء شهادة عامة، مثل أثناء التطوير أو للأدوات الداخلية للشركة، يقوم المطور بإصدار الشهادة بنفسه. هذه هي “شهادة التوقيع الذاتي (Self-Signed Certificate)”.

يوضح مخطط التسلسل التالي سلوك نظام التشغيل عند محاولة تثبيت حزمة MSIX موقعة بشهادة توقيع ذاتي.

sequenceDiagram
autonumber
participant U as "المستخدم (Windows 11)"
participant P as "مثبت تطبيق MSIX"
participant C as "مخزن شهادات Windows"
U->>P: "نقر مزدوج على ملف .msix"
P->>P: "قراءة AppxSignature.p7x"
P->>P: "استخراج التوقيع والشهادة"
P->>P: "التحقق الرياضي (هل تتطابق التجزئة؟)"
P->>C: "التحقق من ثقة شهادة الناشر"
alt "الشهادة موجودة في مخزن المراجع المصدقة الجذرية الموثوقة"
C-->>P: "تم التحقق من الثقة بنجاح"
P->>U: "مطالبة بالتثبيت (زر التثبيت نَشِط)"
U->>P: "ينقر على تثبيت"
P->>U: "تم التثبيت بنجاح"
else "الشهادة غير موثوقة (الفخ)"
C-->>P: "فشل التحقق من الثقة (0x800B0109)"
P->>U: "عرض خطأ: تمت معالجة سلسلة الشهادات، لكنها انتهت في شهادة جذر غير موثوقة"
P->>U: "زر التثبيت مُعَطَّل"
end

هذا هو بالضبط “الفخ”. على الرغم من أن المطور قد أنشأها ووقّعها بشكل صحيح، إلا أن نظام Windows 11 في حالته الافتراضية لا يعرف (لا يثق بـ) شهادة التوقيع الذاتي تلك، وبالتالي يتم حظر التثبيت برمز الخطأ 0x800B0109. يتحول زر “تثبيت” في المثبت إلى اللون الرمادي ولا يمكن الضغط عليه.

يواجه العديد من المطورين هذا الخطأ، ويقعون في متاهة إعادة كتابة ملف البيان مراراً وتكراراً معتقدين أن “MSIX مليء بالأخطاء” أو “يجب أن يكون الإعداد خاطئاً”، ولكن المشكلة لا تكمن في هيكل الحزمة، بل في وجود أو عدم وجود تسجيل في مخزن الشهادات (Certificate Store) لنظام التشغيل.

7. الحل: إنشاء ونشر شهادة توقيع ذاتي باستخدام PowerShell

لحل هذه المشكلة، من الضروري تنفيذ الخطوتين التاليتين بشكل موثوق.

إنشاء شهادة توقيع ذاتي صالحة، وتصدير ملف PFX الذي يحتوي على المفتاح الخاص.
تثبيت جزء المفتاح العام (ملف CER) للشهادة التي تم إنشاؤها في مخزن “المراجع المصدقة الجذرية الموثوقة (Trusted Root Certification Authorities)” لجميع أجهزة الكمبيوتر المستهدفة.

باستخدام PowerShell، يمكن معالجة ذلك بشكل موثوق وتلقائي.

الخطوة 1: إنشاء وتصدير شهادة التوقيع الذاتي

أولاً، قم بتشغيل PowerShell بصلاحيات المسؤول (Administrator)، وقم بتنفيذ البرنامج النصي التالي لإنشاء الشهادة. هنا، سنقوم بإنشاء شهادة مخصصة لأغراض توقيع التعليمات البرمجية (Code Signing).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# 1. تعريف المعلمات
$SubjectName = "CN=MyCompany Self-Signed, O=MyCompany"
$CertStoreLocation = "Cert:\CurrentUser\My"

# 2. إنشاء شهادة توقيع ذاتي (لغرض توقيع التعليمات البرمجية: 1.3.6.1.5.5.7.3.3)
$Cert = New-SelfSignedCertificate -Type Custom `
 -Subject $SubjectName `
 -KeyUsage DigitalSignature `
 -FriendlyName "MyCompany MSIX Signing Cert" `
 -CertStoreLocation $CertStoreLocation `
 -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")

Write-Host "تم إنشاء الشهادة. البصمة (Thumbprint): $($Cert.Thumbprint)"

# 3. إنشاء كلمة مرور لتصدير ملف PFX (متضمن المفتاح الخاص)
$Password = ConvertTo-SecureString -String "YourSecurePassword123!" -Force -AsPlainText

# 4. تصدير ملف PFX (للتوقيع باستخدام SignTool)
$PfxPath = "C:\Path\To\Output\MyCompanyCert.pfx"
Export-PfxCertificate -Cert $Cert -FilePath $PfxPath -Password $Password

# 5. تصدير CER (المفتاح العام فقط) (للتثبيت على أجهزة العملاء)
$CerPath = "C:\Path\To\Output\MyCompanyCert.cer"
Export-Certificate -Cert $Cert -FilePath $CerPath

باستخدام ملف $PfxPath الذي تم إنشاؤه هنا، قم بالتوقيع على حزمة MSIX.

1

SignTool.exe sign /fd SHA256 /a /f "C:\Path\To\Output\MyCompanyCert.pfx" /p "YourSecurePassword123!" "C:\Path\To\Output\AwesomeApp_1.0.0.0_x64.msix"

الخطوة 2: تثبيت الشهادة على جهاز الكمبيوتر العميل (إزالة الفخ)

إذا أخذت حزمة MSIX الموقعة إلى جهاز كمبيوتر آخر (أو بيئة افتراضية)، ونقرت عليها نقراً مزدوجاً كما هي، فلن تتمكن من تثبيتها كما هو موضح أعلاه. مقدماً (أو في نفس الوقت)، ستحتاج إلى تثبيت ملف $CerPath الذي تم تصديره للتو في “المراجع المصدقة الجذرية الموثوقة” لـ “الكمبيوتر المحلي (Local Computer)”.

للقيام بذلك، افتح PowerShell بصلاحيات المسؤول على جهاز الكمبيوتر المستهدف للنشر، وقم بتنفيذ الأمر التالي.

1
2
3
4
5
6
7


# مسار ملف CER
$CerPath = "C:\Path\To\Output\MyCompanyCert.cer"

# استيراد إلى "المراجع المصدقة الجذرية الموثوقة" للكمبيوتر المحلي
Import-Certificate -FilePath $CerPath -CertStoreLocation "Cert:\LocalMachine\Root"

Write-Host "تم تثبيت الشهادة في المراجع المصدقة الجذرية الموثوقة."

[!CAUTION] تعد امتيازات المسؤول مطلوبة لإضافة الشهادة إلى مخزن المراجع المصدقة الجذرية لـ “الكمبيوتر المحلي (LocalMachine)”. يجب الحذر لأنه حتى إذا تم إدراجها في المخزن الشخصي للمستخدم (CurrentUser)، فقد لا يتم التعرف عليها بسبب سياق امتيازات App Installer.

مباشرة بعد نجاح هذا البرنامج النصي، حاول النقر نقراً مزدوجاً فوق ملف MSIX الذي كان يعطي خطأ في وقت سابق مرة أخرى. وكأنه سحر، يجب أن تختفي رسالة الخطأ ويظهر زر “تثبيت” نشط بلون أزرق ساطع. بهذا تكون قد تخطيت “فخ شهادة التوقيع الذاتي” بالكامل.

8. التشغيل في بيئة المؤسسات وأفضل الممارسات

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

أفضل الممارسات في بيئة المؤسسات هي كما يلي.

1. الاستفادة من نهج مجموعة Active Directory (GPO)

إذا تم تقديم Active Directory داخل الشركة، يمكنك استخدام “نهج المفتاح العام” لـ GPO لتوزيع شهادة التوقيع الذاتي (ملف CER) تلقائياً على “المراجع المصدقة الجذرية الموثوقة” لجميع أجهزة الكمبيوتر المنضمة إلى المجال. هذا يسمح للموظفين بتثبيت التطبيق بمجرد النقر المزدوج على ملف MSIX في مجلد مشترك دون أي وعي بالشهادة.

2. النشر عبر Microsoft Intune (MDM)

تستخدم البيئات الحديثة Microsoft Intune لإدارة الأجهزة. في Intune، يمكنك دفع شهادة موثوقة (.cer) إلى نقاط النهاية باستخدام ميزة “ملف تعريف التكوين (Configuration Profile)”. بعد ذلك، يمكنك نشر حزمة MSIX نفسها كتثبيت صامت كتطبيق LOB (Line of Business).

3. التحديث التلقائي من خلال ملف App Installer (.appinstaller)

يحتوي MSIX على ميزة قوية لأتمتة تحديثات التطبيقات. عن طريق إنشاء ملف .appinstaller يستند إلى XML ووضعه على خادم ويب أو مجلد SMB مشترك، يمكنك جعل التطبيق يتحقق في الخلفية من وجود إصدارات جديدة من MSIX عند تشغيل التطبيق وتطبيق التحديثات تلقائياً.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


<?xml version="1.0" encoding="utf-8"?>
<AppInstaller
 Uri="https://internal.mycompany.com/apps/AwesomeApp.appinstaller"
 Version="1.0.0.0"
 xmlns="http://schemas.microsoft.com/appx/appinstaller/2018">
 <MainPackage
 Name="MyCompany.AwesomeApp"
 Publisher="CN=MyCompany Self-Signed, O=MyCompany"
 Version="1.0.0.0"
 ProcessorArchitecture="x64"
 Uri="https://internal.mycompany.com/apps/AwesomeApp_1.0.0.0_x64.msix" />
 <UpdateSettings>
 <OnLaunch HoursBetweenUpdateChecks="0" />
 </UpdateSettings>
</AppInstaller>

عن طريق توزيع هذا الملف للمستخدمين لتثبيته، من الآن فصاعداً، بمجرد استبدال ملف MSIX على الخادم وتحديث رقم الإصدار في .appinstaller، سيتم تحديث تطبيق جميع المستخدمين تلقائياً.

9. استكشاف الأخطاء وإصلاحها: الأخطاء الشائعة المتعلقة بالشهادات

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

0x800B0101: انتهت صلاحية الشهادة المستخدمة للتوقيع. يرجى إصدار شهادة جديدة، أو استخدم خادم طابع زمني عند التوقيع (مثل http://timestamp.digicert.com) لإثبات أن التوقيع تم ضمن فترة صلاحية الشهادة (بإضافة طابع زمني، سيتم اعتبار التوقيع صالحاً حتى لو انتهت صلاحية الشهادة نفسها).
0x80080204: قيمة Publisher المذكورة في AppxManifest.xml لا تتطابق تماماً مع قيمة Subject للشهادة. يرجى التحقق بدقة مما إذا كانت تتطابق تماماً كسلسلة نصية، بما في ذلك وجود أو عدم وجود مسافة بعد الفاصلة.
التحقق من عارض الأحداث (Event Viewer): للبحث في سبب أكثر تفصيلاً للخطأ، من المهم جداً فتح عارض أحداث Windows والتحقق من السجلات ضمن “سجلات التطبيقات والخدمات (Applications and Services Logs)” -> “Microsoft” -> “Windows” -> “AppxPackagingOM” أو “AppXDeployment-Server”.

10. الخلاصة

تعد حزم MSIX لنظام التشغيل Windows 11 تقنية قوية تحسن إدارة دورة حياة التطبيقات بشكل كبير. يمكنك التحرر من Win Rot وجحيم DLL، وتوفير بيئة نظيفة وآمنة للمستخدمين.

من ناحية أخرى، نظراً لأن نموذج الأمان أصبح أكثر صرامة، فإن الفهم العميق لـ “سلسلة الثقة” الخاصة بالتوقيعات الرقمية والشهادات أمر بالغ الأهمية. “فخ شهادة التوقيع الذاتي” هو بوابة مرور يواجهها تقريباً كل مطور يلمس تقنية MSIX لأول مرة. من خلال فهم آلية إنشاء الشهادات، وتصديرها، واستيرادها إلى المخزن المناسب الموضحة في هذه المقالة، والاستفادة من البرامج النصية و GPO للأتمتة، ستتمكن من تحقيق نشر سلس يستخرج أقصى إمكانات MSIX.

يُرجى الاستفادة من هذه المعرفة لبناء بيئة توزيع تطبيقات Windows نظيفة من الجيل التالي.

أساسيات سجل ويندوز (Windows Registry) وطرق التحرير الآمنة والقابلة للبرمجة

Sat, 12 Sep 2026 12:00:00 +0900

أساسيات سجل ويندوز (Windows Registry) وطرق التحرير الآمنة والقابلة للبرمجة

في نظام التشغيل ويندوز (Windows)، يُعد “السجل” (Registry) قاعدة بيانات هرمية ضخمة تخزن التكوينات والإعدادات المختلفة للنظام والتطبيقات. في هذه المقالة، سنشرح بالتفصيل الشديد كل شيء بدءًا من البنية الأساسية لسجل ويندوز، ووصولاً إلى طرق التحرير الآمنة والقابلة للبرمجة باستخدام PowerShell و C#.

1. مقدمة: تاريخ وتطور سجل ويندوز

في الإصدارات الأولى من ويندوز (عصر Windows 3.x)، كانت إعدادات النظام والتطبيقات تُحفظ بشكل أساسي في ملفات .ini (ملفات التهيئة). ومع ذلك، أصبحت ملفات INI التي لا تعد ولا تحصى متناثرة في جميع أنحاء النظام لكل تطبيق، مما جعل الإدارة معقدة للغاية. بالإضافة إلى ذلك، نظرًا لأن ملفات INI تعتمد على النصوص العادية، كان من الصعب تخزين البيانات الثنائية (Binary data)، ولم تكن هناك آلية للتحكم في الوصول (الأمان). كما كانت سرعة تحليل الملفات بطيئة، مما جعلها غير مناسبة لتخزين الإعدادات واسعة النطاق.

لحل هذه المشكلات بشكل جذري، ومنذ نظامي التشغيل Windows NT و Windows 95 وما بعدهما، تم اعتماد “السجل” (Registry) بشكل كامل كقاعدة بيانات مركزية للإعدادات. السجل عبارة عن قاعدة بيانات هرمية توفر كتابة قوية (Strong typing)، ودعمًا للبيانات الثنائية، وميزات أمان قوية من خلال قوائم التحكم في الوصول (ACL). بفضل هذا، أصبح بإمكان أي مكون، من نواة نظام التشغيل (OS Kernel) إلى تطبيقات مساحة المستخدم (User-space applications)، قراءة الإعدادات وكتابتها من خلال واجهة موحدة (مجموعة دوال Reg* في واجهة برمجة تطبيقات Win32).

وحتى في نظام Windows 11 الحديث، لا يزال السجل يعمل كقلب نظام التشغيل. يتم تجميع كافة البيانات الوصفية (Metadata) اللازمة لتشغيل النظام في السجل، بما في ذلك تكوين الأجهزة، وترتيب تحميل برامج تشغيل الأجهزة (Device drivers)، وبيئة سطح مكتب المستخدم، وقائمة البرامج المثبتة.

2. عمق البنية: الكيانات الحقيقية لخلايا السجل (Registry Hives) وتعيين الذاكرة (Memory Mapping)

على الرغم من أن السجل يبدو منطقيًا كبنية شجرة (Tree) ضخمة واحدة، إلا أنه فعليًا مقسم إلى عدة ملفات تسمى “الخلايا” (Hives) ويتم تخزينها على القرص. هذا يفصل بين إعدادات النظام بالكامل وإعدادات المستخدم الخاصة، مما يتيح تحميلًا فعالاً.

توجد ملفات الخلايا الرئيسية عادةً في دليل %SystemRoot%\System32\config.

SYSTEM: الإعدادات المهمة اللازمة لتمهيد نظام التشغيل (برامج التشغيل، الخدمات، تكوين التمهيد، إلخ).
SOFTWARE: إعدادات النظام بالكامل للبرامج المثبتة. توجد هنا معظم إعدادات تطبيقات الجهات الخارجية.
SAM: مدير حسابات الأمان (حسابات المستخدمين المحليين وتجزئات كلمات المرور).
SECURITY: سياسات الأمان المحلية وتعيين الصلاحيات.
DEFAULT: ملف تعريف المستخدم الافتراضي (قالب عند إنشاء مستخدم جديد).

توجد ملفات خلايا المستخدم الفردية كملفات مخفية في دليل ملف تعريف المستخدم (مثال: C:\Users\Username).

NTUSER.DAT: الإعدادات الأساسية لذلك المستخدم (معظم محتويات HKCU).
UsrClass.dat: إعدادات اقتران امتدادات الملفات لذلك المستخدم (موجودة في AppData\Local\Microsoft\Windows).

يتم تعيين هذه الملفات في ذاكرة تجمع صفحات النواة (Kernel page pool memory) بواسطة “مدير التكوين” (Configuration Manager - CM) الخاص بالنواة عند بدء تشغيل نظام التشغيل. مدير التكوين هو مكون يعمل في وضع النواة (Kernel-mode) ويعالج طلبات القراءة والكتابة في السجل.

ما يستحق الذكر هو أنه ليست كل بيانات السجل موجودة على القرص. على سبيل المثال، الخلية HARDWARE متطايرة (Volatile) ولا يتم حفظها على الإطلاق في أي ملف على القرص. في كل مرة يبدأ فيها تشغيل نظام التشغيل ويكتشف مدير “التوصيل والتشغيل” (PnP) الأجهزة، يتم إعادة بنائها ديناميكيًا في الذاكرة.

علاوة على ذلك، لزيادة موثوقية السجل، تطبق أحدث إصدارات ويندوز تسجيل المعاملات (Transaction logging). لا تتم كتابة التغييرات التي تطرأ على ملفات الخلايا مباشرة في ملف البيانات، بل يتم تسجيلها أولاً في سجل المعاملات (.log1، .log2). يمنع هذا تلف البيانات (Corruption) في حالة الانقطاع المفاجئ للتيار الكهربائي أو تعطل النظام أثناء الكتابة، ويضمن سلامة قاعدة البيانات بشكل قريب من خصائص ACID.

3. البنية الهرمية لمفاتيح وقيم السجل

يتمتع السجل ببنية هرمية تشبه إلى حد كبير نظام الملفات. تُسمى العقدة (Node) الجذرية “المفتاح الجذري” (Root Key) أو “الخلية” (Hive)، وتُخزن تحتها “المفاتيح” (Keys)، و"المفاتيح الفرعية" (Subkeys)، و"القيم" (Values) التي تمثل البيانات الفعلية. من الأسهل فهمها إذا اعتبرت أن المفاتيح تقابل الأدلة (Directories) والقيم تقابل الملفات.

تُصنف المفاتيح الجذرية الرئيسية إلى الخمسة التالية:

HKEY_LOCAL_MACHINE (HKLM): يُخزن إعدادات النظام والبرامج التي تنطبق على الكمبيوتر بالكامل (جميع المستخدمين). يتطلب التعديل صلاحيات المسؤول (Administrator).
HKEY_CURRENT_USER (HKCU): يُخزن الإعدادات الخاصة بالمستخدم الذي قام بتسجيل الدخول حاليًا. في الواقع، هذه ليست قاعدة بيانات مستقلة، بل هي مجرد ارتباط رمزي (Symbolic link / Alias) لمفتاح المعرف الأمني (SID) الخاص بالمستخدم المعني ضمن HKEY_USERS.
HKEY_CLASSES_ROOT (HKCR): يُخزن اقترانات امتدادات الملفات، ومعلومات تسجيل فئات COM (نموذج كائن المكون)، وامتدادات واجهة المستخدم (Shell extensions). هذا المفتاح خاص؛ فهو عرض افتراضي (Virtual view) يتم فيه دمج (Merge) HKLM\SOFTWARE\Classes (للنظام بالكامل) و HKCU\Software\Classes (للمستخدم الحالي) بواسطة مدير التكوين. في حالة وجود تعارض، تُعطى الأولوية لإعدادات المستخدم الخاصة (HKCU).
HKEY_USERS (HKU): يُخزن إعدادات جميع ملفات تعريف المستخدمين على النظام (تلك المحملة حاليًا في الذاكرة). يتم تنظيمه هرميًا بناءً على معرفات الأمان (SIDs).
HKEY_CURRENT_CONFIG (HKCC): الإعدادات المتعلقة بملف تعريف الأجهزة الحالي. وهو في الواقع رابط إلى HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current.

يمكن تصور هذه البنية الهرمية المعقدة وعلاقات الارتباط على النحو التالي:

mindmap
root(("سجل ويندوز (Windows Registry)"))
HKLM(("HKEY_LOCAL_MACHINE"))
SAM(("SAM (حسابات الأمان)"))
SECURITY(("SECURITY"))
SOFTWARE(("SOFTWARE"))
SYSTEM(("SYSTEM"))
HARDWARE(("HARDWARE (متطاير)"))
HKCU(("HKEY_CURRENT_USER (رابط)"))
AppEvents(("AppEvents"))
Console(("Console"))
Software(("Software"))
System(("System"))
HKCR(("HKEY_CLASSES_ROOT (عرض مدمج)"))
HKU(("HKEY_USERS"))
SID(("معرفات أمان المستخدم (User SIDs)..."))
HKCC(("HKEY_CURRENT_CONFIG (رابط)"))

4. أنواع بيانات السجل (شرح مفصل)

كل “قيمة” في السجل لها نوع بيانات محدد بدقة. عند التعامل مع السجل برمجيًا، من الضروري فهم هذه الأنواع بشكل صحيح وكتابة البيانات بالنوع المناسب. ستؤدي الكتابة بنوع خاطئ إلى رمي التطبيقات لاستثناءات (Exceptions) أو التسبب في توقف ميزات نظام التشغيل.

REG_SZ (قيمة سلسلة): نوع البيانات الأكثر شيوعًا. يخزن سلسلة نصية Unicode (UTF-16LE) منتهية بحرف NULL. يُستخدم لمسارات الملفات، وعناوين URL، وأسماء العرض في واجهة المستخدم، وما إلى ذلك.
REG_DWORD (قيمة عدد صحيح 32-بت): قيمة عدد صحيح غير إشارة (Unsigned integer) بحجم 32-بت (4 بايت). يُستخدم بشكل متكرر للقيم المنطقية (0 = معطل، 1 = ممكّن)، وقيم انتهاء المهلة بالمللي ثانية، وإعدادات رموز الخطأ. نظرًا لأن ويندوز يستخدم بنية Little Endian، فإنه يتم حفظه على القرص بدءًا من البايت الأقل أهمية (مثال: 0x12345678 يُحفظ كـ 78 56 34 12).
REG_QWORD (قيمة عدد صحيح 64-بت): قيمة عدد صحيح بحجم 64-بت (8 بايت). مع انتشار معمارية 64-بت، يُستخدم لحفظ الأرقام الضخمة (مثل الحصص النسبية للقرص وتحديد حجم الذاكرة الكبيرة) وإعدادات حجم المؤشرات (Pointers).
REG_MULTI_SZ (قيمة سلسلة متعددة الأسطر): يخزن سلاسل نصية متعددة منتهية بحرف NULL بشكل متتابع، وينتهي في النهاية بحرف NULL إضافي فارغ (Double NULL). يُعد مناسبًا لتخزين بيانات تشبه المصفوفات (Arrays)، مثل قوائم عناوين IP، وقوائم الخدمات ذات التبعيات، وترتيب الارتباط (Binding order).
REG_EXPAND_SZ (قيمة سلسلة قابلة للتوسيع): نوع سلسلة خاص يتضمن سلاسل متغيرات البيئة غير الموسعة (Unexpanded) مثل %USERPROFILE% أو %SystemRoot%. عند قيام أحد التطبيقات بقراءتها عبر واجهة برمجة التطبيقات RegQueryValueEx، أو باستدعاء واجهة برمجة التطبيقات ExpandEnvironmentStrings، يتم توسيعها ديناميكيًا بواسطة نظام التشغيل إلى المسار المطلق الفعلي.
REG_BINARY (قيمة ثنائية): دفق بيانات ثنائية خام عشوائية. يخزن كلمات المرور المشفرة (مثل LSA Secrets)، والشهادات الرقمية، والهياكل المعقدة الخاصة بالتطبيقات، والبيانات المتسلسلة (Serialized data).
REG_NONE: بيانات غير محددة النوع. نادر الاستخدام جدًا، لكنه يُستخدم في مناطق الحجز لمفاتيح التشفير وما إلى ذلك.
REG_RESOURCE_LIST / REG_FULL_RESOURCE_DESCRIPTOR: أنواع متقدمة خاصة بالنواة (Kernel) تُستخدم بواسطة برامج تشغيل الأجهزة لتسجيل معلومات تخصيص موارد الأجهزة (طلبات المقاطعة IRQ، ومنافذ الإدخال/الإخراج I/O ports، وقنوات الوصول المباشر للذاكرة DMA).

5. النموذج الرياضي للسجل وأداؤه في نظام التشغيل

نظرًا لأن السجل يرتبط ارتباطًا مباشرًا بأداء نظام التشغيل (خاصة وقت التمهيد وسرعة تهيئة العمليات)، فقد تم تحسينه داخليًا باستخدام بنية بيانات متقدمة تشبه شجرة-B (B-Tree) تسمى “مؤشر الخلية” (Cell Index).

التعقيد الزمني للبحث (Time Complexity)

يعتمد التعقيد الزمني $T_{\text{search}}$ عند البحث عن مفتاح معين (مسار) في السجل على عمق الشجرة وعدد العقد (Nodes) في كل مستوى. عند البحث في مفتاح فرعي ذي عمق $d$ (مثال: A\B\C\D يعني $d=4$)، يمكن نمذجة التعقيد نظريًا على النحو التالي:

$$ T_{\text{search}}(d, L) = \sum_{i=1}^{d} O(\log(C_i) \cdot L_i) $$

هنا، $C_i$ هو عدد العقد التابعة (المفاتيح الفرعية أو القيم) في العمق $i$، و $L_i$ هو طول السلسلة (عدد الأحرف) التي تتم مقارنتها. داخل ملف الخلية الذي يمثل كيان السجل، يتم الاحتفاظ بقائمة المفاتيح الفرعية كفهرس مرتب أبجديًا أو بقيم التجزئة (Hash values) للأسماء. لذلك، بدلاً من البحث الخطي البسيط $O(C_i)$، يمكن إجراء بحث ثنائي (Binary Search) $O(\log(C_i))$، مما يحقق وصولاً سريعًا للغاية حتى لو كان هناك عشرات الآلاف من المفاتيح الفرعية ضمن مفتاح واحد.

البصمة التخزينية (Space Complexity)

يتم حساب الحجم الإجمالي للسجل (المساحة المشغولة على القرص الفعلي) كمجموع جميع الخلايا.

$$ \text{Size}_{\text{Total}} = \sum_{h \in \text{Hives}} \left( N_{h} \times S_{\text{key\_metadata}} + \sum_{v \in h} S_{\text{value}}(v) \right) + S_{\text{overhead}} $$

$N_h$ هو عدد المفاتيح في الخلية $h$، و $S_{\text{key\_metadata}}$ هو حجم البيانات الوصفية لكل مفتاح (مثل الطابع الزمني لآخر كتابة، ومؤشر إلى واصف الأمان، ومؤشر إلى المفتاح الأصل، إلخ)، و $S_{\text{value}}(v)$ هو حجم الحمولة للقيمة $v$. يتم أيضًا تضمين النفقات الإضافية $S_{\text{overhead}}$ الناتجة عن سجلات المعاملات والخلايا الفارغة التي لم يعد يُحتاج إليها (التجزئة - Fragmentation). إذا تركت بيانات غير ضرورية (مثل بقايا البرامج التي لم يتم إلغاء تثبيتها بالكامل) في السجل لفترة طويلة، فستزيد هذه البصمة، مما يضغط على ذاكرة تجمع صفحات نظام التشغيل ويؤدي إلى انخفاض الأداء.

6. مخاطر التحرير اليدوي واحتمالات التلف التي تهدد استقرار النظام

يجب اعتبار التحرير اليدوي باستخدام محرر السجل (regedit.exe) بمثابة الملاذ الأخير لإدارة النظام. لا يحتوي السجل على ميزة “تراجع” (Undo) كما هو الحال في محررات المستندات العامة، ويتم تطبيق تغييرات القيم أو حذف المفاتيح فورًا على النظام عبر مدير التكوين.

على وجه الخصوص، إذا قمت بالخطأ بتحرير أو حذف حرف واحد فقط من المفاتيح الحرجة (Critical keys) الضرورية لبدء تشغيل النظام (على سبيل المثال، إعدادات برامج تشغيل وحدة تحكم القرص تحت HKLM\SYSTEM\CurrentControlSet\Services، أو قيمة Userinit في HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon)، فهناك خطر قاتل يتمثل في تعطل نظام التشغيل وظهور شاشة الموت الزرقاء (BSoD) أو عدم القدرة على تجاوز شاشة تسجيل الدخول (الشاشة السوداء).

النموذج الرياضي لاحتمالية التلف

لنفكر في احتمالية حدوث فشل في النظام إذا تم تغيير المفاتيح أو حذفها عشوائيًا في السجل. لنفترض أن مجموعة المفاتيح الحرجة الضرورية لكي يعمل النظام بشكل طبيعي هي $C$، وإجمالي عددها هو $N_c = |C|$. ولنفترض أن إجمالي عدد المفاتيح في السجل بأكمله هو $N_{\text{total}}$. إذا قمنا بحذف أو إتلاف عدد $k$ من المفاتيح بشكل عشوائي، فإن احتمالية إتلاف مفتاح حرج واحد على الأقل $P_{\text{failure}}$ يمكن التعبير عنها من خلال حساب احتمالية العينة بدون إرجاع (Sampling without replacement) على النحو التالي:

$$ P_{\text{failure}} = 1 - \frac{\binom{N_{\text{total}} - N_c}{k}}{\binom{N_{\text{total}}}{k}} = 1 - \prod_{i=0}^{k-1} \left( 1 - \frac{N_c}{N_{\text{total}} - i} \right) $$

يقدر إجمالي عدد المفاتيح في السجل $N_{\text{total}}$ بمئات الآلاف إلى الملايين، ولكن يتواجد أيضًا عدد $N_c$ في نطاق عشرات الآلاف. رياضيًا، حتى مع العمليات العشوائية، سترتفع احتمالية الفشل بشكل حاد مع زيادة $k$. وعلاوة على ذلك، في العمليات اليدوية الواقعية، لا يقوم المستخدمون بالتحرير “عشوائيًا”، بل يتعمدون التلاعب (أثناء النظر إلى مواقع الدروس التعليمية وما إلى ذلك) في الأماكن المرتبطة ارتباطًا مباشرًا بإعدادات النظام وسلوكيات البرامج، لذلك تكون احتمالية المساس بالمفاتيح الحرجة أعلى بكثير من القيمة النظرية المذكورة أعلاه.

7. المحاكاة الافتراضية للسجل (Registry Virtualization) وبنية WOW64

للحفاظ على التوافق مع التطبيقات القديمة (Legacy applications)، ينفذ ويندوز بعض آليات “المحاكاة الافتراضية” (Virtualization / Redirection) المتقدمة للوصول إلى السجل. إذا قمت بالبرمجة دون فهم ذلك، فسوف يتسبب ذلك في حدوث أخطاء برمجية (Bugs) فادحة.

المحاكاة الافتراضية للسجل وUAC

تم تقديم التحكم في حساب المستخدم (UAC) منذ نظام التشغيل Windows Vista. لمنع التطبيقات القديمة التي تم إنشاؤها في عصر Windows XP (والتي تعمل بصلاحيات مستخدم قياسي) من التعطل مع خطأ “تم رفض الوصول” (Access Denied) عندما تحاول الكتابة إلى مفاتيح محمية تتطلب في الأصل صلاحيات المسؤول مثل HKLM\SOFTWARE، يقوم ويندوز بإعادة توجيه تلك الكتابة سرًا إلى المتجر الافتراضي (Virtual Store) داخل ملف تعريف المستخدم: HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE. عند القراءة، يقوم بدمج كل من الموقع الأصلي والمتجر الافتراضي وإعادتهما. يتيح ذلك للتطبيق الاستمرار في العمل بشكل طبيعي دون اكتشاف الأخطاء. ومع ذلك، إذا كنت تقوم بتطوير أداة برمجية لتغيير إعدادات النظام بالكامل، فيجب عليك تحديد <requestedExecutionLevel level="requireAdministrator" /> في ملف البيان (Manifest file) لتعطيل هذه المحاكاة الافتراضية.

إعادة توجيه WOW64 (Windows 32-bit on Windows 64-bit)

عند تشغيل تطبيقات 32-بت قديمة على إصدار 64-بت من ويندوز (التيار السائد حاليًا)، يتم فصل مفاتيح سجل معينة وإعادة توجيهها تلقائيًا لمنع تطبيق 32-بت من الكتابة فوق إعدادات النظام الأصلية (Native) 64-بت عن طريق الخطأ أو تحميل ملفات DLL 64-بت غير متوافقة. على سبيل المثال، عندما يحاول تطبيق 32-بت الوصول إلى HKLM\SOFTWARE\Vendor\App، يقوم نظام التشغيل بإعادة توجيهه بشفافية إلى HKLM\SOFTWARE\WOW6432Node\Vendor\App.

flowchart TD
App32["تطبيق 32-بت"]
App64["تطبيق 64-بت"]
RegAPI["واجهة برمجة تطبيقات السجل (Advapi32.dll)"]
CM["مدير التكوين (النواة)"]
HKLM_Soft["HKLM\SOFTWARE"]
HKLM_WOW64["HKLM\SOFTWARE\WOW6432Node"]
App32 -->| RegOpenKeyEx() | RegAPI
App64 -->| RegOpenKeyEx() | RegAPI
RegAPI --> CM
CM -->| إذا كانت العملية 64-بت | HKLM_Soft
CM -->| إذا كانت العملية 32-بت (إعادة توجيه) | HKLM_WOW64

عند تحرير السجل من نصوص PowerShell أو تطبيقات C#، يجب أن تكون واعيًا تمامًا بما إذا كانت العملية قيد التشغيل نفسها 32-بت أم 64-بت. وإلا، فسوف تتسبب في مشكلة مزعجة تتمثل في “الإعدادات التي كان من المفترض كتابتها غير مرئية في مستكشف الملفات (مكتوبة في مكان آخر)”.

8. التحرير الآمن والقابل للبرمجة باستخدام PowerShell

لتقليل مخاطر تحرير السجل يدويًا، من أفضل الممارسات الحديثة تدوين العمليات (البنية التحتية ككود - Infrastructure as Code) باستخدام نصوص PowerShell لضمان الأتمتة وإمكانية التكرار والقابلية للاختبار. يأتي PowerShell مزودًا بـ “مزود السجل” (Registry Provider)، مما يسمح لك بالتلاعب في السجل بشفافية باستخدام نفس الأوامر (Cmdlets) تمامًا (Get-ChildItem، Get-ItemProperty، New-Item، إلخ) المستخدمة للتعامل مع نظام الملفات (مثل محرك الأقراص C:).

في PowerShell، يتم تركيب محركات أقراص PSDrive مخصصة (تشبه أحرف محركات الأقراص) مثل HKLM: و HKCU: افتراضيًا.

عمليات CRUD الأساسية

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. التحقق من الوجود (Read)
$keyPath = "HKCU:\Software\MyCustomApp"
if (-Not (Test-Path -Path $keyPath)) {
 # 2. إنشاء مفتاح جديد (Create)
 New-Item -Path "HKCU:\Software" -Name "MyCustomApp" -Force | Out-Null
 Write-Host "تم إنشاء المفتاح."
}

# 3. كتابة/تحديث القيم (Update) - الكتابة كنوع REG_DWORD بقيمة 1
Set-ItemProperty -Path $keyPath -Name "EnableDebug" -Value 1 -Type DWord

# 4. قراءة القيم (Read)
$debugFlag = (Get-ItemProperty -Path $keyPath).EnableDebug
Write-Host "علم تصحيح الأخطاء الحالي: $debugFlag"

# 5. حذف القيم (Delete)
Remove-ItemProperty -Path $keyPath -Name "EnableDebug" -Force

مثال عملي 1: التهيئة التلقائية لبيئة التطوير (إضافة مسار PATH إلى متغيرات البيئة)

يوضح البرنامج النصي التالي مثالاً لأتمتة إضافة دليل الأدوات المخصصة بأمان إلى متغير بيئة المستخدم PATH عندما يقوم المطور بإعداد جهاز ويندوز جديد.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


$envKey = "HKCU:\Environment"
$newPath = "C:\tools\bin"

# قراءة مسار PATH الحالي (قمع الأخطاء وجلبه بأمان)
$currentPathInfo = Get-ItemProperty -Path $envKey -Name "Path" -ErrorAction SilentlyContinue
$currentPath = if ($currentPathInfo) { $currentPathInfo.Path } else { "" }

# التحقق مما إذا كان مضمناً بالفعل باستخدام التعابير النمطية (Regex)
if ($currentPath -notmatch [regex]::Escape($newPath)) {
 # إضافة فاصلة منقوطة ودمجها إذا لم تكن موجودة في النهاية
 if ($currentPath -and $currentPath -notmatch ";$") {
 $currentPath += ";"
 }
 $updatedPath = $currentPath + $newPath

 # الكتابة كنوع REG_EXPAND_SZ (مهم)
 Set-ItemProperty -Path $envKey -Name "Path" -Value $updatedPath -Type ExpandString
 Write-Host "تم تحديث متغير بيئة PATH: $newPath"

 # إعلام العمليات الجارية بتغيير متغيرات البيئة (WM_SETTINGCHANGE)
 # يتيح ذلك انعكاس التغيير على متصفح الملفات الجديد وغيرها دون إعادة تشغيل
 [Environment]::SetEnvironmentVariable("Path", $updatedPath, [EnvironmentVariableTarget]::User)
} else {
 Write-Host "تم إضافة PATH بالفعل."
}

هذا برنامج نصي يضيف عنصرًا مخصصًا يسمى “فتح في بيئة التطوير (My IDE)” إلى قائمة السياق التي تظهر عند النقر بزر الماوس الأيمن فوق ملف أو دليل معين.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# القائمة عند النقر بزر الماوس الأيمن فوق خلفية الدليل (مساحة بيضاء)
$menuPath = "HKCR:\Directory\Background\shell\OpenWithMyIDE"
$commandPath = "$menuPath\command"

try {
 # إنشاء المفتاح الأصل لعنصر القائمة
 New-Item -Path $menuPath -Force -ErrorAction Stop | Out-Null

 # تعيين اسم العرض للقيمة (الافتراضية)
 Set-ItemProperty -Path $menuPath -Name "(default)" -Value "فتح في بيئة التطوير (My IDE)" -Type String

 # تعيين الأيقونة (اختياري)
 Set-ItemProperty -Path $menuPath -Name "Icon" -Value "C:\Program Files\MyIDE\ide.exe,0" -Type String

 # إنشاء مفتاح command الفرعي وتعيين سطر الأوامر الذي سيتم تنفيذه
 # %V هو متغير يتم توسيعه إلى مسار الدليل الحالي
 New-Item -Path $commandPath -Force -ErrorAction Stop | Out-Null
 Set-ItemProperty -Path $commandPath -Name "(default)" -Value "`"C:\Program Files\MyIDE\ide.exe`" `"%V`"" -Type String

 Write-Host "تم إضافة قائمة السياق."
} catch {
 Write-Error "فشل تعديل السجل. يرجى التحقق مما إذا كنت تقوم بتشغيله بصلاحيات المسؤول. الخطأ: $_"
}

تسلسل داخلي لوصول PowerShell إلى السجل

يوضح المخطط التالي التسلسل الداخلي لنظام التشغيل عندما يقوم نص PowerShell بتعديل السجل.

sequenceDiagram
participant U as "المسؤول / PowerShell"
participant PS as "مزود السجل (.NET)"
participant CM as "مدير التكوين (النواة)"
participant Disk as "ملفات الخلية (Hive) على NTFS"
U->>PS: "Set-ItemProperty -Path ... -Value ..."
PS->>PS: "تحليل المسار والتحقق من أنواع البيانات"
PS->>CM: "NtSetValueKey (استدعاء النظام)"
CM->>CM: "التحقق من رمز الوصول (Access Token) مقابل قائمة التحكم في الوصول (ACL) للمفتاح"
alt "تم منح الوصول (رمز المسؤول)"
CM->>CM: "تخصيص خلية في الذاكرة المخبئية المتطايرة"
CM->>Disk: "التفريغ إلى سجل المعاملات (.log1)"
Disk-->>CM: "تم كتابة السجل بنجاح"
CM->>Disk: "كتابة كسولة (Lazy Write) إلى ملف بيانات الخلية (في الخلفية)"
CM-->>PS: "STATUS_SUCCESS (0x00000000)"
PS-->>U: "اكتمل الأمر"
else "تم رفض الوصول (مستخدم قياسي)"
CM-->>PS: "STATUS_ACCESS_DENIED (0xC0000022)"
PS-->>U: "طرح استثناء UnauthorizedAccessException"
end

9. الوصول القوي إلى السجل باستخدام C# (.NET)

عند الوصول إلى السجل من تطبيق .NET (مثل C#)، يتم استخدام الفئة Microsoft.Win32.Registry والفئة RegistryKey. الميزة الكبرى لاستخدام C# هي معالجة الأخطاء القوية من خلال المعالجة القوية للاستثناءات (try-catch)، والتحقق الصارم من النوع (Type checking)، والقدرة على تحديد العرض 32-بت / 64-بت بشكل صريح باستخدام التعداد (Enum) RegistryView.

فيما يلي مثال لشفرة C# البرمجية التي تقرأ وتكتب السجل بشكل موثوق على جانب 64-بت (تجنب إعادة توجيه WOW6432Node) في بيئة نظام تشغيل 64-بت.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


using System;
using System.Security;
using Microsoft.Win32;

class RegistryEditor
{
 static void Main()
 {
 // مسار تحت HKLM (يتطلب صلاحيات المسؤول)
 string keyPath = @"SOFTWARE\MyEnterpriseApp\Settings";

 // تحديد RegistryView.Registry64 لفتح العرض الأصلي 64-بت
 // استخدام عبارة using للتأكد من التخلص (Dispose) الآمن لمقبض مفتاح السجل (مورد غير مُدار - Unmanaged Resource)
 try
 {
 using (RegistryKey baseKey = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64))
 {
 // فتح المفتاح مع صلاحية الكتابة (writable: true). سيتم إنشاؤه إذا لم يكن موجوداً.
 using (RegistryKey subKey = baseKey.CreateSubKey(keyPath, writable: true))
 {
 if (subKey != null)
 {
 // الكتابة كنوع REG_DWORD
 subKey.SetValue("MaxConnections", 100, RegistryValueKind.DWord);

 // الكتابة كنوع REG_SZ
 subKey.SetValue("ApiEndpoint", "https://api.example.com", RegistryValueKind.String);

 // الكتابة كنوع REG_BINARY (مصفوفة بايتات)
 byte[] secretData = { 0x01, 0x02, 0x0A, 0xFF };
 subKey.SetValue("BinarySecret", secretData, RegistryValueKind.Binary);

 Console.WriteLine("تمت الكتابة في السجل بنجاح.");
 }
 }
 }
 }
 catch (UnauthorizedAccessException ex)
 {
 // يحدث غالبًا عندما لا يتم التشغيل كمسؤول
 Console.WriteLine($"خطأ في الصلاحيات: يرجى 'تشغيل البرنامج كمسؤول'. التفاصيل: {ex.Message}");
 }
 catch (SecurityException ex)
 {
 // عند حظره بواسطة أمان الوصول إلى التعليمات البرمجية (CAS) الخاص بـ .NET
 Console.WriteLine($"استثناء أمني: {ex.Message}");
 }
 catch (Exception ex)
 {
 // أخطاء إدخال/إخراج غير متوقعة أخرى
 Console.WriteLine($"خطأ غير متوقع: {ex.Message}");
 }
 }
}

“المقبض” (Handle) الذي يعيده نظام التشغيل عند فتح مفتاح السجل هو مورد غير مُدار يستهلك الذاكرة وموارد النظام. لذلك، من القواعد الصارمة في برمجة C# استخدام كتلة using أو استدعاء .Dispose() (أو .Close()) صراحةً داخل كتلة finally لمنع تسرب المقابض (Handle leaks).

10. طرق النسخ الاحتياطي واستعادة السجل

حتى مع الأتمتة باستخدام البرامج النصية أو البرامج، من الضروري للغاية أخذ نسخة احتياطية قبل إجراء تغييرات حرجة.

النسخ الاحتياطي والاستيراد باستخدام ملفات .reg

الطريقة الأكثر كلاسيكية وتنوعًا هي التصدير إلى ملف .reg. هذا الملف هو ملف نصي ذو تنسيق خاص به، ويأخذ الهيكل التالي:

1
2
3
4
5
6


Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\MyCustomApp]
"EnableDebug"=dword:00000001
"ApiEndpoint"="https://api.example.com"
"BinaryData"=hex:01,02,0a,ff

ملاحظة: يتم تمثيل البيانات الثنائية بأرقام سداسية عشرية مفصولة بفواصل وتأتي بعد hex:.

باستخدام أداة سطر الأوامر reg.exe، يمكنك تنفيذ النسخ الاحتياطي التلقائي داخل البرامج النصية الدفعية (Batch scripts).

1
2
3
4
5


REM نسخ احتياطي للمفتاح المحدد (يتم تصدير المفاتيح الفرعية بشكل متكرر أيضاً)
reg export HKLM\SOFTWARE\MyEnterpriseApp C:\backup\myapp_backup.reg /y

REM استعادة النسخة الاحتياطية
reg import C:\backup\myapp_backup.reg

طريقة نسخ احتياطي أكثر تقدمًا باستخدام PowerShell

بدلاً من مجرد نصوص عادية، يمكنك الاستفادة من التوجه الكائني (Object-Oriented) في PowerShell لتصدير كائنات السجل وحفظها بتنسيق XML (CliXML). يتيح لك ذلك التعامل مع البيانات مع الحفاظ على معلومات النوع دون الاعتماد على تحليل السلاسل النصية عند الاستعادة.

1
2
3
4
5
6
7


# أخذ نسخة احتياطية (حفظ الخصائص كـ XML)
Get-ItemProperty -Path "HKCU:\Software\MyCustomApp" | Export-Clixml -Path "C:\backup\reg_backup.xml"

# مفهوم الاستعادة
$backup = Import-Clixml -Path "C:\backup\reg_backup.xml"
# نظراً لأن المتغير $backup يحتوي على كائن PSObject المخصص المستعاد،
# يمكن بناء منطق لتكرار (Loop) خصائصه وتطبيقها مرة أخرى باستخدام Set-ItemProperty.

11. استكشاف الأخطاء وإصلاحها باستخدام Sysinternals Process Monitor (Procmon)

إذا لم تكن متأكدًا من المكان الذي يكتب فيه البرنامج في السجل، أو إذا كنت تبحث عن سبب الخطأ “تم رفض الوصول” (Access Denied)، فإن أداة Process Monitor (Procmon) التي توفرها مايكروسوفت (Microsoft) مجانًا تعتبر قوية للغاية. باستخدام Procmon، يمكنك التقاط جميع استدعاءات واجهة برمجة تطبيقات السجل (مثل RegOpenKey، RegQueryValue، RegSetValue) التي تحدث على نظام التشغيل في الوقت الفعلي، ويمكنك استكشاف الأخطاء وإصلاحها باستخدام التصفية المتقدمة التالية:

Process Name is powershell.exe
Operation begins with Reg
Result is ACCESS DENIED

يسمح لك هذا بتحديد قائمة التحكم في الوصول (ACL) المفقودة لأي مفتاح على الفور، أو ما إذا كان قد تم إعادة توجيهه عن طريق الخطأ إلى WOW6432Node.

12. الأمان وأفضل الممارسات

أخيرًا، نلخص مبادئ التصميم المهمة وأفضل الممارسات عند التعامل مع السجل.

الالتزام بمبدأ الامتياز الأقل (Least Privilege): يجب حفظ إعدادات التطبيق أو البرنامج النصي ضمن المفتاح Software الموجود أسفل HKCU (للمستخدم الحالي) قدر الإمكان. تتطلب الكتابة إلى HKLM تصعيد صلاحيات المسؤول من خلال UAC، مما يوسع من سطح الهجوم (Attack surface) الأمني ويضر بتجربة المستخدم.
تمكين التدقيق (Auditing): بالنسبة للمفاتيح المهمة أمنيًا (مثل مفتاح Run المسؤول عن بدء التشغيل التلقائي، ومفاتيح إعدادات الخدمات، وما إلى ذلك)، قم بتكوين قائمة التحكم في وصول النظام (SACL) لتسجيل (تدقيق) من قام بتغيير القيم أو حذفها ومتى تم ذلك في “سجل الأمان” (Security Log) الخاص بعارض أحداث ويندوز (Event Viewer).
التعامل مع إيقاف ميزات المعاملات (Deprecation): تم إهمال (Deprecated) ميزة معاملات السجل (TxR) باستخدام “مدير معاملات النواة” (Kernel Transaction Manager - KTM) التي تم تقديمها مسبقًا في Windows Vista بدءًا من نظام التشغيل Windows 10 وما بعده. تحتاج التطبيقات إلى تنفيذ آليات النسخ الاحتياطي والتراجع الخاصة بها (مثل قراءة القيم الأصلية والاحتفاظ بها في الذاكرة قبل إجراء أي تغييرات).
احذر من التعارض مع نهج المجموعة (Group Policy - GPO): يجب أن تكون مناطق HKLM\SOFTWARE\Policies و HKCU\Software\Policies مخصصة للإدارة المركزية بواسطة نهج مجموعة Active Directory. حتى إذا قمت بإعادة كتابة هذه المفاتيح مباشرة من البرنامج النصي، فسيتم الكتابة فوقها قسرًا بإعدادات وحدة تحكم المجال (Domain Controller) في دورة تحديث خلفية نهج المجموعة التالية (عادةً بفاصل زمني من 90 إلى 120 دقيقة)، مما يؤدي إلى عدم استمرار الإعدادات.

الخلاصة

يعد سجل ويندوز (Windows Registry) نظامًا أساسيًا قويًا ومعقدًا يدير بشكل متكامل جميع سلوكيات نظام التشغيل وإعدادات التطبيقات. يحمل التحرير اليدوي العشوائي مخاطر عالية ومثبتة رياضيًا لإلحاق الضرر بالنظام. لذلك، فإن استخدام وسائل قابلة للبرمجة مثل PowerShell أو C# لإدارة التكوين بطريقة آمنة وقابلة للاختبار وقابلة للتكرار، وفقًا لمبدأ البنية التحتية ككود (Infrastructure as Code)، يعد أمرًا ضروريًا في إدارة الأنظمة وتطويرها في العصر الحديث. يُرجى الاستفادة من الفهم العميق للبنية وأنماط التنفيذ المشروحة في هذه المقالة لبناء بيئات ويندوز أكثر قوة وأمانًا.

Windows 11 on kenji.blog

دليل إنشاء حزم MSIX لنظام Windows 11 وفخ شهادة التوقيع الذاتي

1. ما هو MSIX؟ مقارنة مع MSI/EXE التقليدية

مشاكل المثبتات التقليدية (MSI/EXE)

الحل من خلال بنية الحاويات في MSIX

2. النظرة العامة على إنشاء حزمة MSIX وسلسلة الأدوات

3. النهج أ: إنشاء MSIX باستخدام Visual Studio

دليل خطوة بخطوة

4. النهج ب: الإنشاء باستخدام سطر الأوامر (MakeAppx.exe)

1. إعداد ملف البيان

2. الحزم باستخدام MakeAppx

5. التوقيع الرقمي والخلفية الرياضية لتكنولوجيا التشفير

تطبيق دالة التجزئة

إنشاء التوقيع (الناشر)

التحقق من التوقيع (نظام تشغيل Windows)

6. العائق الأكبر: “فخ شهادة التوقيع الذاتي”

7. الحل: إنشاء ونشر شهادة توقيع ذاتي باستخدام PowerShell

الخطوة 1: إنشاء وتصدير شهادة التوقيع الذاتي

الخطوة 2: تثبيت الشهادة على جهاز الكمبيوتر العميل (إزالة الفخ)

8. التشغيل في بيئة المؤسسات وأفضل الممارسات

1. الاستفادة من نهج مجموعة Active Directory (GPO)

2. النشر عبر Microsoft Intune (MDM)

3. التحديث التلقائي من خلال ملف App Installer (.appinstaller)

9. استكشاف الأخطاء وإصلاحها: الأخطاء الشائعة المتعلقة بالشهادات

10. الخلاصة

أساسيات سجل ويندوز (Windows Registry) وطرق التحرير الآمنة والقابلة للبرمجة

أساسيات سجل ويندوز (Windows Registry) وطرق التحرير الآمنة والقابلة للبرمجة

1. مقدمة: تاريخ وتطور سجل ويندوز

2. عمق البنية: الكيانات الحقيقية لخلايا السجل (Registry Hives) وتعيين الذاكرة (Memory Mapping)

3. البنية الهرمية لمفاتيح وقيم السجل

4. أنواع بيانات السجل (شرح مفصل)

5. النموذج الرياضي للسجل وأداؤه في نظام التشغيل

التعقيد الزمني للبحث (Time Complexity)

البصمة التخزينية (Space Complexity)

6. مخاطر التحرير اليدوي واحتمالات التلف التي تهدد استقرار النظام

النموذج الرياضي لاحتمالية التلف

7. المحاكاة الافتراضية للسجل (Registry Virtualization) وبنية WOW64

المحاكاة الافتراضية للسجل وUAC

إعادة توجيه WOW64 (Windows 32-bit on Windows 64-bit)

8. التحرير الآمن والقابل للبرمجة باستخدام PowerShell

عمليات CRUD الأساسية

مثال عملي 1: التهيئة التلقائية لبيئة التطوير (إضافة مسار PATH إلى متغيرات البيئة)

مثال عملي 2: إضافة إجراء مخصص إلى قائمة السياق (Context Menu)

تسلسل داخلي لوصول PowerShell إلى السجل

9. الوصول القوي إلى السجل باستخدام C# (.NET)

10. طرق النسخ الاحتياطي واستعادة السجل

النسخ الاحتياطي والاستيراد باستخدام ملفات .reg

طريقة نسخ احتياطي أكثر تقدمًا باستخدام PowerShell

11. استكشاف الأخطاء وإصلاحها باستخدام Sysinternals Process Monitor (Procmon)

12. الأمان وأفضل الممارسات

الخلاصة