The window station assigned to services running under a given account is completely different from the window station of the logged-on interactive user. Windows internally manages several window stations, each with their own desktop. "before Vista"), this is extremely tricky.
If you continue down the road of trying to make your service interact with the user's desktop directly, you'll lose: even under the best of circumstances (i.e. Is this possible, and if so how?Īny pointers to the above questions would be appreciated! Secondly - taking a step back, all I'm trying to achieve, is simply a windows service that provides a gui for configuration - I'd be quite happy to run using the non-Local System Account (with named user/pwd), if I could get the service to interact with the desktop (that is, have a context menu available from the system tray).
My first question is - why might the "Local System Account" login takes SOOOOO MUCH LONGER than when the service logs in with the non-LocalSystemAccount, causing the windows service time-out? what's could the difference be between these two to cause such different behavior at start up? Incidentally, I increased the windows service timeout from the default 30 seconds to 2 minutes via a registry hack (see, search for TimeoutPeriod in section 3), however the service start up still times out. service on Local Computer.Įrror 1053: the service did not respond to the start or control request in a timely fashion. Here is the problem though - when I choose the "LocalSystemAccount" option, and check the "interact with desktop" option, the service takes AGES to start up for no obvious reason, and I just keep gettingĬould not start the. When I install the service via "installutil" using a named account (i.e., not Local System Account), the service runs fine, but doesn't display the icon in the system tray (I know this is normal behavior because I don't have the "interact with desktop" option). My code works fine in debug mode, and I get the context menu come up, and everything behaves correctly etc. The reason why we need a gui for a windows service is in order to be able to re-configure the behaviour of the windows service(s) without resorting to stopping/re-starting. I have recently inherited a couple of applications that run as windows services, and I am having problems providing a gui (accessible from a context menu in system tray) with both of them.
0 kommentar(er)
