ما يجب التحقّق منه عندما لا يعمل ActiveX على Office 2024 / Microsoft 365 - الترتيب العمليّ لتغطية التعطيل الافتراضيّ، 32bit / 64bit، تسجيل COM، DLL التابعة، ووصولًا إلى IE mode

الملخّص التنفيذيّ

• أوّل ما يجب فهمه هو أنّه على Office 2024 و Microsoft 365، عناصر تحكّم ActiveX في Word / Excel / PowerPoint / Visio معطّلة افتراضيًّا. حتّى القوالب الداخليّة وملفّات الأعمال التي كانت تُفتَح سابقًا قد تظهر فجأةً ‹غير عاملة› بعد تغيير إعداد أو تحديث.
• يمكن تكثيف الأسباب في ثلاث فئات. تغيّر إعدادات الأمن، وعدم تطابق 32bit / 64bit أو دعم OS، ونقص في تسجيل COM أو DLL التابعة / .NET / Visual C++ runtime. عمليًّا، الأقصر هو معالجتها بهذا الترتيب.
• أكبر فرق بين عائلة Office 2024 و Microsoft 365 Apps هو نموذج التحديث وفرضيّات الدعم. عائلة Office 2024 تتمحور حول تحديثات الأمن/الجودة، ولا تتلقّى تحديثات ميزات جديدة بصورة مستمرّة. في المقابل، Microsoft 365 Apps يتغيّر باستمرار حسب قناة التحديث. إضافةً إلى ذلك، اعتبارًا من 2026، فإنّ متطلّبات Windows الرسميّة لـ Microsoft 365 Apps تتمحور حول Windows 11 / Windows Server 2022 و 2025. Windows 10 بحدّ ذاته انتهى دعمه بوصفه OS في 2025-10-14، لكنّ Microsoft 365 Apps يَتلقّى تحديثات الأمن على Windows 10 حتّى 2028-10-10 ضمن مهلة الترحيل، ويتلقّى تحديثات الميزات حتّى Version 2608. لا يعني ذلك أنّ ‹Windows 10 لا يعمل مطلقًا›، بل المعالجة الصحيحة هي اعتباره فرضيّة مزدوجة: ‹OS انتهى دعمه، و Apps في مهلة الترحيل›.
• ممّا يَسهل إغفاله عند العودة بعد فترة هو أنّ معظم سجلّ Registry / السياسات في كلٍّ من Office 2024 و Microsoft 365 يبقى ضمن Office 16.0. كَون اسم المسار لا يحوي 2024 لا يعني أنّك تبحث في المكان الخطأ.

هذا المقال دليل عمليّ يصبّ المراجع الرسميّة من Microsoft في خطوات تحقّق جاهزة للاستخدام في الميدان، انطلاقًا من فرضيّة بيئات Office لإصدار Windows التي تستخدم تقارير داخليّة، وأدوات أعمال تعتمد على Excel، وعناصر تحكّم مدمجة في Word / PowerPoint / Visio، ومكوّنات COM قائمة.

نظرة عامّة ونطاق التأثير

من أجل الإيجاز، نشير في هذا المقال إلى Office 2024 ذي الترخيص الدائم و Office LTSC 2024 مجتمعَين بـ ‹عائلة Office 2024›. معظم نقاط التحقّق التقنيّة مشتركة بينهما.

استيعاب الجدول الزمنيّ التالي يجعل تفسير ‹لماذا توقّف ActiveX فجأةً› أسهل.

timeline
    title Office / Windows / IE mode prerequisite changes
    2024 : Office 2024 family released
         : ActiveX disabled by default in Office / Microsoft 365
    2025-10-14 : End of support for consumer Windows 10
    2026 : Microsoft 365 Apps mainly requires Windows 11 / Server 2022/2025
         : IE mode supported at least through 2029

حالات الاستخدام التي يَسهل ظهور التأثير فيها هي مصنّفات Excel التي تحوي أزرارًا أو نماذج، وكائنات ActiveX المدمجة في Word / PowerPoint / Visio، وحلول Office القديمة، والتقارير/مساعدات الإدخال الداخليّة المعتمدة على مكوّنات COM. عندما يكون ActiveX معطّلًا، لا يتعذّر إنشاء كائنات ActiveX جديدة فحسب، بل يتعذّر التفاعل مع القائمة منها أيضًا.

