كيف يعمل حلّ أسماء DLL في Windows - ترتيب البحث وKnown DLLs وAPI sets وSxS من منظور عمليّ

حين يدور النقاش حول تحميل DLL في Windows، كثيراً ما يُختَزل إلى سؤال يبدو بسيطاً ومضلِّلاً:

• «أيّ مجلَّد يفحصه Windows أوّلاً؟»

هذا ليس النموذج كاملاً.

في الممارسة، تتوقّف الفرق عادةً عند مشاكل أكثر تحديداً:

• LoadLibrary("foo.dll") يعمل على جهاز ويُحمِّل وحدة مختلفة على آخر
• DLL مُوضَع بجوار الـ EXE يخسر رغم ذلك أمام مسار حلّ آخر
• System32 ومجلَّد التطبيق ومانيفست وAPI sets وKnown DLLs تختلط معاً
• SetDllDirectory وAddDllDirectory وLoadLibraryEx تُستخدَم دون فهم واضح لآثارها الجانبيّة
• مشكلة توزيع تتحوّل إلى مشكلة أمنيّة لأنّ العمليّة لا تزال تُحمِّل بالاسم العاري لـ DLL

النقطة العمليّة هي:

Windows لا يبدأ بمسح المجلَّدات بشكل أعمى.
قبل الفحص الاعتياديّ لنظام الملفّات، يُقيّم الـ loader عدّة قواعد حلّ على مستوى أعلى.

تنظِّم هذه المقالة حلّ أسماء DLL في Windows بشكل عمليّ، شاملةً DLL search order وKnown DLLs وفحص الوحدات المحمَّلة وAPI sets ومانيفست side-by-side وأثر عائلة LoadLibraryEx والفرق بين تطبيقات packaged وunpackaged.
يستند النقاش إلى توثيق Microsoft Learn المتاح حتّى مارس 2026.^123456789

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

إذا ضغطنا الإجابة الواقعيّة بشدّة، تبدو كالآتي:

• حلّ أسماء DLL في Windows ليس مجرّد ترتيب بحث في نظام الملفّات. فـ DLL redirection وAPI sets وSxS manifest redirection وقائمة الوحدات المحمَّلة وKnown DLLs كلّها جزء من الحلّ قبل الفحص الاعتياديّ للمجلَّدات. ¹
• لتطبيقات سطح المكتب unpackaged في الإعداد الافتراضيّ الآمن safe DLL search، يبقى مجلَّد التطبيق في موقع متقدّم في الترتيب، لكنّه ليس أوّل ما يحسم النتيجة دائماً. ¹
• حتّى إذا حمّلتَ أوّل DLL بـ مسار كامل، فإنّ DLLات التبعيّة تُفحَص كأنّها حُمِّلت باسم وحدة فقط. هذا مصدر شائع لأخطاء خاصّة بالبيئة. ¹
• Known DLLs ليست مجرّد «System32 يفوز أوّلاً». إنّها آليّة محدَّدة في الـ loader تربط أسماء وحدات معيّنة بنسخة النظام المحدَّدة لإصدار Windows ذاك. ¹
• API sets هي أسماء عقود افتراضيّة، وليست أسماء ملفّات DLL فعليّة عاديّة. قراءة اسم مثل api-ms-win-... على أنّه بحث ملفّ قرص عاديّ تقود إلى نموذج ذهنيّ خاطئ. ³
• SetDllDirectory يفعل أكثر من إضافة مجلَّد. تُشير Microsoft صراحةً إلى أنّه يُعطّل فعليّاً وضع safe DLL search ما دام مجلَّده موجوداً في مسار البحث. ¹
• في الكود الحديث، يكون عادةً أكثر أماناً تضييق فضاء البحث عمداً عبر المسارات الكاملة وSetDefaultDllDirectories وAddDllDirectory وLoadLibraryEx مع رايات LOAD_LIBRARY_SEARCH_*. ⁴⁵⁶²

النموذج العمليّ هو:

حلّ DLL في Windows يعتمد على كلّ من قواعد الحلّ السابقة لنظام الملفّات والـ APIs التي تُعيد تشكيل فضاء البحث.

2. الحلّ يبدأ قبل بحث المجلَّدات الاعتياديّ

يُدرج توثيق DLL search order من Microsoft صراحةً عدّة عوامل ينبغي معاملتها كجزء من الحلّ نفسه. ¹

في سيناريوهات سطح المكتب، يأخذ الـ loader هذه العوامل المبكِّرة بعين الاعتبار:

1. DLL redirection
2. API sets
3. SxS manifest redirection
4. قائمة الوحدات المحمَّلة
5. Known DLLs

