مدخل إلى ملف تعريف المستخدم في Windows - AppData و NTUSER.DAT

هذه المقالة ملخص عام موجّه إلى فرق تقنية المعلومات التي تدير Windows، ومسؤولي نشر الأجهزة، ومطوّري تطبيقات Windows. الرسوم مخطّطات مفاهيمية. في بيئة Markdown تدعم Mermaid تظهر كرسوم.

المحتوى مبني على معلومات Microsoft الرسمية التي أمكن التحقق منها حتى أبريل 2026.[1][4][7][10][13][14]

دليل القراءة

المقالة طويلة، لذا نضع أولاً مدخلاً حسب الموقع.

في استشارات Windows تُستخدم كلمة «ملف التعريف (profile)» بمعنى واسع جداً.

• ماذا يوجد داخل C:\Users\اسم المستخدم
• كيف ينبغي توزيع الاستخدام بين %AppData% و %LocalAppData%
• ما هو roaming profile في بيئة domain
• ما الفرق بين Mandatory profile و Temporary profile
• ماذا نختار في جهاز مشترك أو RDS أو VDI أو Azure Virtual Desktop
• من أين نبدأ المعاينة عندما يتلف الملف التعريفي

هنا تختلط دفعة واحدة الحساب و المجلد و Registry و طريقة المزامنة و سياسة التشغيل، فينحرف النقاش بسرعة.

في هذه المقالة نضع أولاً منظوراً يرى ملف تعريف المستخدم في Windows كمخطّط تصميم واحد، ثم نرتّب بالترتيب توزيع AppData، و roaming، و Mandatory، و Temporary، و FSLogix، وطريقة المعاينة عند العطل.

1. الخلاصة أولاً

قبل التفاصيل، هذه الخلاصات العملية.

• ملف تعريف المستخدم في Windows ليس مجرد مجلد C:\Users\اسم المستخدم. إنه مجموعة من الملفات + user registry hive (NTUSER.DAT).[1]
• في جهاز محلي عادي يُنشأ افتراضياً ملف تعريفي محلي. عند أول تسجيل دخول يُنشأ ملف تعريفي جديد على أساس C:\Users\Default.[11][12]
• لا يُحسَم مكان حفظ التطبيق عشوائياً. القاعدة الأساسية: الإعدادات التي نريد حملها مع كل مستخدم في %APPDATA%، و cache أو الحالة المؤقتة الخاصة بهذا الجهاز في %LOCALAPPDATA%.[2][3]
• roaming profile آلية «نقل الملف التعريفي بأكمله إلى مشاركة». Folder Redirection آلية «توجيه known folders مثل Documents فقط إلى مكان آخر». ليستا الشيء نفسه.[4][5]
• Mandatory profile ملف تعريفي للقراءة فقط الغرض منه «السماح بالاستخدام دون السماح بالحفظ». Temporary profile ملاذ طارئ عند الخطأ، ويُفترض أنه يُحذف في كل مرة.[7][8][9]
• roaming الذي يعبر أجيال نظام التشغيل يحتاج حذراً. Windows 10 / Server 2016 وما بعدهما غير متوافقين مع ما قبلهما، فنفصل إصدارات الملف التعريفي.[6]
• في RDS / VDI / Azure Virtual Desktop، في حالات كثيرة يكون FSLogix profile container الخيار الأول أفضل من الدفع بـ roaming التقليدي وحده. Microsoft أيضاً توصي بـ FSLogix في Azure Virtual Desktop.[13][14]
• عند العطل، قبل لمس C:\Users، الأسلم النظر إلى Application log، و Operational / Diagnostic لخدمة User Profile Service، ومسار المشاركة، وسمات وأذونات NTUSER.DAT / USRCLASS.DAT.[10][11][16]

باختصار، حديث ملف التعريف في Windows يختصر إلى أين نضع ماذا، وإلى أي مدى نحمله مع المستخدم، وكيف نعود عند الفشل.

1.1 الاختصارات المستخدمة في هذه المقالة

نوسّع هنا الاختصارات التي تظهر من البداية.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 24، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. ما هو أصلاً «ملف تعريف المستخدم» في Windows

في البداية، يسهل الأمر إذا فصلنا الحساب عن الملف التعريفي.

flowchart LR
    A["حساب المستخدم (من يسجّل الدخول)"] --> B["ملف تعريف المستخدم (إعداداته وبياناته)"]
    C["الجهاز / نظام التشغيل"] --> B
    B --> D["إعدادات سطح المكتب"]
    B --> E["AppData"]
    B --> F["Documents / Desktop وغيرها"]
    B --> G["الإعدادات الظاهرة في HKCU"]

الشكل 1: الحساب معرّف، والملف التعريفي كيان الإعدادات والبيانات، والجهاز يحمّله ليستخدمه.

• الحساب يعرّف شخصاً ما
• الملف التعريفي هو الكيان الفعلي لبيئة عمل ذلك الشخص
• الجهاز هو المكان الذي يُحمَّل فيه الملف التعريفي ويُستخدم

في Microsoft Learn أيضاً يُشرح أن ملف تعريف المستخدم يشمل مجموعة مجلدات الملف التعريفي على نظام الملفات و registry hive NTUSER.DAT، وأن هذا الـ hive يُحمَّل عند تسجيل الدخول ويُستخدم كـ HKEY_CURRENT_USER.[1]

2.1 ليس «المجلدات فقط» بل «يشمل Registry أيضاً»

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

flowchart TD
    A["تسجيل الدخول"] --> B["تحديد مجلد الملف التعريفي"]
    B --> C["تحميل NTUSER.DAT"]
    C --> D["الاستخدام كـ HKCU"]
    B --> E["تجهيز Desktop / Documents / AppData"]
    D --> F["تصبح إعدادات المستخدم سارية"]
    E --> F

الشكل 2: عند تسجيل الدخول يكتمل إعداد المجلدات وتحميل NTUSER.DAT معاً حتى تسري إعدادات المستخدم.

أي أن النظر إلى C:\Users\اسم المستخدم وحده لا يزال نصف الصورة.

