كيفية استكشاف أخطاء .NET 2.0 خطأ الإبلاغ عن الرسائل في سجل الحدث؟

StackOverflow https://stackoverflow.com/questions/814560

سؤال

أنا أعمل على منتج مفتوح المصدر يسمى إيفمون مكتوبة في C# التي تستهدف منصة .NET 2.0 ، لدي مستخدم واحد يعاني من تحطم غريب .NET لم نتمكن من حله.

Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 5000
Date: 4/29/2009
Time: 10:58:10 PM
User: N/A
Computer: removed this
Description:
EventType clr20r3, P1 evemon.exe, P2 1.2.7.1301, P3 49ea37c8, P4
system.windows.forms, P5 2.0.0.0, P6 4889dee7, P7 6cd3, P8 18, P9
system.argumentexception, P10 NIL.

Data:
//hex representation of the above Description

يتعطل التطبيق نفسه دون عرض خطأ (على الرغم من وجود خطأ في التعامل مع واجهة المستخدم) ، تم نسخ الرسائل المذكورة أعلاه من سجل أحداث Windows. قام المستخدم النهائي بإعادة تثبيت .NET وتم تحديثه إلى أحدث الإصدارات. يتم توزيع ملفات .pdb مع كل إصدار إصدار من البرنامج للمساعدة في تصحيح الأخطاء والاختبار ، فإن المستخدم الذي يعاني من المشكلة المعنية لديه مكمل كامل لملفات PDB للإصدار الصحيح من Evemon.

هل هناك تقنية محددة ومجربة ومختبرة لتحليل وتشخيص هذا النوع من التعطل؟ وإذا كان الأمر كذلك فما هي الأدوات والتقنيات المتاحة للمساعدة في تصحيح الأخطاء؟

شكر خاص

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

هل كانت مفيدة؟

المحلول

هذه هي الطريقة التي سأواجه بها مشكلة مستخدم نهائي مع تحطم.

  1. قم بتنزيل وتثبيت أدوات تصحيح الأخطاء لنظام التشغيل Windows على http://www.microsoft.com/whdc/devtools/debugging/default.mspx

  2. بمجرد تثبيت الأدوات (ينتهي الأمر بالانتقال إلى C: Program Files افتراضيًا) ، قم بتشغيل نافذة سطر الأوامر.

  3. قم بتغيير إلى الدليل الذي يحتوي على AdPlus (على سبيل المثال "C: Program Files Debugging Tools for Windows (x86)").

  4. تشغيل الأمر follwing. سيؤدي هذا إلى بدء التطبيق وإرفاق AdPlus.

adplus -crash -o C:\debug\ -FullOnFirst -sc C:\path\to\your\app.exe

بعد إنشاء تفريغ الحادث

بمجرد بدء تشغيل التطبيق WindBG وتحميل ملف .dmp الذي يتم إنشاؤه في C: Debug. (ملف -> فتح تفريغ تحطم)

قم بتنفيذ هذه الأوامر لرؤية تتبع المكدس ونأمل أن نجد المشكلة.

لتحميل SOS لتصحيح الأخطاء

  • قبل .NET 4.0
.loadby sos mscorwks
  • .NET 4.0
.loadby sos clr

لرؤية تتبع المكدس

!clrstack

لرؤية تتبع مكدس أكثر فائدة

!clrstack –p

الكزة داخل كائن .. ربما ترى ما الذي تسبب في الاستثناء

!do <address>

على سبيل المثال ، هذه هي النتيجة من تطبيق تعرض بشكل عشوائي مع استثناء IO. أشار Windbg إلى المسار الذي تم الرجوع إليه والذي كان غير صحيح.

0:009> !do 017f2b7c    
Name: System.String    
MethodTable: 790fd8c4    
EEClass: 790fd824    
Size: 124(0x7c) bytes    
 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)    
String: \\server\path\not_here.txt
Fields:    
      MT    Field   Offset                 Type VT     Attr    Value Name    
79102290  4000096        4         System.Int32  1 instance       54 m_arrayLength    
79102290  4000097        8         System.Int32  1 instance       53 m_stringLength    
790ff328  4000098        c          System.Char  1 instance       5c m_firstChar    
790fd8c4  4000099       10        System.String  0   shared   static Empty    
    >> Domain:Value  00161df8:790d884c <<    
7912dd40  400009a       14        System.Char[]  0   shared   static WhitespaceChars    
    >> Domain:Value  00161df8:014113e8 <<

نصائح أخرى

يشير النظر إلى رمز المصدر الخاص بك (الجذع) إلى أن معالجة الاستثناء الخاصة بك غير مكتملة فيما يتعلق بتطبيقات نماذج Windows:

