SbieSvc.exe handle/memory leak

[Registered Username]

Windows 10 1803 (AMD64 17134.1)
Sandboxie v5.26 and previous versions
NAME & Version/build numbers of any applications involved? (see below)
Are you running antivirus/anti-malware software? (none, just Comodo firewall)
What are the exact steps to reproduce the issue? (see below)

Hello, I believe I have found a handle leak in Sandboxie. Some programs that are prone to spamming SBIE2203, SBIE2327, or any other errors appear to cause a handle leak in the SbieSvc.exe process(es?) which can be observed by any program that can view them, these handles are not freed and will retain their memory usage even after terminating the offending program, I have observed up to 3-4GB on a single SbieSvc process in a 30minute span before manual intervention by means of restarting Sandboxie entirely including its service.

Steps to reproduce:

• Visit https://raft.itch.io/raft
  Download V1.05b_Raft_Win64.zip

• run the program in a clean sandbox and start the game

• click "create new game", name it, and then click "Create", start playing

• instantly it will throw some SBIE errors, that's fine, but observe the rise of handles and memory usage of SbieSvc.exe

here is a screenshot example of 30 seconds with the above mentioned program running, 2000+ handles created.

I understand that clicking "hide errors" is something that is mentioned as a possible solution to the above type SBIE errors and I'm fine with doing that, normally on programs that are less spammy (maybe a few errors per 30 minutes max) it works fine, but when dealing with any program that will potentially throw SBIE errors at a rate of a few hundred times in the span of 1 minute, this bug can quickly cause a full exhaustion of system resources so I'm wondering is there anything that can be done to help solve this?

[Barb@Invincea]

Hello Registered Username,

As covered here viewtopic.php?p=134233#p134233 , hiding a message is a workaround provided when nothing else can be found at the support level.

The currently supported applications are listed here: viewtopic.php?f=2&t=24980
Anything else is considered low priority, thus, you may receive a workaround until the devs have time to look into a specific application (if they get to it) . I have made them aware of this problem report and we will update this thread if anything new comes up.

I tested the game and I did see the messages, however no CPU or memory spikes (perhaps I should run it for a longer time? can you provide more info? ) .

As for a workaround, adding "* " helped making the errors disappear . Please give this a try:
Right-click on your Sandbox --> Sandbox settings--> Resource Access --> Windows access
Click "Add"
Enter the following:
*
Apply and OK your way out.
Relaunch your game after deleting the contents of your Sandbox.

This is a testing setting, so if it works for you and you decide to use it I recommend a few things:
1) Use it in a separate Sandbox for this game only (and restrict other programs from running).
2) Keep in mind you are punching a whole in your Sandbox, so only allow this if you trust this game.
3) Unexpected behaviors may occur (YMMV).

Please let me know the outcome (including if this affects the memory issues you are experiencing).

Regards,
Barb.-

[Registered Username]

I can confirm that allowing specific window access does indeed fix leaks because errors aren't being generated in that specific program.

I tested the game and I did see the messages, however no CPU or memory spikes (perhaps I should run it for a longer time? can you provide more info? ) .

when the errors are shown in the SbieCtrl.exe process, the handles go up inside of one of the SbieSvc.exe processes and even after closing the control window + messages dialog the leaks remain. Here is a straightforward webm example of what I'm talking about. take note of the memory usage and handles constantly going up every time there is a message being displayed, these are not freed up when closing the program, closing the messages window, and letting everything just idle. I'm pretty sure that is not the intended program behavior but who knows

hopefully that is enough to get an idea of what I'm talking about, thanks for taking a look at it.