لملف التعريف في Windows طبقتان كبيرتان:

1. طبقة الملفات Desktop، Documents، Downloads، AppData وغيرها
2. طبقة Registry HKCU بعد تحميل NTUSER.DAT

ما يعقّد أعطال الملف التعريفي أن الطبقة المجلدية وحدها قد تتلف و طبقة registry hive قد تكون هي مصدر المشكلة.[1][11]

2.2 عند أول تسجيل دخول يكون Default هو الأساس

عندما يسجّل مستخدم جديد الدخول إلى هذا الجهاز لأول مرة، ينشئ Windows ملفاً تعريفياً محلياً على أساس C:\Users\Default.[11]

flowchart LR
    A["C:\\Users\\Default"] --> B["أول تسجيل دخول"]
    B --> C["إنشاء C:\\Users\\اسم المستخدم"]
    C --> D["تحميل NTUSER.DAT"]
    D --> E["تصبح بيئة خاصة بذلك المستخدم"]

الشكل 3: عند أول تسجيل دخول يُنشأ ملف تعريفي خاص بذلك المستخدم على أساس Default.

إذا عولج هذا بسطحية في سياق نشر الصور أو تجهيز الأجهزة، يصبح الأمر شاقاً لاحقاً.

تشرح Microsoft أن الطريقة المدعومة لتخصيص ملف التعريف الافتراضي هي استخدام CopyProfile. النسخ اليدوي أو التكرار العشوائي القديم قد يدخل معلومات زائدة ويسبب مشكلات في استقرار التطبيقات أو النظام.[12]

3. كيف نقرأ C:\Users\اسم المستخدم

إذا نظرنا إلى ملف تعريف المستخدم من جهة المجلدات، فالبنية تقريباً كالتالي.

flowchart TD
    A["C:\\Users\\اسم المستخدم"] --> B[Desktop]
    A --> C[Documents]
    A --> D[Downloads]
    A --> E[Pictures]
    A --> F[AppData]
    A --> G[NTUSER.DAT]
    F --> H[Roaming]
    F --> I[Local]
    F --> J[LocalLow]

الشكل 4: الملف التعريفي يتكوّن من مجموعة مجلدات و NTUSER.DAT، وينقسم AppData إلى ثلاثة أجزاء.

الأماكن التي ننظر إليها أولاً في العمل تقريباً هذه.

3.1 فكّر في AppData مقسوماً إلى ثلاثة

هنا أكثر ما يختلط في تطوير تطبيقات Windows وتحقيق الأعطال.

يرشد دليل Microsoft إلى استخدام FOLDERID_RoamingAppData (Roaming AppData) لبيانات التطبيق الخاصة، و FOLDERID_LocalAppData للملفات المؤقتة أو البيانات التي لا تُستخدم على أجهزة أخرى.[2]

وفي تعريفات Known Folders تُرتَّب المسارات الافتراضية كالتالي.[3]

• %APPDATA% = %USERPROFILE%\AppData\Roaming
• %LOCALAPPDATA% = %USERPROFILE%\AppData\Local
• LocalLow = %USERPROFILE%\AppData\LocalLow

flowchart LR
    A[AppData] --> B[Roaming]
    A --> C[Local]
    A --> D[LocalLow]

    B --> B1["إعدادات نريد حملها"]
    B --> B2["حالة مستخدم صغيرة نسبياً"]

    C --> C1["cache"]
    C --> C2["بيانات قابلة لإعادة التوليد"]
    C --> C3["حالة خاصة بهذا الجهاز"]

    D --> D1["منطقة تكتب فيها عمليات التكامل المنخفض"]

الشكل 5: Roaming لإعدادات الحمل، و Local لما يخص هذا الجهاز، و LocalLow لعمليات التكامل المنخفض.

LocalLow ليس «مكاناً لا يُستخدم» بل «مكان التطبيقات ذات الصلاحيات المنخفضة»

من الثلاثة، يميل شرح LocalLow إلى القصر. الغرض خاص، لكن سبب وجوده واضح.

لعمليات Windows تصنيف صلاحيات يُسمّى مستوى التكامل (integrity level). العملية التي تعمل بتكامل منخفض لا تستطيع الكتابة إلى معظم AppData\Roaming و AppData\Local و HKCU. من دون مكان آخر لا تحفظ شيئاً، لذلك وُجد مكان يمكن الكتابة إليه حتى بالتكامل المنخفض. هذا المكان هو %USERPROFILE%\AppData\LocalLow، وعلى جهة Registry HKEY_CURRENT_USER\Software\AppDataLow.[19]

أي أن الترتيب كالتالي.

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

الخلاصة من جهة تطوير التطبيقات بسيطة.

• إذا لم تشغّل تطبيقك بتكامل منخفض، فلا سبب لاستخدام LocalLow. استخدم Local.
• بالمقابل، إذا ظهرت مجلدات غير مألوفة في LocalLow، فما يكتب هناك هو شيء يعمل بتكامل منخفض. هذا دليل عند فحص استهلاك المساحة.

توزيع الاستخدام في العمل هكذا

ProgramData في تعريفات Microsoft للمجلدات المعروفة هو بيانات التطبيقات الموجّهة إلى كل المستخدمين، ومخصّص لبيانات مشتركة لا تتجوّل.[3]

ما يجب تجنّبه أكثر من غيره هنا هو وضع بيانات runtime الخاصة بكل مستخدم في Program Files. ينهار معه ترتيب الملف التعريفي وتصميم الأذونات دفعة واحدة.

3.2 Public و Default يختلفان في الدور

هنا أيضاً يسهل الخلط.

flowchart LR
    A["C:\\Users"] --> B[Default]
    A --> C[Public]
    A --> D["كل مستخدم"]

    B --> B1["بذرة إنشاء ملف تعريفي جديد"]
    C --> C1["مشترك ظاهر لكل المستخدمين"]
    D --> D1["الكيان الخاص بكل مستخدم"]

الشكل 6: Default بذرة الإنشاء الجديد، و Public منطقة مشتركة، ومجلد كل مستخدم هو الكيان الفردي.

