KMDF driver for turning off the displays

Hi All,

Doron Holan forwarded me to this forum to ask my question here. I hope you can help me with it.

I?m writing a KMDF driver in order to be able to turn off the displays properly from a user-mode application and I?d like you to ask you whether my method is correct or not. What I do is actually get the device interfaces with IoGetDeviceInterfaces for GUID_DEVINTERFACE_DISPLAY_ADAPTER, iterate over them, get the device object pointers to them with IoGetDeviceObjectPointer so that I can build an I/O control request with IoBuildDeviceIoControlRequest and send it to them. I know that IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE is deprecated, but I don?t know what IRP I should send.

Could you help me out with this?

Thank you in advance!

Regards,
Szil?rd

>to be able to turn off the displays properly

from a user-mode application

Can you explain further, please, what you specifically mean by “turn off the displays properly”?

You want to idle the displays in low power state?

You want to BLANK the display (set it all black) and later turn it back to the Windows desktop?

Can you please tell us more, so we can try to help you?

Peter
OSR
@OSRDrivers

>Can you please tell us more, so we can try to help you?

Also, I might add, it’s not simple to do this… and certainly not in a way that’ll make ANY application that might happen to be running on ANY display (in a multi-display system) happy. Ordinary GUI apps might work fine, but full-screen stuff or other weirdo graphics stuff, not so much.

Peter
OSR
@OSRDrivers

Hi Peter,

Thanks for your reply!

I would either like to put the displays in D3 power state or just blank
them. My goal is to be able to grab the desktop image of computer A and
send it over to computer B, meanwhile the user in front of computer A would
be facing a black screen.

Szilard

2018-07-10 23:21 GMT+02:00 xxxxx@osr.com :

> >Can you please tell us more, so we can try to help you?
>
> Also, I might add, it’s not simple to do this… and certainly not in a
> way that’ll make ANY application that might happen to be running on ANY
> display (in a multi-display system) happy. Ordinary GUI apps might work
> fine, but full-screen stuff or other weirdo graphics stuff, not so much.
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

On Jul 10, 2018, at 3:02 PM, xxxxx@gmail.com wrote:
>
> I would either like to put the displays in D3 power state or just blank them. My goal is to be able to grab the desktop image of computer A and send it over to computer B, meanwhile the user in front of computer A would be facing a black screen.

I’m reading between the lines here, but given your description, are you hoping to have computer A’s desktop continue to be fully operational, but grab the image periodically and send it to computer B while computer A shows a black screen? If so, that’s simply impossible. If you put the graphics card in computer A into D3, then it isn’t going to respond to any more drawing requests.

There are some pretty significant security considerations here. You can’t steal a user’s active display without his active permission.

You need to take a look at the mechanisms that the current products use. The VNC products copy the live desktop, which must therefore remain visible. The RDP products use a separate display driver drawing into a memory buffer, but they lock the workstation.

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

Hi Tim,

It’s not the graphics card I’d like to put into D3 but the monitors.

Regards,
Szilard

  1. júl. 11. dátummal, 8:42 időpontban xxxxx@probo.com írta:

    >> On Jul 10, 2018, at 3:02 PM, xxxxx@gmail.com wrote:
    >>
    >> I would either like to put the displays in D3 power state or just blank them. My goal is to be able to grab the desktop image of computer A and send it over to computer B, meanwhile the user in front of computer A would be facing a black screen.
    >
    > I’m reading between the lines here, but given your description, are you hoping to have computer A’s desktop continue to be fully operational, but grab the image periodically and send it to computer B while computer A shows a black screen? If so, that’s simply impossible. If you put the graphics card in computer A into D3, then it isn’t going to respond to any more drawing requests.
    >
    > There are some pretty significant security considerations here. You can’t steal a user’s active display without his active permission.
    >
    > You need to take a look at the mechanisms that the current products use. The VNC products copy the live desktop, which must therefore remain visible. The RDP products use a separate display driver drawing into a memory buffer, but they lock the workstation.
    > —
    > Tim Roberts, xxxxx@probo.com
    > Providenza & Boekelheide, Inc.
    >
    >
    > —
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: http:
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at http:
    >
    > To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

xxxxx@gmail.com wrote:

It’s not the graphics card I’d like to put into D3 but the monitors.

