RunAs bug : AddTheAceWindowStation failed

Hi, I have a Windows Service that interact with desktop. The service uses the utility command line tool RunAs to run processes that needs to interact with the user desktop. The tool works great only if I use it a certain number of times in one session. When I use it more then thirty-something times, I get the following error:

Logging in as ho\mcnejf...
Setting user environment...
Logged in. Impersonating...
Binding new process to the user Desktop...
AddTheAceWindowStation failed.

It seems like every time the service runs the tool, the tool creates a new desktop and it binds the process to it, but when the process has been terminated, the tool doesn't dispose of the desktop. So at one point there's no more desktop available.

Is that standard behaviour or is it a bug?

Good point. The only thing it doesn't create a new desktop. It binds process to the existing user desktop. We have a separate utility called BindDesktop. Please check if it works for you.

Thanks for the quick answer. Well the RunAs tool works in disconnected mode, when no user has logon, so no desktop have been created. That's why I assumed that at some point a desktop must have been created. That's a shame really, the tool would work perfectly for me if it weren't for that bug. Coding all the calls to the Windows API (LogonAsUser, LoadUserProfile, CreateDesktop, CreateProcessAsUser, etc.) is really a pain in the...And all the other tools I've tried does not work except this one (: .

I've looked at the tool BindDesktop, unfortunately I cannot run processes under a specified user account. The tool doesn't have the parameters "user/domain" and "password" to do so. My Windows service runs as the local System account to interact with desktop, but the applications started by the service need to acces the current user's registry key (HKEY_CURRENT_USER) to function. I know, it's really tricky, but I didn't make the rules. That's why I need to run these processes under a specificed user account, not under the local System account.

In that scenario "when no user has logon, so no desktop have been created. That's why I assumed that at some point a desktop must have been created." it somehow makes Windows to create a new desktop. Do you actually see the new desktop? If it works in a disconnected mode, why do you need to bind to the desktop? I am asking these questions so I create new issue for the development and post the necessary details.

In disconnected mode, we don't see the application running, we do see it when we logon to the machine. I talked about BindDesktop because you mentionned it and I'm looking for an alternate solution. But it has nothing to do with our problem, so forget about it, for the time being

The problem only concerns RunAs. I have the same problem in connected and disconnected mode, the tool has the same behaviour. Everytime I use the tool, it seems to create a new user desktop. My guess is that the tool probably calls the API OpenDesktop, if returns null it calls the API CreateDesktop. Then it binds the process to the desktop with the API SetProcessWindowStation (another guess). Finally, once the process has been terminated, RunAs should disposes of the unused ressources and delete the desktop and window station by calling the API CloseWindowStation and CloseDesktop.

Somehow it doesn't do the last part correctly, CloseWindowStation because I get this error from the tool :

"AddTheAceWindowStation failed"

This method creates a new handle on a windowstation and it seems like there is a limit on the number of handles created. So if they are are not deleted after being used (like it seems to be the case with RunAs), you eventually reach the limit ERROR_NOT_ENOUGH_QUOTA and RunAs stop working until you reboot the server.

Thanks. I will add your input to the tracking issue.

Thanks SysOp, do you have any idea how long it takes before new releases are made ? I know its probably hard to say but if you could just give me a rough idea on how long it could take, or maybe just a simple description on the debugging process of your company, that would be really appreciated.

Unfortunately I am unable to provide any timing. It is really unclear what's causing it. We are looking into this. The desktop is not created. It is definitely opened and closed and looks like for every kind of "open" there is a matching "close" statement. Besides the process is not persistent, it starts and ends on every run. Even if something is not closed properly, that all resources should be released by the system automatically when the process ends. I will post any updates in this message thread as they become available. Make sure you checked "notify me" option so that you don't miss them.

Thanks a lot. Nonetheless the bug is really easy to reproduce, just run the tool more than 30 or 40 times, open Notepad for example and you should get the same error.

The new version has been copied to the webserver.

PS. The problem was caused by usage of low level security API, which required for binding service processes to the interactive window-station and desktop so that these processes can interact with a logged on user, even if the service and user have different logon accounts. Apparently Windows doesn't restore automatically access control entries (ACE) and discretionary access control lists (DACL) after termination of the process that adjusted DACL for the window-station or desktop. As a result, after 30 runs the amount of reserved memory for DACL gets exhausted making it impossible to bind new processes to the interactive user desktop. For more reading, see http://msdn2.microsoft.com/en-us/library/aa379195.aspx

Does that mean that you already solved the problem and that I can download the new version of the tool at : http://www.softtreetech.com/24x7/extras/RunAs.exe ?

It probably does cause I've downloaded this version and ran over 50 processes and it works ! I have to say that I'm very impressed with the quickness of your company to solve this problem, especially when you consider the complexity of the problem. Thanks for the quick answers also.

Yes, we think that problem has been resolved.

Thanks again.