Debugging Consistent Blank App On Remote Machine

[AlbinoDrought]

Hello,

I have an app written in Wails. It works great!

Unfortunately, on one otherwise-regular Windows 10 laptop, the app opens to a blank screen. The Go code is running successfully and the OnStartup event is received. I'm not able to reproduce this issue locally, and I don't have direct access to the problematic machine.

At the time of writing, this issue is still unresolved. Any tips are appreciated.

Here's what I've done that hasn't solved the issue:

• Updated from 2.3.0 to 2.4.1 to avoid CreateWebResourceResponse Error: An attempt was made to reference a token that does not exist. (this message was appearing in logs)

Here's what I've done that hasn't been tested yet:

• Enable debug logging
• Log unhandled UI errors

import { LogError } from '../wailsjs/runtime/runtime';

if (window) {
  window.onunhandledrejection = (event) => {
    LogError(`UI.OnUnhandledRejection: ${event}`);
  };
  window.onerror = (event, source, lineno, colno, error) => {
    LogError(`UI.OnError: ${event} / ${source} / ${lineno} / ${colno} / ${error}`);
  };
}

Here's what I haven't tried yet:

• Try the old Webview2Loader
• Anything to do with possible messages in event viewer (possibly related: Webview2 not loading in both UWP and Winui3 MicrosoftEdge/WebView2Feedback#3318 (comment) )

[stffabi]

Those are annoying to identify. Good candidates are those you already mentioned

• Try the old Webview2Loader
• Event-Viewer
• Increase all log-levels to debug.

Another one if you trust the user of the Laptop is to provide a debug build --debug and take a look into the "inspector" console and network output.

[stffabi]

There are a couple exposed options in windows/frontend.go@setupChromium already. I'm not sure how common this RendererCodeIntegrity issue is. Would it be reasonable to allow direct modifications to disableFeatues and chromium.AdditionalBrowserArgs?

I'm personally hesitant to just open up those internal properties to everyone, since those might have a security impact on the app as @leaanthony already mentioned. As of this I would rather see specific options for specific features there, so in your case an option DisableRendererCodeIntegrity with clear information what the impacts are when using this flag.
So we would have at least a little bit of control what people are going to use out there.

If so, I can submit a PR. Otherwise, I'm fine maintaining this patch on an internal fork.

Would be awesome to provide a PR since it seems like other people are also suffering from this issue. If you don't have time, just let me know, I can then provide the PR. Thanks again for looking so intensively into this issue.

(it seems like this issue also impacts Tauri, but in this user's screenshot a Chromium (?) error message is shown: tauri-apps/tauri#4659 (comment) )

Yeah, that's really bad in our case the error is not shown. I would love to find a fix for that one, since we had reports of blank screens from other users, which might be the same issue. So a clear error message would be awesome. Do you know which software caused the issue so we could maybe, if it's an antivirus program try that in a VM?

[AlbinoDrought]

I understand the caution around exposing internal properties.

I have not gotten the user to travel to Event Viewer - they've been patient so far, but that can only last so many trials 😅 - so I'm not sure the exact error causing this issue. If anyone has sample code to programmatically grab these from the "Event Viewer log", I can try it out.

It sounds like RendererCodeIntegrity should trigger when any non-MS DLL is injected into the renderer process. This article lists some proprietary applications that used to trigger this error (none of them have free trials). I agree that a free way to reproduce this would be great.

(I will try to reply with more details before 2023-04-27)

[stffabi]

I tried to reproduce it by removing signatures from Microsoft loaded DLLs but that didn't work 😞 ...

[stffabi]

@AlbinoDrought I'm trying to understand why we don't show the message and the only thing that would explain this is if the navigationCompleted (from webview which corresponds to OnDomReady in wails) event doesn't fire. Which seems plausible, but then the window should also not be shown but in your case you are seeing the Window. Do you probably do a runtime.WindowShow in your app, for example in OnStartup?

[AlbinoDrought]

Hello,

Unfortunately I haven't been able to reproduce this RendererCodeIntegrity issue either. My user-mode injections into the msedgewebview2.exe process with --type=renderer fail (WriteProcessMemory fails).

I doubt this is what happened in this user's case, but one bad injection attempt on a non-renderer process caused the msedgewebview2.exe process tree to crash. This can be "reproduced" by just killing the msedgewebview2.exe child processes in task manager. The GUI's background colour remains:

Do you probably do a runtime.WindowShow in your app, for example in OnStartup?

In OnStartup, we register a semaphore to prevent multiple instances from running. When another instance starts:

• The first instance calls runtime.WindowShow(ctx)
• The other instance fails with an instance already running error

It's possible this happened here, but the instance already running error does not appear in this user's logs.

[stffabi]

Thanks for this feedback, that hardens my assumptions.

I've opened a PR #2627 which adds the flag to disable the integrity checks. Furthermore Wails now handles WebView2 process crashes. If the main process crashes and we can't recover from that, an error message is shown and the application is closed after clicking ok. If the renderer process fails and a chromium error page is shown, we now make sure to show the window and the webview2 control.

Would it be possible for you @AlbinoDrought to give that a try? That would be awesome.

[AlbinoDrought]

Works great, cheers!

[AlbinoDrought]

Unfortunately:

• The flag to disable integrity checks has been removed from Edge WebView2 v118+
• We still have customers running versions of Symantec Endpoint Protection that trigger this issue. The problematic DLL is at C:\Windows\System32\SYSFER.DLL. More unfortunately, the problematic Symantec Endpoint Protection version (< 14.2) might not even be EOL...
• An above patch attempts to handle this error and show the expected WebView2 error page. However, impacted customers do not end up seeing this page. I think it's because "COREWEBVIEW2_PROCESS_FAILED_KIND_RENDER_PROCESS_EXITED: [...] A new render process is created automatically and navigated to an error page.", but the new render process probably crashes with the same error.

Customer SEP Alert	Customer Blank Window

Approximate log: (kind 1 == COREWEBVIEW2_PROCESS_FAILED_KIND_RENDER_PROCESS_EXITED)

time="2024-10-01T12:00:10-00:00" level=info msg="main()"
time="2024-10-01T12:00:12-00:00" level=info msg="wails.OnStartup()"
time="2024-10-01T12:00:12-00:00" level=error msg="WebVie2wProcess failed with kind 1" a=app 
time="2024-10-01T12:00:12-00:00" level=info msg="wails.OnDomReady()" 
time="2024-10-01T12:00:12-00:00" level=error msg="WebVie2wProcess failed with kind 1" a=app 
time="2024-10-01T12:02:13-00:00" level=info msg="wails.Run() == nil, exiting" 

This is an oddball issue. Because it is difficult to exactly reproduce, it is very frustrating to solve. I would like to clarify that I am reopening this discussion to track my own effort on this issue: I don't expect Wails contributors to expend effort on this when it doesn't impact them or their wider user base.

My current plan of attack:

• Bubble failures from chromium.ProcessFailedCallback to the parent non-Wails application, to allow custom handling
• Use the above in our application to show errors to the user outside of WebView2, if it's determined to be a code integrity issue
• If I can reproduce the issue exactly (by installing and configuring an impacted version of SEP), I'll play with the upstream patch until the WebView2 window successfully renders a native code integrity error message, and contribute this upstream

[AlbinoDrought]

Here's an example of how I will bubble failures:

diff --git a/v2/internal/frontend/desktop/windows/frontend.go b/v2/internal/frontend/desktop/windows/frontend.go
index 806f4ffb..1156c3c9 100644
--- a/v2/internal/frontend/desktop/windows/frontend.go
+++ b/v2/internal/frontend/desktop/windows/frontend.go
@@ -518,6 +518,14 @@ func (f *Frontend) setupChromium() {
 				f.ShowWindow()
 			}
 		}
+
+		if f.frontendOptions.OnChromiumProcessFailed != nil {
+			message := f.frontendOptions.OnChromiumProcessFailed(args)
+			if message != "" {
+				winc.Errorf(f.mainWindow, message)
+				os.Exit(-1)
+			}
+		}
 	}
 
 	chromium.Embed(f.mainWindow.Handle())
