استدعاء الشاشة الزرقاء للموت باستخدام التعليمات البرمجية المدارة

Question

فقط فضولي هنا: هل من الممكن استدعاء شاشة Windows Blue للموت باستخدام رمز مُدار .NET ضمن نظام التشغيل Windows XP/Vista؟ وإذا كان ذلك ممكنًا ، فما الذي يمكن أن يكون رمز المثال؟

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

Answer 1

ربما يكون شيء لوحة المفاتيح خيارًا جيدًا ، ولكن إذا كنت بحاجة إلى القيام بذلك عن طريق الكود ، تابع القراءة ...

أنت لا تحتاج حقًا إلى أي شيء إلى Barf ، في حد ذاته ، كل ما عليك فعله هو العثور على وظيفة kebugcheck (ex) واستدعاء ذلك.

http://msdn.microsoft.com/en-us/library/ms801640.aspx http://msdn.microsoft.com/en-us/library/ms801645.aspx

بالنسبة للحوادث التي تم البدء بها يدويًا ، تريد استخدام 0xe2 (يدويًا _initied_crash) أو 0xDeadDead (يدويًا _initied_crash1) كرمز فحص الأخطاء. وهي مخصصة بشكل صريح لهذا الاستخدام.

ومع ذلك ، قد يكون العثور على الوظيفة أمرًا صعبًا بعض الشيء. قد يساعد Windows DDK (تحقق من NTDDK.H) - لا أتوفر في الوقت الحالي ، ولا يمكنني العثور على معلومات حاسمة في الوقت الحالي - أنا الآن - أنا فكر في إنه في ntoskrnl.exe أو ntkrnlpa.exe ، لكنني لست متأكدًا ، وليس لدي حاليًا الأدوات اللازمة للتحقق منها.

قد تجد أنه من الأسهل فقط كتابة تطبيق C ++ بسيط أو شيء يدعو الوظيفة ، ثم تشغيل ذلك.

مانع لك ، أنا على افتراض أن Windows لا يمنعك من الوصول إلى الوظيفة من مساحة المستخدم (قد يكون لدى .NET بعض الأحكام الخاصة). لم أختبرها بنفسي.

Answer 2

لا أعرف ما إذا كان الأمر يعمل حقًا ، وأنا متأكد من أنك بحاجة إلى حقوق المسؤول ، ولكن يمكنك تعيين مفتاح تسجيل CrashOnCtrlsCroll ثم استخدام SendKeys لإرسال قفل Ctrl+Scroll Scroll.

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

http://support.microsoft.com/kb/244139

hkey_local_machine system currentControlset services i8042prt parameters
الاسم: CrashonCtrlsCroll
نوع البيانات: reg_dword
القيمة: 1
إعادة بدء

Answer 3

أود أن أقول لا. يجب عليك P/استدعاء وتفاعل سائق أو رمز آخر يعيش في مساحة kernel. . NET Code Lives Exted of هذا المجال ، على الرغم من وجود بعض الحديث عن برامج التشغيل المدارة في الإصدارات المستقبلية من Windows. فقط انتظر بضع سنوات أخرى ويمكنك أن تصطدم تمامًا مثل أصدقائنا غير المُدارين.

Answer 4

بقدر ما أعرف أن BSOD حقيقي يتطلب الفشل في رمز وضع kernel. لا يزال Vista لديه BSOD ولكنه أقل تواتراً لأن طراز السائق الجديد يحتوي على برامج تشغيل أقل في وضع kernel. أي فشل في وضع المستخدم سيؤدي فقط إلى قتل تطبيقك.

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

ولكن من بين الآلاف من المستخدمين ، ربما يكون هناك شخص قام بذلك :-)

Answer 5

يمكنك استخدام أداة OSR Online التي تؤدي إلى تعطل kernel. لم أجربها بنفسي أبدًا ، لكنني أتخيل أنه يمكنك تشغيله عبر فئة عملية .NET القياسية:

http://www.osronline.com/article.cfm؟article=153

