Sandboxie fails to purge Sandbox - ACCESS DENIED error on delete invocation

Hi Carbonyl,

This is a fairly common scenario, and it is usually triggered by AVs holding on to files. 

A few suggestions:
-Try a leader program setting for Chrome https://www.sandboxie.com/ProgramStopSettings#leader
-Add Sandboxie to the AVs exclusions and see if that helps. 

The last option is what you already figured out, a reboot takes care of whatever is holding on the files and allows Sandboxie to empty the contents. 

Regards,

Hi Barb,

Thanks for the fast reply. I very much appreciate the information. Just to be clear, does the frequency of this issue indicate it's fairly benign? It's the first time I've seen it, and it has me quite worried.

To respond to your suggestions:

-At present the sandbox in question already has Chrome as a leader program. The sandbox was configured this way before the issue occurred, and the settings are still configured that way. From what I can tell, no processes are running in the sandbox at all when this error is encountered.

-I believe I had already added Sandboxie to the exclusions list in ESET, but I will verify that once I get home from work to check on that today.

As an additional question: Is there any way to determine what program is holding on to RegHive? It seems to be quite persistent, but I can't find out what program is doing it in this case.

I'd prefer not to have to reboot my computer every time I want to purge the Sandbox!

Thanks very much for your help on this matter. I will also update as I learn more.

Reinstalled NOD32 for some more testing.

Sadly did not notice any decrease in frequency with removal of ESET compatibility:  {on Win10 1903 18362.239, Sandboxie 5.31.2}

The issue has always been extremely random on this end though.  Sometimes it happens after a single start and termination of a browser following a boot, sometimes it won't occur until a day's end with dozens of repeat closures.  I can also now confirm that this impacts "any software" under Sandboxie, not just Chrome / Palemoon, the reason the occurrence rate is so high with browsers is just due to how often they're launched and closed.

-- For instance, had this happen under VLC Media Player yesterday.  For that matter it happens with LibreOffice, TightVNC, Microsoft Word, several IRC clients.  Just keep starting and closing a program and sooner or later the hive won't close.

** ESET support has informed me that they've added the Sandboxie behavior to their internal list of issues...  They told me that this is not considered a "high-priority" & that very few have reported such, yet also that mixing security-software is not guaranteed to work {e.g, no promises will be made on fixing it}.

Maybe it's because of what Eset last marked as scanned. Run a full scan, maybe the problem will occur less often.

Did you refer Eset Support to this thread? This might help to increase the priority a bit. Unfortunately this is probably not the case.

Edit: I've already checked with ProcessMonitor (also started as admin) what accesses the registry keys HKEY_USERS\Sandbox_, but nothing is found if you exclude the processes of Sandboxie and the software itself. So it can't be ekrn.exe.

tec tec said:

Maybe it's because of what Eset last marked as scanned. Run a full scan, maybe the problem will occur less often.

Worth a shot, perhaps if there's no registry changes made over the course of a session then cached scan results might help.

tec tec said:

Did you refer Eset Support to this thread? This might help to increase the priority a bit. Unfortunately this is probably not the case.

I had not, yet I've now tacked this into the ticket.

tec tec said:

I've already checked with ProcessMonitor (also started as admin) what accesses the registry keys HKEY_USERS\Sandbox_, but nothing is found if you exclude the processes of Sandboxie and the software itself. So it can't be ekrn.exe.

I've not tried Process Monitor yet.  Though Process Explorer, Process Hacker, Lock Hunter, etc, list ekrn as the culprit.  I'd expect that perhaps the method employed for monitoring access is different in Process Monitor.  -- At the very least we know that if NOD32 is uninstalled or real-time protection is disabled, the problem goes away.  {It minimally has to be some form of interaction involving ESET's real-time scanner}

Jerry Atricks -- One of the initial troubleshooting steps that I tried was a Win10 VM as a fresh install of 1903, rather than my feature-upgraded.  That said, DISM and sfc /scannow come back clean (no errors).

The Process Explorer only shows which process was started by which one. It can't show registry calls, or am I missing something?

Since my upgrade of PDFCreator (which has nothing to do with Sandboxie) suddenly prevented all sandboxes that were currently in use from being cleared, Eset must have blocked a registry key that was also used by software outside of Sandboxie.

As an attempt, I nevertheless enter the RegHive file into Eset's scan exceptions: C:\Sandbox\username\*RegHive

tec tec said:

The Process Explorer only shows which process was started by which one. It can't show registry calls, or am I missing something? 

Process Explorer [and Process Hacker] can't list registry-access persay, yet they can list all opened handles by a given process.  Or specifically in this case the file-handle of Sandboxie's mounted hive.  If Sandboxie is completely closed {including the service unloaded}, the only remaining software with open handles for the hive are Windows (system) and ekrn.

I had not tried placing exclusions based on the hive files -- only by application exclusions, I'll have to give that a shot too.

Scan exception: C:\Sandbox\username\*RegHive doesn't help. :-|

Edit: The coming cleaner module 1197 (currently 1195) could be the solution.

forum.eset.com/.../

Awesome!  Glad that this is getting adequate publicity and that ESET is looking into it. (more than I was let on to believe in my ticket and calls!)

Can't wait to switch back off Avira.

ESET Cleaner module 1197 has fixed the issue for me on two 7x64 machines.

Page42 said:

ESET Cleaner module 1197 has fixed the issue for me on two 7x64 machines.

How can I get this "ESET Cleaner module 1197" so that the problem goes away? Will it be downloaded as a virus definitions update by itself or do I downlaod it from somewhere?

I have ESET Antivirus for Business, version 6.something.

Thank you.

I joined this forum this morning just to say thanks for this thread. Once I found this thread it was a simple matter to set the two Win7/x64 machines I use to download pre-release updates. Once ESET Cleaner module 1197 installed and I rebooted, Sandboxie is working normally.

Thanks again to everyone in the thread.

I joined this forum this morning just to say thanks for this thread. Once I found this thread it was a simple matter to set the two Win7/x64 machines I use to download pre-release updates. Once ESET Cleaner module 1197 installed and I rebooted, Sandboxie is working normally.

Thanks again to everyone in the thread.

Where did you get it? 

Set your ESET updates to download pre-release updates instead of regular updates. Then go to update screen and click on Update Now.

After that you can check view all modules to make sure you received the update.

Suggestions in this group to download beta versions of ESET does not work. Cleaner Module is now 1199 and has no effect to correct the problem. A fresh reboot and immediate 'delete contents of sandbox' seems to be the only thing that works. This is an ESET related problem as a complete removal of ESET restores sandboxie functionality.

The cleaner modules after version 1195, currently 1199, only protects against new registry locks but doesn't unlock existing ones.

https://forum.eset.com/topic/20056-eset-issue-with-sandboxie-persistent-holding-of-registry-keys/?do=findComment&comment=100089

So you should have no more problems with Sandboxie as long as you don't go back to the regular updates and 1195 is still loaded there while Sandboxes are active.

Thanks @tec tec rolling back to 1195 fixed it

???

That's practically impossible.
You should stay on the test updates with version 1199 as long as the release is version 1195.