How to run WebView2 Application on system startup when UAC is enabled

Question

How to run WebView2 Application on system startup when UAC is enabled

ajay.shinde 20

We have developed a C++ application which starts on system startup. This is configured through 'Winlogon/shell' registry value. UAC is configured as enable on the system.
CPP application on launch spawns a C#,WebView2 application. However it fails to execute or shows white screen issues. We understand this is due to running WebView2 application in admin/privileged mode.
We can not create new user with standard privileges or we can not use 'explorer.exe' that establishes runtime environment for WebView2 application. These are our environment restrictions.
Through ShellLauncherV2 approach also we need new standard user available, thus it can not be used as well.

Request to please suggest an approach where we can spawn C#,WebView2 application safely without any issue.

Thanks in advance.

Ajay Shinde

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Damien Pham (WICLOUD CORPORATION) 2,055 Microsoft External Staff Moderator

Hello @ajay.shinde ,

For this design, the supported direction is to keep the WebView2-hosting C# process in the interactive user's standard, non-elevated security context. The WebView2 security guidance recommends hosting WebView2 in a standard, non-elevated user-integrity process, and User Account Control creates both a standard user access token and an administrator access token when an administrator signs in. So with UAC enabled, you should not need a separate standard user account only to obtain a standard token.

The practical approach is: if the C++ Winlogon\Shell launcher is already running with the standard token, start the C# WebView2 process with normal CreateProcess. If the launcher is running with the elevated administrator token, query the linked standard token with GetTokenInformation using TokenLinkedToken / TOKEN_LINKED_TOKEN, then start the WebView2 process with that real linked token using CreateProcessAsUser or CreateProcessWithTokenW. Avoid creating a hand-restricted token by stripping privileges or SIDs, because WebView2 uses a Chromium multi-process model and the runtime must be able to create its browser, renderer, and helper processes, as described in the WebView2 process model.

Also make sure the WebView2 process is launched in the interactive desktop/session and uses a writable per-user user data folder, for example under %LocalAppData%. If the app still shows a white screen after launching with the real linked standard token, the next useful data is the exact EnsureCoreWebView2Async / CoreWebView2InitializationCompleted exception and HRESULT, plus verbose webview2.log, because that will show whether msedgewebview2.exe is failing during environment/controller creation.

Hope this helps clarify things. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance or provide feedback.

Thank you.

ajay.shinde 20 Reputation points

2026-08-21T06:28:31.46+00:00

Hi @Damien Pham (WICLOUD CORPORATION)

We tried options suggested and observed CreateProcessAsUser or CreateProcessWithTokenW both failed.

It returned Error code 1346 ERROR_BAD_IMPERSONATION_LEVEL .

Please let us know if any more details are required. Thank you for the suggestions.
Damien Pham (WICLOUD CORPORATION) 2,055 Reputation points Microsoft External Staff Moderator

2026-08-21T06:56:31.7766667+00:00

Hello @ajay.shinde ,

Thanks for testing this and sharing the exact Win32 error.

ERROR_BAD_IMPERSONATION_LEVEL means that a required impersonation level was not provided, or the provided level is invalid, as listed in the Win32 system error codes. In this flow, that points to the token passed into process creation, before WebView2 initialization starts.

Please check the token preparation step before the WebView2 host launch. Both CreateProcessAsUser and CreateProcessWithTokenW document hToken as a primary token representing the user. If the handle you have is an impersonation token, convert it with DuplicateTokenEx, requesting TokenPrimary and using SecurityImpersonation or higher. Avoid SecurityIdentification, because the impersonation-level documentation says that level can identify the client but cannot impersonate it.

If it still returns 1346 after that, please share the token-preparation sequence and the GetLastError() result after GetTokenInformation(TokenLinkedToken), any DuplicateTokenEx call, and the final CreateProcessAsUser / CreateProcessWithTokenW call. Also please confirm the TokenType, TokenImpersonationLevel if applicable, TokenElevationType, and TokenSessionId values for the token passed into process creation. That should show whether the remaining issue is token type, impersonation level, or session/profile setup.
ajay.shinde 20 Reputation points

