SearchProtocolHost.exe
مصطلحات البحث في الكتالوج searchprotocolhost, search protocol host
مستضيف معالج بروتوكول Windows Search. بيحمل معالجات ISearchProtocol عشان يزحف في الـ URIs. الـ SearchIndexer.exe بيكتب في الـ catalog. والـ SearchFilterHost.exe بيحمل الـ IFilters.
اللي محتاج تعرفه
مستضيف البروتوكول بيزحف. مش بيكتب في الـ catalog وما بيحملش IFilters.
SearchProtocolHost.exe هو مستضيف معالج بروتوكول Windows Search. بيفتح بروتوكولات الملفات و MAPI و URIs تانية عشان الـ indexer يشوف العناصر. SearchIndexer.exe بيكتب الـ catalog. و SearchFilterHost.exe بيعزل IFilters. أما SearchApp.exe فده واجهة المستخدم (UI).
- آمن؟
- اتأكد من مسار الملف اللي شغال، وتوقيعه، وجهة النشر بتاعته. مجرد اسم الملف لوحده ما يثبتش إنه آمن.
- هل بيكتب في الفهرس؟
- لا. SearchIndexer هو اللي بيعمل كده
- هل بيحمل IFilters؟
- لا. SearchFilterHost هو اللي بيعمل كده
إيه هو SearchProtocolHost.exe؟
SearchProtocolHost.exe هو مستضيف معالج البروتوكول. بيحمل تطبيقات ISearchProtocol عشان يزحف في الـ URIs. مش بيكتب في الـ catalog، SearchIndexer.exe هو اللي بيعمل كده. ومش بيحمل IFilters، SearchFilterHost.exe هو اللي بيعمل ده.
بيعمل إيه؟
بيعد العناصر من خلال معالجات البروتوكول (نظام الملفات، Outlook، ومعالجات مخصصة). النص اللي بيتحلل لسه بيعدي على مستضيف الفلاتر. وكتابة الـ catalog بتتعمل عن طريق الـ indexer.
ليه شغال؟
WSearch بيزحف في مكان أنت ضفته، ملف PST جديد، أو URI بيملكه معالج بروتوكول. استهلاك الهارد هنا سببه الزحف، مش SearchApp وهو بيرسم الاقتراحات.
ليه فيه منه كذا نسخة شغالين؟
ممكن أكتر من مستضيف بروتوكول يزحفوا في URIs مختلفة في نفس الوقت. ولا نسخة منهم بتكتب في الـ catalog. SearchIndexer.exe هو اللي بيعمل ده.
فحص النسخة قيد التشغيل
في Windows PowerShell، يسرد هذا الاستعلام للقراءة فقط معرفات العمليات المطابقة، وأوقات الإنشاء، ومسارات الملفات التنفيذية على هذا الكمبيوتر.
Get-CimInstance -ClassName Win32_Process | Where-Object { $_.Name -eq 'SearchProtocolHost.exe' } | Select-Object ProcessId, ParentProcessId, CreationDate, Name, ExecutablePath | Format-List
لا يوجد نتيجة أو مسار غير قابل للوصول يعتبر غير حاسم. قد تقيد العمليات المحمية الوصول، ويمكن إعادة استخدام معرفات العمليات. احتفظ بالمسارات الشخصية محلية.
استخدم دليل هوية الملف لمقارنة التوقيعات وبيانات التعريف الخاصة بالمنتج. اسم الملف وحده لا يمكن أن يثبت الأمان.
هل هو آمن؟
تحقق من هذا الملف قيد التشغيل
SearchProtocolHost.exe اللي في System32 هو مستضيف الزحف الفعلي. النسخة اللي في ملف مضغوط لتسريع البحث مش هو. الملف ده برضه مش بيكتب في الـ catalog ولسه مش بيحمل IFilters.
قارن الموقع المسجل بالملف الفعلي. مجلد مألوف وحده لا يثبت الهوية.
C:\Windows\System32\SearchProtocolHost.exe
- جهة النشر المتوقعة: Microsoft Corporation
- كاتب الـ catalog: هو SearchIndexer.exe
- مستضيف IFilter: هو SearchFilterHost.exe
هل ينفع أقفله؟
الزحف بيقف مؤقتاً
إنهاء SearchProtocolHost.exe بيوقف زحف البروتوكول ده لحد ما الـ indexer يشغل مستضيف تاني. مش بيمسح الـ catalog. ومش بيلغي تحميل IFilters في SearchFilterHost.
هل ينفع أفتحه وأمسحه؟
لأ
بلاش تمسح SearchProtocolHost.exe. شيل مكان من Indexing Options لو عاوز تقلل الزحف. وعطل WSearch بس لو موافق على بحث مش مفهرس.
هل المفروض يشتغل مع بداية تشغيل Windows؟
WSearch بيشغل مستضيفات البروتوكول وقت الحاجة. ده مش سطر في Startup Apps جنب SearchApp.
قياس استخدام الموارد
| وحدة المعالجة المركزية والذاكرة | قارن عدة ملاحظات لنفس معرف العملية وحمل العمل. هذه الإدخال ليس له خط أساس عالمي مقاس بشكل مستقل. |
|---|---|
| القرص والشبكة | نسب النشاط إلى العملية الفعلية والمهمة الحالية؛ اسم الملف وحده لا يحدد الوجهات المتوقعة أو حجم النقل. |
معلومات الملف
| اسم الملف التنفيذي | SearchProtocolHost.exe |
|---|---|
| مسار التثبيت المسجل | C:\Windows\System32\SearchProtocolHost.exe |
| جهة النشر | Microsoft Corporation |
| فحص التوقيع | افحص الملف الفعلي؛ هذا الإدخال لا يصدق هوية شهادته. |
المشاكل الشائعة
استهلاك هارد عالي واللوم بيقع على SearchFilterHost
استهلاك المعالج في الفلتر بيبقى بسبب تحليل المحتوى. استهلاك الهارد في مستضيف البروتوكول بيبقى بسبب المرور على الفولدرات ومخازن الإيميل. افصل بينهم في Resource Monitor.
زحف Outlook مش بيخلص أبداً
معالج بروتوكول MAPI ممكن يخلي المستضيف ده مشغول دايماً. قلل فهرسة Outlook في Indexing Options قبل ما تعيد البناء.
استكشاف الأخطاء وإصلاحها
شخّص المشكلة الأول قبل ما تعمل أي تغيير يضر النظام.
قلل أماكن Indexing Options الأول
شيل الفولدر الضخم أو مسار UNC القديم. ده هيوقف مستضيف البروتوكول من غير ما تلمس IFilters.
خلي إعادة بناء الفهرس آخر خطوة
إعادة البناء بتبدأ الزحف والفلاتر من أول وجديد. استعملها بعد ما تظبط الأماكن أو تصلح معالج بروتوكول بايظ، مش كأول ضغطة زرار.
التفاصيل التقنية
التفاصيل التقنية
| اسم الصورة (Image name) | SearchProtocolHost.exe |
|---|---|
| الدور | مستضيف زحف ISearchProtocol |
التحقق من هوية ملف شغال
اسم الملف وحده لا يمكن أن يثبت الأمان. تحقق من المسار الفعلي والتوقيع وهوية المنتج.
المصادر والتحقق
تاريخ المصدر المسجل: أغسطس 2026. التاريخ ده مش إثبات لتحقق مستقل. إزاي بنعمل أبحاثنا.
- Microsoft Learn: معالجات البروتوكول (protocol handlers) · مستضيفات ISearchProtocol بتزحف في الـ URIs
- دعم Microsoft: فهرسة البحث (search indexing) · الأماكن وإعادة البناء تخص الـ indexer
- خريطة عمليات Foxhole · عينات طرف أول على أجهزة كمبيوتر ويندوز. مش مقياس أداء معملي.
- Microsoft Sysinternals: أداة Sigcheck · بتشرح إزاي تفحص التواقيع الرقمية للملفات. المرجع ده مش إثبات لهوية أو أمان ملف معين شغال حالياً.
- Microsoft: Get-CimInstance · طريقة استعلام العمليات المحلية للقراءة فقط.
- خصائص Microsoft: Win32_Process · توثق معرفات العمليات، ومسارات الملفات التنفيذية، وتواريخ الإنشاء، وإعادة استخدام معرف العملية الأب.
هل المقالة دي كانت مفيدة؟
مجرد نعم أو لأ كفاية. اختار سبب لو تحب، أو اكتب ملاحظة سريعة.
شكراً ليك. ده بيساعدنا نحسن الصفحة دي.