ولا تنتقل العمليّة إلى البحث الاعتياديّ في المجلَّدات مثل مجلَّد التطبيق وSystem32 ومجلَّد Windows والمجلَّد الحاليّ وPATH إلّا بعد ذلك. ¹

لذلك تكون عبارة «Windows يفحص دائماً مجلَّد التطبيق أوّلاً» ناقصة. فهي تُسقط جزءاً من النموذج كثيراً ما يُفسِّر النتيجة المفاجئة.

flowchart TD
    A["Need to resolve a DLL name"] --> B["DLL redirection"]
    B --> C["API set mapping"]
    C --> D["SxS manifest redirection"]
    D --> E["Loaded-module check"]
    E --> F["Known DLLs"]
    F --> G["Filesystem search order"]
    G --> H["Actual DLL load result"]

3. ترتيب البحث القياسيّ لتطبيقات unpackaged

بالنسبة لتطبيقات unpackaged، يوثِّق Microsoft الترتيب القياسيّ بشكل منفصل. مع تفعيل وضع safe DLL search، يكون التدفّق الرئيسيّ كالآتي: ¹

1. DLL redirection
2. API sets
3. SxS manifest redirection
4. قائمة الوحدات المحمَّلة
5. Known DLLs
6. على Windows 11 إصدار 21H2 وما بعده، رسم تبعيّات حزمة العمليّة
7. المجلَّد الذي حُمِّل منه التطبيق
8. System32
9. مجلَّد النظام 16-bit
10. مجلَّد Windows
11. المجلَّد الحاليّ
12. PATH

الانعكاسات العمليّة هي:

• المجلَّد الحاليّ ليس مبكِّراً افتراضيّاً
• لكنّ تأخّره لا يجعل العمليّة آمنة تلقائيّاً
• إذا تحكَّم مهاجم في أيّ مجلَّد ضمن البحث، فإنّ تحميل اسم عارٍ قد يصبح مشكلة DLL preloading ²
• النماذج الذهنيّة الأقدم كثيراً ما تُسقط ملاحظة رسم تبعيّات الحزمة التي ظهرت الآن لتطبيقات unpackaged على إصدارات Windows الأحدث ¹

4. تطبيقات packaged وunpackaged ليست نموذج تحميل واحد

يُوثِّق Microsoft تطبيقات packaged بشكل منفصل لسبب وجيه. فرسم تبعيّات الحزمة يُشارك بشكل مختلف، ونموذج البحث الكلّيّ ليس مطابقاً للتحميل الكلاسيكيّ لسطح المكتب unpackaged. ¹

يهمّ هذا في الممارسة عند انتقال فريق من:

• التطوير المحلّيّ unpackaged
• إلى توزيع MSIX أو غيره من التوزيعات packaged
• أو إلى سيناريوهات Windows App SDK التي تُدخل تبعيّات قائمة على الحزم

إذا قدّمت مقالة أو مراجعة تصميم «ترتيب بحث DLL في Windows» على شكل قائمة مسطّحة وحيدة خالدة، فعلى الأرجح أنّها تُبسِّط المشكلة أكثر من اللازم.

5. ماذا تعني فعلاً قائمة الوحدات المحمَّلة وKnown DLLs

جزءان من النموذج كثيراً ما يُفاجئان الناس لأنّهما ليسا بحث مجلَّدات اعتياديّاً.

5.1 قائمة الوحدات المحمَّلة

تُصرِّح Microsoft بأنّ النظام يستطيع التحقّق ممّا إذا كان DLL باسم الوحدة نفسه محمَّلاً بالفعل في الذاكرة، بصرف النظر عن المجلَّد الذي جاء منه أصلاً. ¹

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

5.2 Known DLLs

يُوثِّق Microsoft أيضاً Known DLLs بوصفها قائمة Windows لكلّ إصدار تحت:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs ¹

إن كان اسم الوحدة في تلك القائمة، فإنّ النظام يستخدم نسخته من ذلك الـ Known DLL. فالأمر إذن ليس مجرّد سباق طبيعيّ بين مجلَّد التطبيق ومجلَّد قرص آخر. إنّه آليّة على مستوى الـ loader.

6. API sets عقود، لا أسماء ملفّات قرص اعتياديّة

تصف Microsoft اسم API set بأنّه اسم مستعار افتراضيّ لملفّ DLL فعليّ. والغرض هو فصل العقد عن تنفيذ DLL المضيف الفعليّ. ³

لذلك لا ينبغي قراءة اسم مثل api-ms-win-core-... بالنموذج الذهنيّ نفسه الذي يُستخدَم لـ DLL تطبيق عاديّ مُوضَع بجوار EXE.

النقطة الهندسيّة مهمّة:

