(888) 881-CORE
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:
contacting Dropbox support, and/or
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:
C:\Program Files (x86)\Dropbox\Update\Download\{CC46080E-4C33-4981-859A-BBA2F780F31E}\81.4.195
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.
September 19 @ 10 PM Pacific: Dropbox posted Beta Build 82.3.133 earlier today.
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.
September 25 @ 10:30 PM Pacific: Dropbox forum user Wilson7777 has proposed a workaround:
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!
September 27 @ 12:30 AM Pacific: The fix from 9/25 is working well so we have documented our recommended workaround in this post. Enjoy!
Have you tested this on Terminal Services in Windows Server 2012 R2 VM? It is definitely not working in such configuration.
Hi Anastas. So far, we have only tested on Server 2012 R2 without Terminal Services.
Do you see anything strange (such as an error message) when you switch to Session 0? Please send us a screenshot if you do.
81.4.195 and previous 81.4.193 have the issue. Win10 Pro x64 machines fully updated. In Always Up, after 1-3 hours it stops syncing. To get to the 3 hour point, first run Dropbox in this session and then acknowledge any notifications in the app (also make sure they are all turned off). Even running in this session or outside of Always Up seems to stop working if running for more than a few hours.
As the memory usage steadily increases and disk activity is more noticable in these versions, I would hazard agues they were supposedly putting out a new sync process that is not to scratch.
Just a follow up. Using Always Up 9.7.2.88, if you try to stop/restart the service running Dropbox, when Always Up says it is stopped, there are 3 proccess still “running” but there will also be an Application Error, event 1000, in the Application event log.
Always Up is not closing all the child proccesses if one of them casuses an application error. I have noticed a similar issue with an in-house app and dot net. If the application causes an error when quitting, Windows can bring up an app error with the same process name but it ends up with a different PID.
Thanks Brian.
AlwaysUp will terminate child processes so something else is in play.
My guess is that AlwaysUp is terminating the main application, but before it can get to the child processes, one of them re-starts Dropbox (which then goes on to spawn another 2 copies of itself). The process IDs will tell the story.
We’ll investigate and see if that is what is going on.
Hi again Brian. It is indeed as we suspected.
When Dropbox starts, it actually runs 3 instances of Dropbox — a main executable and 2 subordinates/helpers.
When AlwaysUp closes the “main” Dropbox.exe, one of the other processes quickly starts up another copy of Dropbox. It looks like some exit/crash protection is going on.
Anyway, that new copy starts up 2 more instances of Dropbox.exe. The end result is that you have a different 3 remaining (after AlwaysUp has terminated the original 3).
One solution is to be more aggressive when closing, not giving Dropbox the chance to spin up that new copy. We recommend using the Windows “taskkill” command to help.
To do so:
1. Edit your Dropbox configuration in AlwaysUp
2. Switch to the Extras tab
3. In the “Use this special command to stop the application” field, enter this command line:
c:\windows\system32\taskkill.exe /f /t /im "Dropbox.exe"
4. Save your settings.
When you stop Dropbox from AlwaysUp, AlwaysUp will run that command, which will forcibly terminate all instances of “Dropbox.exe” and their child processes.
Please try it and let me know if it works for you. (It did on our Server 2019 box.)
Hello ctcadmin,
I’ve tried your settings but the 3 Dropbox.exe-Tasks will start again after a few minutes nonetheless.
We use Windows Server 2012 R2.
In the Eventlog we see the following messages until the 3 Dropbox.exes run again:
Failed to get driver message: (-2147024890) Das Handle ist ungültig.
CertFindCertificateInStore failed with: (-2146885628) Das Objekt oder die Eigenschaft wurde nicht gefunden.
Hi Wambo. Can you please email us your Dropbox settings for review? Thanks.
I have managed to get more details. Teh dropbox process does it itself. Using “wmic process get *” once ended in Always Up there is a new process “C:\Program Files (x86)\Dropbox\Client\Dropbox.exe” –autorestarted –restart-for= . This GUID appears to match the token parameter from one of the child Dropbox processes when it starts (the one that has -type:exit-monitor)
I’ll try the specific command option to kill it.
I am having the same issue with 3 instances of dropbox being found, resulting in being very unreliable on syncing. I am trying the taskkill option. first glance, appears to be working in initial tests.
We’ve been experimenting with some changes to make AlwaysUp close the 3 instances of Dropbox gracefully. The final, working solution is available in the current release candidate (version 12.0.1.39). Please feel free to try it.