Automatically deleting sandbox content always yields an error

[Vstory]

Describe what you noticed and did

If you set automatic deletion for any sandbox, it will fail to automatically delete. You must enter the maintenance page and restart with administrator privileges to delete it normally.

How often did you encounter it so far?

No response

Expected behavior

The automatic deletion works fine without my intervention.

Affected program

1.14.6

Download link

Not available

Where is the program located?

Not relevant to my request.

Did the program or any related process close unexpectedly?

No, not at all.

Crash dump

No response

What version of Sandboxie are you running now?

Sandboxie-Plus v1.14.6

Is it a new installation of Sandboxie?

I just updated Sandboxie from a previous version (I remember which one it is).

Is it a regression from previous versions?

No response

In which sandbox type you have this problem?

All sandbox types (I tried them all).

Can you reproduce this problem on a new empty sandbox?

Not relevant to my request.

What is your Windows edition and version?

24H2

In which Windows account you have this problem?

A local account (Administrator).

Please mention any installed security software

Huorong

Did you previously enable some security policy settings outside Sandboxie?

No

Trace log

No response

Sandboxie.ini configuration

#
# Sandboxie configuration file
#

[GlobalSettings]
EditAdminOnly=y
Template=AdGuard
Template=Edge_Fix
Template=Microsoft_MSMQ
Template=OfficeLicensing
Template=WindowsLive
Template=WindowsRasMan
DefaultBox=DefaultBox
FileRootPath=D:\Software\Sandbox\%USER%\%SANDBOX%
KeyRootPath=\REGISTRY\USER\Sandbox_%USER%_%SANDBOX%
IpcRootPath=\Sandbox\%USER%\%SANDBOX%\Session_%SESSION%
NetworkEnableWFP=y
ForgetPassword=y
ForceDisableSeconds=45

[UserSettings_08EA01CB]
SbieCtrl_AutoStartAgent=SandMan.exe -autorun
SbieCtrl_EnableAutoStart=y
SbieCtrl_RecoverTarget=C:\Users\Visx\Downloads
SbieCtrl_HideMessage=,初始化失败
BoxGrouping=:DefaultBox,Music,WeChat,tg,qq,Chrome

[DefaultBox]
Enabled=y
BlockNetworkFiles=y
RecoverFolder=%{374DE290-123F-4565-9164-39C4925E467B}%
RecoverFolder=%Personal%
RecoverFolder=%Desktop%
BorderColor=#00ffff,ttl,6
Template=OpenBluetooth
Template=SkipHook
Template=FileCopy
Template=qWave
Template=BlockPorts
Template=LingerPrograms
Template=AutoRecoverIgnore
ConfigLevel=10
DropAdminRights=y
ClosePrintSpooler=y
AutoDelete=y
OpenClipboard=n
BlockInterferePower=y
BlockInterferenceControl=y
AllowCoverTaskbar=y
BlockScreenCapture=y
ForceFolderDisabled=D:\youjzhai

[Music]
Enabled=y
BlockNetworkFiles=y
RecoverFolder=%{374DE290-123F-4565-9164-39C4925E467B}%
RecoverFolder=%Personal%
RecoverFolder=%Desktop%
BorderColor=#02f6f6,ttl,6
Template=OpenBluetooth
Template=SkipHook
Template=FileCopy
Template=qWave
Template=BlockPorts
Template=LingerPrograms
Template=AutoRecoverIgnore
ConfigLevel=10
FileRootPath=D:\Software\Sandbox\%USER%\%SANDBOX%
UseFileDeleteV2=y
UseRegDeleteV2=y
DropAdminRights=y
ForceFolder=D:\Software\CloudMusic
ForceFolder=D:\Software\QQMusic
ForceFolder=D:\Software\CloudMusic\CloudMusic 2.10.12.201849 mod
ClosePrintSpooler=y
BlockInterferePower=y
LingerProcess=SGTool.exe
OpenClipboard=n
BlockScreenCapture=y

