ما هي بعض الأساليب لاستكشاف أخطاء انتهاك الوصول المتقطع للغاية وإصلاحها على جهاز يعمل بنظام Windows Mobile؟

Question

لدي تطبيق Compact Frameworks V2.0 كبير يعمل بشكل جيد جدًا في معظم الحالات.على أجهزة معينة، يتلقى المستخدم مرة واحدة يوميًا تقريبًا الخطأ الأصلي 0xC0000005 الذي لم يتم اكتشافه باستخدام كتلة Try/Catch المُدارة القياسية.

يتزامن تطبيقي مع الخادم عبر مكالمات ASMX على فترات زمنية محددة.يبدو أن المشكلة تحدث أثناء المزامنة.يوجد منطق عمل كبير بالإضافة إلى استدعاء ASMX الذي يحدث في وقت المزامنة، ولكن 98% من ذلك عبارة عن تعليمات برمجية مُدارة.لقد قمت بمراجعة جميع مكتبات P/Invoces الخاصة بي ومكتبات C++ الأصلية للتطبيقات وفي هذه المرحلة أنا متأكد بنسبة 95٪ تقريبًا من عدم وجود المشكلة.

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

سيكون موضع تقدير أي أفكار حول كيفية استكشاف هذه المشكلة وإصلاحها.

Answer 1

وبلدي معالجة الاستثناء مواطن C ++ وليس بما في ذلك استثناء المتزامن، وبالتالي لم يكن اصطياد الاستثناءات انتهاك وصول.

وهذا قد / قد لا يكون مفيدا لمشكلتي، ولكن قد يكون من المفيد للآخرين.

واستخدام رمز التبديل / EHA كما هو موثق في هذا الرابط سوف تسمح لصيد هذه الأنواع من الاستثناءات:

http://msdn.microsoft.com/en-us/library /1deeycx5.aspx

Answer 2

يعد 0xC0000005 انتهاكًا للوصول، لذا يحاول شيء ما القراءة منه أو الكتابة إلى عنوان ليس لديه حقوق الوصول إليه.يصعب العثور على هذه الأدوات وتمثل تجربتها واحدة من أفضل الأدوات (حسنًا، يعد مصحح الأخطاء الخاص بـ Platform Builder مفيدًا أيضًا، ولكن هذا يمثل وسيلة منفصلة تمامًا لتصحيح الأخطاء ويتطلب خبرة ربما لا تمتلكها أو قد تكون لديك بالفعل حاولت ذلك).أجد أن التسجيل يميل إلى أن يكون أقل فائدة من الترميز الطرحي - إزالة مكالمات P/invoc مع مكالمات مُدارة وهمية كلما أمكن ذلك.

تحدث انتهاكات الوصول في التطبيقات المُدارة عادةً لأحد الأسباب التالية:

• يمكنك P/استدعاء واجهة برمجة تطبيقات أصلية لتمرير مؤشر إلى كائن مُدار وتستخدم واجهة برمجة التطبيقات الأصلية هذا المقبض.إذا حصلت على مجموعة وضغط أثناء تشغيل واجهة برمجة التطبيقات الأصلية، فقد يتحرك الكائن المُدار ويصبح المؤشر غير صالح.
• يمكنك P/استدعاء شيء ما بمخزن مؤقت صغير جدًا أو أصغر من الحجم الذي تمرره وتتجاوز واجهة برمجة التطبيقات عملية القراءة أو الكتابة
• المؤشر (IntPtr، وما إلى ذلك) الذي تمرره إلى استدعاء P/Invine غير صالح (-1 أو 0) ولا يتحقق منه المواطن الأصلي قبل الاستخدام
• يمكنك P/استدعاء مكالمة أصلية ونفاد الكود الأصلي من الذاكرة (عادة ما يكون افتراضيًا) ولا يتحقق من التخصيصات الفاشلة ويقرأ/يكتب إلى عنوان غير صالح
• أنت تستخدم GCHandle الذي لم تتم تهيئته أو الذي يشير بطريقة ما إلى كائن تم الانتهاء منه وتجميعه بالفعل (لذا فهو لا يشير إلى كائن، ولكنه يشير إلى عنوان كان موجودًا فيه الكائن)
• يستخدم تطبيقك مؤشرًا لشيء تم إبطاله بسبب السكون/الاستيقاظ.هذا أكثر خصوصية ولكنه يحدث بالتأكيد.على سبيل المثال، إذا كنت تقوم بتشغيل تطبيق من بطاقة تخزين، فلن يتم تحميل التطبيق بأكمله في ذاكرة الوصول العشوائي (RAM).يتم ترحيل القطع المستخدمة إلى صفحات الطلب للتنفيذ.هذا هو كل شيء حسن وجيد.الآن، إذا قمت بإيقاف تشغيل الجهاز، فسيتم إيقاف تشغيل جميع برامج التشغيل.عند إعادة تشغيل الطاقة، تقوم العديد من الأجهزة ببساطة بإعادة تركيب أجهزة التخزين.عندما يحتاج تطبيقك إلى صفحة الطلب في المزيد من البرامج، فإنه لم يعد في مكانه ويموت.يمكن أن يحدث سلوك مماثل مع قواعد البيانات الموجودة في المتاجر المثبتة.إذا كان لديك مؤشر مفتوح لقاعدة البيانات، بعد دورة السكون/التنبيه، فقد لا يكون مؤشر الاتصال صالحًا.

ستلاحظ الاتجاه هنا وهو أن كل هذه العناصر تقريبًا عبارة عن P/Invocations وهذا ليس من قبيل الصدفة.من الصعب جدًا الحصول على تعليمات برمجية مُدارة للقيام بذلك بمفردها.