KMDF driver for turning off the displays

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?

I thought it is OK as long as it is no advertisement.
But agreed: Better to get in touch by private mail.
You’ll easily find my email contact data on our datronicsoft website.
Looking forward to inspect the product and see what it is really doing :slight_smile:

Marcel Ruedinger

datronicsoft

> I thought it is OK as long as it is no advertisement

It definitely IS OK… as long as it’s not some sort of commercial or advocacy for a product.

The idea isn’t to not mention the names of products. The idea IS to not having people try to sell or advertise products via this forum.

In any case, thank you very much for your consideration for the rules.

Carry on…

Peter
OSR
@OSRDrivers

Alright then, it’s TeamViewer.
It’s not enabled by default, you have to fiddle around the settings, and it’ll install a driver for you.

Once it’s enable you can connect and the monitor will be off (can’t remember if it actually turns off the display or if it just shows dark colour)

Isn’t TeamViewer just using “out of the box” standard Windows functionality RDP (Remote Desktop Protocol) to support this scenario?

Can’t exactly the same functionality be achieved with two plain Windows machines?
Run RDP client software on one machine (client).
Then connect the client to the other machine (server) via RDP.
Isn’t the Server machine console user locked out while RDP client is active?

This approach could possibly be a valid suggestion for the OP:

  • Just use or write a RDP client software.
  • Write a monitor driver (Power Policy Owner) which puts the server’s locked out console Window monitor to sleep while a RDP client is connected (no need to capture the locked out console monitor content anyway).

Marcel Ruedinger

datronicsoft

On 13/07/18 03:07 PM, xxxxx@datronic.de wrote:

Isn’t TeamViewer just using “out of the box” standard Windows functionality RDP (Remote Desktop Protocol) to support this scenario?

Can’t exactly the same functionality be achieved with two plain Windows machines?
Run RDP client software on one machine (client).
Then connect the client to the other machine (server) via RDP.
Isn’t the Server machine console user locked out while RDP client is active?

This approach could possibly be a valid suggestion for the OP:

  • Just use or write a RDP client software.
  • Write a monitor driver (Power Policy Owner) which puts the server’s locked out console Window monitor to sleep while a RDP client is connected (no need to capture the locked out console monitor content anyway).

In my experience, though RDP can connect to “Desktop” OSes (vs
“Server”), you’re then forced to deal with that protocol which probably
half defeats the purpose of the alternate remote desktop access
solution. (Even if you implement alternate framegrab you are at minimum
forced to keep the RDP connection alive with e.g. occasional frame acks,
to prevent the session from suspending).

A Remote Desktop Services Protocol Provider (RDSPP) can use a custom
protocol, but only works on Windows Server. MS uses the same
rdpcorets.dll RDSPP implementation for RDP on Desktop and Server OSes,
but it seems they whitelist themselves for desktop OS, nobody else is
allowed to load. (If somebody knows otherwise I’d be happy to find out how.)

-Nathan