لماذا أحصل على GPF في DLLMain عند تشغيله كمستخدم مقيد؟

Question

لماذا يتعطل هذا الرمز عند تشغيله كمستخدم مقيد، ولكن ليس عند تشغيله كمسؤول للجهاز؟

extern "C" BOOL WINAPI DllMain(HINSTANCE hInstance, 
                               DWORD dwReason, 
                               LPVOID lpReserved)
{
 hInstance;
 m_hInstance=hInstance;
 return _AtlModule.DllMain(dwReason, lpReserved); 
}

الكود يتعطل عند العودة...وأنا لا أعرف لماذا.

تلقيت:

The instruction at "0x7c90100b" referenced memory at "0x00000034". 
The memory could not be "read".

علاوة على ذلك، يبدو _AtlModule.DLLMain كما يلي:

inline BOOL WINAPI CAtlDllModuleT<T>::DllMain(DWORD dwReason, LPVOID lpReserved) throw()
{
#if !defined(_ATL_NATIVE_INITIALIZATION)
    dwReason; lpReserved;
#pragma warning(push)
#pragma warning(disable:4483)
    using namespace __identifier("<AtlImplementationDetails>");
#pragma warning(pop)
    if (dwReason == DLL_PROCESS_ATTACH)
    {
        ATLASSERT(DllModuleInitialized == false);
    }
    return TRUE;
#else
    return _DllMain(dwReason, lpReserved);
#endif
}

نحن نقوم باستيراد ملف ATL DLL، وحاولنا الارتباط بشكل ثابت أيضًا...لا حظ.

---

تحديث

باستخدام ProcMon، أحصل على تجاوز سعة المخزن المؤقت هنا:

RegqueryValue HKU S-1-5-21-448539723-854245398-1957994488-1005 Softwar144

ماذا يعني هذا؟

Answer 1

عندما تحصل على خطأ يفيد بأنه لا يمكنك الرجوع إلى ذاكرة عند مستوى 0x0000...الموقع، فهذا يعني عادةً أن التعليمات البرمجية الخاصة بك تحاول الإشارة إلى متغير عضو لبعض الكائنات، لكن مؤشر الكائن يشير إلى NULL.في هذه الحالة، يكون متغير العضو 0x34 بايت في الكائن.مزيد من التخمين، نظرًا لأنه يفشل فقط عند التشغيل تحت مستخدم مقيد، أود أن أقول إن بعض العمليات التي من المفترض أن تعيد مؤشرًا إلى كائن تفشل بسبب عدم كفاية الحقوق.إذا لم يتم اختبار المؤشر الذي تم إرجاعه للتأكد من كونه فارغًا، فسيستمر تشغيل التعليمات البرمجية حتى يحاول شخص ما قراءة أحد متغيرات أعضائه، وعند هذه النقطة تحصل على العطل.

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

Answer 2

جيسون,

أين تعلن m_hInstance؟هل هو ثابت في أعلى DllMain؟أحاول فقط الحصول على مزيد من التفاصيل حول الكود.

Answer 3

أنت لا تقول حقًا ما تعنيه بكلمة "تحطم" لذلك من الصعب معرفة ذلك.لا يقوم الكود بأي شيء على وجه الخصوص من شأنه أن يتسبب في حدوث عطل، لذلك من المحتمل أن يتم الاتصال بوحدة ATL DllMain يتطلب امتيازات المسؤول ويفشل بسبب ذلك.

Answer 4

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

هناك شيء واحد يجب التحقق منه إذا كنت تستخدم ATL DLL (بدلاً من المكتبة الثابتة):تأكد من حصولك على نفس الإصدار من DLL في كلتا الحالتين.

Answer 5

يبدو أننا قمنا بتتبع RDCOMClient، والذي يستخدم لتشغيل كائن COM داخل R.

ساعدت إجابات الجميع.شكرًا لك.