Windows 2008 RenderFarm Service: CreateProcessAsUser “Session 0 Isolation” and OpenGL

Question

I have a legacy Windows server service and (spawned) application that works fine in XP-64 and W2K3, but fails on W2K8. I believe it is because of the new \"Session 0 isolat

Answer 1

For anyone interested in the resolution of this issue:

I discussed this issue with MS Support for the LogonSDK team. It appears that it is not possible to fully impersonate an interactive user programatically, such that you get a physical console and associated GDI constructs, and we've essentially been "just lucky" that it worked until now. They did confirm that session 0 isolation was the root cause of the regression.

Their recommendation is to enable auto-logon to an interactive session, and refactor the service to speak to a new client component in the interactive session. To address the security disadvantage of this, they recommend implementing a shell replacement to place the server in a "Kiosk" mode on logon (e.g. no Explorer access without appropriate credentials, etc.)

On the up-side, this should address the issues we've been encountering with terminal service sessions killing our hardware acceleration.

I will be submitting a request to MS consider this kind of "render farm" use case for "proxy user session" support in future releases, such that a server can spawn hardware-accelerated processes without the security compromise of requiring an existing client user process to be logged on at the console.

Answer 2

I have not completed the training course, but I have found a "Session 0 isolation workaround" tutorial on the Microsoft-MSDN site:

http://msdn.microsoft.com/en-us/windows7trainingcourse_sessionisolation_unit.aspx

I have the same session-0-isolation problem manifested within a scheduled task.

Answer 3

farmComm will launch the application(s) of your choosing into session 0, with no GUI visible, but with access to graphics hardware, whether users are logged in or not. It also responds to user activity in whatever session is active (including session 0 or the "secure desktop," when that is the active session). It is designed to launch applications thus when users are idle, and terminate them upon user resume from idle, but those run conditions could easily be altered in the source AutoHotkey scripts.

https://github.com/r-alex-hall/farmComm

It spawns applications in session 0 "invisibly," but it can very easily be modified (change a variable with the value "hide" to "show") to have the GUIs of spawned processes visible (if they have a GUI). If they are visible, however, they may either trigger Windows nags to see "messages" in session 0, and/or only be visible from session 0 (which, it seems, includes any time the "secure desktop" is visible--for example when a workstation is locked, or disconnected from user sessions, or no users are logged on).

At this writing, if any Remote Desktop (RDP) session is begun while processes spawned by farmComm run, farmComm will terminate those processes and attempt to re-launch them to respond to the RDP session, which, if they are applications which attempt to access graphics hardware, may cause them to crash (because RDP restricts access to graphics hardware). Probably this RDP problem could be worked around, too . . . or you can tweak the source to never terminate processes, or never migrate to other sessions. (NOTE: a possible planned change is to enable you to script whether and when farmComm terminates, does not terminate, suspends, or resumes processes--or for that matter, script it to run entirely different processes when users resume from idle).

The scripts can be compiled to executables, which in my distribution, they are.

The linchpins of this toolset are a particular version of paexec (which launches applications into session 0), and AutoHotkey's very reliable responses to user activity (or lack thereof), and retrieval of system information about a session. The option to launch processes "hidden" (with no GUI visible) is also via AutoHotkey.

Disclosure: I scripted (or coded) farmComm, and released it into the Public Domain.