قائمة التحقّق المسبقة

من حيث الاستنتاج، إنّ التحقّق من ‹build / bitness في Office›، و‹فرضيّات Windows›، و‹Trust Center›، و‹كيان COM› بالترتيب من الأعلى إلى الأسفل هو الأسلوب الأكثر فعّاليّة. وعلى وجه الخصوص، في Microsoft 365، يلزم النظر إلى فروق القنوات وتأثير تحديثات الأمن على مستوى build.

مرجع سريع لـ Registry والسياسات الرئيسة

في كلٍّ من عائلة Office 2024 و Microsoft 365، عدد المسارات التي ينبغي تذكّرها ليس كبيرًا. المهمّ هما: ‹ابحث عن 16.0›، و‹افصل بين كيان COM والحظر من جانب Office›.

سياسات Trust Center في تطبيقات Office تترتّب حسب التطبيق، مثلًا على هذا النحو: Microsoft Excel 2016 > Excel Options > Security > Trust Center. النمط نفسه ينطبق على Word / PowerPoint / Visio / Access. عند الانطلاق من هذه الشجرة، لا تضيع في تتبّع Trusted Locations وما يتعلّق بـ Macro.

خطوات التشخيص التفصيليّة

في الميدان، الأسلوب القياسيّ هو التضييق بترتيب: خطأ الإعدادات، عدم تطابق OS/bitness، مشكلة كيان COM، التبعيّات، فرق التحديثات. التدفّق التالي هو ترجمة هذا الترتيب مباشرةً إلى رسم.

flowchart TD
    A[Reproduce symptom] --> B[Capture Office product, build, bitness, OS]
    B --> C{Are OS/Office prerequisites met?}
    C -- No --> C1[Fix prerequisites: OS / Office edition / channel]
    C -- Yes --> D[Check Trust Center]
    D --> E{Issue with ActiveX/Protected View/Trusted Documents/Publisher?}
    E -- Yes --> E1[Fix settings, signing, distribution design]
    E -- No --> F{Legacy Web / IE-dependent?}
    F -- Yes --> F1[Check IE mode and site list]
    F -- No --> G[Inspect CLSID / InprocServer32 / TypeLib]
    G --> H{Is COM registration valid?}
    H -- No --> H1[regsvr32 / Regasm / reinstall]
    H -- Yes --> I[Check dependent DLLs / .NET / VC++]
    I --> J{Are dependencies satisfied?}
    J -- No --> J1[Repair / redistribute the runtime]
    J -- Yes --> K[Collect logs / Procmon / Process Explorer]
    K --> L[Inspect build delta and security update delta]

أوّلًا التقاط معلومات البيئة

أوّل ما يجب توثيقه هو اسم منتج Office، الإصدار، build، نوع التثبيت، bitness، و build في Windows. على جانب Office نتحقّق عبر [ملف] > [حساب] > [معلومات المنتج]، ثمّ نصل إلى bitness عبر [حول ××]. في عائلة Office 2024 يُقابَل ذلك مع صفحة سجلّ التحديث، وفي Microsoft 365 Apps مع ملاحظات إصدار / قناة التحديث.

# Windows-side prerequisite information
Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption, Version, BuildNumber, OSArchitecture

Get-ComputerInfo |
  Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture

# If Office apps are running, record the executable paths
Get-Process WINWORD, EXCEL, POWERPNT, VISIO -ErrorAction SilentlyContinue |
  Select-Object ProcessName, Path

عند هذه النقطة، إذا كان Microsoft 365 يعمل على Windows 10 الذي انتهى دعمه بوصفه OS (مع متابعة التشغيل عبر تحديثات الأمن في مهلة الترحيل)، أو عناصر تحكّم خاصّة بـ 32bit مَحمَلة على Office 64bit، فالأسرع هو التحقّق من الفرضيّات قبل الخوض في فحص جانب Apps فقط. متطلّبات Microsoft 365 Apps الحاليّة (تتمحور حول Windows 11 / Server 2022 و 2025، مع تعامل Windows 10 على أساس مهلة الترحيل حتّى 2028-10-10)، وإرشاد Microsoft بضرورة التفكير في Office 32bit عند استخدام إضافات/امتدادات COM خاصّة بـ 32bit، موجودان لهذا السبب بالضبط.