You can’t do that without the involvement of the graphics driver,
because the signals all get sent through the graphics card.


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

On Wed, Jul 11, 2018 at 3:21 PM, xxxxx@probo.com wrote:
> xxxxx@gmail.com wrote:
>>
>> It’s not the graphics card I’d like to put into D3 but the monitors.
>
> You can’t do that without the involvement of the graphics driver,
> because the signals all get sent through the graphics card.
>

On Linux at least the power state of a graphics device and the state
of the graphics device’s outputs are not linked. The wording of the
IOCTL could be interpreted to mean the same.
“IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE,” as in “set video device
output device power state.”

If this does do what OP wants it is unfortunate it is deprecated, or
if not, unfortunate that there seems to be no way to do as they want.

On Windows especially I have had problems keeping some applications
active while not drawing. It may be possible turning the screen off
generates similar issues. Despite the graphics card still rendering,
the OS might keep in mind that the main display is off and stop asking
applications to render.

Cheers,
R0b0t1

xxxxx@gmail.com wrote:

It’s not the graphics card I’d like to put into D3 but the monitors.

The last person who asked about this, in 2011, noted that LogMeIn does
the same function.  It does so by replacing the in-box monitor driver,
monitor.sys, with one of their own.

https://www.osronline.com/showthread.cfm?link=214666


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

If the monitors are in d3 the graphics card will stop using them as active
displays. As a simple experiment, push the power button on an active
display. You could put a black window in front of all the other windows on
each display. It is an awful hacky thing to do, but it seems to be waht you
want.

Mark Roddy

On Wed, Jul 11, 2018 at 4:02 AM xxxxx@gmail.com <
xxxxx@lists.osr.com> wrote:

Hi Tim,

It’s not the graphics card I’d like to put into D3 but the monitors.

Regards,
Szilard

  1. júl. 11. dátummal, 8:42 időpontban xxxxx@probo.com <
    xxxxx@lists.osr.com> írta:

On Jul 10, 2018, at 3:02 PM, xxxxx@gmail.com
> wrote:
>
>
> I would either like to put the displays in D3 power state or just blank
> them. My goal is to be able to grab the desktop image of computer A and
> send it over to computer B, meanwhile the user in front of computer A would
> be facing a black screen.
>
>
> I’m reading between the lines here, but given your description, are you
> hoping to have computer A’s desktop continue to be fully operational, but
> grab the image periodically and send it to computer B while computer A
> shows a black screen? If so, that’s simply impossible. If you put the
> graphics card in computer A into D3, then it isn’t going to respond to any
> more drawing requests.
>
> There are some pretty significant security considerations here. You can’t
> steal a user’s active display without his active permission.
>
> You need to take a look at the mechanisms that the current products use.
> The VNC products copy the live desktop, which must therefore remain
> visible. The RDP products use a separate display driver drawing into a
> memory buffer, but they lock the workstation.
> —
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

xxxxx@gmail.com wrote:

If the monitors are in d3 the graphics card will stop using them as
active displays. As a simple experiment, push the power button on an
active display. You could put a black window in front of all the other
windows on each display. It is an awful hacky thing to do, but it
seems to be waht you want.

Not if I understand his concept.  I believe he wants the desktop to be
updated and generated as usual, so he can grab a copy and send it to
another computer.  He just doesn’t want it to be visible at the
originating machine.

It’s slimy, and it’s a huge security hole.  Imagine if a hacker got a
hold of this.


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

On Wed, Jul 11, 2018 at 6:13 PM, xxxxx@probo.com wrote:
> xxxxx@gmail.com wrote:
>>
>> If the monitors are in d3 the graphics card will stop using them as
>> active displays. As a simple experiment, push the power button on an
>> active display. You could put a black window in front of all the other
>> windows on each display. It is an awful hacky thing to do, but it
>> seems to be waht you want.
>
> Not if I understand his concept. I believe he wants the desktop to be
> updated and generated as usual, so he can grab a copy and send it to
> another computer. He just doesn’t want it to be visible at the
> originating machine.
>
> It’s slimy, and it’s a huge security hole. Imagine if a hacker got a
> hold of this.
>

There’s a myriad valid reasons to do this, most of which we don’t even
know yet. Making it impossible because of “hackers” is pointless.

