Jump to content

Recommended Posts

Posted

A couple of our users have reported that Drive for Desktop (File stream) crashes immediately on launch. All our installations are set to auto update, and the problem machines are running version 48.0.13.0. The logs show the below:

2021-07-01T08:55:31.657ZI [13384:MediaManagerThread] root_preference_db.cc:735:UpdateSchema Outdated RootPreferenceDB schema version. V2 stored in sqlite file vs. V1 in executable.
2021-07-01T08:55:31.658ZE [13384:MediaManagerThread] root_preference_db.cc:739:UpdateSchema RootPreferenceDB schema downgrades are not supported. Sign out and uninstall required.
2021-07-01T08:55:31.658ZE [13384:MediaManagerThread] root_preference_db.cc:318:Initialize Failed to update schema for RootPreferencesDb.
2021-07-01T08:55:31.658ZE [13384:MediaManagerThread] media_manager.cc:449:StartInternal Failed to initialize RootPreferenceDb: Status::UNSUPPORTED_SCHEMA_DOWNGRADE
2021-07-01T08:55:31.658ZE [11444:NonCelloThread] client.cc:318:Initialize Failed to start MediaManager: Status::UNSUPPORTED_SCHEMA_DOWNGRADE
2021-07-01T08:55:31.658ZI [11444:NonCelloThread] drive_fs.cc:576:RunDriveFS Return code: CANNOT_CREATE_UI
2021-07-01T08:55:31.683ZI [11444:NonCelloThread] ipc_server_manager.cc:40:~IpcServerManager Quitting the IPC thread
2021-07-01T08:55:31.685ZI [11444:NonCelloThread] ipc_server_manager.cc:43:~IpcServerManager IPC thread destroyed.

 

We've tried clearing the users' appdata, and reinstalling the application but neither fixed it. Has anyone else experienced this?

  • 2 years later...
Posted

Old post, but 92.0.1.0 has rolled out recently, but it has hit us disastrously so this week. Pretty much every device affected. Google suggests to stop AV from scanning the sync folder, but erm no, not going to do that. It's not the sync folder that's the problem anyway; it's the user's profile based DriveFS that seems to have been corrupted. 92.0.1.0 install is good and renaming DriveFS in the appdata\local\google folder fixes it.

 

Might have to see if Sophos allows for wildcards to so I can blanket exclude this user specific location. Going to turn off auto update for google drive too

Posted
DEFINITELY you must exclude the sync folder otherwise you'll be hammering CPU and you'll have core i7's with 16gb ram falling over. There's no safety issue with excluding that folder as it's being scanned already as part of the drive, what you're doing by adding the exception is stopping it being scanned twice.
  • Thanks 1
Posted
DEFINITELY you must exclude the sync folder otherwise you'll be hammering CPU and you'll have core i7's with 16gb ram falling over. There's no safety issue with excluding that folder as it's being scanned already as part of the drive, what you're doing by adding the exception is stopping it being scanned twice.

 

interesting, thanks. Will see to that then. Doesn't explain the corrupt DriveFS though :/

Posted
Not sure, sophos has been known to do funny things with it and was one of the many issues I looked at when we had major problems. Are you streaming or syncing?

 

 

Streaming. The options that it offers are stream or mirror, so the files sync 'up' to Google with Google cloud being the authoritative 'boss'. I've added the mapped drive letter to Sophos global exclusions.

Posted
Ah yes - sorry, I still have onedrive in my head so I forget google calls it mirroring ;) We're streaming too, I'll keep an eye for similar as we're also on Sophos and drive app v 92.0.1.0
Posted
Ah yes - sorry, I still have onedrive in my head so I forget google calls it mirroring ;) We're streaming too, I'll keep an eye for similar as we're also on Sophos and drive app v 92.0.1.0

 

Fingers crossed you have no issues, though the update came out end of May and so I suspect you would know by now. Look out for users saying "my G drive has gone" and the client loading before crashing and being stuck in a loop. Beyond renaming their DriveFS in ..\appdata\local\google I do not know much more yet. In a support chat with Google.

Posted
If you're using it in appdata then be careful if that is redirected or part of a roaming profile, especially if offline files are enabled. Worth moving it out to another location or adding an exception to offline files.
Posted (edited)

Their synced files are just getting mapped to G, however the cache and logs etc all reside in appdata, presumably because that's the default behaviour. I've got a ticket in with Google and they have a video of the problem happening as well as bunch of log files, so I'll keep this thread updated.

 

EDIT: yeah appdata is the standard location for all the caching of files, logs etc, regardless of where their drive location is set to. I'm not sure this would be a problem, otherwise surely Google would recommend another location? It is possible via a registry to move it, but I'm extremely reluctant to change this until I know why this is keeps happening at big FS updates...

 

We don't redirect appdata nor do we use roaming profiles, thankfully

I wish we were back on 365; I cannot stress how much more I preferred 365 over Google. Getting Windows and Google to play together in a way that that is simple and intuitive for users is a huge challenge, especially on our overly stretched team. I had a much better option with Teams, SharePoint, and OneDrive.

Edited by Planehazza
Posted
A few users here having the same.

 

Deleting AppData\Local\Google\DriveFS Folder appears to work for us.

 

Yup that's the fix. I've had to roll out a user policy logoff script to delete it and have it live for a week to catch all. Google have been beyond useless in looking for a reason.

 

We have a few leads internally. We do not use AppLocker (on my list) and have a GPO that blocks access to the C drive so I suspect that may be part of the issue. It looks like the Google installer has successfully updated the client, but has failed in making changes/purging user files. Not sure if this happens in the context of the user which would account for this issue in most education IT worlds if it is.

  • Thanks 1
Posted
Yup that's the fix. I've had to roll out a user policy logoff script to delete it and have it live for a week to catch all. Google have been beyond useless in looking for a reason.

 

We have a few leads internally. We do not use AppLocker (on my list) and have a GPO that blocks access to the C drive so I suspect that may be part of the issue. It looks like the Google installer has successfully updated the client, but has failed in making changes/purging user files. Not sure if this happens in the context of the user which would account for this issue in most education IT worlds if it is.

 

Very small update. It's a file within the long numbered folder within DriveFS. I do not know what file and the log files show multiple restarts matching what we're seeing, but no further forward as to which file is broken or why.

 

Google are not helpful at all...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...