ثمّ تشخيص Trust Center والتحكّم الأمنيّ

التشخيص التالي هو الفصل بين هل الملفّ نفسه محظور، أم فشل تحميل كيان COM. ننظر بالترتيب إلى شريط الرسائل الأصفر لـ ActiveX، و [تمكين المحتوى] في Backstage، و Protected View، و Trusted Documents، و Trusted Publishers. وعلى وجه الخصوص، Trusted Documents يَسهل أن تُحرِّف الفحوصات اللاحقة بمجرّد منح trust، فيلزم الانتباه.

أوّلًا ننسخ الملفّ المُشكِل إلى مجلّد محلّيّ مُدار، ونعيد إنتاج الحالة باسم مختلف عن الأصل. لأنّ ملفّات المشاركة عبر الشبكة، ومرفقات البريد، والملفّات المنزَّلة حديثًا، تخضع بسهولة لتأثير Protected View والحكم بأنّها من الويب. وفي وثائق Microsoft، يُفعَّل Protected View عند مصادر مثل الإنترنت والمواقع الخطرة والمرفقات، وعند جعل المستند Trusted Document يَسهل أن يُفتح المحتوى النشط لاحقًا دون تحذير.

:: Launch Office apps in Safe Mode to isolate add-in effects
excel /safe
winword /safe
powerpnt /safe

:: Backup before changing the registry
reg export HKCU\Software\Microsoft\Office\Common\Security "%USERPROFILE%\Desktop\office-common-security.reg" /y

Safe Mode فعّال لتمييز تأثير الإضافات المحيطة وإعدادات المستخدم. كما أنّ حذف Trusted Publishers وبعض التغييرات لا يمكن إجراؤه إلّا بصلاحيّات المسؤول، لذا عندما تكون ‹الإعدادات رماديّة لا يمكن تغييرها›، نُجرّب تشغيل Office نفسه بوصفه مسؤولًا.

بعد ذلك التحقّق من تسجيل COM والتبعيّات

إذا لم يكن هناك سبب واضح في جانب Trust Center، فالتالي هو CLSID و InprocServer32. أساس COM هو أن يكون ذلك CLSID موجودًا في Registry، وأن يكون مسار DLL الكيانيّ صحيحًا. وعند COM-published assembly في .NET، نستخدم Regasm وليس regsvr32.

:: Standard verification of COM registration
reg query "HKLM\SOFTWARE\Classes\CLSID\{YOUR-CLSID-HERE}\InprocServer32" /s

:: Register / unregister an ActiveX / COM DLL
regsvr32 C:\Path\YourControl.dll
regsvr32 /u C:\Path\YourControl.dll

:: مثال على نشر COM لـ .NET assembly
:: مهمّ: يجب مطابقة bitness في RegAsm مع bitness في Office.
:: التسجيل عبر Framework64 يدخل فقط إلى عرض COM 64bit، فلا يَره Office 32bit.
:: والعكس صحيح: عرض COM 32bit المسجَّل عبر Framework لا يَره Office 64bit.
:: 64bit Windows + 32bit Office (تركيب شائع في الأصول القديمة):
"%WINDIR%\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" "C:\Path\YourManagedControl.dll" /codebase /tlb

:: 64bit Windows + 64bit Office:
"%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe" "C:\Path\YourManagedControl.dll" /codebase /tlb

:: لإدخاله إلى كلا عرضَي COM، نشغّل كلا RegAsm بالتعاقب.

في الصياغة الرسميّة لـ regsvr32، /u لإلغاء التسجيل، و /s صامت، و /i لـ DllInstall. تسجيل COM لـ .NET assembly مبنيّ على Regasm، حيث يُنشأ CLSID / Interface / TypeLib في Registry. ‹تشغيل regsvr32 على managed DLL› خطأ نموذجيّ. وبالنسبة لـ Office، عندما لا تتطابق bitness في RegAsm مع bitness في Office، يحدث الحادث النموذجيّ: التسجيل في Registry ناجح ظاهريًّا، لكنّ Office لا يجده. عند 32bit Office على 64bit Windows استخدم RegAsm من Framework، وعند 64bit Office استخدمه من Framework64.

