Driver for taking a screenshot

Hello all.

I’m newbie in driver development and I’m looking for a way to take screenshot using driver. Is it actually possible? And what kind of driver should it be: a WDDM driver (miniport driver, user-mode driver, or both) or some other?
Any information or example would be helpful and very much appreciated.

(In prospect I’d like to develop driver for taking a screenshot and some application, that process screenshot from this driver. And yes, I know there are easier ways of taking a screenshot)

Thanks, Maksim

xxxxx@mail.ru wrote:

I’m newbie in driver development and I’m looking for a way to take screenshot using driver. Is it actually possible? And what kind of driver should it be: a WDDM driver (miniport driver, user-mode driver, or both) or some other?
Any information or example would be helpful and very much appreciated.

No. This is absolutely the wrong way to do this. The desktop and the
visible screen are user-mode concepts, not kernel concepts.

(In prospect I’d like to develop driver for taking a screenshot and some application, that process screenshot from this driver. And yes, I know there are easier ways of taking a screenshot)

If you know there are easier ways, the what’s the point of asking? What
do you think you would gain by doing it in the kernel? You can do a
single BitBlt to fetch a copy of the current desktop. It’s hard to
think of anything easier.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> No. This is absolutely the wrong way to do this. The desktop and the visible screen are user-mode concepts, not kernel concepts.
Yes, I understand. But still, is there a way to copy video memory (like in DOS) or map it to user space memory or something like this?

If you know there are easier ways, the what’s the point of asking? What do you think you would gain by doing it in the kernel? You can do a single BitBlt to fetch a copy of the current desktop. It’s hard to think of anything easier.
This is for my course project and it’s a great opportunity to learn something about drivers and kernel-mode, I think.

xxxxx@mail.ru wrote:

> No. This is absolutely the wrong way to do this. The desktop and the visible screen are user-mode concepts, not kernel concepts.
Yes, I understand. But still, is there a way to copy video memory (like in DOS) or map it to user space memory or something like this?

No. In the DOS era, the location of the EGA/VGA frame buffers was
well-known and fixed in memory. In today’s world, the frame buffer
memory is a resource that belongs to the display driver. You don’t know
where it is located, nor when it might be safe to access it, nor what
format it is in.

You can use DirectDraw from an application to get a user-mode address
for the primary surface. You can use the new Desktop Duplication API to
get a snapshot of the current desktop. Or, as I said, you can BitBlt to
a memory bitmap. All from user mode.

This is for my course project and it’s a great opportunity to learn something about drivers and kernel-mode, I think.

Not really. Graphics is the wrong choice for learning about kernel mode.

There are a billion USB experimenter’s kits out there that would make an
excellent basis for something like this. You can get a Teensy board
with 32 digital I/O lines and go crazy inventing real-world things to
control and respond to.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.