• يمكن للتنفيذات أن تنتقل بين DLLات مضيفة عبر إصدارات Windows وعائلات الأجهزة
• يستطيع المستدعون مع ذلك استهداف العقد
• تتحسّن التوافقيّة لأنّ الكود غير مرتبط باسم DLL مضيف ملموس واحد ³

7. مانيفست والتجميعات side-by-side تحلّ صنفاً مختلفاً من المشكلات

كثيراً ما يُذكَر DLL redirection ومانيفست SxS معاً، لكنّهما ليسا فكرتين متطابقتين.

يُوثِّق Microsoft مانيفست بوصفها ملفّات XML تصف تجميعات side-by-side أو تطبيقات معزولة، شاملةً الهويّة والـ binding ومعلومات التفعيل والملفّات التي تُكوِّن التجميعة. ⁸

كما يُوضِّح Microsoft أنّ تجميعات side-by-side تُستخدَم وحدةً للتسمية والـ binding وإصدار النسخ والتوزيع والإعداد، وأنّ مانيفست مع هويّة الإصدار يُتيحان للـ loader أن يربط نسخة التجميعة الصحيحة بالتطبيق. ⁹

ولذلك يُفيد في الممارسة التمييز بين:

• وضع DLL خاصّ في مجلَّد التطبيق
• DLL redirection
• ربط side-by-side المُوجَّه بمانيفست

تُؤثِّر الثلاثة جميعاً على ما يُحمَّل، لكنّها ليست أداة التصميم نفسها.

8. ماذا يُغيِّر SetDllDirectory وAddDllDirectory وLoadLibraryEx

8.1 SetDllDirectory

يُغيِّر SetDllDirectory ترتيب البحث، لكنّ النقطة الأمنيّة الحاسمة هي أنّ Microsoft تُصرِّح بأنّه يُعطِّل فعليّاً وضع safe DLL search ما دام المسار المحدَّد موجوداً. ¹

ذلك يعني أنّه ليس API ملاءمة غير ضارّ.

ثمّة نقطة دقيقة أخرى: يُلاحِظ Microsoft أنّ عمليّة أب تستدعي SetDllDirectory يمكن أن تُؤثِّر على ترتيب البحث القياسيّ للعمليّة الابن. ¹

بالنسبة لمعظم الكود الحديث، هذا سبب وجيه لعدم اللجوء إلى SetDllDirectory أوّلاً.

8.2 AddDllDirectory

يُضيف AddDllDirectory مجلَّدات تشارك عبر LOAD_LIBRARY_SEARCH_USER_DIRS. يُلاحِظ Microsoft أيضاً أنّه إذا أُضيفَ أكثر من مسار، فإنّ ترتيب البحث بينها غير محدَّد. ¹⁵

لذلك إذا تطلّب تصميمك بحثاً صارماً من اليسار إلى اليمين بين عدّة مجلَّدات مخصَّصة، فهذا افتراض ضعيف.

8.3 SetDefaultDllDirectories

يصف Microsoft SetDefaultDllDirectories بوصفه طريقة لتعريف مسار بحث DLL افتراضيّ على مستوى العمليّة يُزيل المجلَّدات الأكثر هشاشة من مسار البحث القياسيّ. ⁴

عمليّاً، يعني ذلك:

• ينطبق على العمليّة المستدعية
• يستمرّ طوال حياة تلك العمليّة
• مُصمَّم للحدّ من التعرّض لـ DLL preloading

إنّه واحد من أوضح الـ APIs لتحريك عمليّة نحو وضع تحميل افتراضيّ أكثر أماناً. ⁴

8.4 LoadLibraryEx

يُتيح لك LoadLibraryEx التأثير على سلوك البحث برايات مثل LOAD_WITH_ALTERED_SEARCH_PATH وعائلة LOAD_LIBRARY_SEARCH_*. ⁶¹

في الممارسة، يساعد ذلك حين تحتاج إلى:

• تقييد فضاء البحث المسموح
• تضمين المجلَّدات المعروفة الآمنة فقط
• ضمان أن يتضمّن البحث عن التبعيّات مجلَّد تحميل DLL عند الاقتضاء

9. التحميل بمسار كامل لا يُثبِّت تلقائيّاً DLLات التبعيّة

هذه واحدة من أهمّ التفاصيل العمليّة في توثيق Microsoft.

حتّى عند تحميل أوّل DLL بمسار كامل، يبحث النظام عن تبعيّات ذلك الـ DLL كأنّها حُمِّلت باسم وحدة فقط. ¹⁴

ذلك يعني أنّ الافتراض التالي غير آمن:

• «حمّلتُ C:\MyApp\plugins\foo.dll بشكل صريح»
• «إذن فإنّ تبعيّته bar.dll يجب أيضاً أن تأتي من المجلَّد نفسه»

ليس بالضرورة.