[WeChat]
Enabled=y
BlockNetworkFiles=y
RecoverFolder=%{374DE290-123F-4565-9164-39C4925E467B}%
RecoverFolder=%Personal%
RecoverFolder=%Desktop%
BorderColor=#02f6f6,ttl,6
Template=OpenBluetooth
Template=SkipHook
Template=FileCopy
Template=qWave
Template=BlockPorts
Template=LingerPrograms
Template=AutoRecoverIgnore
ConfigLevel=10
FileRootPath=D:\Software\Sandbox\%USER%\%SANDBOX%
UseFileDeleteV2=y
UseRegDeleteV2=y
DropAdminRights=y
ForceFolder=D:\Software\WeChat
ClosePrintSpooler=y
BlockInterferePower=y
OpenClipboard=n
BlockInterferenceControl=y
AllowCoverTaskbar=y
BlockScreenCapture=y
AutoDelete=y

[tg]
Enabled=y
BlockNetworkFiles=y
RecoverFolder=%{374DE290-123F-4565-9164-39C4925E467B}%
RecoverFolder=%Personal%
RecoverFolder=%Desktop%
BorderColor=#02f6f6,ttl,6
Template=OpenBluetooth
Template=SkipHook
Template=FileCopy
Template=qWave
Template=BlockPorts
Template=LingerPrograms
Template=AutoRecoverIgnore
ConfigLevel=10
FileRootPath=D:\Software\Sandbox\%USER%\%SANDBOX%
UseFileDeleteV2=y
UseRegDeleteV2=y
DropAdminRights=y
ClosePrintSpooler=y
BlockInterferePower=y
ForceFolder=D:\Software\Telegram

[qq]
Enabled=y
BlockNetworkFiles=y
RecoverFolder=%Desktop%
RecoverFolder=%Personal%
RecoverFolder=%{374DE290-123F-4565-9164-39C4925E467B}%
BorderColor=#02f6f6,ttl,6
Template=AutoRecoverIgnore
Template=LingerPrograms
Template=BlockPorts
Template=qWave
Template=FileCopy
Template=SkipHook
Template=OpenBluetooth
ConfigLevel=10
FileRootPath=D:\Software\Sandbox\%USER%\%SANDBOX%
UseFileDeleteV2=y
UseRegDeleteV2=y
DropAdminRights=y
CoverBoxedWindows=y
ClosePrintSpooler=y
OpenClipboard=n
BlockInterferePower=y
BlockInterferenceControl=y
BlockScreenCapture=y
ForceFolder=D:\Software\QQ
AllowCoverTaskbar=y
AutoDelete=y

[Chrome]
Enabled=y
BlockNetworkFiles=y
RecoverFolder=%{374DE290-123F-4565-9164-39C4925E467B}%
RecoverFolder=%Personal%
RecoverFolder=%Desktop%
BorderColor=#00fd00,ttl,6
Template=RpcPortBindingsExt
Template=OpenBluetooth
Template=SkipHook
Template=FileCopy
Template=qWave
Template=BlockPorts
Template=LingerPrograms
Template=AutoRecoverIgnore
ConfigLevel=10
NoSecurityIsolation=y
UseFileDeleteV2=y
UseRegDeleteV2=y
DropAdminRights=y
BlockScreenCapture=y

[Vstory]

#4085

This is the previous feedback.

[Syrinx2024]

Hey there, have you looked at the NTFS Security Permissions for the directory "D:\Software\Sandbox" ?
Being that it's not in a standard location I'm guessing you may have created it manually and as such Sandboxie won't change the permissions for pre-existing directories, only ones it created itself and so you may need to add some rules to allow non-admin users to delete subfolders\files (Particularly whichever User [or UserGroup] the SandMan.exe is running as! Eg in your case it looks like "Visx" running as Medium Integrity which, unless explicit rules are added, will likely be treated as any Standard User so you may just need give your ComputerName\UserName Full Access for subfolders\files so that you don't need to run the UI as Admin just to delete stuff?)

[Vstory]

