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

 Hi. I've encountered a troubling error with Sandboxie this morning after having no issues for quite some time.

I'm running on the latest version of Windows 10, with ESET as my antivirus solution. The Sandbox in question contains only Chrome, version 75.0.3770.100.

I first experienced this issue on Sandboxie version 5.31.1

I have since upgraded and seen the issue on Sandboxie 5.31.2

 ---------

 The Issue:

I have a sandbox configured to contain Chrome, which on termination of Chrome processes, auto-deletes the contents of the sandbox. Last night (and for years prior) this was not an issue.

This morning I started up my machine, did some light browsing, and then closed Chrome to go to work. Sandboxie initiated the self-purge of the sandbox, and then gave this error:

The error reads "Delete Sandbox DefaultBox: Could not move the sandbox folder out of the way. The object (file or folder) may be in use by another program. Close any application or windows that may prevent access. System Error Code: Access is denied. (5)"

I attempted to update Sandboxie from 5.31.1 to 5.31.2, but the error persisted.

By rebooting my computer and then invoking a delete sandbox command from Sandboxie, I was able to purge the sandbox - But only if it was the first thing I did. If I opened Chrome again, then the error would repeat. It is not possible to purge the sandbox unless the system is rebooted again.

All Chrome processes are terminated when this error is observed. The Sandbox lists no processes running within it, and Process Explorer doesn't show any Chrome processes running.

By manually going into the sandbox folder, I was able to find the file that is giving the problem:

RegHive seems to be the culprit, though I'm not sure how. Somehow this file is in use and/or access to it is denied to both me, and from Sandboxie.

 --------------

 Any help on this would be greatly appreciated. I'm not sure why everything would have been fine last night, and now suddenly this is happening - As I installed no new software, and not even any updates were applied. I fear something nefarious may be afoot, but an ESET scan is not revealing anything.

 If anyone could provide assistance, I am getting worried and would thank you profusely for helping to determine just what is going on here. Thanks.

 EDIT: After a deeper Google Search, it appears this issue has been discussed numerous times on the old forums. Is there any way to access that knowledge? Clicking each Google search result link just brings me right back here, and there's no cached versions to view.

Parents
  • 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,

    Barb@Sophos
    Community Support Engineer | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'This helped me' link.

     

  • 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.

  • Hi Carbonyl,

    Each situation may be different, but as you saw in your searches, and as covered in my previous response this is a common situation that gets reported. 
    If you are worried about an infection, please do scan your computer with your AV , and if needed, get a second opinion, here's a suggestion:
    https://www.sophos.com/en-us/products/free-tools.aspx --> Scroll down to find the "Virus removal tool", which will work alongside your existing AV. 

    To see what programs are holding on to files, you may perform an online search for third party software, typically they go by "file unlocker". 

    I'd also recommend trying a new Sandbox with default settings (as installing a diff version of Sandboxie does not delete your existing sandboxes). 

    If all fails, you may also try manually deleting the Sandbox folder instead of restarting your machine (Navigate to C:\Sandbox\....  to find your Sandboxes and right-click delete the affected one) . 

    Let us know how things go. 

    Regards,

    Barb@Sophos
    Community Support Engineer | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'This helped me' link.

     

  • Hi Barb,

    Thanks again for your help on this matter.

    Unfortunately, the suggested paths did not result in a solution.

    I've done a full malware scan, and the results came back negative - No malware detected.

    I've added the RegHive files to the exception list in ESET, and that hasn't remedied the issue, either.

    When I check what process has the RegHive files open and won't let go of them, the process is "PID 4 - System". Which is either extremely uninformative, or extremely disturbing.

    Even more disturbing - This morning when I started my computer from a COLD BOOT, the first thing I did was try to empty the sandbox. Access was denied!

  • Further update:

    It appears that ESET is actually holding on to a specific registry key even after there are no processes running in the Sandbox, and Sandboxie is trying to close it out.

    Ekrn.exe persists in holding open the "HKU\Sandbox_(Username)_(Sandboxname)" key, even long after all processes in the sandbox have terminated.

  • I am also getting this same error just over the last few days  I am running 2 x WIN7 PC's both with ESET and firefox and with Sandboxie 5.30  I can only delete the firefox contents after a clean reboot  Does this present a threat or can I live with it ubtil a solution is found

  • I just wanted to note that I have reached out to ESET support about this. I've provided them with log files and am awaiting a response.

  • Carbonyl Stretch said:

    I just wanted to note that I have reached out to ESET support about this. I've provided them with log files and am awaiting a response.

     

    Ironically, I've also contacted ESET about this as well detailing how ekrn was holding onto said hive / preventing an unmount {effects both Chrome and Palemoon for me}.  Got a response on the 5th.

    This is what they sent me per my case: {Sandboxie "Access is Denied", when deleting sandbox contents}

    An ESET Technical Support Representative has updated this case with the following information:

    Hello,

    Thank you for contacting ESET North America Technical Support.

    To exclude an application or IP address from protocol filtering from ESET Windows home products, visit: support.eset.com/.../


    Thank you for using ESET security products,
    ESET Technical Support
    North America
    ------------------------------------------------------------------------------
    ESET Knowledgebase | articles | videos | manuals | support
    http://support.eset.com/

    Needless to say, excluding the Sandboxie processes under web protocol filtering had no effect in mitigating the issue {nor realtime protection exclusions -- though disabling NOD32 realtime protection "completely" does work}.  I'm also waiting per round two going on ~72 hours since that last reply.  Please do keep the thread updated if you find out anything.


    To add a bit more, even if the Sandboxie service is forcefully killed and regedit is launched as "SYSTEM" -- that's still not enough to unmount the hive.  {NOD32 still hangs onto it}

    -- Best I've managed to do right now is flushing everything with the exception of the hive, manually, as even disabling realtime protection {post incident} the hive file is still not released.

