Sandboxie Acquired by Invincea

Windows 10 pro 1809 with sandboxie stable 5.30
All programs I sandbox are updated to the latest version like Firefox and Thunderbird and all running good.
Since I don't want to "betatest" windows feature updates I only install security patches. (personal choice not sandboxie related but wanted to mention it)

 

Yes, I also thought about this, but sometimes it seems to happen with no good reason. But since it's launched by Sandboxie, I'm guessing it's not malicious in any way. Perhaps I will block execution of rundll32.exe to see what happens.

 

You could:

1. Use a restricted sandbox and allow rundll32.exe to run. If this is what you do, the only rundll32.exe process that would be allowed to run is the one in your system. If malware using the name rundll32.exe gets downloaded in the sandbox and attempts to run, it wont run as it wont be allowed. 2. You could also use a restricted sandbox and not allow rundll32.exe to Start and Run, if this is what you do, when rundll32.exe attempts to run it will get blocked, close the Sandboxie message and (you ll be able to) continue doing what you doing.

Bo

 

I am about to upgrade my Windows 7 to Windows 10. Should I uninstall Sandboxie before I perform this upgrade?

 

yes. but save c:\windows\sandboxie.ini and copy it back before you install sandboxie again.

for windows 10 a clean install is recommended if you have done the upgrade to use your windows 7 license.

 

Hi all - Sorry to bring this problem here, but it looks like the official Sandboxie Forums got turned into some kind of Fisher-Price nightmare that isn't well maintained, and has no archive.

This morning, after no changes whatsoever, Sandboxie started to fail to auto-purge sandboxes I had set up to self-delete. I have a default sandbox for Chrome that will purge itself on exit of the browser. Last night, everything worked as expected, as it has for months (if not years) before. For some reason this morning, it threw the following error at me:

http://i.imgur.com/GQgHx5B.png

This is on 5.31.1 and 5.31.2.

After manually trying to purge the sandbox, it looks like a file called RegHive is the one causing issues and preventing the sandbox from purging.

No processes are running in the sandbox at the time of the error. Chrome is set to a leader program in the sandbox in question, and no processes are observed either in Process explorer or Sandboxie.

Has anyone seen this behavior before, or know what could be causing it? It makes me feel itchy when the sandbox can't purge itself - I begin to suspect malicious activity.

EDIT: It looks like this issue has been reported at the old Sandboxie forums one or two times - according to a Google search. But trying to follow those links only brings me to the new forums. Is there a way to access the information and posts from the old forums?

 

when "reghive" is blocked then its used from another program outside sandboxie, this is no sandboxie issue, its is your system. which is your used antivirus?

sandboxie hasnt changed anything, so its one of the above.

 

ESET is my current antivirus.

I've updated or changed no other programs between last night and today, so I am wondering what could be causing it even if it ISN'T Sandboxie.

Is this an indication of something more sinister afoot?

 

Hi, I've seen this basically by accident as I don't realy read these forums... Anyway, I've been getting the same error and the same problem on one of my laptops, and on that laptop I use ESET AV too. I have Windows Defender and Avast on the others. It started a couple of days ago, the old solution from the old forums was to restart the PC and try again - and then it would delete the sandbox. I use Firefox, not Chrome by the way, I don't even have Chrome installed. I tried the old trick and it worked. But after a couple of times closing Firefox the error apears again and then keeps appearing each time you try to terminate the sandbox. So I updated to the lastest beta version, I tought that would work, but it didn't. So now one of my PCs has this same problem as you do. I have the latest Sandboxie (and the same was going o with v5.28 ), Firefox, ESET Antivirus and Windows 10 (not the latest version, I'm 2 big updates behind I think). But I'm not sure it's ESET, I haven't updated it, only the definitions get updated... So I don't know but would like to solve it as well. Will you post in on the official SBIE/Sophos forums?

 

Dont feel itchy, what you experienced is not due to malicious activity.

When you see the type of message you saw, it means a security program has a lock in files inside the sandbox, this prevents Sandboxie to delete contents. This happens as you close the sandboxed pogram, and the AV do ts thing scanning the files before they are deleted.

The short term solution is to reboot, after you reboot, you ll be able to easily delete the sandbox manually.

Long term. If you rarely experience the sandbox cant be deleted glitch, then ignore the message and you know what to do next time this thing happens. But if its happening often, like everyday, then you need to figure out which program is locking the files. Usually, it is your real time AV. So, switching AV will be your long term solution.

Bo

 

Hi Bell, something as simple as a recent definitions update could be the cause, and perhaps, another definition update could solve it. Since you are in W10, you could use WD for now, for a while. You ll never see the cant delete contents message with WD as your AV.

Bo

 

Thanks very much for your insight and information, bo! I very much appreciate it. I'm going to verify if ESET is holding on to the RegHive file. I know that rebooting does in fact solve the problem, but as soon as the sandbox is repopulated, it seems like that issue resumes again very quickly. I'm not sure if I want to dump ESET after years of it performing admirably - But I suppose it might be necessary.

