«Paused» Chrome profile - Sign in again

Mr.X

Member
Staff member
Sandboxie-Plus v1.16.8
Windows 10
Google Chrome 143.0.7499.110 installed (non-portable) on the host (download msi installer here)
Chrome profile is always signed in

Starting chrome in a:
• Red box: profile is Paused asking to Sign in again.
r.png

• Orange box: profile is Paused asking to Sign in again.
o.png

• Yellow box: profile is signed in as expected.
y.png


All chrome's services stopped and disabled, as I always do.
serv.png


All was good until I installed this Chrome recent/latest version.
:mad:
 
Last edited:
The only good thing is that it appeared after an update of Chrome and not after you updated Sandboxie-Plus or both.

Did the latest Chrome update change something about how profile information are stored? I am not sure, if I have the correct change log, as I don't see something being mentioned, but maybe it is no user facing change and therefore not mentioned.

If only the red box was unable to use the profile normally, it should mean that there is a resource that it needs to access, what is not allowed in the red box, but as it is occurring in the orange box, something else is "wrong".

Are those three different boxes? Do they have the same settings, apart from what makes them red and orange boxes?
 
Chrome 142 changed something:

Simplified and Consolidated Version of Sign-in and Sync Experience: Chrome sync is no longer shown as a separate feature in Chrome settings page or elsewhere. Users can now sign-in to Chrome to use and save browsing data such as bookmarks, passwords, etc in their Google Account.

So it could have shown up at this point. It seems unlikely that you skipped 142.
 
Do you know the syntax to read the whole registry?
Nope.

How to create a NormalKeyPath for these lines (Trace log):

NormalKeyPath=full path of registry goes here. This will apply to all binaries.
NormalKeyPath=program.exe, full path of registry. This will apply to "program.exe"
NormalKeyPath=!program.exe, full path of registry. This will apply to all binaries, "program.exe" is excluded

Code:
NormalKeyPath=HKEY_LOCAL_MACHINE\SOFTWARE\7-Zip
NormalKeyPath=HKEY_CURRENT_USER\Software\7-zip

For example. Depending on which key it refers to.

Code:
NormalKeyPath=HKEY_USERS\.DEFAULT
NormalKeyPath=HKEY_USERS\S-1-5-7

Match what you have asked for.
 
Using a red box yesterday, I tried to allow access to these resources without success:

Trace Log
Code:
|Type|     |Status|   |Count|   |Value|                                                                                                 

Ipc        X          58        $:explorer.exe                                                                                          
Ipc        X          456       \Device                                                                                                 
Ipc        X          18        \Device\00000022                                                                                        
Ipc        X          21        \Device\HarddiskVolume3                                                                                 
File       X          535       \Device\HarddiskVolume3\                                                                                
File       X          18        \Device\HarddiskVolume3\ProgramData\                                                                    
File       X          3         \Device\HarddiskVolume3\ProgramData\Intel                                                               
File       X          3         \Device\HarddiskVolume3\ProgramData\USOShared\                                                          
File       X          6         \Device\HarddiskVolume3\ProgramData\USOShared\Logs\                                                     
File       X          6         \Device\HarddiskVolume5\                                                                                
File       X          1         \device\mup\                                                                                            
Ipc        X          6         \Device\USBPDO-0                                                                                        
Ipc        X          2         \Device\USBPDO-4                                                                                        
Key        X          28        \REGISTRY\User\.Default                                                                                 
Key        X          28        \REGISTRY\USER\S-1-5-100-2826866237-1938905013-802508159-3314461274-2197435908                          
Key        X          3         \REGISTRY\USER\S-1-5-21-1009946359-284503068-744831232-1000_Classes\Local Settings\MuiCache\106\52C64B7E
WinClass   X          12        ApplicationManager_DesktopShellWindow                                                                   
WinClass   X          6         Chrome_MessageWindow                                                                                    
RtClass    X          3         Windows.UI.Notifications.ToastNotificationManager                                                       
ComClass   X          68        {4991D34B-80A1-4291-83B6-3328366B9097} Background Intelligent Transfer Control Class 1.0



I struggle to write (syntax) the proper lines, obviously.
 
If the same issue appears in the orange box, it is unlikely to be resolved by opening the FilePath or KeyPath. In that case, try disabling the following settings one at a time and check whether the issue is resolved:

Remove:
INI:
UseSecurityMode=y

Test these (y -> n):
INI:
SysCallLockDown=y
RestrictDevices=y
DropAdminRights=y



I wonder why sbie handles it that way.

The \REGISTRY\User maps to HKEY_USERS, not HKEY_CURRENT_USER.
\REGISTRY\User\.Default represents the default user profile, whereas HKEY_CURRENT_USER is simply a per-process alias that points to one specific SID under HKEY_USERS for the currently logged-on user.
 
Which of the following settings does not trigger the issue?

# 1
Code:
UseSecurityMode=n
SysCallLockDown=n
RestrictDevices=y
DropAdminRights=y
UseRuleSpecificity=y

