لا ينقطع مصحح الأخطاء VS2008 عند الاستثناء غير المعالج

Question

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

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

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

فيما يلي الأسطر القليلة الأخيرة من علامة التبويب "الإخراج":

A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
The thread 0x60c has exited with code 0 (0x0).
The program '[3588] ALMSSecurityManager.vshost.exe: Managed' has exited with code -532459699 (0xe0434f4d).

لا أفهم سبب وضع علامة على الاستثناء باعتباره استثناء "الفرصة الأولى" عندما لا تتم معالجته.

أعتقد أن رمز الخروج 0xe0434f4d هو خطأ COM عام.

أيه أفكار؟

مترو.

Answer 1

إذا كنت تستخدم نظام تشغيل 64 بت، فهناك احتمال كبير أن تتعرض للعض من خلال سلوك على مستوى نظام التشغيل يؤدي إلى اختفاء الاستثناءات.الطريقة الأكثر موثوقية لإعادة إنتاجه هي إنشاء تطبيق WinForm جديد يقوم ببساطة بطرح استثناء في OnLoad؛سيبدو أنه لا يتم إلقاؤه.ألق نظرة على هذه:

1. لا ينفصل Visual Studio عن الاستثناءات غير المعالجة مع نظام التشغيل Windows 64 بت
   • http:// social.msdn.microsoft.com/Forums/en/vsdebug/thread/69a0b831-7782-4bd9-b910-25c85f18bceb
2. حالة اختفاء استثناء OnLoad
3. الاستثناءات الصامتة على أجهزة تطوير x64 (Microsoft Connect)
   • https://connect.microsoft.com/VisualStudio/feedback/details/357311/silent-exceptions-on-x64-development-machines

الأول هو ما وجدته من جوجل (بعد أن لم يساعد هذا الموضوع)، وقادني هذا الموضوع إلى الموضوعين التاليين.يحتوي الثاني على أفضل تفسير، والثالث هو خطأ/تذكرة Microsoft (التي تؤكد مرة أخرى أن هذا سلوك "حسب التصميم").

لذا، في الأساس، إذا قام تطبيقك بطرح استثناء يصل إلى حد وضع kernel في طريقه إلى أعلى المكدس، فسيتم حظره عند هذا الحد.وقرر فريق Windows أن أفضل طريقة للتعامل معها هي التظاهر بأنه تم التعامل مع الاستثناء؛يستمر التنفيذ كما لو أن كل شيء اكتمل بشكل طبيعي.

أوه، وهذا يحدث في كل مكان.التصحيح مقابل الإصدار غير ذي صلة..Net vs C++ غير ذي صلة.هذا هو السلوك على مستوى نظام التشغيل.

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

الحمقى.

Answer 2

عندما قرأت الإجابة عن وجود خانتي اختيار في مربع الحوار "استثناء..."، عدت وفتحت مربع الحوار مرة أخرى.لم يكن لدي سوى عمود واحد من خانات الاختيار - للفاصل عند "الرمي".

كما اتضح، إذا لم يكن لديك خيار "تمكين الكود الخاص بي فقط (مُدار فقط)" محددًا في خيارات التصحيح، فلن يظهر عمود "المستخدم غير المعالج" في مربع حوار "الاستثناءات".

لقد حددت خيار "تمكين الكود الخاص بي فقط" وتحققت من تحديد مربع الاختيار "غير معالج بواسطة المستخدم" في مربع الحوار "الاستثناءات" لجميع فئات الاستثناءات.

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

مترو.

Answer 3

Ctl-D, E يعرض نافذة الاستثناءات.يمكنك تعيين الاستثناءات التي تريدها والتي لا تريد كسرها.

Answer 4

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

Answer 5

مرة واحدة كل فترة يحدث هذا لي أيضًا.يبدو وكأنه خطأ أو شيء من هذا القبيل، كما هو الحال عندما أقوم بتكرار السيناريو، يتم اكتشاف الاستثناء ويظهر كالمعتاد.

Answer 6

لقد واجهت مشكلة مماثلة، وقام تحديد "تمكين الكود الخاص بي فقط (مُدار فقط)" بإصلاح المشكلة، بينما إذا قمت بإيقاف تشغيلها مرة أخرى، فقد عادت المشكلة، ولا يوجد دليل على السبب (ولكن من المحتمل أن بعض ملفات DLL التي يبدو أنها تحصل على تم تحميله عندما لا يتم تحديده مما يتسبب في حدوث السلوك).