عند فحص التبعيّات أيضًا، الأسلوب الأكثر عمليّة هو التحقّق من DLL المُحمَّلة عبر Process Explorer، وتتبّع NAME NOT FOUND / PATH NOT FOUND / ACCESS DENIED عبر Procmon. يستطيع Process Explorer إظهار DLL المُحمَّلة، ويستطيع Procmon تتبّع نشاط الملفّات/Registry/العمليّات/الخيوط آنيًّا.

التحقّق من runtime التابع أيضًا يُفضَّل ألّا يُؤجَّل إلى النهاية كثيرًا. تذكر وثائق Microsoft أنّ أحدث .NET Framework هو 4.8.1، وأنّ Visual C++ Redistributable مفترض تثبيت النسخة المناسبة لكلّ جيل من Visual Studio. في أنظمة الأعمال وعناصر التحكّم القائمة، يتكرّر ‹DLL الرئيس موجود، لكنّه لا يقلع بسبب نقص VC++ 2013 / v14 runtime›.

وأخيرًا جمع السجلّات لتحديد ما إذا كانت المشكلة فرق build أو مشكلة كيان

إذا بقي السبب غامضًا حتّى هنا، نُفعِّل السجلّات لالتقاط لحظة إعادة الإنتاج. على جانب Office، توجد طرق لجمع السجلّ العامّ وسجلّ Click-to-Run، وتُرشد Microsoft إلى أنّ الإخراج يكون في %windir%\temp أو %temp%. بالتوازي ننظر إلى Event Viewer > Windows Logs > Application، وعند الحاجة Applications and Services Logs.

:: Office general log
reg add HKCU\Software\Microsoft\Office\16.0\Common\Logging /v EnableLogging /t REG_DWORD /d 1

:: Click-to-Run detailed log
reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3
reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v PipelineLogging /t REG_DWORD /d 1

:: Disable logging
reg delete HKCU\Software\Microsoft\Office\16.0\Common\Logging /v EnableLogging /f
reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v PipelineLogging /f
reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /f

:: Event Viewer
eventvwr.msc

إذا كان وقت إعادة الإنتاج معلومًا، فالحيلة هي تضييق مراجعة السجلّ إلى دقائق قبل وبعد ذلك. عند الاشتباه بالتبعيّات قد يكون .NET Runtime أو SideBySide في سجلّ Application هو الدليل الحاسم، وفي مشاكل تحديث/إصلاح Office يكون سجلّ Click-to-Run هو الدليل الأقوى.

مرجع سريع للأوامر والأدوات

الأسباب الشائعة والمعالجات العمليّة

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

الحلول البديلة والإعدادات الموصى بها

أساس الإجراء الدائم هو ‹عدم خفض الأمن العامّ، بل السماح بشكل محدود فقط للأهداف الضروريّة›. حتّى الوثائق الرسميّة لـ Microsoft تفترض أنّ Protected View و Trusted Documents و Trusted Locations و Trusted Publishers جميعًا تعمل ‹على المصادر الموثوقة فقط›.

معايير سهلة التوصية للمؤسّسات

مثال سكربت Registry للاختبار

التالي مخصّص للاختبار فقط. قبل اعتماده دائمًا، رتّب توقيع المصدر، والشهادة، ومسار التوزيع. الغرض هو إلغاء التعطيل الإجماليّ لـ ActiveX من أجل تشخيص السبب.

Windows Registry Editor Version 5.00

; Test only: clear Office-wide ActiveX disable
[HKEY_CURRENT_USER\Software\Microsoft\Office\Common\Security]
"DisableAllActiveX"=dword:00000000

عند الرغبة في حظر كائن COM معيّن داخل Office، أو التحقّق من حدوث الحظر، نستخدم آليّة Office COM kill bit. مكان الفحص يختلف بين 64bit Office على 64bit Windows، و 32bit Office على 64bit Windows.

Windows Registry Editor Version 5.00

; Example: block a specific COM object inside Office
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Common\COM Compatibility\{YOUR-CLSID-HERE}]
"Compatibility Flags"=dword:00000400

نقاط الانتباه عند التوزيع