• Default قالب لإنشاء ملف تعريفي جديد
• Public منطقة مشتركة تُعرض لكل المستخدمين
• مجلد كل مستخدم الكيان الخاص بذلك الشخص

هذه الثلاثة تبدو متشابهة، وأدوارها مختلفة تماماً.

4. ترتيب أنواع الملفات التعريفية

حتى كلمة «ملف تعريفي» وحدها تغطي في التشغيل أنواعاً لا تقل عن التالي.

flowchart TD
    A["ملف التعريف في Windows"] --> B["ملف تعريفي محلي"]
    A --> C["ملف تعريفي متجوّل"]
    A --> D["Mandatory profile"]
    A --> E["Temporary profile"]
    A --> F["حاوية ملف تعريف FSLogix"]

الشكل 7: في التشغيل تنقسم الملفات التعريفية إلى خمسة أنواع على الأقل، من المحلي حتى FSLogix.

4.1 الملف التعريفي المحلي

في جهاز عادي هذا هو الافتراضي.

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

تشرح Microsoft أيضاً أن Windows ينشئ افتراضياً local user profile.[14]

4.2 roaming profile

في Microsoft Learn، roaming user profile يُحفظ في مشاركة على الخادم، ليتيح استلام إعدادات نظام التشغيل والتطبيقات نفسها على عدة أجهزة.[4][5]

flowchart LR
    A["ملف تعريفي على خادم مشترك"] <--> B[PC-A]
    A <--> C[PC-B]
    A <--> D[PC-C]

الشكل 8: roaming profile آلية يستلم بها عدة أجهزة الملف التعريفي من خادم مشترك.

لكن في العمل انتبه للنقاط التالية.

• يسهل أن يثقل النسخ أو المزامنة عند تسجيل الدخول والخروج
• الاحتفاظ ببيانات كبيرة في AppData\Local يصبح شاقاً
• يتأثر بسهولة بفروق إصدارات نظام التشغيل
• يتأثر بقوة بمسار المشاركة وجودة الشبكة

4.3 Mandatory profile

Mandatory profile هو «roaming profile لا يُحفظ» يعدّه المسؤول.[7][8]

بحسب شرح Microsoft، حتى لو غيّر المستخدم أثناء الجلسة، لا تُحفظ التغييرات كما يحدث في roaming profile العادي.[7]

وتشرح وثائق Win32 أيضاً أن:

• إعادة تسمية NTUSER.DAT إلى NTUSER.MAN تجعله Mandatory
• جعل لاحقة اسم مجلد مسار الملف التعريفي .man تجعله Super-mandatory

.[8]

flowchart LR
    A["ملف تعريفي أعدّه المسؤول"] --> B["يسجّل المستخدم الدخول"]
    B --> C["يمكن التغيير أثناء الاستخدام"]
    C --> D["تسجيل الخروج"]
    D --> E["لا تُحفظ التغييرات"]

الشكل 9: Mandatory ملف تعريفي يعدّه المسؤول ولا يحفظ تغييرات الجلسة عند تسجيل الخروج.

يناسب مثلاً هذه الاستخدامات.

• أجهزة تعليم
• أجهزة استقبال
• kiosk
• أجهزة مشتركة نريد إعادتها إلى حالة نظيفة في كل مرة

4.4 Temporary profile

Temporary profile ليس خيار تصميم، بل وجهة تراجع تظهر عندما يتعذر تحميل الملف التعريفي الحقيقي بسبب خطأ.[9]

تشرح Microsoft Learn أنه عند تعذر تحميل الملف التعريفي الحقيقي بسبب شرط خطأ يُصدر Temporary profile، ويُحذف عند انتهاء الجلسة، وتضيع التغييرات.[9]

flowchart TD
    A["بدء تحميل الملف التعريفي العادي"] --> B{"هل يمكن التحميل؟"}
    B -->|Yes| C["تسجيل دخول عادي"]
    B -->|No| D["تسجيل دخول بـ Temporary profile"]
    D --> E["يمكن العمل"]
    E --> F["تضيع التغييرات عند تسجيل الخروج"]

الشكل 10: Temporary وجهة تراجع عند فشل التحميل، وتختفي التغييرات عند تسجيل الخروج.

أي أن العمل بـ Temporary profile إشارة عطل بحد ذاتها.

4.5 حاوية ملف تعريف FSLogix

تصف Microsoft Learn خدمة FSLogix بأنها آلية تجعل تجربة ملف تعريف المستخدم في Windows متسقة في بيئة سطح المكتب الافتراضي.[13]

حاوية ملف تعريف FSLogix طريقة تحمل الملف التعريفي بأكمله كـ VHD / VHDX، وتُرفقه عند تسجيل الدخول ليظهر كملف تعريفي أصلي.[13][14]

flowchart LR
    A["ملف تعريفي على VHD / VHDX"] --> B["الإرفاق عند تسجيل الدخول"]
    B --> C["يظهر على مضيف الجلسة كـ C:\\Users\\المستخدم"]
    C --> D["الفصل عند تسجيل الخروج"]

الشكل 11: يرفق FSLogix الملف التعريفي على VHD عند تسجيل الدخول ويظهره كملف أصلي.

في Azure Virtual Desktop توصي Microsoft بـ استخدام FSLogix profile containers.[14]

5. ما الفرق بين roaming profile و Folder Redirection و FSLogix

كثيراً ما تُروى هذه الثلاثة كحديث واحد، لكن الأدوار مختلفة.

flowchart TD
    A["حمل حالة المستخدم"] --> B["roaming profile"]
    A --> C[Folder Redirection]
    A --> D[FSLogix]

    B --> B1["الملف التعريفي بأكمله إلى المشاركة"]
    C --> C1["known folders فقط إلى مكان آخر"]
    D --> D1["إرفاق VHD/VHDX"]

الشكل 12: الطرق الثلاث تختلف في نطاق الحمل: الكل، أو known folders فقط، أو التحويل إلى حاوية.

بمواءمة ترتيب Microsoft Learn، يسهل رؤية الفروق هكذا.[4][5][14]