Answer 6

تمكنت ذات مرة من إنشاء BSOD على Windows XP باستخدام System.net.sockets في .NET 1.1 بشكل غير مسؤول. كان بإمكاني تكرار ذلك بانتظام إلى حد ما ، لكن لسوء الحظ كان ذلك قبل عامين ولا أتذكر بالضبط كيف أثارت ذلك ، أو الحصول على الكود المصدري بعد الآن.

Answer 7

جرب FideoInput Live باستخدام DirectShow في DirectX8 أو DirectX9 ، ومعظم المكالمات تنتقل إلى برامج تشغيل الفيديو في وضع kernel. لقد استسلمت في الكثير من الشاشات الزرقاء عند تشغيل إجراء رد اتصال من مصدر التقاط الفيديو المباشر ، الجسيم إذا استغرق رد الاتصال الخاص بك وقتًا طويلاً ، يمكن أن يوقف برنامج Kernel بالكامل.

Answer 8

من الممكن أن يتسبب الكود المدارة في حدوث Bugcheck عندما يكون لديه إمكانية الوصول إلى برامج تشغيل kernel الخاطئة. ومع ذلك ، سيكون برنامج تشغيل kernel هو الذي يتسبب مباشرة في BSOD (على سبيل المثال ، BSODS Directshow من UFFE ، و BSODs Terence Lewis ، أو BSODs التي شوهدت عند استخدام BitTorrent مع محولات شبكة معينة).

قد يتسبب الوصول المباشر في وضع المستخدم إلى الموارد المنخفضة المتميزة Device\PhysicalMemory, ، إذا لم يفسد القرص الثابت أولاً ؛ لا يسمح Vista بوصول وضع المستخدم إلى الذاكرة الفعلية).

إذا كنت تريد فقط ملف تفريغ ، فإن اقتراح Mendelt لاستخدام Windbg هو فكرة أفضل بكثير من استغلال خطأ في برنامج تشغيل kernel. لسوء الحظ، ال .dump لا يتم دعم الأمر لتصحيح أخطاء kernel المحلي ، لذلك ستحتاج إلى جهاز كمبيوتر ثانٍ متصل عبر المسلسل أو 1394 ، أو VM متصل عبر منفذ تسلسلي افتراضي. LiveKd قد يكون خيارًا واحدًا ، إذا لم تكن بحاجة إلى حالة تفريغ الذاكرة لتكون متسقة تمامًا.

Answer 9

هذا لا يحتاج إلى أي برامج تشغيل وضع نواة ، فقط sedebugprivilege. يمكنك ضبط العملية الحرجة NtSetInformationProcess, ، أو RtlSetProcessIsCritical وقتل عمليتك فقط. سترى نفس رمز Bugcheck حيث تقتل CSRSs.exe ، لأنك وضعت نفس العلم "الحرجة" في عمليتك.

Answer 10

لسوء الحظ ، أعرف كيفية القيام بذلك كخدمة .NET على الخادم الخاص بنا كانت تسبب شاشة زرقاء. (ملاحظة: Windows Server 2008 R2 ، وليس XP/Vista).

بالكاد أستطيع أن أصدق أن برنامج .NET كان الجاني ، لكنه كان كذلك. علاوة على ذلك ، لقد قمت بتكرار BSOD في جهاز افتراضي.

الرمز المخالف ، يسبب 0x00000F4:

string name = string.Empty; // This is the cause of the problem, should check for IsNullOrWhiteSpace

foreach (Process process in Process.GetProcesses().Where(p => p.ProcessName.StartsWith(name, StringComparison.OrdinalIgnoreCase)))
{
    Check.Logging.Write("FindAndKillProcess THIS SHOULD BLUE SCREEN " + process.ProcessName);
    process.Kill();
    r = true;
}

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

تحرير: القتل CSRSS.Exe يبدو أن سبب الشاشة الزرقاء. وفقًا للتعليقات ، من المحتمل أن يحدث هذا في رمز النواة.