AlwaysUp version 17 is now available to all customers.
While the primary focus of this new release is to improve logging and monitoring capabilities for our security-conscious enterprise clients, we managed to squeeze in a couple fresh features as well. The end result is clear — higher uptime and greater security for anyone looking to run their important Windows applications 24/7.
So, without further ado, let’s dive in and review the highlights of AlwaysUp 17.
AlwaysUp will automatically restart your script if it hangs
While the vast majority of folks use AlwaysUp to run exe files, a good portion run scripts. And instead of running 24/7 continuously, those batch files, Python and PowerShell scripts are designed to perform a specific job and exit when done. It’s a beautiful arrangement, because AlwaysUp simply fires them up again a few seconds or minutes later.
However, trouble takes hold when a script gets stuck and never completes its work. In that case, the job will remain stalled — and AlwaysUp will let it continue like that, indefinitely.
For customers in that frustrating situation, introducing a periodic sanity check is a great solution. The idea is that the sanity check would eventually notice that the script isn’t doing its work and restart it.
AlwaysUp version 17 introduces a new option — a simple watchdog timeout.
For example, suppose you have a batch file that typically takes about 30 seconds to do its work. To protect yourself against the script getting stuck and hanging until someone notices, you can instruct AlwaysUp to terminate and restart the batch file if it runs for longer than 5 minutes. That safety net will tolerate a long-running script (say, if it has lots of work to do) but provides a solid backstop that ensures the batch file will never flounder for too long.
The new feature is available on the Monitor tab, where it’s very easy to set:
Full support for group Managed Service Accounts (gMSA)
Group Managed Service Accounts (gMSAs) have become very popular with Windows administrators. With automatic password management, support for clustered services and built-in security features, what’s not to like?
Recent versions of AlwaysUp are compatible with gMSAs but version 17 takes support up a notch. For example, AlwaysUp no longer prompts for a password when you enter a gMSA on the Logon tab:
There are several internal improvements as well, to ensure smooth operation as AlwaysUp runs your application in the gMSA.
Extensive reporting to the Windows Event Logs
The experts agree: Logging is a foundational pillar of any effective information security system. Indeed, without the systematic, automated recording of system events, it’s nearly impossible to investigate potential threats and problems. You’re flying blind.
Our team is well versed in bedrock ISO 27001 principles so we understand the importance of logging. And in AlwaysUp 17, we rewrote key components to report all sensitive operations to the standard Windows Event Logs. From there, enterprise administrators can pipe those events into Splunk, SolarWinds Security Event Manager, Graylog or any other SIEM compatible with the Windows operating system.
Here’s a quick rundown of the major changes in this area:
When writing to the Windows Application Event Log, AlwaysUp now sets a semi-unique Event ID value to classify the event. You can use that ID to trigger alerts downstream, as the data makes it to your SIEM.
The Event Log Messages page documents the identifiers associated with each record reported by AlwaysUp.
AlwaysUp sets the Task Category to “AlwaysUp Events” for every record it creates. Doing so makes it easy for you to identify and group all activity from AlwaysUp — across all applications installed as Windows Services.
To improve oversight and accountability, AlwaysUp now reports important application/configuration updates to the event logs. For example, here is event 108 telling us that Administrator modified the Dropbox Windows Service:
In version 17, there’s now a “User” column in the Activity Pane. It tracks who performed each activity.
The Activity Detail window displays the name of the user as well:
Of course, all that information is stored in the Windows Event Logs.
Autologon refinements
Several customers rely on automatic logon to run their applications in an interactive user session. Because of that, we continue to make sure that AlwaysUp works well with autologon — safely and smoothly.
Version 17 brings one improvement in the area of feedback. If you happen to log in before autologon completes, your application will show a waiting icon that tells you what’s going on:
Behind the scenes, there are a couple of code changes that bolster security.
First, AlwaysUp now removes any leftover plain-text passwords it finds in the registry, opting for encrypted representations instead.
Second, if you disable automatic logon from AlwaysUp, the encrypted password is removed from the secure secrets repository. Even though the password remains obfuscated, there’s simply no good reason to leave it behind.
Other fixes & improvements
Customers running Python scripts as a Windows Service will notice that AlwaysUp 17 automatically closes Python scripts more gracefully now. There shouldn’t be any warnings about terminating python.exe.
Tip: If you find that your script is still being abruptly killed, be sure to update your code to catch the KeyboardInterrupt exception and exit when it’s triggered.
Unfortunately, new versions of OneDrive continue to experience trouble running in Session 0. And we remain flummoxed and frustrated with the folks in Redmond.
Until there’s a solution, we updated the Application Advisor to warn users setting up OneDrive as a Windows Service that automatic logon may be required:
The Google Drive for desktop application now uses Microsoft’s WebView2 component, which is allergic to running as an administrator. We added a warning to that effect when installing Google Drive as a Windows Service:
To run more smoothly on Windows Secure Host Baseline (SHB) and other locked down versions of Windows, our developers rearchitected internal components to avoid conflicts related to Data Execution Prevention (DEP) and similar process mitigation technologies. But as much as we want to geek out, it’s far too technical (and boring) to go into the details now. We’ll stop here.
Finally, AlwaysUp now supports online registration. You can assign your license directly from the software; all you need is your order reference:
Some folks may find it more convenient than the traditional “offline” method.
As usual, please review the release notes for the full list of features, fixes and improvements included in AlwaysUp version 17.
Upgrading to AlwaysUp 17
If you bought AlwaysUp version 16 (on or after February 7 2025), you can upgrade to version 17 for free. Simply download and install “over the top” to preserve your existing applications and all settings. Your registration code will continue to work as well.
I work for a large technology company based in Germany. Last year, we bought an Unlimited OEM License for AlwaysUp and integrated it into our industrial automation delivery chain.
As an important supplier, we want to ensure that your company takes a holistic approach to Cybersecurity. And in particular, we’d like to know if you’ll be implementing the new EU Cyber Resilience Act (CRA). Please provide a short statement.
If your product will comply, we can rely on that. If you cannot confirm conformity (mostly in case delivery is done outside the EU market), we may have to analyze further effects on our side and raise additional requests/requirements.
— Michael S.
Hi Michael, thanks for reaching out.
Even though we’re based in the USA, our team has been tracking this new EU regulation ever since it started taking shape in 2023. It soon became clear that the CRA would impact us since we have many customers deploying our software in the EU.
But let’s start at the beginning.
What is the Cyber Resilience Act (CRA)?
The EU Cyber Resilience Act enhances cybersecurity standards for hardware and software products by requiring manufacturers and retailers to infuse cybersecurity throughout the lifecycle of their products. It came into force in November 2024 and organizations in the European Union have until December 2027 to achieve full compliance.
Our company isn’t located in the EU and we don’t make any hardware products. But we do create software used by EU companies. As such, we must help our EU customers adhere to the CRA.
Fortunately the CRA aligns with other global standards — like ISO 27001:2022 — which we already embrace. So let’s review what we have in place today.
We’re serious about security
To understand we do today, please review this article detailing how we keep our software (and company) safe and secure. There, you’ll see that we’ve infused information security best practices throughout our processes and practices.
But even though there’s overlap with the CRA and other time-tested standards, the new regulation brings its own perspectives. It deserves dedicated examination. Therefore, from our viewpoint as a US-based software producer, we’ll review 10 major requirements of the CRA and briefly describe how we support you and other EU organizations in each area.
CRA Requirement #1: No exploitable vulnerabilities
Don’t ship software with serious flaws
How we help you to comply
It’s very important to check for malware at every stage of the software production pipeline. And, most importantly, the final product must be pristine. That’s why we engage third-party services to verify that nothing strange has crept into our software.
For example, before release, we run all our applications through Virustotal — a well-respected online virus-scanning engine owned by Google. We halt the release if any critical or high vulnerabilities are detected.
The bottom line: The software we provide to customers is free of major known vulnerabilities at the time it’s shipped.
CRA Requirement #2: A secure default configuration
Make software as secure as possible out-of-the-box
Are installed to a protected folder in “C:\Program Files (x86)” by default
Must be run by an administrator
There’s no way around those important, default safeguards.
Furthermore, there are no “default passwords” of any kind.
CRA Requirement #3: Regular security updates
Establish a method of resolving vulnerabilities discovered after the software was installed
How we help you to comply
It’s company policy to issue a patch for critical and high vulnerabilities within 30 days of their discovery. Medium and Low vulnerabilities are addressed as part of regularly scheduled quarterly or annual releases.
However, as purveyors of software that must operate 24/7/365, we do not support unattended, automatic updates because they’re too dangerous. We leave it to customers to deploy updates manually — after sufficient testing and at a time of their choosing. We keep customers informed of security issues by posting security bulletins on our active blog.
CRA Requirement #4: Protection from unauthorized access
Ensure that the software is accessible only to those who are allowed to use it
How we help you to comply
AlwaysUp and Service Protector are restricted to administrators only. A standard user without admin rights cannot start either of the programs on his own.
If a standard user attempts to start AlwaysUp, Windows prompts for admin credentials:
That important safeguard prevents untrusted (or untrained) individuals from updating your critical applications and services.
Furthermore, after you install your program as a service with AlwaysUp, you have the power to enforce who can start, stop, restart or edit the service.
That capability is available by selecting Advanced > Service Security Settings from the Application menu:
From there, it’s easy for you to specify what each user can do. For example, here’s how we allow Hazel Jones to start or stop the service, but not to modify or delete it:
CRA Requirement #5: Data confidentiality
Maintain the confidentiality of all data processed
How we help you to comply
None of our products collect personal data.
And when our applications communicate with our servers — for example when checking for updates or assigning a license — all data is encrypted in transit over HTTPS.
CRA Requirement #6: Data integrity
Protect data collected from manipulation or modification
How we help you to comply
By design, we intentionally limit the data stored by our applications. That’s because our strong preference is to delegate all data persistence to the Windows operating system.
For example, when you set up an application with AlwaysUp:
Your configuration/settings are saved in the standard registry entries related to the Windows Services created
Any account passwords you supply are saved and protected by Windows itself (the same way it handles other passwords)
That is, there is no separate repository of data managed by AlwaysUp. And we rely on Windows to protect any settings we collect from manipulation or modification.
CRA Requirement #7: Minimize data collection
Don’t collect and process data unless it’s absolutely necessary
How we help you to comply
As mentioned before, we intentionally limit the data collected and stored by our applications. And none of our products collect personal data.
That’s by design. We simply don’t want the responsibilities, requirements and headaches that come with collecting unnecessary information!
CRA Requirement #8: Protect essential functions
Employ methods to survive cyber attacks and other onslaughts
How we help you to comply
AlwaysUp and Service Protector are all about protecting essential functions. It’s not a stretch to say that simply using our products demonstrates your commitment to surviving crashes, human error, and other exceptions — just as the CRA demands.
Our software can also help you protect your systems from cyber attacks. For example, you can have AlwaysUp run your security monitoring components 24/7. And in that scenario, even if a hacker kills your application, AlwaysUp will be there to restart protection in a few seconds.
CRA Requirement #9: Limit attack surfaces
Minimize interfaces and other points of vulnerability when designing and implementing software
How we help you to comply
Security always has a front row seat whenever we design and build software.
For example, with AlwaysUp:
There are no open/listening TCP/IP ports
All communication is encrypted in transit
Program settings (including passwords) are stored by the operating system and accessed via Windows API functions
Only administrators can run the program
CRA Requirement #10: Logging & monitoring
Implement event logging and reporting
How we help you to comply
Both AlwaysUp and Service Protector write detailed, timestamped messages to the Windows Event Logs. If you’re curious, this page documents the information, errors and warnings reported by AlwaysUp.
Specifically, AlwaysUp writes entries to the Application event log. You can browse those records using the Event Viewer:
It’s important to realize that because our products support standard Windows logging methods, customers can easily feed those records into a SIEM or other central repository. As such, our logging and reporting is readily compatible with professional, enterprise systems.
Hopefully this article demonstrates our commitment to the principles behind the Cyber Resilience Act. Needless to say, we’ll continue to monitor the emerging regulation and react to any amendments introduced before 2027.
Posted onDecember 8, 2025 (Revised December 21, 2025)
ISO 27001 is an internationally recognized information security standard. It focuses on three core principles — confidentiality, integrity and availability (CIA) — and provides detailed guidance to help you keep your company’s information assets safe from bad actors, data breaches, extended downtime and much more.
AlwaysUp is our professional software that runs any application as a Windows Service. Today, many of the Fortune 500 companies rely on AlwaysUp to keep their key software running 24/7. And because every single one of those companies obsesses about information security, we do too. Indeed, we design and build all our software atop CIA principles.
Does your company operate an information security management system (ISMS) based on ISO 27001? If so, here are a five important Annex A controls that AlwaysUp will help you implement.
Annex A 5.15: Access Control
ISO 27001 Annex A 5.15 focuses on controlling access to information assets. Its objective is to ensure that employees only have access to the information they need to perform their duties. In other words, Annex A 5.15 is all about enforcing the principle of least privilege.
How AlwaysUp helps you control access
#1: Only admins can run AlwaysUp
AlwaysUp is restricted to administrators only. A standard user without admin rights cannot start the program on his own.
If a standard user attempts to start AlwaysUp, Windows prompts for admin credentials:
That important safeguard prevents untrusted (or untrained) individuals from updating your critical applications.
#2: You can restrict access to your AlwaysUp Windows Services
After you install your program as a service with AlwaysUp, you have the power to enforce who can start, stop, restart or edit the service.
That capability is available by selecting Advanced > Service Security Settings from the Application menu:
From there, it’s easy for you to specify what each user can do. For example, here’s how we allow Hazel Jones to start or stop the service, but not to modify or delete it:
#3: You can run your applications without admin rights
By default, Windows Services operate with full rights. There’s no User Account Control (UAC) in place, where an administrator can run an application without elevated rights. And that can violate the principle of least privilege.
AlwaysUp fixes that shortcoming. With AlwaysUp, you’re able to launch your application in the context of a full blown administrator yet have those powerful admin rights removed when your application runs. That’s a sure fire way to limit what your application is able to do — and protect your systems.
The option to run your application with reduced rights is available on the Logon tab:
Annex A 5.30: Readiness for Business Continuity
Annex A 5.30 is an organizational control focusing on business resilience. It aims to prepare you to survive the inevitable operational bumps in the road as you serve your customers.
AlwaysUp is designed to be a core component of your resilience plan. By quickly detecting failures and automatically restarting your mission-critical software, AlwaysUp reduces interruptions and downtime. And that’s great for your Recovery Time Objective (RTO).
Annex A 8.9: Configuration Management
Annex A 8.9 emphasizes the need for standardized configurations in IT operations.
As ISO 27001 points out, relying on tested, predefined settings instead of having staff constantly “reinventing the wheel” is a guaranteed way to reduce risk, improve reliability and increase oversight.
How AlwaysUp helps with configuration management
#1: We’ve created guides for hundreds of applications
Did you know that our team has tested and documented how to set up over 160 popular programs with AlwaysUp? If you’re running one of those apps as a Windows Service, all you’ve got to do is follow our step-by-step instructions. There’s no need for you to re-engineer on your own.
#2: You can easily export and import standard configurations
Once you’ve settled on a configuration that works for your application, you can export it to a file. And to re-create that application on a different computer, all you’ve got to do is import the file there.
With that approach, your team will deploy the same, standard AlwaysUp configurations every time — exactly what Annex A 8.9 encourages.
Annex A 8.15: Logging
ISO 27001 stresses the importance of logging in robust, resilient systems. As such, the standard includes Annex A 8.15 to drive the point home.
AlwaysUp is aligned with the recommendations of Annex A 8.15. As it runs your programs as services, AlwaysUp writes key information to the Windows Event Logs — the standard, centralized location where applications report important software and hardware events.
Specifically, AlwaysUp writes entries to the Application event log. You can browse those records using the Event Viewer:
The bottom line is that you can rely on detailed logging from AlwaysUp when investigating incidents and providing root cause analysis to your management team.
Annex A 8.16: Monitoring Activities
As described in ISO 27001 Annex A 8.16, organizations should proactively and reactively monitor IT and security operations to prevent incidents, detect anomalies, and ensure compliance.
AlwaysUp fulfills those obligations by closely monitoring your business-critical applications and shouting whenever they misbehave.
For example, AlwaysUp can detect when your application consumes too much memory, CPU or resource handles. And email from AlwaysUp will quickly alert you of the trouble, as it did here when the “Appointment Server” stopped responding to network requests:
With those details in hand, you’ll be well positioned to investigate and determine if the situation requires your attention. For instance, is your application demanding too much CPU because it’s overloaded? Or is your network the victim of a denial-of-service attack?
In any case, AlwaysUp’s monitoring and early warning systems allow you to quickly intervene and prevent incidents before they occur. And that strengthens your security posture.
So that’s a quick look at how AlwaysUp aligns with your security best practices. Rest assured that our company will continue to follow bedrock ISO 27001 principles as we improve our software.
Finally, best of luck with your information security program! Please be sure to get in touch if you need any help with documentation or implementation.
As a workaround for recent problems running OneDrive in Session 0, we configured AlwaysUp to automatically log in and start OneDrive in the new session. I followed your instructions but it’s not working because, as far as I can see, Windows isn’t logging in automatically. What could be going wrong with auto login and how can I fix it?
— Amy
Hi Amy, thanks for reaching out.
We’re not surprised that you’ve run into trouble. For some reason, automatic login (“autologin”) remains a poorly documented feature of Windows. It’s available, but Microsoft doesn’t make it particularly easy to use.
In any case, let’s review the five most likely places where things could be going off the rails with autologin.
Problem #1: Automatic login isn’t set up properly
Autologin only works if you’ve provided a known user name and its associated password. Are you positive that you entered the correct password? If you haven’t, automatic login will silently fail.
How to fix it
Download Microsoft’s free, standalone Autologon utility and use it to set up automatic login.
It’s super easy to use. Enter the user name, domain (if applicable) and password and Autologon will save them all in the Windows registry:
And when you click the Enable button, Autologon will verify your credentials and alert you if you put in a bad password:
That check will eliminate some head scratching later on if you’re prone to fat-finger situations. 🙂
Note that Autologon encrypts your password in the registry. But even though that’s a good line of defense, the password may remain vulnerable to determined administrators. For more on that, please review this post discussing security issues related to automatic login.
Problem #2: Your password changed
When you set up automatic login, your user name, domain and password are all saved in the registry. If you subsequently change your password, autologin will fail because Windows keeps using your old password.
How to fix it
Simply re-run the Autologon utility and enter your new password. Autologon will save your updated password, encrypted.
Problem #3: A local or group policy is preventing automatic log on
Even though you may have set up automatic login using Autologon or another method, your intentions may be at odds with the administrator who manages your machine. In fact, that’s extremely likely if your computer is part of a corporate Windows domain.
You see, Windows enforces your company’s policies and practices through group policies — centrally-managed restrictions that apply to all company computers. And those all-powerful policies can curtail almost any feature, including autologin.
How to fix it
If you think that your local settings are being countermanded by a group policy, it’s best to raise the issue with your system/domain administrator. They can make the necessary changes to permit auto-login — but only if they agree with what you’re trying to do. Be prepared to discuss security.
Here are some resources that may be helpful as you’re working with your administrator:
Do you have to acknowledge a legal notice or disclaimer when you sign into your computer? It may look like this:
That interactive Logon Banner — which requires you to click a button whenever you sign in — will definitely hold up automatic login.
In fact, Microsoft says exactly that on this page:
This registry change does not work if the Logon Banner value is defined on the server either by a Group Policy object (GPO) or by a local policy. When the policy is changed so that it does not affect the computer, the autologon feature works as expected.
Problem #5: AlwaysUp isn’t starting your application after autologin
It doesn’t seem this way from what you describe, but is it possible that automatic login succeeds and AlwaysUp fails to launch OneDrive in the newly-created session? That may be happening for a couple of reasons.
Reason number one is that you’re not giving Windows enough time to start AlwaysUp. For instance, if you’ve instructed AlwaysUp to start your application Automatically but shortly after the computer boots, it may take up to 5 minutes for your application to start running. If you log in too soon, you may get the impression that “nothing’s working.”
And beyond a slow start, it’s quite possible that AlwaysUp is running into a problem finding the new login session or cannot launch your program on the desktop. If any of those oddities occur, AlwaysUp will note the problem in the Windows Event Logs. Select Application > Report Activity > Past Week to generate a full report in your web browser:
How to fix it
First, please be patient. Automatic login may take longer than you think.
Second, review the AlwaysUp activity report for clues and take action on what you find. This page documents common errors and warnings. Please be sure to get in touch with our technical support team if you need help.
I installed AlwaysUp on August 8 and set up Google Drive for desktop 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”.
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.
Do you have any idea what could be causing this?
— Allen
Hi Allen. Sorry to hear of the trouble!
To investigate, we jumped onto our Windows Server 2025 machine and installed Google Drive for desktop (using the Application Advisor). When we launched Google Drive, we saw exactly what you did. Drive exited quickly after AlwaysUp started it:
We’d never seen that fruitless “flapping” with Google Drive before! It was time to roll up our sleeves…
The problem: Google Drive uses WebView2, which has issues
Our investigation continued with Microsoft’s superb Process Explorer. That free utility allowed us to examine how Google Drive works — both inside and out — when it’s started normally on your desktop.
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 to do its work:
What’s unusual is that some of the applications started by Drive are not created by Google. And even stranger yet, msedgewebview2.exe is from Microsoft — a component of their Edge web browser:
According to the release notes, Google Drive for desktop introduced Microsoft’s WebView2 framework in the August 18, 2025 release (version 113.0):
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?
Anyway, curiosity piqued, we switched back to running Google Drive with AlwaysUp. In that setup, we consistently observed the following disappointing pattern:
AlwaysUp starts launch.bat (the batch file that starts Google Drive for desktop).
The batch file spawns GoogleDriveFS.exe, the main Google Drive executable.
GoogleDriveFS.exe launches msedgewebview2.exe.
msedgewebview2.exe starts 5 more copies of itself, lingers for a couple of seconds then exits.
GoogleDriveFS.exe restarts msedgewebview2.exe up to 5 times, each time ending in failure.
GoogleDriveFS.exe eventually gives up and closes.
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.
It was time to dig into WebView2…
What’s Microsoft Edge WebView2 anyway?
One of our AI overlords (Gemini) puts it this way:
Microsoft Edge WebView2 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.
Developers use the WebView2 control to display web content directly within a native app, whether it’s a Win32, .NET, WinRT, or other application.
Many desktop applications use WebView2 to display web-based content, such as in-app browsers, ads, or rich text.
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:
What’s wrong with using WebView2?
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.
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?
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:
Yet WebView2 didn’t complain. Google Drive (and WebView2) started and synchronized files as normal.
So WebView2 can run elevated. But then why did a Microsoft employee say the opposite?
We believe he’s mostly right, but the situation is nuanced. Here’s why.
Of the 6 processes that WebView2 launched, 3 of them were created with full admin rights:
But 2 of them were launched without admin rights. One was even run at the lowest level possible — untrusted:
So, as part of normal operation, the security-conscious WebView2 launches some sub-components with maximum rights and others with minimal or zero rights.
And for some reason, particularly in the context of a Windows Service, WebView2 cannot start those limited, sandboxed sub-processes with minimal powers.
We think the problem has to do with the deeply technical subject of UAC and split tokens. 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.
Time to focus on potential workarounds instead.
The solution: Run Google Drive in a standard Windows account
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 box on the Logon tab:
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, and that’s what AlwaysUp creates as it strips away admin permissions. More technical weeds and another dead end.
What about running Google Drive in a “true” non-admin account?
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:
Next, we logged in as Hazel, installed Google Drive for desktop and ensured that it worked well for Hazel.
Finally, we returned to AlwaysUp and switched the account on the Logon tab to Hazel:
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:
Furthermore, the “G” drive (where Google Drive mounts its cloud file system) was accessible to Hazel. We confirmed that from a standard command prompt:
So 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.
(888) 881-CORE
I work for a large technology company based in Germany. Last year, we bought an 