Hey there, have you looked at the NTFS Security Permissions for the directory "D:\Software\Sandbox" ? Being that it's not in a standard location I'm guessing you may have created it manually and as such Sandboxie won't change the permissions for pre-existing directories, only ones it created itself and so you may need to add some rules to allow non-admin users to delete subfolders\files (Particularly whichever User [or UserGroup] the SandMan.exe is running as! Eg in your case it looks like "Visx" running as Medium Integrity which, unless explicit rules are added, will likely be treated as any Standard User so you may just need give your ComputerName\UserName Full Access for subfolders\files so that you don't need to run the UI as Admin just to delete stuff?)

It was not created manually by me, but by the sandbox program. I just gave a path "D:\Software" when creating a new sandbox, and then the sandbox program created the "sandbox" folder by itself.

There should be no problem with permissions.

[Syrinx2024]

Thank you for checking and leaving a response (and the pics!)

Sadly I currently don't have any further (different) ideas to suggest offhand. Have you tried running ProcMon (As Admin, OUTSIDE of the sandbox) during the exit\delete phase?

Checking over that may help get you closer to figuring out what is actually happening on your system...eg if something still has a handle open (other 3rd party Security software [or perhaps the program has a service running OUTSIDE of the sandbox?] for instance but all that seems unlikely if running SandMan as admin to delete the box works...) or it still is outright "ACCESS DENIED".
Just in case ~ please understand that were you to save and share such a ProcMon log it may contain unrelated (and data that one might potentially describe as private depending on what you have running/opened) information so I would not suggest you share it publicly or lightly (even including me) unless you are ok with what EVERY SINGLE ENTRY (and it may have 'data saved' which is not always shown in the ProcMon UI) contains.

If it was me, I would run ProcMon, enabling "Capture Events" just prior to exit, and after the delete failed end the Capture. Then I'd set up a filter for "Result - Is - ACCESS DENIED - then - include" and look at the (related) programs Integrity Level and UserName (especially if it has to do with the sandboxes subfolder which it was trying to remove) then compare that Users Integrity\Name\etc with the NTFS Security permissions for the folder which it fails to delete (eg don't run it as admin, let it fail and log what happens and try to get a better sense of what is happening while it fails).

The chances are that if Sandboxie is creating those sandbox folders again (after you actually get it to delete via an Admin SandMan prompt) it's going to have the same permissions you showed in the pics above but surely there is no harm in your double-checking? Don't worry I won't will try not to ask you to do it a third time without a more specific reason but if you wouldn't mind humoring me again for now and checking 'that' yourself you may be able to get a hint as to what is going on without anyone else being involved. Sadly, your situation isn't standard or easily reproducible so I'm currently guessing (but when am I not?)

P.S. I think SandMan has an option to always run as admin at
Global Settings > Advanced Config > Sandboxie.ini Presets > Always run SandMan UI as Admin
Any chance that'd work AND be ok with your use-case?

[Vstory]

P.S. I think SandMan has an option to always run as admin at
Global Settings > Advanced Config > Sandboxie.ini Presets > Always run SandMan UI as Admin
Any chance that'd work AND be ok with your use-case?

Thank you very much for your help.
My previous conclusion was incorrect. Even in maintenance mode, restarting the sandbox as an administrator service will still result in deletion failure.

Just now, I restarted the computer (I shut down the computer last night), and then chose to delete the sandbox content, and it worked. Maybe, as you said, something unknown is still using the files in the sandbox? So the deletion failed.

I'll keep an eye on that and try Process Monitor, thanks.

[Syrinx2024]

Helpful update! Now that we know it's likely something that still has a handle open it might actually be easier to switch to using Process Explorer as it has a nifty search feature you could use to Check the Sandbox Path for in real time after the delete fails and the error pops up.

ex, if it was the Chrome Sandbox which was failing to delete you launch ProcessExplorer as Admin and in its menu
Find > Handle or DLL substring: D:\Software\Sandbox\Visx\Chrome > Search

Then that list should hopefully narrow down possible culprits or at least give you a better idea of what's 'involved in the issue'.

[Vstory]

The normal path is: "D: \ Software \ SANDBOX \ yuyin"
When deleted, if the sandbox is displayed: delete '\ ?? \ d: \ software \ sandbox \ yuyin', and then it will be prompted to delete the failure.
Similar to the following picture:

I can't understand the problem log.
Logfile.zip

[Syrinx2024]

The ProcMon log file was pretty short and seemed to be trimmed down to just the target directory (not a bad thing, just can't be sure a hint wasn't lost) but it only seemed to show DirectoryOpus refreshing its information about the sandbox directory (likely in the background as it seems to happen every 2-3 seconds). It also shows the SandMan UI going through its attempt(s) to delete the folder (but unlike a working attempt everything remains found afterward). Sadly I attempted to install Directory Opus with default settings and still had no issues removing sandboxes on my end in a VM so unless there is an option somewhere that changes its behavior I'd lean toward saying that it seems fairly well behaved and isn't the root cause.

However, given that we've changed suspected targets away from 'Access Denied' over to 'something likely has a Handle open' we should really have much better (easier) luck trying to narrow it down using something like ProcessExplorer (ProcExp) As Admin and using the "Find Handle or DLL (Ctrl+Shift+F)" option to narrow targets to related sandbox directory. Basically anything shown in that search list for D:\Software\SANDBOX\yuyin (that isn't related to Sandboxie) would likely be where you'll want to focus on 'tweaking settings' in order to prevent the auto-delete issues you are seeing. Most likely this would be done by adding a specific exclusion but we 'can't try anything' until we know 'what to try it on'. =(

[zomoleg]

I had the same problem when deleting sandbox contents from the Sandboxie-Plus-x64 menu when I upgraded to Windows 11 24H2. On Windows 11 23H2 there were no problems whatsoever.
So far I've switched to Sandboxie-Classic-x64, there's no problem with sandbox cleanup in Win 11 24H2.

[DonEstefan]

I had the same problem this week after my Update from Win10 to Win11 24H2. It was the first time I used a sandbox after the win update. I saw the two popup messages from Step 6 of this issue ("error deleting sandbox")

After hours of testing, I found this post here from @Vstory

Just now, I restarted the computer (I shut down the computer last night), and then chose to delete the sandbox content, and it worked. Maybe, as you said, something unknown is still using the files in the sandbox? So the deletion failed.

So I tried to reboot - and sandbox deletion suddenly worked 🤦‍♂️

However, I'm sure there was no open file handle in my sandbox path before the reboot. I checked process explorer in admin mode for open handles in my sandbox path. There were none.
I also tried deletion of the sandbox folder in windows explorer, which is only possible if there are no open file handles. This deletion method worked fine.
I also tested changing the filerootpath in sandboxie. The changed paths worked fine for sandbox creation - but never for sandbox deletion.

Anyways, the deletion problem finally disappeared after a simple reboot. Maybe this helps others running into the same problem...

[bot-1450]

Well, it should be quite easy to figure out what's wrong here. The status is stored in a stack and is never assigned a value if FileAttributes is neither FILE_ATTRIBUTE_REPARSE_POINT nor FILE_ATTRIBUTE_DIRECTORY. A simple restart inadvertently zeros out the stack, which happens to make the code work.

Sandboxie/SandboxiePlus/QSbieAPI/Helpers/NtIO.cpp

Lines 103 to 122 in 28e8818

	NTSTATUS NtIo_DeleteFile(ULONG FileAttributes, OBJECT_ATTRIBUTES* attr, bool (*cb)(const WCHAR* info, void* param), void* param)
	{
	NTSTATUS status;
	if (FileAttributes & (FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM))
	NtIo_RemoveProblematicAttributes(attr);
	if (FileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)
	status = NtIo_RemoveJunction(attr);
	else if (FileAttributes & FILE_ATTRIBUTE_DIRECTORY)
	status = NtIo_DeleteFolderRecursivelyImpl(attr, cb, param);
	if (NT_SUCCESS(status))
	status = NtDeleteFile(attr);
	if (status == STATUS_OBJECT_NAME_NOT_FOUND || status == STATUS_OBJECT_PATH_NOT_FOUND)
	status = STATUS_SUCCESS; // we wanted it gone and its not here, success
	return status;
	}