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

Barb@Sophos -- unfortunately the suggested changes did not help.  (removal of ESET from software compatibility, and attempted blocking of ekrn through Sandboxie settings)

-- Lucas, are you also using NOD32 as your AV solution?

So far all responses that I have gotten from ESET have not been promising (getting the runaround), as they have not acknowledged a problem nor the intent to fix said problem.

Disabling components within NOD32 selectively, such as shutting off HIPS or ransomware protection doesn't help ... only complete disabling of NOD32's realtime protection seems to resolve the issue.  Short term, if you rely heavily on Sandboxie I would suggest that you temporarily swap AntiVirus Software.  Of course, you should also open a support ticket with ESET support, so that they see that this impacts many people and it gets escalated.  (I've also tried calling them, though yes the more they hear of this the better -- given it's something they pretty recently broke)

For the record, I went back over to Avira while waiting.  {as I'd happened to still have an active license}  Avira is working just fine with Sandbox deletion.

Same problem here. I think it started with one of the last two Eset module updates on 18.06.2019 or 25.06.2019.

I don't like Avira because of their aggressive marketing. Kaspersky is not compatible with Sandboxie and Bitdefender has a bad performance and no expert options.

EDIT: Did you restart your system after you disabled Eset compatibility in Sandboxie? It seems to work for me.

EDIT 2: After two days of testing with Eset compatibility disabled, I actually can't reproduce the problem anymore.

I tested it with Firefox 68.0 x64, Internet Explorer 11, the old Palemoon 26.5 x86 with downloaded and moved files and PDF read in the browser and even after Windows 7 x64 hibernation.

Maybe the solution only works with Sandboxie 5.28 on Windows 7 x64.

I will post it if the problem should occur again.

EDIT 3: It occurred for all sandboxes in use when I updated a software outside of Sandboxie (the installer uninstalls the old version first). :-|

EDIT 4: I tested it again with Eset compatibility enabled and then it practically always happens. With compatibility disabled it happens much less. 

Good afternoon, I use Eset Internet Security.
I have tried all the indications that have been commented (Deactivation compatibility, etc ...) but it does not work with any.
I have tried other AV but I do not like them.
I hope it can be solved as soon as possible.

Thank you.

hello! i have the same problem. All solutions provided by Bard doesn't help. I hope that developers will find a solution.

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.