5.1 Folder Redirection يوجّه «known folders فقط»

في Microsoft Learn، Folder Redirection آلية توجّه مسار known folder إلى مكان آخر.[4]

مثلاً إذا وُجّه Documents إلى مشاركة ملفات، يراه المستخدم كما لو كان محلياً بينما الكيان في مكان آخر.[4]

flowchart LR
    A[Documents] --> B["الكيان مشاركة ملفات"]
    C[Desktop] --> D["إعداد منفصل إن لزم"]
    E[AppData] --> F["كما هو أو بطريقة أخرى"]

الشكل 13: Folder Redirection إعادة توزيع حسب المجلد، لا بديل عن الملف التعريفي بأكمله.

أي أن Folder Redirection ليس بديلاً عن الملف التعريفي بأكمله، بل إعادة توزيع حسب المجلد.

5.2 لا تخلط roaming profile عبر أجيال نظام التشغيل بلا حساب

تشرح Microsoft أن roaming profile في Windows 10 / Server 2016 وما بعدهما غير متوافق مع Windows الأقدم.[6]

flowchart LR
    A["عائلة Windows 7 / 8.1"] -.اختلاط يحتاج حذرا.-> B["المشاركة نفسها"]
    C["Windows 10 / Server 2016 وما بعدهما"] -.اختلاط يحتاج حذرا.-> B
    B --> D["سبب لعدم الاتساق / خلل قائمة ابدأ / خلل شريط المهام"]

الشكل 14: خلط roaming profiles من أجيال نظام تشغيل مختلفة في المشاركة نفسها يسبب عدم اتساق.

المهم هنا:

• فصل إصدار الملف التعريفي حسب جيل نظام التشغيل
• ألا نفكر «المستخدم نفسه، فالمجلد نفسه يكفي»
• في نشر الأجهزة أو التجديد، إدخال توافق الملف التعريفي في خطة الترحيل

.[6]

6. أماكن الحفظ التي يجب أن يحسمها المطوّر ومسؤول التشغيل أولاً

حديث الملف التعريفي يعود في النهاية إلى هنا. ماذا نضع أين.

flowchart TD
    A["بيانات نريد حفظها"] --> B{"هل هي نتائج أنشأها المستخدم؟"}
    B -->|Yes| C["Documents وغيرها"]
    B -->|No| D{"هل تخص هذا الجهاز؟"}
    D -->|Yes| E["%LOCALAPPDATA%"]
    D -->|No| F{"هل هي إعدادات لكل مستخدم؟"}
    F -->|Yes| G["%APPDATA%"]
    F -->|No| H{"هل هي بيانات متغيرة مشتركة لكل المستخدمين؟"}
    H -->|Yes| I["ProgramData + ACL"]
    H -->|No| J["إعادة النظر في مكان الوضع"]

الشكل 15: تُوزَّع البيانات المراد حفظها بهذا الترتيب: نتائج عمل، أم خاصة بالجهاز، أم إعدادات مستخدم، أم مشتركة.

6.1 افصل ملفات المستخدم عن الحالة الداخلية للتطبيق

إذا اختلط هذان، يسهل أن ينكسر النسخ الاحتياطي والترحيل معاً.

• نتائج يتعامل معها المستخدم بوعي Documents، Pictures، مجلد حفظ للعمل
• حالة داخلية للتطبيق إعدادات، cache، صور مصغّرة، معلومات الجلسة، ملفات عمل

الأولى بيانات عمل، والثانية حاجة التطبيق. حتى لو كان كلاهما «ملفات»، فالمعالجة يجب أن تنفصل.

flowchart TB
    accTitle: فصل نتائج العمل عن الحالة الداخلية للتطبيق
    accDescr: مخطّط يبيّن أن نتائج يتعامل معها المستخدم بوعي تُعامل كبيانات عمل مثل Documents، وأن الإعدادات والـ cache كحالة داخلية للتطبيق تحتاج مكاناً حسب حاجة التطبيق، وإلا يسهل أن ينكسر النسخ الاحتياطي والترحيل.
    sp1["الملفات المحفوظة"] --> sp2["نتائج يعيها المستخدم"]
    sp1 --> sp3["حالة داخلية للتطبيق"]
    sp2 -.-> sp4["بيانات عمل مثل Documents"]
    sp3 -.-> sp5["الإعدادات والـ cache حاجة التطبيق"]

الشكل 16: حتى الملف نفسه، بيانات العمل وحاجة التطبيق يختلفان مكاناً ومعالجة.

6.2 ما يوضع في %APPDATA%

ما يوضع هنا تقريباً من هذا النوع.

• إعدادات صغيرة
• تفضيلات لكل مستخدم
• حالة نريد أن تبدو نفسها على عدة أجهزة
• ما يجوز حمله مع الملف التعريفي

وثائق Fast User Switching أيضاً ترشد إلى FOLDERID_RoamingAppData كمكان لبيانات التطبيق الخاصة.[2]

6.3 ما يوضع في %LOCALAPPDATA%

ما نميل به إلى هنا ما يجب أن يبقى محلياً من زاوية إعادة التوليد أو عدم الحمل.

• cache قابل لإعادة التوليد
• حالة لا معنى لها إلا على هذا الجهاز
• ملفات عمل كبيرة
• ما لا نريد حمله لأسباب أداء

في تعريفات Known Folders أيضاً، LocalAppData هو %USERPROFILE%\AppData\Local.[3]

6.4 ما يوضع في ProgramData

البيانات المشتركة لكل المستخدمين لكنها تتغير أثناء التشغيل مرشحة لجهة ProgramData.[3]

مثلاً،

• قاموس مشترك
• ملفات تعريف مشتركة لكل المستخدمين
• بيانات متغيرة يشاركها خدمة وعدة مستخدمين

لكن هنا يجب التفكير مع تصميم ACL. ليس «مشترك إذن ProgramData مؤقتاً»، بل حسم من يقرأ ومن يكتب هو المهم.

6.5 عندما نريد تجهيز ملف التعريف الافتراضي