Reply
  • Carbonyl Stretch said:

    I just wanted to note that I have reached out to ESET support about this. I've provided them with log files and am awaiting a response.

     

    Ironically, I've also contacted ESET about this as well detailing how ekrn was holding onto said hive / preventing an unmount {effects both Chrome and Palemoon for me}.  Got a response on the 5th.

    This is what they sent me per my case: {Sandboxie "Access is Denied", when deleting sandbox contents}

    An ESET Technical Support Representative has updated this case with the following information:

    Hello,

    Thank you for contacting ESET North America Technical Support.

    To exclude an application or IP address from protocol filtering from ESET Windows home products, visit: support.eset.com/.../


    Thank you for using ESET security products,
    ESET Technical Support
    North America
    ------------------------------------------------------------------------------
    ESET Knowledgebase | articles | videos | manuals | support
    http://support.eset.com/

    Needless to say, excluding the Sandboxie processes under web protocol filtering had no effect in mitigating the issue {nor realtime protection exclusions -- though disabling NOD32 realtime protection "completely" does work}.  I'm also waiting per round two going on ~72 hours since that last reply.  Please do keep the thread updated if you find out anything.


    To add a bit more, even if the Sandboxie service is forcefully killed and regedit is launched as "SYSTEM" -- that's still not enough to unmount the hive.  {NOD32 still hangs onto it}

    -- Best I've managed to do right now is flushing everything with the exception of the hive, manually, as even disabling realtime protection {post incident} the hive file is still not released.

Children
  • Hi all,

    While you wait for the AV team to reply to you, I have some suggestions

    Try deleting the Sandbox folder manually via Safe Mode. Then, reboot to normal mode, and if present, remove the ESET template from Sandboxie (Configure -- Software Compatibility --> Uncheck the ESET template) . Re-test the behavior with a new Sandbox (if this fails, or causes other problems, please re-add the template).

    Since you mentioned Ekrn.exe , you may want to try blocking that file in the Sandbox and test what happens (it may or may not work, as it it may trigger error messages).

    Right-click on your Sandbox
    Sandbox settings---> Resource Access ---> File Access --> Blocked access
    Add the following entry:
    *\ekrn.exe
    Ok and Apply
    Re-test

    Remove the changes if they don't help/cause problems.

    Regards,

    Barb@Sophos
    Community Support Engineer | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'This helped me' link.

     

  • Good morning, I have the same problem.
    I can not delete the sandbox since the "RegHive" file remains in use after closing all processes.
    Do you know if it will take a long time to solve this problem?
    I use this application a lot and with this failure it is not operative.
    
    Thank you
  •  -- 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. 


    Windows 7 x64 with all updates • Sandboxie 5.31.6 x64 • Browser (each with its own sandbox, cleared on exit): Firefox 70 x64, Internet Explorer 11, Pale Moon 26.5.0 x86 • Eset Internet Security 13

  • 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.


    Windows 7 x64 with all updates • Sandboxie 5.31.6 x64 • Browser (each with its own sandbox, cleared on exit): Firefox 70 x64, Internet Explorer 11, Pale Moon 26.5.0 x86 • Eset Internet Security 13

  • 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}

     

     -- 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


    Windows 7 x64 with all updates • Sandboxie 5.31.6 x64 • Browser (each with its own sandbox, cleared on exit): Firefox 70 x64, Internet Explorer 11, Pale Moon 26.5.0 x86 • Eset Internet Security 13