If you actually want to make any progress in this regard, try to get
API functions like CreateRemoteThread (start a thread in another
process?
) removed, and enforce process boundaries as strictly as user
boundaries are enforced.

I can just trivially debug any program you are running to scrape info
out of it. Should we get rid of debuggers?

Cheers,
R0b0t1

This discussion made me curious.
So we just tried this “D3 approach”.
We took the DXGI Desktop Duplication API Microsoft sample.
Removed the rendering part and redirected the duplicated content
(to another machine over the network).
Would it capture any screen updates during monitor D3?

The result:
Some Windows (drawn by GDI?) seem to be updating even while the monitor is off
(e.g. system clock application with second hand).
Some Windows (drawn by DirectX?) seem NOT to be updating while the monitor is off
(e.g. system clock display in task bar, video player, etc.).

Thus the long story can be cut very short:
In general, this “D3 approach” is useless.
In certain special cases, it might be applicable (if only the content of a specific subset of all Windows is needed).

PS: Of course the “blackout approach” is useless, too (as long as the covered content needs to be retrieved at the same time).

Marcel Ruedinger

datronicsoft

yeah it was entirely unclear what the actual intentions were. If the op
just wanted to black out the screens, that’s easy.

Mark Roddy

On Thu, Jul 12, 2018 at 5:41 AM xxxxx@datronic.de wrote:

> This discussion made me curious.
> So we just tried this “D3 approach”.
> We took the DXGI Desktop Duplication API Microsoft sample.
> Removed the rendering part and redirected the duplicated content
> (to another machine over the network).
> Would it capture any screen updates during monitor D3?
>
> The result:
> Some Windows (drawn by GDI?) seem to be updating even while the monitor is
> off
> (e.g. system clock application with second hand).
> Some Windows (drawn by DirectX?) seem NOT to be updating while the monitor
> is off
> (e.g. system clock display in task bar, video player, etc.).
>
> Thus the long story can be cut very short:
> In general, this “D3 approach” is useless.
> In certain special cases, it might be applicable (if only the content of a
> specific subset of all Windows is needed).
>
> PS: Of course the “blackout approach” is useless, too (as long as the
> covered content needs to be retrieved at the same time).
>
> Marcel Ruedinger
>
> datronicsoft
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

Hi All,

Thanks for dealing with my issue!

In fact it’s not putting the monitors into D3 that is necessary for me, blacking out the screens would perfectly suit my needs. The only problem with this is that if I put black full-screen windows on each display (GDI or DirectX), the Desktop Duplication API grabs them too, so the user at computer B is left with black screens as well. That’s the reason I chose to stick with the D3 power state and try to put the monitors into it.

Any suggestions are welcome!

Regards,
Szilard

  1. júl. 12. dátummal, 13:28 időpontban xxxxx@gmail.com írta:

    > yeah it was entirely unclear what the actual intentions were. If the op just wanted to black out the screens, that’s easy.
    >
    > Mark Roddy
    >
    >
    >> On Thu, Jul 12, 2018 at 5:41 AM xxxxx@datronic.de wrote:
    >> This discussion made me curious.
    >> So we just tried this “D3 approach”.
    >> We took the DXGI Desktop Duplication API Microsoft sample.
    >> Removed the rendering part and redirected the duplicated content
    >> (to another machine over the network).
    >> Would it capture any screen updates during monitor D3?
    >>
    >> The result:
    >> Some Windows (drawn by GDI?) seem to be updating even while the monitor is off
    >> (e.g. system clock application with second hand).
    >> Some Windows (drawn by DirectX?) seem NOT to be updating while the monitor is off
    >> (e.g. system clock display in task bar, video player, etc.).
    >>
    >> Thus the long story can be cut very short:
    >> In general, this “D3 approach” is useless.
    >> In certain special cases, it might be applicable (if only the content of a specific subset of all Windows is needed).
    >>
    >> PS: Of course the “blackout approach” is useless, too (as long as the covered content needs to be retrieved at the same time).
    >>
    >> Marcel Ruedinger
    >>
    >> datronicsoft
    >>
    >> —
    >> NTDEV is sponsored by OSR
    >>
    >> Visit the list online at: http:
    >>
    >> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    >> Details at http:
    >>
    >> To unsubscribe, visit the List Server section of OSR Online at http:
    > — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:>

