Chrome Extensions Crash

bjm_ said:
fwiw ~ finally realized -- I need to disable Elevation Service before Relaunch
Click to expand...
I don't get it. It's well known we need to disable Elevation Service after installing chrome or right after updating chrome. However, in my case, since version 146, disabling doesn't work anymore.
 
Mr.X said:
I don't get it. It's well known we need to disable Elevation Service after installing chrome or right after updating chrome. However, in my case, since version 146, disabling doesn't work anymore.
Click to expand...
Yeah, today I manually updated Chrome (to 149)(on host) and the update process did not bork my Chrome profile.
I started with three Google Services at Disabled.
I opted Manual for Google Updater Service -> then I called Chrome internal updater.
At Relaunch -> I did not Relaunch.
I opted Disabled for Google Chrome Elevation Service -- which had changed to Manual.
Then I invoked Relaunch.
And now, I'm back to three Google Services at Disabled.
Google Updater Internal Service is always Disabled.
I only changed Google Updater Service to Manual .... to run Chrome internal updater.
Chrome internal updater run -- changes Elevation Service from Disabled to Manual and prepares Relaunch.
That's when I go back to Services and change Elevation Service from Manual to Disabled.
Then and only then-- I'll invoke Relaunch.

Previously, and for some time. I'd been invoking Relaunch and then changing Elevation Service from Manual to Disabled.
This was the first Chrome update in a while ... that I did not need to re-do my Chrome profile.
I'll try this update process flow with Edge (next update).
~ as always your mileage may vary ~
 
Last edited:
Didn't work for me. My Google chrome profiles are still running naked, i.e., unsandboxed. Actually, no big deal because I only visit Wilder's, email accounts, GDrive, MDL forums, this forum and that's it. Adventurous browsing is done in a portable Catsxp browser, and of course, in a very constrained sandbox.
 
Mr.X said:
Didn't work for me. My Google chrome profiles are still running naked [...]
Click to expand...
I should have explained. I run Chrome/Edge detached. I do not Sign In. I do not Sync.

Sandboxie operates through two distinct layers:
The App Layer (The Boxes): This is what you see in your Sandboxie UI. When it is empty, no isolated file writing or temporary session hosting is taking place.
The Driver Layer (The Kernel Driver): This is a low-level Windows system driver that boots up alongside your operating system. Even when your sandboxes are empty, this driver remains attached to the core Windows kernel. It acts like an active toll booth, continuously monitoring every process running on your PC—including native, unsandboxed apps like Chrome—to see if they are trying to communicate with or modify sandboxed spaces.

Because you do not sync to the cloud, Chrome relies entirely on a local Windows security file called the Local State file, which holds the decryption keys for your extensions and preferences.
The Update Trigger: You update Chrome normally outside the box. Chrome launches for the first time post-update and invokes its background Elevation Service to migrate its local encryption databases.
The Driver Block: Sandboxie's low-level kernel drivers (SboxDrv.sys), which are always running in your Windows background, monitor the process. The Chrome Elevation Service tries to execute deep system-level registry and cryptographic checks. Sandboxie blocks or hooks into this behavior because it looks like suspicious root-level activity.
The Panic Reset: Because the Elevation Service gets blocked or times out, Chrome's main process is suddenly locked out of its own Local State decryption file.
The Result: Chrome panics. It assumes your profile has been corrupted or maliciously altered, so it triggers a failsafe: it wipes the local layout and creates a blank, default profile to ensure the browser can safely boot.

When Chrome triggers its updated Elevation Service, that service attempts to execute deep, highly sensitive cryptographic handshakes directly with the Windows security subsystem.
Because Sandboxie’s driver is constantly filtering system calls in the background, it intercepts this deep system activity to inspect it. The driver doesn't necessarily block it maliciously; its mere presence introduces a tiny microsecond delay or hooks into the query. Chrome's security protocol detects this third-party interception, panics because it thinks a malware strain is trying to steal your encryption keys, and immediately builds a blank profile to protect your data.

