windows vista - quitar - Invoque la pantalla azul de la muerte usando un código administrado

pantalla azul windows 7 solucion definitiva

Question

Solo curiosidad aquí: ¿es posible invocar una pantalla azul de la Muerte de Windows usando el código administrado .net en Windows XP / Vista? Y si es posible, ¿cuál podría ser el código de ejemplo?

Solo para que conste, no es para ningún propósito malicioso, solo me pregunto qué tipo de código tomaría realmente matar el sistema operativo como se especifica.

Answer 1

Es posible que el código administrado provoque una comprobación de errores cuando tiene acceso a controladores de kernel defectuosos. Sin embargo, sería el controlador del kernel el que causa directamente el BSOD (por ejemplo, los BSOD DirectShow de uffe, los BSOD del socket de Terence Lewis o los BSOD cuando se usa BitTorrent con ciertos adaptadores de red).

El acceso directo en modo de usuario a recursos de bajo nivel con privilegios puede provocar una comprobación de errores (por ejemplo, garabatear en Device/PhysicalMemory , si no daña primero su disco duro; Vista no permite el acceso en modo usuario a la memoria física).

Si solo quiere un archivo de volcado, la sugerencia de Mendelt de usar WinDbg es una idea mucho mejor que explotar un error en un controlador de kernel. Desafortunadamente, el comando .dump no es compatible con la depuración local del núcleo, por lo que necesitaría una segunda PC conectada a través de una serie o 1394, o una VM conectada a través de un puerto serie virtual. LiveKd puede ser una opción de una sola PC, si no necesita que el estado del volcado de memoria sea completamente consistente.

Answer 2

Lo del teclado es probablemente una buena opción, pero si necesita hacerlo por código, continúe leyendo ...

Realmente no necesita nada para barf, per se, todo lo que necesita hacer es encontrar la función KeBugCheck (Ex) e invocar eso.

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

Para bloqueos iniciados manualmente, desea utilizar 0xE2 (MANUALLY_INITIATED_CRASH) o 0xDEADDEAD (MANUALLY_INITIATED_CRASH1) como el código de comprobación de errores. Están reservados explícitamente para ese uso.

Sin embargo, encontrar la función puede ser un poco complicado. El DDK de Windows puede ser útil (ver Ntddk.h) - No lo tengo disponible en este momento, y parece que no puedo encontrar información decisiva en este momento - Creo que está en ntoskrnl.exe o ntkrnlpa.exe, pero No estoy seguro, y actualmente no tengo las herramientas para verificarlo.

Puede que le resulte más fácil simplemente escribir una aplicación simple de C ++ o algo que llame a la función, y luego simplemente ejecutar eso.

Eso sí, supongo que Windows no le impide acceder a la función desde el espacio de usuario (.NET podría tener algunas disposiciones especiales). No lo he probado yo mismo.

Answer 3

No sé si realmente funciona y estoy seguro de que necesita derechos de administrador, pero podría establecer la clave de registro CrashOnCtrlScroll y luego usar SendKeys para enviar CTRL + Bloq Despl + Bloq Despl.

Pero creo que esto TIENE que provenir del Keyboard Driver, así que supongo que un simple SendKeys no es lo suficientemente bueno y tendrías que engancharlo de algún modo al Keyboard Driver (suena realmente desordenado) o comprobar que CrashDump tiene una API que puede ser llamado con P / Invoke.

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

HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Services / i8042prt / Parameters
Nombre: CrashOnCtrlScroll
Tipo de datos: REG_DWORD
Valor: 1
Reiniciar

Answer 4

Por lo que sé, un BSOD real requiere falla en el código del modo kernel. Vista todavía tiene BSOD pero son menos frecuentes porque el nuevo modelo de controlador tiene menos controladores en modo kernel. Cualquier falla en el modo de usuario provocará la muerte de su aplicación.

No puede ejecutar el código administrado en modo kernel. Entonces, si quieres BSOD, necesitas usar PInvoke. Pero incluso esto es bastante difícil. Necesitas hacer PInvokes realmente elegantes para obtener algo en modo kernel para barf.

Pero entre los miles de usuarios de SO probablemente haya alguien que haya hecho esto :-)

Answer 5

Pruebe la entrada de video en vivo usando directshow en directx8 o directx9, la mayoría de las llamadas van a los controladores de video en modo kernel. Tuve éxito en muchas pantallas azules cuando ejecutaba un procedimiento de devolución de llamada desde una fuente de captura de video en vivo, particularmente si su devolución de llamada tarda mucho tiempo, puede detener todo el controlador Kernel.

Answer 6

Tendría que decir que no. Tendría que p / invocar e interactuar con un controlador u otro código que vive en el espacio del kernel. El código .NET vive lejos de esta área, aunque se ha hablado de controladores administrados en futuras versiones de Windows. Solo espere unos años más y podrá marcharse como nuestros amigos no administrados.

Answer 7

Una vez logré generar un BSOD en Windows XP usando System.Net.Sockets en .NET 1.1 de manera irresponsable. Podría repetirlo con bastante regularidad, pero desafortunadamente eso fue hace un par de años y no recuerdo exactamente cómo lo activé, o ya no tengo el código fuente.

Answer 8

Puede usar la herramienta de OSR Online que desencadena un bloqueo del kernel. Nunca lo intenté, pero me imagino que podría ejecutarlo a través de la clase de proceso .net estándar:

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

Answer 9

Este no necesita ningún controlador en modo kernel, solo un SeDebugPrivilege. Puede establecer su proceso crítico mediante NtSetInformationProcess o RtlSetProcessIsCritical y simplemente RtlSetProcessIsCritical su proceso. Verá el mismo código de comprobación de errores cuando mate csrss.exe, porque establece el mismo indicador "crítico" en su proceso.

Answer 10

Desafortunadamente, sé cómo hacer esto ya que un servicio .NET en nuestro servidor estaba causando una pantalla azul. (Nota: Windows Server 2008 R2, no XP / Vista).

Apenas podía creer que un programa .NET fuera el culpable, pero lo era. Además, acabo de replicar el BSOD en una máquina virtual.

El código ofensivo causa un 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;
}

Si alguien se pregunta por qué me gustaría replicar la pantalla azul, no es nada malicioso. Modifiqué nuestra clase de registro para tomar un argumento diciéndole que escriba directamente en el disco ya que las acciones anteriores al BSOD no aparecían en el registro a pesar de que se llamaba a .Flush (). Repetí el bloqueo del servidor para probar el cambio de registro. El VM se estrelló debidamente pero la sesión funcionó.

EDITAR: Killing csrss.exe parece ser lo que causa la pantalla azul. Según los comentarios, es probable que esto suceda en el código del kernel.