شائع في نشر الصور أن نريد «الإعدادات الأولية نفسها لكل مستخدم جديد». عندها الأسلم ألا نلمس Default عشوائياً، بل نبني على طريقة CopyProfile التي تدعمها Microsoft.[12]

flowchart LR
    A["إعداد أولي بحساب المسؤول"] --> B["Sysprep + CopyProfile"]
    B --> C["التطبيق على Default profile"]
    C --> D["يسري على المستخدمين الجدد بعد ذلك"]

الشكل 17: تجهيز ملف التعريف الافتراضي يتم عبر مسار Sysprep و CopyProfile.

طرق من قبيل «نسخ C:\Users\A يدوياً إلى Default على جهاز آخر» تبدو سريعة، لكنها سهلة الكسر لاحقاً.[12]

7. كيف نعاين عندما يتلف، أو يتحول إلى مؤقت، أو يتوقف عن المزامنة

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

7.1 قسّم الأعراض أولاً إلى ثلاثة

flowchart TD
    A["يشبه مشكلة ملف تعريفي"] --> B{"هل يمكن تسجيل الدخول؟"}
    B -->|Yes| C{"هل يبدو المنظر وقد أُعيد إلى الافتراضي؟"}
    B -->|No| D["عائلة فشل التحميل"]
    C -->|Yes| E["Temporary / تلف / ملف تعريفي آخر"]
    C -->|No| F{"هل ترجع بعض الإعدادات فقط؟"}
    F -->|Yes| G["عائلة roaming / إعادة التوجيه / المزامنة"]
    F -->|No| H["احتمال مشكلة خاصة بتطبيق"]

الشكل 18: بإمكانية تسجيل الدخول وبما إذا بدا المنظر معاد التهيئة، تنقسم مشكلات الملف التعريفي إلى ثلاثة مسارات.

تقريباً هذه العائلات الثلاث.

1. يفشل عند تسجيل الدخول
2. يمكن تسجيل الدخول لكن يبدو كأن كل شيء أُعيد إلى الافتراضي
3. جزء فقط لا يُزامَن

7.2 السجلات التي ننظر إليها أولاً

ترشد Microsoft Learn إلى النظر بهذا الترتيب عند تحقيق مشكلات الملف التعريفي.[10]

1. Application log
2. Operational log لخدمة User Profile Service
3. إن لزم Diagnostic log
4. وإن لزم أكثر ETL trace

المسارات المحددة كالتالي.[10]

• Event Viewer Applications and Services Logs > Microsoft > Windows > User Profile Service > Operational
• للمزيد من التفصيل ... > User Profile Service > Diagnostic

في Event Viewer على Windows الياباني، تصبح الشجرة اليسرى アプリケーションとサービス ログ > Microsoft > Windows > User Profile Service > Operational. من اسم الموفر فما دون يبقى بالإنجليزية.

flowchart LR
    A["Application log"] --> B["Operational log"]
    B --> C["Diagnostic log"]
    C --> D["ETL trace"]

الشكل 19: التحقيق يتعمق من Application log إلى Operational ثم Diagnostic ثم ETL trace.

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

السجلات الثلاثة في «أماكن مختلفة»

هنا أول ما يربك، فنرتّبه مسبقاً.[10]

Diagnostic log لا يظهر في الشجرة كما هو. في Event Viewer فعّل Actions > View > Show Analytic and Debug Logs ثم اختر Diagnostic ونفّذ Enable Log. بعد انتهاء التحقيق أعده إلى معطّل حتماً. السجل أشد تفصيلاً مما ينبغي تركه يعمل.[10]

رؤية الشيء نفسه من دون فتح الواجهة

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

# 1) Application ログから User Profile Service のイベントだけを新しい順に見る
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
} -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message

# 2) Operational ログを直接見る
Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

# 3) 長いパス起因の Event ID 1509 だけを絞り込む
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
    Id           = 1509
} | Format-List TimeCreated, Id, Message

هنا فخ واحد. اسم المصدر في جهة Application log هو Microsoft-Windows-User Profiles Service (Profiles بالجمع)، واسم القناة في Operational log هو Microsoft-Windows-User Profile Service/Operational (Profile بالمفرد). إذا لم يعمل النسخ واللصق، فعادة هذا هو السبب.

Event ID 1509 يظهر في Application log لا Operational log. المستوى تحذير، ونص الرسالة بالصيغة «يتعذر على Windows نسخ الملف \\server\share\... إلى C:\Users\...» ثم يليه DETAIL - The filename or extension is too long.. هذا السطر الأخير هو الدليل القاطع على أن طول المسار هو السبب.[16]

وثمة شيء آخر يوفّر الوقت في العمل. Microsoft تنص صراحة على أن الحدث 1530 لخدمة User Profile Service «ملف Registry لا يزال مستخدماً من تطبيق أو خدمة أخرى» يمكن تجاهله.[10] ملاحقته تذهب سدى.

flowchart TB
    accTitle: فخ المفرد والجمع في اسم السجل
    accDescr: مخطّط يبيّن أن اسم المصدر في جهة Application log هو Profiles بالجمع، واسم قناة Operational log هو Profile بالمفرد، وأن الأوامر التي لا تعمل بعد النسخ واللصق غالباً بسبب هذا الخلط.
    lg1["الأمر لا يعمل"] --> lg2{"أي اسم سجل استُخدم؟"}
    lg2 -->|"مصدر Application"| lg3["Profiles بالجمع"]
    lg2 -->|"قناة Operational"| lg4["Profile بالمفرد"]
    lg3 -.-> lg5["الخلط سبب نمطي"]
    lg4 -.-> lg5

الشكل 20: اسما سجل متشابهان غير متطابقين صارا سبباً نمطياً لفشل النسخ واللصق.

7.3 أسباب شائعة

سمات أو أذونات NTUSER.DAT / USRCLASS.DAT

تشرح Microsoft أن كون NTUSER.DAT أو USRCLASS.DAT للقراءة فقط، أو غياب أذونات الوصول اللازمة، قد يفشل تحميل الملف التعريفي.[11]

