KMDF driver for turning off the displays

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…

On Thu, Jul 12, 2018 at 11:31 AM, xxxxx@osr.com wrote:
>


>
> 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?
>

My point is to make you aware of a flaw in Microsoft’s logic, yes.
Cargo cult security is obnoxious and makes my life harder on the
daily.

So it was worth gating them behind a privilege - why? They’re
potentially insecure and even if a special permission is required in
practice I am able to debug every program in a user’s session once I
can run code in it. Basically every OS has this “problem” and it makes
irrelevant the vast majority of security concerns about X, Y, or Z
because fixing those does not fix the general lack of intrauser
permission separation.

It’s best to just remove them. Despite any purpose they might serve I
could exploit their existence.

>


>
> 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.
>

This will be my last post on the matter, sir. I apologize. As I am not
very smart I sometimes say things I should not.

I do not intend this to be one OS versus the other. It is more along
the lines of “this company sold a broken product and is attempting to
disclaim liability for it” with a touch of “this company is now being
hoist by their own petard.”

Cheers,
R0b0t1

@Tiago Castro

Question 1:
The commercial products you have seen - which Windows version are they running on?
Is it possible that you have seen them run on Windows 7 with an old XPDM display driver active?
This environment only supports AERO OFF glass transparency theme disabled.
According to the information above, the “D3 approach” might indeed work in such an environment.

Question 2:
The commercial products you have seen - if running on Windows 10 at all - are they maybe showing selected Windows content only instead of showing the whole desktop?

Question 3:
If none of the questions above can be answered with yes, then could you name these products?

Marcel Ruedinger

datronicsoft

@Marcel Ruedinger

Q1. Windows 10

Q2. Shows the whole desktop

Q3. Not sure if it’s allowed to share products as per forum rules but I can pm you if you like?