Just Let It Flow

Every so often the topic of having multiple consoles for a single application comes up on various fora and the reaction is, in general, that you can’t. While this is correct from a technical/windows architecture standpoint, the illusion of multiple consoles can be realised in differing ways varying by degrees of work required.

We’ve covered how to grab a partial context for a kernel thread, and the construction of a driver, now it’s time to finally witness the fruits of our labour.

Last time, we discovered how Process Explorer gets a partial context for the kernel portions of a thread and wrote our own function that mimics it. By itself though, our code is useless; we need the rest of the driver in order to be able to use it, and that’s what we’ll be covering in this article.

If you’ve used Process Explorer chances are you’ve checked out a thread stack or two. If you’ve ever tried to implement something similar yourself, the combo of SuspendThread, GetThreadContext, ResumeThread, and StackWalk64 have more than likely done a sterling job getting a user mode trace. But what about further up the stack, or those threads locked in kernel mode?