سبب متواضع، لكن تجاهله يطيل التحقيق.

flowchart LR
    A["تحميل الملف التعريفي"] --> B{"هل يمكن الوصول إلى ملف DAT؟"}
    B -->|No| C["فشل تسجيل الدخول / سطح مكتب أولي / Temporary"]
    B -->|Yes| D["تحميل عادي"]

الشكل 21: تعذر الوصول إلى ملف DAT يؤدي إلى فشل تسجيل الدخول أو التحوّل إلى ملف تعريفي مؤقت.

مسار طويل عند نسخ roaming

تشرح مقالة KB من Microsoft أمثلة يسقط فيها الأمر إلى Temporary profile مع Event ID 1509 لأن اسم الخادم أو المشاركة في جهة مسار المشاركة طويل، فيصبح مسار الوجهة بأكمله أطول مما ينبغي.[16]

يبدو قيداً بسيطاً على طول المسار، بينما يكون السبب في الواقع تصميم وجهة roaming نفسها.

معلومات Registry / مجلدات متبقية بعد حذف غير مكتمل

لدى Microsoft مقالة سكربتات عيّنة لتنظيف معلومات يتيمة متبقية في Registry و C:\Users ومنع TEMP profile.[15]

ما يتضح من هذا أن حذف المجلد وحده لا يكفي.

flowchart LR
    A["حذف عشوائي لملف تعريفي قديم"] --> B["تبقى معلومات Registry"]
    B --> C["عدم اتساق عند تسجيل الدخول التالي"]
    C --> D["سبب لـ TEMP profile أو مجلدات إضافية"]

الشكل 22: معلومات Registry المتبقية بعد حذف عشوائي تولّد عدم اتساق عند تسجيل الدخول التالي.

7.4 ماذا نفحص أولاً

8. أي طريقة ينبغي اختيارها

هنا ليست إجابة واحدة صحيحة. يتغير حسب شكل الاستخدام.

flowchart TD
    A["شكل الاستخدام"] --> B["جهاز شخصي مخصص"]
    A --> C["جهاز عمل منضم إلى domain"]
    A --> D["جهاز مشترك / جهاز تعليم"]
    A --> E["RDS / VDI / AVD"]

    B --> B1["محلي في الأساس"]
    C --> C1["Folder Redirection / roaming حسب الحاجة"]
    D --> D1["Mandatory / Shared PC / cleanup"]
    E --> E1["FSLogix الخيار الأول"]

الشكل 23: حسب شكل الاستخدام يتغير المرشح الأول من المحلي أساساً حتى FSLogix.

8.1 جهاز شخصي مخصص

الأساس ملف تعريفي محلي يكفي.

• إعدادات المستخدم في AppData
• نتائج العمل في Documents
• إن لزم، مزامنة المستندات في طبقة أخرى مثل OneDrive

هذا التكوين الأبسط.

8.2 جهاز عمل منضم إلى domain

حسب المتطلبات نركّب التالي.

• نريد إدارة مركزية لبيانات المستندات ← Folder Redirection
• نريد حمل الإعدادات نفسها أيضاً على عدة أجهزة ← roaming profile
• اختلاط أنظمة تشغيل أو ملف تعريفي كبير ← تصميم حذر، أو إعادة النظر في الطريقة

في Microsoft Learn أيضاً، Folder Redirection و Roaming User Profiles مفيدان للتجميع المركزي والاستخدام دون اتصال وتيسير النسخ الاحتياطي.[4]

8.3 جهاز مشترك / جهاز تعليم / kiosk

في هذا الاستخدام، أهم من «الإبقاء على تخصيص شخصي» هو العودة إلى حالة نظيفة في كل مرة.

المرشحون هؤلاء الثلاثة.

• Mandatory profile
• Shared PC mode
• سياسة الحذف التلقائي للملفات التعريفية القديمة

لدى Microsoft سياسة Delete user profiles older than a specified number of days on system restart، تحذف عند إعادة التشغيل الملفات التعريفية غير المستخدمة لعدد أيام محدد.[17]

ودليل Shared PC أيضاً يعرض فكرة الجمع بين الإدارة التلقائية للحسابات / الملفات التعريفية والحذف على الأجهزة المشتركة.[18]

8.4 RDS / VDI / Azure Virtual Desktop

هنا كثيراً ما لا يكفي roaming التقليدي وحده.

توصي Microsoft في Azure Virtual Desktop بـ FSLogix profile containers، وتشرح أنها ترفق VHDX / VHD عند تسجيل الدخول وتعامله كملف تعريف مستخدم أصلي.[14]

flowchart LR
    A["عدة مضيفات جلسات"] --> B["تخزين مشترك"]
    B --> C["ملف تعريفي للمستخدم على VHDX"]
    C --> D["الإرفاق بالمضيف المتصل"]

الشكل 24: عدة مضيفات جلسات ترفق ملف تعريف VHDX على تخزين مشترك وتستخدمه.

خصوصاً في شروط كهذه ترتفع قيمة النظر إلى FSLogix أولاً.

• مضيف الجلسة يتغير في كل مرة
• يُستخدم Outlook / OneDrive / عائلة Microsoft 365
• VDI غير دائم ويلزم حمل الملف التعريفي
• تأخير تسجيل الدخول في roaming صار مشكلة

9. سوء فهم شائع

9.1 «إذا أنشأنا حساباً، يُستخدم الملف التعريفي نفسه في كل مكان»

ليس كذلك. الحساب معرّف، والملف التعريفي كيان على جهة ذلك الجهاز. مدى الحمل تحدده الطريقة: local، roaming، Folder Redirection، FSLogix وغيرها.[4][14]

9.2 «نسخ C:\Users\اسم المستخدم يكفي للترحيل»

النسخ العشوائي خطر.

• توافق إصدار نظام التشغيل
• NTUSER.DAT
• الأذونات
• حالة خاصة بالتطبيق
• الاختلاط مع ملف التعريف الافتراضي

هذه كلها موجودة. خصوصاً في roaming عبر أجيال نظام التشغيل، تفترض Microsoft أيضاً فصل إصدارات الملف التعريفي.[6]