في كلٍّ من عائلة Office 2024 و Microsoft 365، ينبغي التفكير في كيان النشر/الإصلاح/التحديث على فرضيّة Click-to-Run. حتّى وثائق Office LTSC 2024 تذكر صراحةً الانتقال من Windows Installer إلى Click-to-Run بوصفه فارقًا مهمًّا. من الضروريّ عدم النقل الحرفيّ لسكربتات التوزيع القديمة من عصر MSI، أو batch التسجيل الذاتيّ، أو فرضيّات وضع DLL يدويًّا.

من أجل التوافق مع ActiveX/COM القديم، إذا أردنا توحيد Microsoft 365 Apps على 32bit و Monthly Enterprise، فالتركيب التالي عمليّ في أداة نشر Office. ليس الهدف ‹ملاحقة الميزات الجديدة بأقصى سرعة›، بل ‹تقليل احتمال كسر أصول الأعمال المفترِضة لـ x86›.

<Configuration>
  <Add OfficeClientEdition="32" Channel="MonthlyEnterprise">
    <Product ID="O365ProPlusRetail">
      <Language ID="ja-jp" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" />
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

كملاذ أخير، Quick Repair / Online Repair فعّال أيضًا. لكن مع أنّه يصلح تلف الإعدادات والتسجيل، إلّا أنّه لا يحلّ بحدّ ذاته عدم تطابق x86/x64 أو مشاكل التوقيع/السياسة. الإصلاح في ‹النهاية فقط› يُجنّب تلويث سجلّات التحقيق.

المصادر الرسميّة الأَولى بالاستناد إليها

في الميدان، العودة إلى المعلومات الرسميّة بالترتيب التالي أسرع وأضمن من البحث الواسع في نتائج البحث.

• التحقّق من واقعة أنّ ActiveX أصبح معطّلًا افتراضيًّا
  وثيقة لتُتحقَّق منها أوّلًا لمعرفة ما تغيّر في Office 2024 / Microsoft 365. تُحدِّد نطاق التأثير على Word / Excel / PowerPoint / Visio.
• كيفيّة التعامل مع ActiveX في ملفّات Office
  أقرب وثيقة إلى عمليّات المستخدم: شريط الرسائل، [تمكين المحتوى] في Backstage، التفعيل المحدود بالجلسة، وغيرها.
• سجلّ تحديث عائلة Office 2024
  يُستخدَم لمقارنة build في Office 2024 / LTSC 2024، وفروق ما قبل/ما بعد التحديث، والتحقّق من التحديث اليدويّ.
• قنوات تحديث / ملاحظات إصدار Microsoft 365 Apps
  لازمة لتتبّع الفرق بين Current / Monthly Enterprise / Semi-Annual، وفروق السلوك الناتجة عن channel.
• معايير الحكم الرسميّة على 32bit / 64bit في Office
  أهمّ وثيقة عند تورّط أصول x86 في ActiveX / COM.
• الوثائق الرسميّة المتعلّقة بـ IE mode
  لتحديد ما إذا كانت الحالة تحتاج إلى IE mode في Edge، والتحقّق من Enterprise Site List وأسماء السياسات.
• COM / regsvr32 / Regasm / COM kill bit
  وثائق أساسيّة لمعرفة أين يحدث الفشل: التسجيل، TypeLib، CLSID، InprocServer32، أم الحظر من جانب Office.
• Procmon / Process Explorer
  السلاح الأخير عند ‹الإعدادات صحيحة لكنّه لا يعمل›. يَكشف واقع تحميل DLL التابعة واستعلامات Registry.
• .NET Framework / Visual C++ Redistributable
  مرجع للحالات التي يسقط فيها التشغيل بسبب نقص في runtime محيط، لا في عنصر التحكّم نفسه.

تبدو مشاكل ActiveX حدسيًّا ‹مشكلة Excel فقط›، لكنّها فعليًّا مشكلة تتقاطع فيها القيم الافتراضيّة لأمن Office، وفرضيّات دعم Windows، وتسجيل كيان COM، و runtime التابع، ونموذج التحديث. مع التشخيص بالترتيب الموصوف، نصل إلى إصلاح أقلّ عرضةً للتكرار، دون إرخاء الإعدادات عشوائيًّا.

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

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

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

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

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

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

غو كومورا

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

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