Might there be a way to set up an exception in the AV to prevent this from happening? Or would that extend to the entire sandbox, which would be a bad idea?

Hi Bellzemos - Thanks for sharing your experiences! It gives some further insight into this, and certainly seems to narrow down that ESET feels like the unifying factor, and likely due to a definitions update that rolled out recently. Or so I might presume, at least.

I just wanted to assure you that I did post this to the Sophos SBIE forums here.

It's quite frustrating - This issue apparently was discussed multiple times in the old Sandboxie forums, Google still points to those discussions. But the forums are inaccessible.

 

Happened to me again today, exactly as explained. And I run ESET NOD32. Reboot fixes, but that is a mighty inconvenient remedy.

Look to the past to predict the future.

 

Unfortunately, Sophos is managed by people who are disrespectful, stupid and liars

Anyway, the solutions has always been what I suggested.

Bo

 

Page, Bellzemos, Carbonyl, ESET has traditionally worked well along Sandboxie, perhaps a soon to be released definitions update fixes whats causing the lock. It could be days. So, if you are in W10, I would temporarily switch to WD, and in a few days, try ESET again. Page, you in W7, perhaps setting up an exclusion for Sandboxies processes and/or the Sandbox folder in C drive might solve the problem.

Myself, when I used AV, I experienced this sort of thing about twice a year. After I stopped using AV, the sandbox contents dont delete sitiation stopped from occurring completely. It just never happens. Since I stopped using AV, the only time I get something somewhat similar to what you guys are experiencing is if and when I open and close sandboxed programs too quickly. So, as an example, if I open a new instance of Firefox before the one I just closed gets actually deleted, then I might get a somewhat similar message and situation to the one you are experiencing.

Bo

 

I am using ESET IS with sandboxie 5.30 in windows 10 v.1803. My sandbox folder is in imdisk ram disk. I face no issues.

 

Followed your sound advice, Bo, and excluded Sandboxie folder in ESET. We'll see how it goes. I also used a leader program setting for Chrome.

This Sandboxie failing to purge the Chrome sandbox business is really happening with increasing frequency for me. I'll report back on any changes.

My thanks to Bo, Bellzemos, Carbonyl Stretch.

 

I spoke too soon. Eset updated and I cannot empty sandbox folder

 

Just an update: I added an exception for the RegHive files in ESET - The problem continues to persist regardless of that fact.

More disturbingly - This morning when I started my machine from a cold boot, I was unable to empty the sandbox. That's basically just starting the computer up, and immediately invoking the deletion, and getting the same error.

I do not know if ESET is to blame here, honestly. When I use Process Explorer to search for which processes are holding on to RegHive files, the only process listed is PID - 4 "SYSTEM".

This is becoming more and more perplexing! Though I will note that a full Malware scan didn't bring back any results, so it doesn't seem to be something malicious.

 

The reghive is basically a data file where the registry information is stored. This is mounted when the sandbox is started and SBIE attempts to dismount it when all the applications in said box are terminated. If anything, eg even an Anti-Virus, has a handle open on any value in that hive windows won't allow it to be dismounted. This means the reghive FILE remains locked as it is actually still 'in use'. You could open regedit and attempt to dismount it manually. If that works then it may simply be a timing thing where the AV is being a bit slow.

Instead of excluding the FILE you could try excluding the REGISTRY entries themselves (something like "HKEY_USERS\Sandbox_*") if possible. Note that even if it is possible and does end up solving the issue (likely a reboot may be needed to see a difference after adding an exclusion. Assuming you even can...) you will be reducing the protection ESET provides sandboxed apps a bit.

Before even trying that, as you already have Process Explorer try scanning for HKU\Sandbox_ to see what has keys open there still as that may help you isolate exactly which process is involved.

 

Wow, thanks tremendously for the help, syrinx. After searching for HLU\Sandbox_ with Process Explorer, I can verify that ekrn.exe is in fact the process holding on to the registry entry in this case. It looks very specifically like ESET is in fact responsible for holding the sandbox hostage in this case! It is absolutely not letting go of that, either. It just never releases it - even long after the processes are closed and nothing is running in the sandbox.

I suppose I ought to reach out to ESET at this point?

 

Have you tried excluding the Sandboxie folder in ESET? I'm having success having done that, although I have taken additional steps. Lots of opening/closing Chrome since, and sandbox deletion is working as it should.

 

If the issue is with ESET, then yeah I believe reporting at the official forum would be a good idea.

 

I have tried adding specific exceptions for the Reghive files in question - It hasn't solved the issue, sadly. Mostly because, I believe, what Syrinx is saying appears to be true - It's not a file that ESET has open, but a registry key.

I've posted over on the ESET forums about this issue here. If anyone else suffering from this behavior would care to add their voice to the issue, it might help the resolution!

And thanks much to everyone for helping out with this issue so far. I really appreciate the wealth of knowledge that you all share.

 

Fairly simple process of elimination to at least try excluding the whole folder, regardless of what specific suspicions you have arrived at.