flowchart TB
    accTitle: لماذا الترحيل بنسخ عشوائي خطر
    accDescr: مخطّط يبيّن أن الترحيل بنسخ مجلد المستخدم عشوائياً خطر لأنه يحمل مشكلات توافق إصدار نظام التشغيل و NTUSER.DAT والأذونات والحالة الخاصة بالتطبيق والاختلاط مع ملف التعريف الافتراضي.
    mv1["نسخ المجلد بأكمله"] --> mv2["يبدو أن الترحيل نجح"]
    mv2 -.-> mv3["تبقى مشكلات توافق نظام التشغيل و NTUSER.DAT"]
    mv2 -.-> mv4["اختلاط الأذونات وملف التعريف الافتراضي"]
    mv3 --> mv5["ترحيل سهل الكسر لاحقاً"]
    mv4 --> mv5

الشكل 25: الملف التعريفي ليس المجلد وحده، لذا لا يُنقل بالنسخ.

9.3 «Mandatory و Temporary متشابهان تقريباً»

هذان شيئان مختلفان. Mandatory ملف تعريفي للقراءة فقط يعدّه المسؤول قصداً. Temporary وجهة تراجع عندما يتعذر قراءة الملف التعريفي الحقيقي بسبب خطأ.[8][9]

9.4 «إذا أردنا المزامنة يكفي وضع كل شيء في Roaming»

هذا خطر. وضع الإعدادات و cache ضخم في الصندوق نفسه يثقّل تسجيل الدخول والخروج ومعالجة الأعطال. أسهل في التشغيل فصل ما نريد تجواله عن ما يجب أن يبقى في Local.[2][3]

9.5 «حتى لو تحول إلى Temporary profile، نواصل الاستخدام كما هو»

الأفضل تجنّبه. Temporary profile يُفترض أنه يختفي عند تسجيل الخروج، فمواصلة العمل في هذه الحالة خطر وضع بيانات مهمة في مكان سيختفي لاحقاً.[9]

10. الخلاصة

ملف تعريف المستخدم في Windows ليس مجرد كلمة تشير إلى مجلد تحت C:\Users.

• مجموعة الملفات
• user registry المتمحور حول NTUSER.DAT
• طريقة التشغيل: أين يُحمل الملف التعريفي، وكيف يُزامَن، وكيف يُحذف

إذا فكّرنا في هذه معاً كتصميم واحد، تتضح الصورة.

ما يستحق تثبيته أولاً في العمل هذه النقاط الست.

• في جهاز منفرد، ابدأ من ملف تعريفي محلي كمرجع
• افصل أماكن حفظ التطبيق إلى Roaming / Local / ProgramData
• في بيئة domain لا تخلط roaming profile بـ Folder Redirection
• على الأجهزة المشتركة فكّر في Mandatory / cleanup / Shared PC
• في RDS / VDI / AVD ضع FSLogix مرشحاً أولاً
• عند التلف، انظر أولاً إلى سجلات User Profile Service

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

flowchart TB
    accTitle: الأسئلة الثلاثة لتصميم الملف التعريفي
    accDescr: مخطّط يبيّن أن تصميم الملف التعريفي يختصر إلى ثلاثة أسئلة: ماذا نضع أين، وإلى أي مدى نحمله، وكيف نعود عند الفشل، وأن ثبات هذه الإجابات يسهّل النشر والتصميم والتحقيق.
    dq1["ماذا نضع أين"] --> dq2["إلى أي مدى نحمله"]
    dq2 --> dq3["كيف نعود عند الفشل"]
    dq3 -.-> dq4["يسهل النشر والتصميم والتحقيق"]

الشكل 26: إذا أجبنا عن الأسئلة الثلاثة، يكون تصميم الملف التعريفي شبه ثابت.

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

• متى تكون امتيازات المسؤول مطلوبة في Windows - UAC والمناطق المحمية وطريقة التمييز في التصميم
• كيف نسرّع التحقق في تطوير تطبيقات Windows باستخدام Windows Sandbox

12. الخدمات المرتبطة بهذا الموضوع

تطوير تطبيقات Windows

كيف نفصل أماكن حفظ إعدادات المستخدم والسجلات والـ cache والبيانات المشتركة يؤثر بقوة في قابلية تشغيل تطبيقات Windows وصيانتها. إذا كنت تنظر من ترتيب المتطلبات إلى التصميم والتنفيذ والتشغيل طويل الأمد، فهذا موضوع يناسب سياق تطوير تطبيقات Windows.

انظر إلى الخدمة / تواصل معنا

استشارة تقنية ومراجعة التصميم

اختيار local / roaming / FSLogix، وكيف نغيّر تشغيل الأجهزة القائمة، وكيف نقطع أماكن الحفظ، يظهر فيها فرق كبير من الترتيب قبل التنفيذ. إذا أردت الترتيب من اختيار الطريقة وتصميم الحدود، فهو موضوع يسهل فصله كاستشارة تقنية ومراجعة تصميم.

انظر إلى الخدمة / تواصل معنا

التحقيق في الأعطال وتحليل الأسباب

التحوّل إلى Temporary profile، فشل تسجيل الدخول، فشل الحفظ عند تسجيل الخروج، والفصل حول مسار المشاركة، تناسب التحقيق في الأعطال جداً. تصير مدخلاً للاستشارة عندما تريد حصر مشكلات ملف تعريفي صعبة الإعادة من السجلات والأحداث والأذونات وتركيبة المشاركة.

انظر إلى الخدمة / تواصل معنا

13. روابط مرجعية

المصدر كثير، لذا نضع أولاً فهرساً يُرجع إليه من زاوية المسألة.

1. Microsoft Learn, About User Profiles (Windows) مكوّنات ملف تعريف المستخدم، و NTUSER.DAT، وأساسيات Temporary profile.

2. Microsoft Learn, Fast User Switching ترتيب استخدام FOLDERID_RoamingAppData لبيانات التطبيق الخاصة، و FOLDERID_LocalAppData للبيانات التي لا تُستخدم على أجهزة أخرى.

