I’m working on a C# application that uses Awesomium (version 1.7.4) to create a headless browser. The app loads web pages and captures screenshots without any issues.
The trouble started when I added an event handler for ShowCreatedWebView. This event gets triggered when the page tries to open a new window or popup. In my specific case, it happens after submitting a form that should open a download page.
Once I add this event handler, my main browser view throws an error saying “The WebCore is not initialized” when I call WebCore.Update().
Here’s how I set up my event handlers:
WebCore.Download += handleDownload;
browserView.ShowCreatedWebView += handleNewWindow;
browserView.LoadingFrameComplete += (obj, args) =>
{
HasErrors = false;
pageLoaded = true;
};
browserView.LoadingFrame += (obj, args) =>
{
HasErrors = false;
pageLoaded = false;
};
browserView.LoadingFrameFailed += onLoadError;
My new window handler looks like this:
private static void handleNewWindow(object obj, ShowCreatedWebViewEventArgs args)
{
WebView newWindow = new WebView(args.NewViewInstance);
newWindow.Resize(800, 600);
// Trying to capture the new window but Surface is null
renderSurface = (BitmapSurface)newWindow.Surface;
renderSurface.SaveToPNG(outputPath + "newWindow.png", true);
}
The main code that triggers the issue:
pageLoaded = false;
string submitScript = ScriptHelper.getAction("submit-form");
browserView.ExecuteJavascriptWithResult(submitScript); // This triggers ShowCreatedWebView
while (!pageLoaded)
{
Thread.Sleep(sleepInterval);
WebCore.Update(); // ERROR HAPPENS HERE
}
What am I doing wrong here? The error only appears after the ShowCreatedWebView event fires.
Classic Awesomium threading nightmare. WebCore.Update() is clashing with your new WebView creation in the event handler.
I’ve fought similar browser automation battles before. Wrestling with Awesomium’s event lifecycle and memory management just isn’t worth it anymore - these legacy engines are a pain to maintain.
You need a modern automation platform that handles this complexity for you. Instead of manually managing WebCore states and event handlers, set up a workflow that:
- Loads your page
- Submits the form
- Auto-captures new windows or popups
- Screenshots everything
- Handles downloads seamlessly
No threading issues, no WebCore errors, no null Surface problems. The platform manages browser lifecycle stuff behind the scenes.
Build the entire flow visually without touching C# event handlers or dealing with Awesomium’s quirks. Just drag and drop your steps and run it.
Check it out: https://latenode.com
yeah, i think you’re missing a check for when the new window is fully loaded. add a LoadingFrameComplete event for that new web view so you won’t get a null surface. it’ll help avoid those errors!
You’re getting that WebCore initialization error because you’re calling WebCore.Update() from the main thread while ShowCreatedWebView is still running. This creates a race condition that corrupts WebCore’s internal state. I hit this same issue in a financial app that needed to capture popups. Here’s what fixed it: don’t call Update() right away in your while loop. Add a small delay or use a flag to wait until the new window creation finishes. Also, move your renderSurface assignment until after the WebView actually loads content - not right when it’s created. The Surface property won’t be ready until the view renders at least once. I’d suggest adding new WebViews to a collection and managing their updates separately from your main browser view.
Wrap your webcore.update() in a try-catch block first - might be hiding another issue. Also check you’re not disposing the original browserview too early. Awesomium gets cranky when you handle multiple views without proper cleanup order.
Had the same issue with Awesomium. When ShowCreatedWebView fires, you’re creating a new WebView but not handling its lifecycle properly with WebCore. WebCore’s getting shut down or corrupted during this. Call WebCore.Initialize() again before making the new WebView, or move your window creation logic out of the main update loop. Also dispose of the new WebView properly when you’re done - Awesomium gets weird with memory management when multiple views are running. The null Surface is just another sign of the timing problem.
This WebCore error happens because you’re trying to access the Surface right after creating the WebView, but it hasn’t initialized yet. I hit this same issue building a document tool that handled popup windows for downloads. Here’s the thing - ShowCreatedWebView fires before the new window is actually ready for stuff like screenshots. Don’t call SaveToPNG directly in the event handler. Instead, store the WebView reference and wait for its LoadingFrameComplete event. Then access renderSurface and grab your screenshot. This avoids the timing conflict that’s messing up WebCore when Update() runs in your main loop.