I wonder whether from .Net managed code, or maybe p/invoking the needed NT dll, if I could generate a BSOD (Blue Screen Of Death) with specific bugcheck-code reason.
I know this is possible from a kernel-mode driver by calling KeBugCheck or KeBugCheckEx methods, but I think there is no way to call those methods from user-mode applications.
Someone could clarify me things, and bring an alternative way (if exists) for managed code?.
I can't say for certain that the kernel does not provide some means of invoking KeBugCheck with arbitrary arguments from user mode, even if just for highly privileged processes, but I very much hope none does and I certainly sympathise with anyone who wonders why on earth you would want something like this to exist let alone to use it.
Of course, even if the kernel doesn't already expose it for calling from user mode, it is readily available in kernel mode, i.e., to be called by drivers. Even there, however, drivers are strongly discouraged from resorting to it in any code that's ever released. Though a driver could expose a user-mode interface, e.g., through Device I/O Control, for calling KeBugCheck on behalf of a user-mode client, even an unprivileged one, doing so would be incredibly irresponsible of a driver writer (except, perhaps, for private testing).
As for CSRSS, some of you may want to know as background (and perhaps know already) that the architecture has long allowed that CSRSS needn't be critical (in the sense that killing it kills Windows) and also that it needn't be the only one. There is an undocumented function RtlSetProcessIsCritical which programs such as CSRSS call to register themselves as being so vital that when the kernel sees them exit then the kernel should raise either of two particular bug checks.
You can kill the csrss process, pretty simple:
Even if that requires administrator rights