[munin]

the bluescreen is because, well, "CRITICAL_OBJECT_TERMINATION". in Windows, some processes, if they terminate, cause the entire operating system to stop with a bugcheck. think of it like init dying in linux.

there sadly is no 'stack backtrace'. it looks like he's managed to send some message to csrss.exe that caused it to crash with an invalid memory operation.

this is bad, it might even be exploitable. even though the exploit would be in csrss, which is not kernel mode, it's still extremely important and trusted. also, untrusted low-user code could make this call to privilege escalate.

it's worth noting that thought the author states " I stumbled accross the bug inadvertently while working on something totally unrelated to security, and decided to publish my findings so that this can be fixed by Microsoft.", microsoft actually has a security team that can be found here: http://technet.microsoft.com/en-us/security/ff852094.aspx (google for "microsoft report security bug")

the bugs you report to them remain confidential until they are fixed. this way, potentially bad exploit code isn't floating around the internet for some indeterminate amount of time. like this!

[yuhong]

You usually can get a backtrace using the right commands in WinDbg after opening the crash dump.

[munin]

indeed!

a trouble here is that the original fault is in user-mode csrss. you cannot use a user-mode debugger to debug csrss, so, to debug it you must use a kernel debugger. the process is involved. it is documented by microsoft though...

another trouble is that it seems that, at least on my systems, the ability to create a full dump of memory from the faulting process has been removed in w7. all you can do now is dump kernel mode memory, which would not include the needed information...