تحتاج إلى التعامل معها على حد سواء استثناءات موضوع غير UI واستثناءات موضوع واجهة المستخدم:

  • بالنسبة إلى الأول ، تحتاج إلى تنفيذ معالج استثناء غير معقد عبر CLR عبر AppDomain.CurrentDomain.UnhandledException, ، وهو في مكانه بالفعل.

  • بالنسبة لهذا الأخير ، تحتاج إلى تنفيذ معالج استثناء غير معالج بنظام Windows عبر Application.ThreadException, الذي يبدو أنه مفقود ؛ هذا يمكن أن يسفر بالضبط تلك المشاكل التي تشهدها. للحصول على مثال التنفيذ ، راجع وثائق MSDN من Application.ThreadException حدث.

يرجى ملاحظة أنك الآن تقمع بشكل صريح من استثناءات Windows غير المعقولة عن طريق استثناءات عبر Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException), ، ستحتاج إلى تغيير هذا إلى UnhandledExceptionMode.CatchException لتمكين التوجيه إلى معالجك Application.ThreadException, ، كما اقترح بشكل صحيح من قبل Jehof بالفعل.

ما هو نظام التشغيل (Windows XP ، Windows Vista ، إلخ) الذي يستخدمه المستخدم؟

إذا حاول Windows Vista تعطيل "ميزة تقارير المشكلات والحلول" (لوحة التحكم-> تقارير وحلول المشكلات-> تغيير الإعدادات-> الإعدادات المتقدمة-> إيقاف تشغيل برامجي ، الإبلاغ عن المشكلات)

أو محاولة ضبط 

  Application.SetUnhandledExceptionMode( UnhandledExceptionMode.CatchException );

سيؤدي هذا دائمًا إلى توجيه الاستثناءات إلى معالج ThreadException.

باختصار: هناك استثناء غير معقول في التطبيق.

إذا كان لديك إمكانية الوصول إلى الجهاز (من خلال الوصول عن بُعد ، وما إلى ذلك) ، فحاول تثبيت Visual Studio Express وبدء التطبيق. يجب أن تشاهد مربع حوار يوفر الفرصة لتصحيح التطبيق مع مثيل جديد من Visual Studio.

قد يكون هناك شيء يمنع نماذج النوافذ من التهيئة بشكل صحيح. لقد رأيت منشورات المنتدى التي تشير إلى أن مشكلات الخطوط يمكن أن تسبب ذلك - تأكد من تثبيت الخطوط التي يحتاجها التطبيق الذي يحتاجه إلى الافتراضات المعتادة مثل MS Sansserif و Arial و Tahoma والأوقات ومثل هذا.

وفشل ذلك ... حاول التضحية بالدجاج على الكمبيوتر. يعمل سحر في كل مرة!

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

ربما شيء من هذا القبيل هو السبب؟

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

الفكرة: سجل مراحل التسجيل

بدلاً من إجراء اختصار لك program.exe, قم بإجراء اختصار ل program.bat, ، والتي سوف

echo "Pre-start" > stage.txt
start program.exe

السطر الأول من Program.cs لذلك سيكون

File.WriteAllLines("stage.txt", "Program execution started.");

في معالج AppDomain.UnhandledException سيكون السطر الأول

File.WriteAllLines("stage.txt", "Unhandled exception has been caught.");

تأكد أيضًا من أن المعالج لا يخصص الذاكرة أو الموارد-تخصيصها مسبقًا على البرامج. المعالج فقط يؤدي الكتابة إلى السجل.

تعليقات

من المحتمل جدًا أن stage.txt (أرسله المستخدم) سيحتوي على "بدء التشغيل". يحدث هذا عندما يتم طرح استثناء في الطرف الثالث .DLL - حتى قبل بدء البرنامج.

في هذه الحالة ، ستحتاج إلى برنامج مدقق بسيط ، والذي لن يشير إلى التجميعات التي أنت program.exe لا ، ولكن سوف Assembly.Load(...) هم.

ملاحظة

stage.txt يجب وضعها في مكان ما تحت ٪ appdata ٪ ، وليس في ملفات البرنامج.

وجدت حالة مثيرة للاهتمام على الخادم 2003 و مناقشة لطيفة أخرى.

يجب أن تحصل على تتبع مكدس أكثر تفصيلاً عن طريق إرسال .pdb ملف لهذا الإصدار الخاص للمستخدم (ليتم وضعه بجوار .exe) وجعلهم يعيد إنتاج الحادث.

يجب أن تتعامل AppDomain.UnhandledException في الكود.

كان هناك سؤال مماثل طلبت. انظر تلك ذات الصلة أيضا.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top