Posted onOctober 16, 2019 (Revised February 21, 2022)
When I look in Services.msc, some of the Windows Services have a startup type of “Automatic (Trigger Start)” and “Manual (Trigger Start)”. What do those mean?
— Liam
Hi Liam. Those trigger start types are indeed mysterious. And the Services application makes no attempt to explain what they are.
For example, even though the phrase “Trigger Start” appears in the “Startup type” column in the list of services, that designation is absent when you dig into an individual service.
Here we see the User Manager service showing a startup type of “Automatic (Trigger Start)” in the list but simply “Automatic” in the same field in the service’s properties window:
Baffling, to say the least.
Let’s break down each of the start type names into their two components, to understand what the Services application is trying to communicate.
What do “Automatic” and “Manual” mean?
The first component tells Windows what to do with the service when the computer boots.
Automatic says “start this service when the computer boots”.
Manual means “don’t start the service at boot; it may be started at some other time”.
There are other startup types too but those will be explained in a future article.
What does the “Trigger Start” part mean?
While the first component focuses on what happens at boot, the “Trigger Start” wording indicates if the service can be started or stopped by various operating system events.
For example, some services are configured to start when a USB drive is inserted. Other services may stop when your computer signs out of a domain or leaves the network.
Services that respond to these events are using windows service triggers — a powerful feature designed to conserve your computer’s precious resources. Service triggers were introduced in Windows 7 and Server 2008 R2.
And here is the point of this journey into triggers: A service that has at least one trigger will show up with the “Trigger Start” designation in the Services application.
(Note that the treatment of triggers in the Services application stops there. Despite indicating when a service contains a trigger, triggers cannot be changed in the Services application. You must use the SC command line utility or our free Service Trigger Editor GUI to add or remove triggers from a service.)
Putting it all together…
In summary:
Automatic (Trigger Start) means:
This service will start automatically at boot. It may also start or stop in response to specific operating system events.
Manual (Trigger Start) means:
This service will NOT start automatically at boot. It may start or stop in response to specific operating system events.
Hope this makes sense! Please be sure to get in touch if you have any other questions about the wonderful world of Windows Services.
The Remote Procedure Call (RPC) service supports communication between Windows applications.
Specifically, the service implements the RPC protocol — a low-level form of inter-process communication where a client process can make requests of a server process. Microsoft’s foundational COM and DCOM technologies are built on top of RPC.
The service’s name is RpcSs and it runs inside the shared services host process, svchost.exe:
Should I stop the RPC service?
The answer is no — you should definitely not stop the service. It is far too important.
Indeed, if you examine the list of services that depend on the RPC service for smooth operation — by running the SC ENUMDEPEND command — you will notice that there are a whopping 103 services that need RpcSs on Windows Server 2019!
If the RPC service stops, those 103 would have to stop as well — surely crippling your computer.
Why are all the options for the RPC service grayed out?
If you examine the service’s screenshot, you will notice that the Stop and Pause buttons are disabled — indicating that the service cannot be interrupted.
Furthermore, the account running the service cannot be changed on the Log On tab:
You can adjust the recovery settings but not much else.
By limiting changes, Microsoft is clearly shouting: Do not update the RPC service!
Questions? Problems?
If you would like to know more about the Windows RPC service, or you have a specific problem, please feel free to get in touch. We will do our best to help you!
Afterwards, restart Dropbox as a service. The OpenGL prompt should be gone — a relic of an unpleasant past.
Huge thanks go to Dropbox forum user Wilson7777, who alerted the community of this remedy. His original solution is here.
Why does the fix work?
The explanation is a bit technical, but here goes…
Dropbox uses Qt — a popular cross-platform development framework.
In turn, Qt requires OpenGL — a cross-platform API for rendering 2D and 3D vector graphics.
So when you run Dropbox, both Qt and OpenGL will be started.
But for some unknown reason, when Dropbox is started as a Windows Service in Session 0, Qt and OpenGL fail to initialize. That failure causes Dropbox to throw up the “Failed to create OpenGL context for format QSurfaceFormat” error, which suggests that there is a problem with the computer’s graphics card/hardware.
Fortunately there is a way to instruct Qt: “Instead of using the computer’s graphics hardware for OpenGL, use software libraries”. Setting the QT_OPENGL environment variable to “software” is the way to do that.
And with the change to use software instead of hardware, Qt, OpenGL and Dropbox all start properly.
Note that when you ran the SETX command in step 2, it added the QT_OPENGL value to your environment. You can see it listed in your environment variables (available from the Control Panel):
Will this fix work for future versions of Dropbox?
We certainly hope so! But like you, we’re not sure what magic the next automatic update of Dropbox will bring…
Posted onSeptember 18, 2019 (Revised January 7, 2023)
The most recent release of Dropbox — Stable Build 81.4.195, posted the morning of September 18 — may not work properly as a Windows Service with AlwaysUp.
We are actively investigating. So far, the problem appears to be related to Session 0 — the background desktop hosting Windows Services.
When Dropbox starts in Session 0, some customers report that this error prompt stops the action:
If OK is pressed, Dropbox simply exits — without synchronizing any files.
Is there a workaround?
Yes. Please see the update from 9/25 (below) for a potential workaround. To date, it has worked for several customers.
Dropbox says to make sure that your display drivers are up to date. This has resolved the problem for some customers. Please let Dropbox know if it doesn’t work for you.
Beyond that, there are a couple other workarounds but neither is a long term solution.
If you start Dropbox in the current session (by selecting Start “Dropbox” in this session from the Application menu), Dropbox will start and your files will be synchronized. However, once you log off, Dropbox will return to Session 0 and it will cease to function again.
Another option is to run Dropbox outside of AlwaysUp, normally on your desktop. Of course, you will have to remain logged in, which is less than ideal.
Please check in the “Updates” section below for additional workarounds as they are developed.
When will this be fixed?
We’re not sure when Dropbox will fix the problem.
They seem to create new desktop client builds regularly so we have our fingers crossed that they deliver a resolution very soon.
Please let Dropbox know that you are affected
We encourage you to “nudge” the Dropbox team into action by:
posting a friendly message on the Dropbox release page expressing your frustration with this release.
The more we speak up, the better the chance of a quick fix.
We need your help!
First, can you let us know if you are experiencing trouble with the latest Dropbox? Please be sure to answer the following questions:
What version of Windows are you running?
Do you see the “OpenGL” error message when you switch to Session 0? That operation is available from the Tools menu in AlwaysUp.
Is your computer a virtual machine? If so, what is the host? (VirtualBox, Hyper-V, VMWare, etc.)
Second, can we access your system remotely to troubleshoot? We have been unable to reproduce the problem on our systems, and that has been an obstacle to us developing a solution/workaround.
Your help will be appreciated!
Updates
September 18 @ 5:38 PM Pacific: Eric Sakariasen from Connetic has come up with a clever workaround:
I found a way to work around this issue, at least in my environment,
We have Dropbox running with separate creds (a service account) I go to the cached installer for 81.4.195, in my case its:
I deny all access to the executable via NTFS permissions for that account. Then install the older 80.4.127 over the top of the current install (it kills the running version automagically). This seems to break the ability for the updater to do its magic so it will skip this version.
We can only hope the next version is up and running with a fix, if not, rinse and repeat.
This has worked for at least 3 of our customers running Dropbox.
September 18 @ 9:20 PM Pacific: So far we have thoroughly tested Dropbox version version 81.4.195 running in Session 0 on the following operating systems:
Windows Server 2019
Windows Server 2012 R2
Windows 10 (Build 1903)
None have exhibited the problem.
Here is the basic test we perform using two computers linked to the same Dropbox account:
Copy a new file into machine’s A’s Dropbox folder
Check that the file shows up on dropbox.com
Check that the file shows up in machine B’s Dropbox folder
We will continue to test other versions of Windows over the next few days.
September 19 @ 6:15 AM Pacific: The Dropbox support team suggests that the problem may be with old display drivers.
Perform the steps outlined in this post to make sure that your PC is up-to-date.
We’re not sure if it fixes the problems running in Session 0 (Dropbox doesn’t post a changelog) but it may be worth a shot. Please try it let us know if it works for you or not.
For those scratching their heads trying to resolve this OpenGL issue running the latest version of Dropbox + AlwaysUp I have successfully resolved this issue by following these steps:
1. In the Windows start menu enter the search term “environment variables” and select “Edit the system environment variables”
2. In the dialog that comes up click “Environment Variables” then click “New” in the system variables section.
3. In the dialog that comes up enter variable name = ‘QT_OPENGL’ (without the quotes) and variable value = ‘software’ (without the quotes)
Click “OK” then “OK” then “OK” to close the system properties dialogue.
Restart Dropbox within AlwaysUp and you should find the OpenGL issues are resolved if you view through session 0 and Dropbox will be synchronising your files fine.
Please try it and let us know if it works for you!
September 26 @ 7:30 AM Pacific: Customer Seth Ruppert from IMT has reported that the 9/25 fix has resolved the issue on his installations.
And other reports of success are trickling in, so setting the QT_OPENGL system environment variable to software seems to be working!
Posted onSeptember 16, 2019 (Revised December 16, 2019)
I setup AlwaysUp to run JRiver Media Center as a Windows Service but it’s simply not working. I reboot the server every week and every time AlwaysUp says it can’t log on. These errors come up, over and over:
Help!
— Anonymous
Hi — sorry to hear that the service isn’t starting for you!
From the logs you sent, the key error appears to be this one:
The service did not start due to a logon failure
Windows is saying that it cannot authenticate your account (the one you specified on the Logon tab in AlwaysUp) so it cannot start the service.
The failure is probably due to one of three problems. Answer the following questions to find a solution.
Has your Windows password expired/changed?
If you recently set a new password on your Windows account, the service may be stuck using the old one.
To update the service’s password:
Edit your JRiver service in AlwaysUp
Switch to the Logon tab
Enter your new password:
Save your settings.
Reboot your PC and see if JRiver starts automatically. If not, read on to keep troubleshooting.
Have you specified a domain account on the AlwaysUp Logon tab?
If your service is running in a domain account, it’s possible that the service is starting too soon — before the primary domain controller is ready to accept requests.
Indeed, this can easily happen when your computer is the slow-starting domain controller!
The fix is to delay the start of the JRiver service, to allow the domain controller enough time to launch and initialize. To do so:
Edit your JRiver service in AlwaysUp
Set the Start the application field to Automatically, but shortly after the computer boots:
Save your settings.
Reboot and see if that does the trick!
Is your Active Directory Group Policy overwriting the Local Policy setting for the “Log on as a service” right?
This last scenario applies if your system uses Active Directory and you have specified a domain account on the AlwaysUp Logon tab.
Your Windows account may be losing the right to run as a service when an incomplete group policy overwrites the local policy. Basically, your account is “out of sync” with the Active Directory server.
If you are still seeing the error, something strange is definitely going on with your setup.
Please get in touch to schedule a remote session, where we can troubleshoot your misbehaving service. We’ll do our best to have you up and running soon!
(888) 881-CORE