diff --git a/v2/pkg/options/options.go b/v2/pkg/options/options.go
index 282a2569..afdb5306 100644
--- a/v2/pkg/options/options.go
+++ b/v2/pkg/options/options.go
@@ -86,6 +86,9 @@ type App struct {
 
 	SingleInstanceLock *SingleInstanceLock
 
+	// args == ICoreWebView2ProcessFailedEventArgs
+	OnChromiumProcessFailed func(args interface{}) string
+
 	Windows *windows.Options
 	Mac     *mac.Options
 	Linux   *linux.Options

[AlbinoDrought]

Here's pseudocode of how I would handle this callback in our application:

onChromiumProcessFailedTrackedCalls := int32(0)

wails.Run(&options.App{
	OnChromiumProcessFailed: func (unknown interface{}) string {
		if ourApplicationRenderedSuccessfullyAtLeastOnce { // imaginary flag set by our application via UI JS --RPC--> backend after application is rendered (UI is never rendered for impacted users)
			return ""
		}

		args, ok := unknown.(*edge.ICoreWebView2ProcessFailedEventArgs)
		if !ok {
			return ""
		}

		kind, err := args.GetProcessFailedKind()
		if err != nil {
			return ""
		}

		if kind != edge.COREWEBVIEW2_PROCESS_FAILED_KIND_RENDER_PROCESS_EXITED {
			return ""
		}

		calls := atomic.AddInt32(&onChromiumProcessFailedTrackedCalls, 1)

		if calls < 2 { // must fail on start and then again when trying to render the error page (assumed)
			return ""
		}

		// text taken from https://github.com/MicrosoftEdge/WebView2Feedback/blob/main/diagnostics/compatibility_problem.png
		return strings.Join([]string{
			fmt.Sprintf("An incompatible piece of software attempted to load along with %v.", "this application"),
			"This can be caused by malware, though it's usually caused by a program that is out-of-date.",
			"We recommend that you have the latest version of that program installed,",
			"and that your antimalware software is running and up-to-date.",
		}, " ")
	},
})

Of course, this code is unlikely to work for the Wails audience at large, but something along the same lines may make sense (if we experience COREWEBVIEW2_PROCESS_FAILED_KIND_RENDER_PROCESS_EXITED -> try to show the error page -> experience COREWEBVIEW2_PROCESS_FAILED_KIND_RENDER_PROCESS_EXITED again, assume nothing can be rendered and fall back to native dialogs)