{"id":13182,"date":"2025-11-10T19:20:51","date_gmt":"2025-11-11T03:20:51","guid":{"rendered":"https:\/\/www.coretechnologies.com\/blog\/?p=13182"},"modified":"2025-11-10T19:20:51","modified_gmt":"2025-11-11T03:20:51","slug":"google-drive-for-desktop-not-working","status":"publish","type":"post","link":"https:\/\/www.coretechnologies.com\/blog\/alwaysup\/google-drive-for-desktop-not-working\/","title":{"rendered":"Q&A: Why isn’t Google Drive For Desktop Working with AlwaysUp?"},"content":{"rendered":"
\"Why<\/div>\n
\n  I installed AlwaysUp on August 8 and set up Google Drive for desktop<\/a> which has been working well until last Friday. It is now displaying an error message: “Unable to restart the application: “C:\\Windows\\sysnative\\cmd.exe” \/c “”C:\\Program Files\\Google\\Drive File Stream\\Launch.bat”” exited immediately after it was started”.<\/p>\n

I stopped the service and was able to run Google Drive for desktop manually and have it catch up on synchronization. I then quit the application, opened AlwaysUp, deleted the Google Drive and recreated it but still get the error.<\/p>\n

Do you have any idea what could be causing this?<\/p>\n

— Allen<\/p>\n<\/div>\n

Hi Allen. Sorry to hear of the trouble!<\/p>\n

To investigate, we jumped onto our Windows Server 2025 machine and installed Google Drive for desktop (using the Application Advisor<\/a>). When we launched Google Drive, we saw exactly what you did. Drive exited quickly after AlwaysUp started it:<\/p>\n

\"Google<\/a><\/div>\n

We’d never seen that fruitless “flapping” with Google Drive before! It was time to roll up our sleeves…<\/p>\n

\n
\n
\"\"<\/a><\/div>\n<\/div>\n

The problem: Google Drive uses WebView2, which has issues<\/h2>\n

Our investigation continued with Microsoft’s superb Process Explorer<\/a>. That free utility allowed us to examine how Google Drive works — both inside and out — when it’s started normally on your desktop.<\/p>\n

True to form, Process Explorer quickly showed us that Google Drive isn’t a simple application. Instead of comprising of a single process (like a regular program), Google Drive launches a tree of 10 processes<\/b> to do its work:<\/p>\n

\"Google<\/a><\/div>\n

What’s unusual is that some of the applications started by Drive are not created by Google. And even stranger yet, msedgewebview2.exe<\/a> is from Microsoft — a component of their Edge web browser:<\/p>\n

\"Microsoft<\/a><\/div>\n

Why does a Google product rely on Microsoft Edge<\/a> — a direct competitor to its ubiquitous Chrome web browser<\/a>? These are some strange bedfellows<\/a> indeed!<\/p>\n

According to the release notes<\/a>, Google Drive for desktop introduced Microsoft’s WebView2 framework in the August 18, 2025 release (version 113.0):<\/p>\n

\"Google<\/a><\/div>\n

That’s very suspicious. Apparently WebView2 came into the picture right around the time you started having trouble running Google Drive in the background. Could that new component be the culprit?<\/p>\n

Anyway, curiosity piqued, we switched back to running Google Drive with AlwaysUp. In that setup, we consistently observed the following disappointing pattern:<\/p>\n

    \n
  1. \n

    AlwaysUp starts launch.bat (the batch file that starts Google Drive for desktop).<\/p>\n<\/li>\n

  2. \n

    The batch file spawns GoogleDriveFS.exe, the main Google Drive executable.<\/p>\n<\/li>\n

  3. \n

    GoogleDriveFS.exe launches msedgewebview2.exe.<\/p>\n<\/li>\n

  4. \n

    msedgewebview2.exe starts 5 more copies of itself, lingers for a couple of seconds then exits.<\/p>\n<\/li>\n

  5. \n

    GoogleDriveFS.exe restarts msedgewebview2.exe up to 5 times, each time ending in failure.<\/p>\n<\/li>\n

  6. \n

    GoogleDriveFS.exe eventually gives up and closes.<\/p>\n<\/li>\n<\/ol>\n

    It seemed that the Microsoft Edge WebView2 application had trouble staying alive when run as a Windows Service with AlwaysUp. And WebView2 must be a critical component because once it closed, the main Google Drive executable did the same.<\/p>\n

    It was time to dig into WebView2…<\/p>\n

    What’s Microsoft Edge WebView2 anyway?<\/h3>\n

    One of our AI overlords (Gemini<\/a>) puts it this way:<\/p>\n

     Microsoft Edge WebView2<\/a> is a component that allows developers to embed web content (like HTML, CSS, and JavaScript) into native [Windows] applications, using the Microsoft Edge (Chromium) rendering engine.<\/p>\n

    Developers use the WebView2 control to display web content directly within a native app, whether it’s a Win32, .NET, WinRT, or other application.<\/p>\n

    Many desktop applications use WebView2 to display web-based content, such as in-app browsers, ads, or rich text.<\/p>\n<\/div>\n

    With that description in mind, it’s clear that Drive is using WebView2 to render its modern, web-based user interface. You can see WebView2 at work here:<\/p>\n

    \"Google<\/a><\/div>\n

    What’s wrong with using WebView2?<\/h3>\n

    It’s all well and good to build a product atop WebView2, but our research across many articles and forum posts turned up a troubling restriction. WebView2 may not be able to run elevated<\/a>.<\/p>\n

    If so, that’s a big deal for Windows Services, which typically operate with full rights. Could that be why WebView2 exits immediately after Google Drive launches it?<\/p>\n

    To test the theory, we decided to run Google Drive as an administrator. If we’re on the right track, Google Drive would fail when WebView2 protests the excessive rights:<\/p>\n

    \"Run<\/a><\/div>\n

    Yet WebView2 didn’t complain. Google Drive (and WebView2) started and synchronized files as normal.<\/p>\n

    So WebView2 can<\/i> run elevated. But then why did a Microsoft employee say the opposite?<\/p>\n

    We believe he’s mostly right, but the situation is nuanced. Here’s why.<\/p>\n

    Of the 6 processes that WebView2 launched, 3 of them were created with full admin rights:<\/p>\n

    \"WebView2<\/a><\/div>\n

    But 2 of them were launched without<\/i> admin rights. One was even run at the lowest level possible — untrusted:<\/p>\n

    \"WebView2<\/a><\/div>\n

    So, as part of normal operation, the security-conscious WebView2<\/a> launches some sub-components with maximum rights and others with minimal or zero rights.<\/p>\n

    And for some reason, particularly in the context of a Windows Service, WebView2 cannot start those limited, sandboxed sub-processes with minimal powers.<\/p>\n

    We think the problem has to do with the deeply technical subject of UAC and split tokens<\/a>. But since there’s no good way to confirm our suspicions without peeking into WebView2 and Microsoft isn’t about to share the code, we decided to leave the mystery there. Our conclusion is that WebView2 can’t run as an administrator from a Windows Service<\/b>.<\/p>\n

    Time to focus on potential workarounds instead.<\/p>\n

    \n
    \n
    \"\"<\/a><\/div>\n<\/div>\n

    The solution: Run Google Drive in a standard Windows account<\/h2>\n

    If WebView2 is truly allergic to administrator rights, why not have AlwaysUp launch it with limited permissions? Wouldn’t that solve the problem? We tried that by checking the Launch the application without admin rights<\/b> box on the Logon<\/b> tab:<\/p>\n

    \"Have<\/a><\/div>\n

    But to our dismay, that change made no difference. Google Drive still refused to run. We think it’s because WebView2 doesn’t run with a restricted token<\/a>, and that’s what AlwaysUp creates as it strips away admin permissions. More technical weeds and another dead end.<\/p>\n

    What about running Google Drive in a “true” non-admin account?<\/p>\n

    To test that approach, we created a brand new standard account for “Hazel Jones”. As you can see she isn’t an administrator on the computer:<\/p>\n

    \"We<\/a><\/div>\n

    Next, we logged in as Hazel, installed Google Drive for desktop and ensured that it worked well for Hazel.<\/p>\n

    Finally, we returned to AlwaysUp and switched the account on the Logon tab to Hazel:<\/p>\n

    \"Setup<\/a><\/div>\n

    Lo and behold, once we started Google Drive in AlwaysUp, it stayed running! WebView2 was finally happy. You can see the entire process tree running happily in Session 0 here:<\/p>\n

    \"Google<\/a><\/div>\n

    Furthermore, the “G” drive (where Google Drive mounts its cloud file system) was accessible to Hazel. We confirmed that from a standard command prompt:<\/p>\n

    \"The<\/a><\/div>\n

    \nSo there you have it, Allen. If you’re still unable to run Google Drive as a Windows Service with AlwaysUp, setup a regular, non-admin account and configure AlwaysUp to run Google Drive as that user. You’ll have access to your cloud files in that setup.\n<\/p>\n

    \n
    \n\n\n\n
    More articles about AlwaysUp…<\/nobr><\/span><\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n