هذا الفهم الخاطئ وحده يُفسِّر حالات كثيرة من:

• يعمل على جهاز البناء
• يفشل على جهاز العميل
• يُحمِّل التبعيّة الخاطئة بعد تثبيت منتج آخر

10. تجنّب مشاكل DLL preloading والـ hijacking

إرشادات Microsoft الأمنيّة لـ DLL واضحة: إذا حمَّل تطبيق DLL ديناميكيّاً دون مسار مؤهَّل بالكامل، وتحكَّم مهاجم في مجلَّد على مسار البحث، فبإمكان المهاجم زرع نسخة خبيثة هناك. تُسمِّي Microsoft ذلك هجوم DLL preloading أو هجوم binary planting. ²

الأساس العمليّ هو:

• تجنّب التحميل الديناميكيّ بأسماء عارية حيثما أمكن
• تفضيل المسارات الكاملة عند معرفة موقع الوحدة المسموح
• تضييق مسار بحث العمليّة بـ SetDefaultDllDirectories
• إضافة مجلَّدات موثوقة صريحة فقط بـ AddDllDirectory
• استخدام LoadLibraryEx مع رايات LOAD_LIBRARY_SEARCH_* لجعل القصد صريحاً
• تجنّب الاعتماد العَرَضيّ على المجلَّد الحاليّ أو محتويات PATH العريضة

هذا مهمّ خاصّةً للعمليّات المرفَّعة الصلاحيّات، لأنّ DLL الخبيث يُنفَّذ بصلاحيّات العمليّة المُضيفة. ²

11. قائمة فحص عمليّة للمراجعة

عند مراجعة تطبيق Windows يُحمِّل DLLات، تكشف هذه الأسئلة كثيراً من المشكلات الواقعيّة مبكّراً:

1. هل التطبيق packaged أم unpackaged؟
2. أيّ DLLات هي تبعيّات ساكنة وأيّها تُحمَّل ديناميكيّاً؟
3. هل التحميلات تتمّ بمسار كامل أم باسم وحدة عارٍ؟
4. هل يُستخدَم SetDllDirectory في أيّ مكان؟
5. هل يمكن للعمليّة الانتقال إلى SetDefaultDllDirectories ورايات LOAD_LIBRARY_SEARCH_*؟
6. هل تُستخدَم مسارات AddDllDirectory متعدّدة مع افتراضات ترتيب خفيّة؟
7. هل إدارة التبعيّات قائمة على الوضع الخاصّ لـ DLL أو مانيفست أو SxS أو redirection؟
8. هل لا تزال العمليّة تعتمد على المجلَّد الحاليّ أو مدخلات PATH الواسعة؟
9. هل يمكن لتبعيّة أن تُحَلّ بشكل مختلف على جهاز آخر حتّى عندما يُحمَّل أوّل DLL بمسار كامل؟

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

12. الخلاصة

حلّ أسماء DLL في Windows ليس مجرّد قائمة مجلَّدات.
إنّه مزيج من قواعد الحلّ السابقة لنظام الملفّات وسياق الحزمة وحالة الوحدات المحمَّلة ومعالجة Known DLLs والوساطة عبر API sets والربط القائم على مانيفست والـ APIs التي تُغيِّر فضاء البحث. ¹³⁴

الاستنتاجات العمليّة هي:

• لا تحفظ جدول ترتيب بحث مسطّحاً واحداً وتتوقّف عند ذلك
• افصل سلوك packaged عن unpackaged
• تذكَّر أنّ التحميل بمسار كامل لا يُثبِّت تلقائيّاً DLLات التبعيّة
• تجنّب الاستخدام العَرَضيّ لـ SetDllDirectory
• اتّجه نحو SetDefaultDllDirectories ورايات بحث LoadLibraryEx الصريحة عندما تحتاج سلوكاً أكثر أماناً

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

Related articles

• قائمة فحص الحدّ الأدنى لأمن تطبيقات Windows
• إلى أيّ مدى يمكن لتطبيق Windows أن يكون فعلاً ملفّاً ثنائيّاً واحداً؟
• متى يحتاج تطبيق Windows فعلاً صلاحيّات المسؤول؟
• ما هو Reg-Free COM؟

References

1. Microsoft Learn: Dynamic-link library search order
2. Microsoft Learn: Dynamic-Link Library Security
3. Microsoft Learn: Windows API sets
4. Microsoft Learn: SetDefaultDllDirectories function
5. Microsoft Learn: AddDllDirectory function
6. Microsoft Learn: LoadLibraryEx function
7. Microsoft Learn: Dynamic-link library redirection
8. Microsoft Learn: Manifests
9. Microsoft Learn: About Side-by-Side Assemblies

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

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

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

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

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

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

غو كومورا

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

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