# 2
Code:
UseSecurityMode=n
SysCallLockDown=n
RestrictDevices=n
DropAdminRights=y
UseRuleSpecificity=y

# 3
Code:
UseSecurityMode=n
SysCallLockDown=n
RestrictDevices=n
DropAdminRights=n
UseRuleSpecificity=y

# 4
Code:
UseSecurityMode=n
SysCallLockDown=y
RestrictDevices=y
DropAdminRights=y
UseRuleSpecificity=n

# 5
Code:
UseSecurityMode=n
SysCallLockDown=y
RestrictDevices=n
DropAdminRights=y
UseRuleSpecificity=n

# 6
Code:
UseSecurityMode=n
SysCallLockDown=n
RestrictDevices=n
DropAdminRights=y
UseRuleSpecificity=n
 
Last edited:
Based on these results, the problematic setting is clearly RestrictDevices=y.
The next step is to determine which specific device paths are triggering the issue. To do this, we should identify the exact \Device\xxx entry that causes the failure by using Trace Logging, focusing on entries that return a Closed status.

Since the issue also occurs on the orange box, the following default device paths are already not closed and should not be the focus of the investigation, unless you have custom device path rules:

Code:
\Device\Floppy*\*
\Device\CdRom*\*
\Device\HarddiskVolume*\*
\Device\Harddisk*\*




1. Use a minimal configuration with RestrictDevices=y.
2. Enable Trace Logging.
3. Filter the log output to show only entries with a closed status. (Type: File + Pipe + Ipc, Status: Closed)
Use Ctrl+F, search for \Device\, and disable highlighting so the results act as a filter rather than a visual marker.​
5. Launch and run the browser under this configuration.
6. Record the device entries that are reported as closed.
7. Redact any personal or sensitive paths and share the resulting entries with us for further analysis.
Select all (Ctrl+A) > Copy Row (Ctrl+C)​
 
There is not much actionable data here; if you can also share your full configuration, we can compare it against a known-good setup and narrow this down further.

Some notes on the entries you listed:

  • \Device\00000022 – I am not sure what this device corresponds to.
  • \Device\HarddiskVolumeX – These should not cause issues unless they are explicitly blocked.
  • \Device\mup\ – This setting has always been active, so it should not be a contributing factor.
  • \Device\USBPDO-x – These should not cause problems unless the data is actually located on a USB device; however, this is not fully certain and may need to be tested using NormalFilePath rules.
 
Is the issue reproducible using only the yellow box with RestrictDevices=y? Without any global or box-specific settings?
 
Is the issue reproducible using only the yellow box with RestrictDevices=y?
Yes it is.
Without any global or box-specific settings?
Yes, without any setting there. In fact, I uninstalled sbie removing custom settings and all. Then I did a completely new, from scratch, sbie installation.

Tnis is the ini I used for testing:
INI:
#
# Sandboxie configuration file
#

[GlobalSettings]
MarkOfTheWebBox=DefaultBox
DefaultBox=ChromeTestY

[UserSettings_36B00489]
SbieCtrl_AutoStartAgent=SandMan.exe -autorun
SbieCtrl_EnableAutoStart=y
BoxGrouping=:ChromeTestY

[ChromeTestY]
Template=OpenBluetooth
Template=SkipHook
Template=FileCopy
Template=qWave
Template=BlockPorts
Template=LingerPrograms
Template=AutoRecoverIgnore
ConfigLevel=10
BorderColor=#00FFFF,ttl
Enabled=y
BlockNetworkFiles=y
RecoverFolder=%{374DE290-123F-4565-9164-39C4925E467B}%
RecoverFolder=%Personal%
RecoverFolder=%Desktop%
RestrictDevices=y


And this is the line in Target field in the shortcut I customize to launch Chrome profiles:
"C:\Program Files\Sandboxie-Plus\Start.exe" /box:ChromeTestY "C:\Program Files\Google\Chrome\Application\chrome.exe" --profile-directory="NNNNNN"
 
Last edited:
"C:\Program Files\Sandboxie-Plus\Start.exe" /box:ChromeTestY "C:\Program Files\Google\Chrome\Application\chrome.exe" --profile-directory="NNNNNN"
One thing I should note, is that I use to change default names to a custom one. For instance, the profile named Default I use to change it to any other custom name like Roxanna or whatever.

Most likely, this has nothing to do at all but I thought it should be mentioned, who knows.
 
@DavidXanatos The issue turned out to be TPM-related. When we add the TPM device using a NormalFilePath entry (for example, \Device\000000XX), the “verify it’s you” issue is resolved.

However, the device number probably changes after a reboot, so a fixed \Device\000000XX entry cannot be used reliably. There is also no log entry explicitly identifying the TPM device.

For now, the only workable approach is to allow it generically using:

INI:
NormalFilePath=chrome.exe,\Device\000000??
 
Back
Top