3. Microsoft Learn, KNOWNFOLDERID, CSIDL تعريفات المجلدات المعروفة مثل %APPDATA% و %LOCALAPPDATA% و LocalLow و ProgramData.

4. Microsoft Learn, Folder Redirection and Roaming User Profiles in Windows and Windows Server الفرق بين Folder Redirection و Roaming User Profiles وفكرة الإدارة المركزية.

5. Microsoft Learn, Deploy roaming user profiles الإجراءات العملية لنشر roaming profile وأذونات المشاركة و GPO وإدارة الإصدار.

6. Microsoft Learn, Roaming user profiles of earlier versions of Windows are incompatible with Windows 10, Windows Server 2016, and later versions عدم التوافق بين أجيال نظام التشغيل وإدارة إصدار الملف التعريفي.

7. Microsoft Learn, Create mandatory user profiles استخدامات Mandatory user profile وطريقة إنشائه.

8. Microsoft Learn, Mandatory User Profiles تعريف NTUSER.MAN و Super-mandatory profile.

9. Microsoft Learn, Temporary User Profiles تعريف Temporary profile وخصائصه.

10. Microsoft Learn, Troubleshoot user profiles with events الفصل باستخدام Application / Operational / Diagnostic logs.

11. Microsoft Learn, Error occurs during desktop setup and desktop location is unavailable when you log on to Windows for the first time إنشاء ملف تعريفي جديد انطلاقاً من C:\Users\Default، ومشكلات سمات وأذونات NTUSER.DAT / USRCLASS.DAT.

12. Microsoft Learn, Customize the default local user profile when you prepare an image of Windows طريقة تخصيص ملف التعريف الافتراضي المدعومة بواسطة CopyProfile.

13. Microsoft Learn, What is FSLogix, Types of Containers أساسيات FSLogix وفكرة Profile Container.

14. Microsoft Learn, User profile management for Azure Virtual Desktop with FSLogix profile containers, Configure profile containers using FSLogix التوصية في Azure Virtual Desktop وطريقة الحاوية باستخدام VHD / VHDX.

15. Microsoft Learn, Scripts: Clean up profile folder information and prevent TEMP user profiles from being created علاقة معلومات الملف التعريفي اليتيمة بـ TEMP profile.

16. Microsoft Learn, User profile cannot be loaded with Event ID 1509: DETAIL - The filename or extension is too long مشكلة المسار الطويل عند حفظ roaming profile.

17. Microsoft Learn, ADMX_UserProfiles Policy CSP تعريفات سياسات مثل Delete user profiles older than a specified number of days on system restart.

18. Microsoft Learn, Configure a shared or guest Windows device Shared PC mode وإدارة الحسابات / الملفات التعريفية على الأجهزة المشتركة.

19. Microsoft Learn, Designing Applications to Run at a Low Integrity Level أن %USERPROFILE%\AppData\LocalLow و HKEY_CURRENT_USER\Software\AppDataLow معدّان كأماكن تستطيع عمليات التكامل المنخفض الكتابة إليها.

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

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

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

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

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

ما هو NTUSER.DAT؟

NTUSER.DAT هو الملف الفعلي لـ user registry hive ضمن ملف تعريف المستخدم في Windows. يقع مباشرة تحت C:\Users\اسم المستخدم، ويُحمَّل عند تسجيل الدخول ليستخدم كـ HKEY_CURRENT_USER (HKCU). أي أن ملف تعريف المستخدم يتكوّن من طبقتين: مجموعة ملفات مثل Desktop و AppData، وطبقة Registry تتمحور حول NTUSER.DAT. إذا كان NTUSER.DAT بسمة للقراءة فقط أو بلا أذونات الوصول اللازمة، يفشل تحميل الملف التعريفي، فيتسبب ذلك في فشل تسجيل الدخول أو التحوّل إلى Temporary profile.

ما هو ملف تعريف المستخدم في Windows؟ هل يختلف عن الحساب؟

الحساب يعرّف من يسجّل الدخول. ملف تعريف المستخدم هو بيئة العمل الفعلية لذلك الشخص. ليس مجرد مجلد C:\Users\اسم المستخدم، بل مجموعة ملفات مثل Desktop و Documents و AppData مع NTUSER.DAT، أي user registry hive. عندما يسجّل مستخدم جديد الدخول لأول مرة، يُنشأ ملف تعريفي جديد على أساس C:\Users\Default. مدى حمل الإعدادات معه تحدده طريقة الاختيار: local أو roaming أو Folder Redirection أو FSLogix.

كيف نوزّع الاستخدام بين %APPDATA% و %LOCALAPPDATA%؟

الإعدادات التي نريد حملها مع كل مستخدم توضع في %APPDATA% (AppData\Roaming). أما cache أو الحالة المؤقتة الخاصة بهذا الجهاز فتوضع في %LOCALAPPDATA% (AppData\Local). نقل cache قابل لإعادة التوليد أو ملفات عمل كبيرة عبر roaming يثقّل تسجيل الدخول والخروج، لذا تُمال إلى جهة Local. للبيانات المتغيرة المشتركة بين كل المستخدمين يُرشَّح ProgramData، لكن فقط مع تصميم ACL لمن يقرأ ومن يكتب. لا توضع بيانات runtime الخاصة بكل مستخدم في Program Files.

ماذا نفعل عند تسجيل الدخول بـ Temporary profile؟

Temporary profile ملاذ طارئ يُصدر عندما يتعذر تحميل الملف التعريفي الحقيقي بسبب خطأ. يُحذف عند تسجيل الخروج، وتضيع كل التغييرات. مواصلة العمل في هذه الحالة خطر لأن بيانات مهمة قد تختفي. في التحقيق، بدل لمس C:\Users فوراً، افحص أولاً Application log و Operational log لخدمة User Profile Service، و Diagnostic إن لزم. أسباب شائعة: سمات أو أذونات NTUSER.DAT / USRCLASS.DAT، مسار roaming أطول مما ينبغي، وبقايا Registry من حذف غير مكتمل.

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

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

غو كومورا

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

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