Sandboxie (SboxDrv.sys) kernel drivers are designed to run silently in the deep background of Windows from the moment your computer boots up. Even if the Sandboxie application window is closed and you are launching Chrome natively on your normal desktop, that driver remains active, actively filtering and monitoring system-level cryptographic operations to protect the OS.
Because the driver is always awake, it instantly steps in when the Chrome installer forces the Elevation Service back to life, triggering the security conflict that panics Chrome into wiping your profile.

Even when sandboxes are completely empty, the Sandboxie driver is actively filtering all system calls to ensure no unauthorized process tampers with isolated memory spaces or system security. The driver intercepts Chrome’s deep cryptographic request to analyze it. It doesn't necessarily block the request, but it forces a hook into the process to inspect what the Elevation Service is doing.

Modern chromium browsers are incredibly sensitive to security. The moment Chrome's Elevation Service attempts its handshake and detects that Sandboxie's driver is attached to the process and watching the exchange, its anti-tamper mechanisms trigger a false positive.
Chrome assumes that a malicious third-party tool is intercepting its local decryption keys. To protect your data from what it perceives as an active attack, Chrome immediately terminates the secure handshake, rejects your local Secure Preferences and Web Data files, and generates a blank, default profile instead.

The driver is just doing its job to protect the core Windows kernel, and Chrome is overreacting to the driver's standard background monitoring. By disabling the Elevation Service before you relaunch, the browser never attempts those deep, sensitive system checks, the driver has nothing to intercept, and Chrome safely loads your normal correct profile.

AI sourced content may make mistakes
Click to expand...
 
Last edited:
Mr.X said:
That explains a lot about my issue. Thank you @bjm_
Click to expand...
Hello @Mr.X
Yeah, AI content explained a lot about my issue.
Do you run Chrome/Edge detached?
fwiw ~ Edge update to 149 (on host) worked okay with similar #24 (not exact) process flow. I did need edgeupate & edgeupdatem at Manual and I needed to call Services -> Refresh (a few times) to see Elevation Service change from Disabled to Manual. May be better to cycle Services page. I'll need to be cautious. I'll need to confirm Elevation Service is at Disabled (after internal update) before I opt Edge -> Restart.
as always your mileage may vary
 
Last edited:
bjm_ said:
Oh! then -- we're likely not similar issue.
Click to expand...
I asked AI about = "detached vs attached"
Being signed into Google Chrome with Sync enabled would likely reduce the impact of the event, but not necessarily prevent the underlying profile detachment/fallback behavior itself.

Important distinction:
  • Sync helps recovery/resilience
  • It does not necessarily stop Chromium from deciding:
    “I can’t safely attach to this profile right now.”
So if the updater/elevation/Sandboxie interaction still occurred, Chrome could still:
  • create “Person 1,”
  • temporarily ignore the real profile,
  • or launch against a fresh profile container.
However, with Sync enabled:
  • bookmarks would repopulate,
  • extensions could return,
  • passwords/settings/history might resync,
  • and the experience would feel less catastrophic.
Without Sync:
  • the event feels like total profile loss,
  • because everything depends solely on local profile integrity.
Another subtle point:
Chrome’s “Local State” file is important here.

Local State contains:
  • profile registry/mapping,
  • last active profile,
  • profile metadata,
  • some encryption-related preferences,
  • and profile association data.
If the update path temporarily confused or rewrote Local State, Chrome may:
  • lose track of the intended profile,
  • or create a new profile mapping even though the actual old profile data still exists.
Sync does not fully protect against that local mapping confusion.

So your detached/local-only setup probably made the symptom:
  • more visible,
  • more alarming,
  • and more manual to recover from.
But I would not say Sync would necessarily prevent the updater-triggered fallback itself. It mainly softens the aftermath.

AI sourced content may make mistakes
Click to expand...
Since, you're "Attached, signed in and syncing". Does your Chrome/Edge profile mostly fix itself?
 
Last edited:
fwiw ~ Elevation Service - Disabled before Restart -- partially satisfied Edge 149.0.4022.62 update
Note: Home and On startup were wiped -- Extensions were retained
 
You must log in or register to reply here.
Back
Top