In case you haven’t seen it, please refer to this venerable thread in which one of the (at the time) WDDM devs discusses this exact request from a dude at Citrix:

http:

There’s a lot in this that’s super interesting.

>There’s a myriad valid reasons to do this

Sure… but…

>it’s a huge security hole

This is exactly the point.

In short… what the OP wants to do is not supported by Windows by design and, to put a finer point on it, support for doing exactly what he wants (the IOCTL previously mentioned) was intentionally removed because it created a security problem.

Peter
OSR
@OSRDrivers</http:>

Super interesting and correct. Let me just emphasize one detail which might easily be overlooked:
The (at the time) WDDM dev discussed it from the point of view of the WDDM driver developer!
Thus it can clearly be seen that not even the WDDM display driver itself holds any screen content while the video output is powered down.

Indeed there is not much left to suggest to the OP.
Windows simply doesn’t support such a thing.
If this answer isn’t appreciated, then it could also be paraphrased in many other ways:

  • When screen content is destroyed (or blacked out), then it cannot be grabbed any more.
  • Desktop Duplication API is exactly doing what it says: Duplicate.
  • Etc.etc.etc.

Marcel Ruedinger

datronicsoft

On Thu, Jul 12, 2018 at 9:54 AM, xxxxx@osr.com wrote:
> In case you haven’t seen it, please refer to this venerable thread in which one of the (at the time) WDDM devs discusses this exact request from a dude at Citrix:
>
> http:
>
> There’s a lot in this that’s super interesting.
>

Thank you, I will read it as well because I am interested in the solution.

>>There’s a myriad valid reasons to do this
>
> Sure… but…
>
>>it’s a huge security hole
>
> This is exactly the point.
>

Alright, like I just pointed out, CreateRemoteThread and debuggers are
also huge security holes. Why allow them?

> In short… what the OP wants to do is not supported by Windows by design and, to put a finer point on it, support for doing exactly what he wants (the IOCTL previously mentioned) was intentionally removed because it created a security problem.
>

This is perhaps the strangest “security problem” I have read about.
How is it actually a problem?

It reminds me of all those CVEs that get filed for null pointer dereferences.

On Thu, Jul 12, 2018 at 10:34 AM, xxxxx@datronic.de wrote:
> Super interesting and correct. Let me just emphasize one detail which might easily be overlooked:
> The (at the time) WDDM dev discussed it from the point of view of the WDDM driver developer!
> Thus it can clearly be seen that not even the WDDM display driver itself holds any screen content while the video output is powered down.
>
> Indeed there is not much left to suggest to the OP.
> Windows simply doesn’t support such a thing.
> If this answer isn’t appreciated, then it could also be paraphrased in many other ways:
> - When screen content is destroyed (or blacked out), then it cannot be grabbed any more.
> - Desktop Duplication API is exactly doing what it says: Duplicate.
> - Etc.etc.etc.
>

So it looks like what I was concerned about in userspace is actually
done at the kernel level. If the display is inactive then no drawing
is done. So the solution, if any, would need to blackhole a fake
display output that simply doesn’t drive a real monitor.

To elaborate on why this is problematic - this is one of the things
that is keeping multisession logins and good remote management at bay.
There is some financial interest for Microsoft in this; per their
license, you should technically be buying a terminal services license
and associated client licenses. You would also be in violation of
their license if you, for example, installed a VNC program to get
around the lack of remote desktop in Home versions of Windows.

But no one cares. Portions of the Microsoft license have been struct
down. Microsoft is also working on supporting SSH and having huge
problems due to its own code design - to work as people would expect
the SSH daemon would need to log people in, but if they implement this
the right way per their own instructions then people are left with a
useless program they can’t use unless they spend multiple thousands of
dollars or hack the terminal services DLL.

Cheers,
R0b0t1</http:>

Are you being deliberately argumentative, or do you actually not understand that both the things you listed require SE_DEBUG_NAME privilege for a process that’s not your own?

Save your baseless and emotional anti-Windows rants, please, for a site where the management is sympathetic to your cause, shares your particular brand of religious zeal, and/or where other *nix fanboys congregate.

This particular forum would fall into none of those categories.

Peter
OSR
@OSRDrivers

As Tim suggested I also have seen commercial products do this through a custom monitor driver, so it is possible…