run DirectX 9 as a service/headless?
David
my own lighting by assigning colors to vertices, etc.). I also know of a way
to save the rendered scene to a jpeg file on disk.
Now, I would like to run this software on Windows Server 2003 where it would
basically run as a service. I.e. Microsoft IIS will indirectly send a
message to it requesting it to dynamically render an image and save it to
disk where that image could then be displayed by a standard html web page.
The obvious problem is that the directx service/process is not running on a
particular user's desktop (it is invoked by the system/IIS with no monitor
plugged in or user logged on) and hence calls to CreateDevice, etc. all will
fail. Even if all of the graphics hardware is present, it seems that DirectX
will not allow a device to be created unless there is an actual desktop to
map it to.
What is the work-around for this? Can I programatically create an internal
desktop on Windows Server 2003 so that directx can create a device (and use
the DirectX9 graphics card that is installed)? It would seem like this
should be a common problem with more and more people developing for the web
(and for web servers). Am I missing something? All I really want to do is
be able to use the graphics hardware on my server to dynamically generate
images/html for a website.
Any suggestions/work-arounds would be greatly appreciated. Thanks.
WenJun Zhang[msft]
The problem should be that the service do not have interactive with desktop
right by default and D3D needs an interactive desktop to allow hardware
acceleration.
Please go to the service console, double-click the service to open its
property window. In Log On tab, you can select 'Allow service to interact
with desktop' option and then test if the DX GUI application starts to work
with the interactive desktop. If this doesn't work in your scenario, you
will need to re-write the DX service application and make it be interactive
with the desktop first. Please refer to the following articles:
Interactive Services
http://msdn2.microsoft.com/en-us/library/ms683502.aspx
Window Stations
http://msdn2.microsoft.com/en-us/library/ms687096.aspx
Desktops
http://msdn2.microsoft.com/en-us/library/ms682573.aspx
However please pay attention that enabling interactive desktops for a
service requires the service to have particular priveleges that one likely
doesn't want to include for most services. The following article describes
some security considerations:
Security, services and the interactive desktop in Windows
http://support.microsoft.com/kb/327618/
Hope the information will be of help. If any problem persists, please
update here to let me know. I'm glad to help further on it.
Have a great week.
Sincerely,
WenJun Zhang
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
David
code as a simple executable (invoked by ISAPI dlls from IIS). As soon as we
enabled the IIS service to "interact with desktop" everything started to
work (at least on our XP development system). Hopefully this should work on
our server too (even though nobody will ever be logged on there). Thanks for
your help.
Best regards,
David
Richard [Microsoft Direct3D MVP]
=?Utf-8?B?RGF2aWQ=?= <Davi...@newsgroup.nospam> spake the secret code
<61D1B8BA-06FD-487E...@microsoft.com> thusly:
>Thanks. We came to the same conclusion here late last night. We wrote the
>code as a simple executable (invoked by ISAPI dlls from IIS). As soon as we
>enabled the IIS service to "interact with desktop" everything started to
>work (at least on our XP development system). Hopefully this should work on
>our server too (even though nobody will ever be logged on there). Thanks for
>your help.
It won't work if noone is logged in and you just compromised the
security of your server. Please don't do this. See my other
response for an alternative.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Richard [Microsoft Direct3D MVP]
wjz...@online.microsoft.com ("WenJun Zhang[msft]") spake the secret code
<QIcHOx4Q...@TK2MSFTNGHUB02.phx.gbl> thusly:
>The problem should be that the service do not have interactive with desktop
>right by default and D3D needs an interactive desktop to allow hardware
>acceleration.
Oh boy is this ever the wrong advice!
You just told him, in effect, "please open a gigantic security hole on
my Windows Server 2003 machine". Yes, you pointed him to articles
that talk about the security problem, but your advice is essentially
one of "open a gigantic security hole and cross your fingers" instead
of suggesting a secure way to accomplish this task.
Please don't do this.
Instead, use IPC (inter-process communication via shared memory, named
pipes, COM, sockets, etc.) to have your service talk to an application
that runs on the interactive desktop. Put the desktop application in the
user's startup program group so that it runs when the user logs in.
Your service doesn't even need to run as SYSTEM (and it shouldn't) in
order to accomplish this.
And people wonder why Windows applications have such horrible
behaviors with respect to security.... Its not the fault of Windows,
its people who write poor code with respect to security in the first
place.
WenJun Zhang[msft]
Please take a look and think over Richard's follow up. I agree with him
that enabling interactive desktop privilege isn't a recommended solution on
security. Especially you are developing a server application which
receives/serves web requests from the network, this shouldn't be a good
enough implement.. Using CreateProcessAsUser API to launch the DX process
and utilizing IPC should be a better approach.
Thanks.
Clint Eastwood
> It won't work if noone is logged in and you just compromised the
> security of your server. Please don't do this. See my other
> response for an alternative.
If you are suggesting it is not possible to use DirectX/GPU services
when noone is logged in, this is incorrect. I have done this myself.
Of course, one might be concerned about security issues. However, I
can think of scenarios where the need for such a feature would
outweigh other security concerns. It may be unacceptable that someone
has to be logged in for the system to work. As long as the system
designer (in generic sense here) and users of the system are
completely aware of any potential security risks, then let people take
whatever risks they're prepared to take.
I highly recommend reading this book -- from it you can infer
everything you need to know about making the above scenario work:
"Programming Windows Security" by Keith Brown
Richard [Microsoft Direct3D MVP]
"Clint Eastwood" <matt....@barco.com> spake the secret code
<1170176288....@p10g2000cwp.googlegroups.com> thusly:
>Richard,
>
>> It won't work if noone is logged in and you just compromised the
>> security of your server. Please don't do this. See my other
>> response for an alternative.
>
>If you are suggesting it is not possible to use DirectX/GPU services
>when noone is logged in, this is incorrect.
It won't display on the screen unless someone is logged in. If you
don't care that your renderings won't be visible, then yeah, that's
fine.
The login process displays its own window station, so the interactive
user's programs can't access the display (and more importantly the
keyboard and mouse0 when the login box is up. This is a security
protection, and an important one.
>Of course, one might be concerned about security issues. However, I
>can think of scenarios where the need for such a feature would
>outweigh other security concerns.
That's the same thing that every person who ever coded a security hole
thought -- at least at the beginning.
Please don't code security holes when there are alternatives!
Chuck Walbourn [MSFT]
operation if you want HAL access. NULLREF should work in many situations,
and with Windows Vista and WDDM it should work more than it does with
Windows XP. Creating a HAL device will fail when the protected desktop is
active or from a service.
--
Chuck Walbourn
SDE, Game Technology Group
T
> Creating a HAL device will fail when the protected desktop is active or
> from a service.
Consequently, if you are in the middle of initializing a display and some
external UAC prompt gets displayed (and it doesn't have to come from your
application), the initialization will fail (possibly midstream). FWIW, I
have been able to duplicate this using Microsoft's 3D Virtual World as well
as every other Aero compatible 3D application I can find. Not only that but
existing devices seem to get invalidated as well and need to be reset (which
BTW fails, requiring everything to be rebuilt from scratch). Is the
presentation of the UAC prompt supposed to be able to do that? I thought
Vista was suppose to eliminate the need to worry about devices needing to be
reset except for a system hang or a stopped driver -- neither of which
appears to be happening.
Tim
Dr Pizza
> Consequently, if you are in the middle of initializing a display and
> some external UAC prompt gets displayed (and it doesn't have to come
> from your application), the initialization will fail (possibly
> midstream). FWIW, I have been able to duplicate this using
> Microsoft's 3D Virtual World as well as every other Aero compatible
> 3D application I can find. Not only that but existing devices seem to
> get invalidated as well and need to be reset (which BTW fails,
> requiring everything to be rebuilt from scratch). Is the presentation
> of the UAC prompt supposed to be able to do that? I thought Vista was
> suppose to eliminate the need to worry about devices needing to be
> reset except for a system hang or a stopped driver -- neither of
> which appears to be happening.
Only if you use D3D9Ex (or D3D10, I suppose). If you stick with D3D9,
you'll still suffer the same device loss frustrations.
--
T
displaying the protected desktop - that just flys in the face of protecting
the user from rogue applications (e.g., the mere act of checking for
priviledges can cause your application to get reset -- let's just hope you
can recover properly and aren't relying on resources to manage live data).
Aero is backing everything with offscreen surfaces anyway so why should D3D9
windows be affected any differently?
"Dr Pizza" <DrP...@quiscalusmexicanus.org> wrote in message
news:xn0f1vj3...@msnews.microsoft.com...
Dr Pizza
> That may be true, but UAC should not be able to reset devices simply
> by displaying the protected desktop
"UAC" doesn't reset devices. "Switching to a different desktop" resets
devices. Always has.
> - that just flys in the face of
> protecting the user from rogue applications (e.g., the mere act of
> checking for priviledges can cause your application to get reset --
> let's just hope you can recover properly and aren't relying on
> resources to manage live data).
Sure; just like pressing ctrl-alt-del or win+l or having someone log in
remotely or starting a full-screen D3D app. UAC is just another thing
to not do when you don't want the device to be reset.
> Aero is backing everything with
> offscreen surfaces anyway so why should D3D9 windows be affected any
> differently?
DWM is backing them with D3D9Ex surfaces. D3D9 is mostly separate.
--
Chris Hill
<chu...@online.microsoft.com> wrote:
>Officially speaking, there's no support in Direct3D 9 for true 'headless'
>operation if you want HAL access. NULLREF should work in many situations,
>and with Windows Vista and WDDM it should work more than it does with
>Windows XP. Creating a HAL device will fail when the protected desktop is
>active or from a service.
Besides any potential implementation burden for MS, is there any
fundamental reason that creating a HAL device couldn't or shouldn't be
supported from a noninteractive service desktop?
Chris
T
>T wrote:
>
>> That may be true, but UAC should not be able to reset devices simply
>> by displaying the protected desktop
> "UAC" doesn't reset devices. "Switching to a different desktop" resets
> devices. Always has.
Not to mince words, but UAC does in fact reset devices BECAUSE it switches
to a different desktop. It's like saying, "I didn't kill him -- the bullet
did". Just because the reset is caused by switching to different desktop and
not by UAC explicitly does not grant immunity to UAC. While the secure
desktop switch can be disabled, we are strongly advised by Microsoft to NOT
turn this off. It the whole "cake and eat it" thing all over again.
>
>> - that just flys in the face of
>> protecting the user from rogue applications (e.g., the mere act of
>> checking for priviledges can cause your application to get reset --
>> let's just hope you can recover properly and aren't relying on
>> resources to manage live data).
> Sure; just like pressing ctrl-alt-del or win+l or having someone log in
> remotely or starting a full-screen D3D app. UAC is just another thing
> to not do when you don't want the device to be reset.
Switching to a different desktop (ctrl+alt+del, win+l, etc.) are all manual
processes that are not really "normal" workflows relative to multitasking
between several active applications. UAC on the other hand can happen during
normal interaction with the desktop UI (e.g., running an application the
requires access to priviledged resources, manipulating file permissions and
ownerships, activating an addin that requires elevated priviledges, etc.).
It was Microsoft's decision to switch to a different desktop when
implementing the secure UAC prompt - not mine - buy my application is paying
a huge penalty. Given that it can take a significant amount of time to
initialize devices, buffers, textures, VBO's, etc., triggering UAC by
whatever means becomes an expensive and destructive action. I can only hope
the load process is not what's causing the UAC to get triggered because I
would never get my data loaded.
>
>> Aero is backing everything with
>> offscreen surfaces anyway so why should D3D9 windows be affected any
>> differently?
> DWM is backing them with D3D9Ex surfaces. D3D9 is mostly separate.
It makes no sense that D3D9 on Vista was not wholly implemented within the
D3D9Ex framework. It would have been trivial to retain support for legacy
interfaces and still provide D3D9Ex virtualization.
Richard [Microsoft Direct3D MVP]
"T" <som...@mydomain.com> spake the secret code
<uCMp8lh...@TK2MSFTNGP05.phx.gbl> thusly:
>Not to mince words, but UAC does in fact reset devices BECAUSE it switches
>to a different desktop.
So? I don't understand what it is you're complaining about -- its not
like this is the *only* reason you have to deal with lost devices.
Lost devices have been part of Direct3D since the beginning and you've
always had to deal with it.
>It makes no sense that D3D9 on Vista was not wholly implemented within the
>D3D9Ex framework. It would have been trivial to retain support for legacy
>interfaces and still provide D3D9Ex virtualization.
Since you don't have access to the code for the D3D runtime *or*
Vista, I don't see that you're in a position to decide what would or
would not have been trivial. I have greater access to sources and I'm
not in a position to decide that either.
T
"Richard [Microsoft Direct3D MVP]" <legaliz...@mail.xmission.com> wrote
in message news:urcx%23RiRH...@TK2MSFTNGP06.phx.gbl...
> [Please do not mail me a copy of your followup]
>
> "T" <som...@mydomain.com> spake the secret code
> <uCMp8lh...@TK2MSFTNGP05.phx.gbl> thusly:
>
>>Not to mince words, but UAC does in fact reset devices BECAUSE it switches
>>to a different desktop.
>
> So? I don't understand what it is you're complaining about -- its not
> like this is the *only* reason you have to deal with lost devices.
> Lost devices have been part of Direct3D since the beginning and you've
> always had to deal with it.
Read the whole post.
--
"Given that it can take a significant amount of time to
initialize devices, buffers, textures, VBO's, etc., triggering UAC by
whatever means becomes an expensive and destructive action. I can only hope
the load process is not what's causing the UAC to get triggered because I
would never get my data loaded."
--
I can't control what my users do through automation with respect to UAC.
Some database accesses may require elevated priviledges and could easily
trigger the UAC secure desktop. Poof, the user has to reload his display.
I'm not concerned about lost devices when screen savers kick in or someone
is playing WOW -- I'm handling lost devices -- but when normal workflows
result in trashing loaded content, I consider that a bit obtuse.
Don't get me wrong, I think that the UAC is a good thing, but I don't like
the way it can adversely affect my running application.
>
>>It makes no sense that D3D9 on Vista was not wholly implemented within the
>>D3D9Ex framework. It would have been trivial to retain support for legacy
>>interfaces and still provide D3D9Ex virtualization.
>
> Since you don't have access to the code for the D3D runtime *or*
> Vista, I don't see that you're in a position to decide what would or
> would not have been trivial. I have greater access to sources and I'm
> not in a position to decide that either.
I am only concerned about D3D9 on the latest WDDM driver model. In that
scenario, the decision to scuttle resouces is entirely internal to the API
(D3D9 or D3D9Ex) and both are layered on the same DirectX runtime
(http://msdn2.microsoft.com/en-us/library/bb173477.aspx). There's no
technical reason for limiting this to D3D9Ex/D3D10. Microsoft's own comments
imply that these restrictions are because of some "quirk" required for
compatibility:
"... even though the new driver model handles the resources transparently
without evicting them from the device context."
"... even though the new driver model can provide a nearly unlimited amount
of virtual video memory."
Why not allow non-quirky D3D9 applications leverage enhanced functionality
(e.g., virtualized resources) on Vista without requiring a port to a new API
that is only partially supported on Vista (i.e., XPDM drivers don't support
D3D9Ex)?
Tim
Dr Pizza
>
> "Dr Pizza" <DrP...@quiscalusmexicanus.org> wrote in message
> news:xn0f1vle...@msnews.microsoft.com...
> > T wrote:
> >
> > > That may be true, but UAC should not be able to reset devices
> > > simply by displaying the protected desktop
> > "UAC" doesn't reset devices. "Switching to a different desktop"
> > resets devices. Always has.
>
> Not to mince words, but UAC does in fact reset devices BECAUSE it
> switches to a different desktop.
There are lots of things that reset the device, though, and you've
already got to deal with them. UAC is no different. The problem is
that device resetting is a pain; it's not anything specific to UAC.
> It's like saying, "I didn't kill him
> -- the bullet did". Just because the reset is caused by switching to
> different desktop and not by UAC explicitly does not grant immunity
> to UAC.
But equally it means that to blame UAC is folly. Device resets are a
fact of life under D3D9. UAC is just one of many sources of resets.
> While the secure desktop switch can be disabled, we are
> strongly advised by Microsoft to NOT turn this off. It the whole
> "cake and eat it" thing all over again.
Not really, no.
> Switching to a different desktop (ctrl+alt+del, win+l, etc.) are all
> manual processes that are not really "normal" workflows relative to
> multitasking between several active applications. UAC on the other
> hand can happen during normal interaction with the desktop UI
UAC prompts should only be seen after a user has initiated a
UAC-protected action, and the user knows he will do this because the
button or icon will have a Windows shield on it. It's just another
manual process.
(There are ways to get UAC prompts that do not have a Windows shield,
for example executing a program whose manifest states that it needs to
be run as Administrator from Win+R or cmd.exe, but this is not a
scenario that a normal user will ever come across, so it's not a
concern).
> (e.g.,
> running an application the requires access to priviledged resources,
> manipulating file permissions and ownerships, activating an addin
> that requires elevated priviledges, etc.).
All manually-initiated.
> It was Microsoft's
> decision to switch to a different desktop when implementing the
> secure UAC prompt - not mine - buy my application is paying a huge
> penalty.
It's paying the same penalty it always had to pay.
> Given that it can take a significant amount of time to
> initialize devices, buffers, textures, VBO's, etc., triggering UAC by
> whatever means becomes an expensive and destructive action. I can
> only hope the load process is not what's causing the UAC to get
> triggered because I would never get my data loaded.
Even if you were to do something so stupid, that's not actually true.
Once the process's token got replaced with the proper administrator
token, it'll remain privileged (unless it deliberately forfeits the
administrator token and reverts to being unprivileged, as Explorer
does).
> It makes no sense that D3D9 on Vista was not wholly implemented
> within the D3D9Ex framework. It would have been trivial to retain
> support for legacy interfaces and still provide D3D9Ex virtualization.
This is not in the least bit obvious. D3D9Ex needs WDDM drivers, which
D3D9 does not. That alone would seem to preclude implementing D3D9 in
terms of D3D9Ex.
--
Chuck Walbourn [MSFT]
> fundamental reason that creating a HAL device couldn't or shouldn't be
> supported from a noninteractive service desktop?
On XPDM the unsharable nature of Direct3D HAL was the main reason. For
Windows Vista, the WDDM driver can technically handle it, but session
isolation doesn't allow it. This is being evaluated for future support.