2026-08-24T09:40:12.3266667+00:00

Hello @Damien Pham (WICLOUD CORPORATION)

Thankyou for your inputs.

We tried using the DuplicateTokenEX() but it failed with Error: 1346. Later we tried Duplicating the Token from one of our non elevated exe and launched the webview Host application using that token, with this approach we are able to run the WebView Host exe as non elevated medium integrity application.

Now, the LoginScreen UI is loaded properly, however when this UI is closed and before the next UI appears, there is a complete white screen displayed for about 1-2 seconds. We have attached the verbose webview2.log file for your reference. webview2.log

Request to check and let us know in case any more details are required.

Best Regards,

Ajay Shinde
Damien Pham (WICLOUD CORPORATION) 2,055 Reputation points Microsoft External Staff Moderator

2026-08-24T10:26:02.79+00:00

Hello @ajay.shinde ,

Thanks for the update and for sharing the WebView2 verbose log.

The log is a good sign for the launch path: it shows the WebView2 Runtime starting, creating GPU/utility/renderer processes, creating the profile under C:\Users\saiprasad.balgoni\AppData\Local\WebView2\EBWebView\Default, and loading the local LoginScreen files such as AuthWebScreens/index.html, index.js, CSS, and fonts. I do not see the earlier pattern where WebView2 child processes fail to start.

For the remaining white screen between LoginScreen close and the next UI, I would treat this as the next WebView/navigation/lifecycle transition rather than the non-elevated launch/token problem. WebView2 uses a browser, renderer, and helper-process model as described in the WebView2 process model, and the same doc recommends using CoreWebView2.ProcessFailed for crashes or hangs. Please add logging around the close-to-next-screen transition for CoreWebView2.ProcessFailed, NavigationStarting, NavigationCompleted, and any host-side EnsureCoreWebView2Async / new environment or controller creation. The NavigationCompleted event should show whether the next page completes loading or stops with an error, and ProcessFailed should show if a WebView process exits unexpectedly or becomes unresponsive.

If possible, also capture the DevTools Console and Network output during the transition. Microsoft documents that WebView2 content can be debugged with Edge DevTools in the same way as a page in Edge, including by calling OpenDevToolsWindow when keyboard/context menu access is unavailable: Debug WebView2 apps with Microsoft Edge DevTools. Please share the next UI URL/source, NavigationCompleted.IsSuccess and WebErrorStatus, any ProcessFailed kind/reason/exit code, and whether the app disposes/recreates the WebView2 control or reuses the same environment/user data folder between the login UI and the next UI.If the next UI depends on remote API/auth/config calls, then a network/proxy/DNS delay is still possible. The current log shows some DNS/proxy/update-related messages, but they do not by themselves prove that the application UI is blocked on traffic. The most useful check would be DevTools Network output during the exact white-screen interval, including the request URL, status/error, and timing for any request started after LoginScreen closes.

Since the non-elevated startup launch is now working, it may be cleaner to track the remaining white-screen transition as a separate WebView2 UI/navigation issue with the transition logs attached.

Thank you.
ajay.shinde 20 Reputation points

2026-08-26T06:36:36.78+00:00
Hi @Damien Pham (WICLOUD CORPORATION)

The next UI is not a part of this WebView host application, it is from a different application.

The sequence is as below,

After successful login, the login UI closes using loginScreen.close().

Inside OnWinodwClosed(),

Next UI which is a part of another exe is invoked.

WebView2.dispose() is called.

Though we have subscribed to ProcessFailed, this function is not hit, looks like it did not fail. The white screen appears for 1-2seconds between these two UIs.

We tried executing DevTools as suggested. The DevToolConsole closes as soon as the login screen is closed. We have attached the screenshot of the same before the login UI is closed.

As suggested since the non-elevated startup launch is now working, we can close this thread. I will open new question and inform you accordingly. Thank you.