5.09 Beta Available (latest version 5.10 RC)
-
- Sandboxie Support
- Posts: 3523
- Joined: Thu Jun 18, 2015 3:00 pm
- Location: DC Metro Area
- Contact:
Re: 5.09 Beta Available (latest version 5.10 RC)
I spoke with Tom about this issue this morning, he's the one working on the rcpss issue for sometime now....
As for the programs lingering...that may happen. rcpss is the parent to dcom and others in the SB. However, they are all should close within a reasonable time frame...from a instantly to upwards of 30 seconds. It depends on various things. IE seems to take a lot longer for example. But some programs will vary. Browsers will vary given extensions, etc. But some delay is acceptable and expected.
The Leader/Linger process as a whole may be something we need to look at. Given all the code changes/tweaks and timing...it may not even be needed any longer.
Tom stated that Ronen had that code for various reasons..maybe to overcome issues in the past that are no longer issues at this time.
So, for testing and just being curious about it:
Do these programs that "hang around" are they are a part of a Linger / Leader process you've set up?
If so, if these programs are removed from that, does it improve=Do they exit in a timely manner? Get worse=take much longer?
No difference?
If may be better/worse in Win 10. It may be better/worse in Win 7, etc. But Win 10 has gotten better about managing this, but this was present to some extent in Win 7, so whatever is targeted in Win 10 will very likely impact Win 7, 8.1 in some way.
No if something simply doesn't exit/quit in the SB...well...that's not acceptable.
As for the programs lingering...that may happen. rcpss is the parent to dcom and others in the SB. However, they are all should close within a reasonable time frame...from a instantly to upwards of 30 seconds. It depends on various things. IE seems to take a lot longer for example. But some programs will vary. Browsers will vary given extensions, etc. But some delay is acceptable and expected.
The Leader/Linger process as a whole may be something we need to look at. Given all the code changes/tweaks and timing...it may not even be needed any longer.
Tom stated that Ronen had that code for various reasons..maybe to overcome issues in the past that are no longer issues at this time.
So, for testing and just being curious about it:
Do these programs that "hang around" are they are a part of a Linger / Leader process you've set up?
If so, if these programs are removed from that, does it improve=Do they exit in a timely manner? Get worse=take much longer?
No difference?
If may be better/worse in Win 10. It may be better/worse in Win 7, etc. But Win 10 has gotten better about managing this, but this was present to some extent in Win 7, so whatever is targeted in Win 10 will very likely impact Win 7, 8.1 in some way.
No if something simply doesn't exit/quit in the SB...well...that's not acceptable.
Re: 5.09 Beta Available (latest version 5.10 RC)
Tried it with the existing leader/lingering rules first. Upon exit of the leader process, they seem to last for at least two minutes without getting stopped at which point I terminated them.
Upon removing the leader/lingering process rules and trying again there was no change.
Once again this seems to occur more often when a program is launched then exited almost immediately. If it's used for a few minutes then closed, it seems to close the lingering processes correctly in most cases. However the one program box that I have which is one of my persistent ones tends to do it all the time now. I tried a clean box, eg renamed the original one and let it create a new one in its place when launched but it didn't seem to help any. =( Other boxes like my browser seem to do this once in a blue moon but otherwise work a good chunk of the time. I'll try to keep testing and see if I can figure out any reason why the one box does it more than the others though.
Update:
While looking around for a bad rule I let the processes hang around on their own. I didn't get exact times but them seemed to finally close on their own after about ten minutes.
Upon removing the leader/lingering process rules and trying again there was no change.
Once again this seems to occur more often when a program is launched then exited almost immediately. If it's used for a few minutes then closed, it seems to close the lingering processes correctly in most cases. However the one program box that I have which is one of my persistent ones tends to do it all the time now. I tried a clean box, eg renamed the original one and let it create a new one in its place when launched but it didn't seem to help any. =( Other boxes like my browser seem to do this once in a blue moon but otherwise work a good chunk of the time. I'll try to keep testing and see if I can figure out any reason why the one box does it more than the others though.
Update:
While looking around for a bad rule I let the processes hang around on their own. I didn't get exact times but them seemed to finally close on their own after about ten minutes.
Goo.gl/p8qFCf
-
- Sandboxie Support
- Posts: 3523
- Joined: Thu Jun 18, 2015 3:00 pm
- Location: DC Metro Area
- Contact:
Re: 5.09 Beta Available (latest version 5.10 RC)
Yes, this is what we do to test rcpss... launch and then quickly exit programs...and then relaunch them again, and if the program is launched, then exits..it can cause problems, add to it...try and start the program right up rapidly after exiting.Once again this seems to occur more often when a program is launched then exited almost immediately. If it's used for a few minutes then closed, it seems to close the lingering processes correctly in most cases.
If you're exiting a program before it registers with the OS (which RCPSS monitors) then that can cause a problem. As RCPSS and it's children will wait. And wait. As RCPSS looks for event IDs registered with the OS.
A good test would be to run a program.....exit it right away...and then bring up another program...let that program load and then exit normally. You should see everything exit the sandbox and those event ID's register...and when they do, and then you exit that program, RCPSS notices the event in the OS has exited. It will then start shutting down as well.
You should see less problems with "forced" applications. As they "load" in a different way, and that timing is changed.
-
- Sandboxie Support
- Posts: 3523
- Joined: Thu Jun 18, 2015 3:00 pm
- Location: DC Metro Area
- Contact:
Re: 5.09 Beta Available (latest version 5.10 RC)
There is legacy logic in SBIE from Ronen along with new logic from Tom to address this issue. Merging the 2 is a complicated process and has to be done in steps. It has been done over many, many beta's know. But there so many variables we have to tread lightly.
Re: 5.09 Beta Available (latest version 5.10 RC)
OK, I recreated my issue in a VM and it seems to be due to the odd way I set up and use templates. I'll try to explain below but it might not make sense at first.
Basically, I have a lot of boxes that shared the exact same rules so I created Templates for these shared rules. Here are some fake examples:
[Template_RuleSet1]
Tmpl.Title=RuleSet1
Tmpl.Class=Security
ClosedFilePath=C:\Folder\Folder
ClosedFilePath=C:\Folder2\Folder2
[Template_RuleSet2]
Tmpl.Title=RuleSet2
Tmpl.Class=Security
ClosedFilePath=C:\Folder3\Folder3
ClosedFilePath=C:\Folder4\Folder4
ClosedFilePath=InternetAccessDevices
Then on an app I can add them as templates rather then adding each path again
[AppBox]
Enabled=y
Template=RuleSet1
Template=RuleSet2
There's actually a ton of paths in my real INI but this seems to now cause the lingering issue somehow where before it did not but ONLY when more than one such template is in use for a single box. It's far easier to change one template than many boxes when a change is needed and even better when a new box is created as all I need to do is add the template and the paths are protected. It's weird that this would cause them to linger and I suppose I could just create a new Template that merges multiple templates into one for those boxes that make use of the paths in both as a workaround. Hopefully I didn't confuse you even more.
Basically, I have a lot of boxes that shared the exact same rules so I created Templates for these shared rules. Here are some fake examples:
[Template_RuleSet1]
Tmpl.Title=RuleSet1
Tmpl.Class=Security
ClosedFilePath=C:\Folder\Folder
ClosedFilePath=C:\Folder2\Folder2
[Template_RuleSet2]
Tmpl.Title=RuleSet2
Tmpl.Class=Security
ClosedFilePath=C:\Folder3\Folder3
ClosedFilePath=C:\Folder4\Folder4
ClosedFilePath=InternetAccessDevices
Then on an app I can add them as templates rather then adding each path again
[AppBox]
Enabled=y
Template=RuleSet1
Template=RuleSet2
There's actually a ton of paths in my real INI but this seems to now cause the lingering issue somehow where before it did not but ONLY when more than one such template is in use for a single box. It's far easier to change one template than many boxes when a change is needed and even better when a new box is created as all I need to do is add the template and the paths are protected. It's weird that this would cause them to linger and I suppose I could just create a new Template that merges multiple templates into one for those boxes that make use of the paths in both as a workaround. Hopefully I didn't confuse you even more.
Goo.gl/p8qFCf
-
- Sandboxie Lead Developer
- Posts: 1638
- Joined: Fri Jan 17, 2014 5:21 pm
- Contact:
Re: 5.09 Beta Available (latest version 5.10 RC)
5.10 has been released.
Re: 5.09 Beta Available (latest version 5.10 RC)
Good stuff. Will you make a post in the announcement section?Curt@invincea wrote:5.10 has been released.
Sandboxie + SUA + DEP
Windows Firewall + NAT Router
Drive SnapShot (on-demand)
Windows Firewall + NAT Router
Drive SnapShot (on-demand)
-
- Sandboxie Support
- Posts: 3523
- Joined: Thu Jun 18, 2015 3:00 pm
- Location: DC Metro Area
- Contact:
Re: 5.09 Beta Available (latest version 5.10 RC)
It's on the Sandboxie website. It's the new Stable that replaced v5.06, it does not differ from the RC.
Re: 5.09 Beta Available (latest version 5.10 RC)
Minor issue, but I guess you forgot to change the release date.Sandboxie version 5.10 ... Released on 16 February 2016
-
- Sandboxie Support
- Posts: 3523
- Joined: Thu Jun 18, 2015 3:00 pm
- Location: DC Metro Area
- Contact:
Re: 5.09 Beta Available (latest version 5.10 RC)
well.. the 5.10RC was 2/22. The Stable v5.10 was 3/1. But they're identical.
Re: 5.09 Beta Available (latest version 5.10 RC)
I'm with osbron. Binaries might be the same, but 5.10 Final/Stable was released on 1 March 2016.Craig@Invincea wrote:well.. the 5.10RC was 2/22. The Stable v5.10 was 3/1. But they're identical.
Windows 8.1 x64/x86 EN | Sandboxie latest beta or stable | All software latest versions unless stated otherwise
-
- Sandboxie Support
- Posts: 3523
- Joined: Thu Jun 18, 2015 3:00 pm
- Location: DC Metro Area
- Contact:
Re: 5.09 Beta Available (latest version 5.10 RC)
Obviously, that as posted on the site for a reason. So, I'm deferring to the OP that handles that part of the site.. The list changes reflects the date however. I will see if they want to edit.
Re: 5.09 Beta Available (latest version 5.10 RC)
Good eye, Osbron.osbron wrote:Minor issue, but I guess you forgot to change the release date.
Bo
-
- Sandboxie Support
- Posts: 3523
- Joined: Thu Jun 18, 2015 3:00 pm
- Location: DC Metro Area
- Contact:
Re: 5.09 Beta Available (latest version 5.10 RC)
That's been corrected.bo.elam wrote:Good eye, Osbron.osbron wrote:Minor issue, but I guess you forgot to change the release date.
Bo
Re: 5.09 Beta Available (latest version 5.10 RC)
5.10 works fine here on Win10 x64. I haven't seen any rpc -1 and similar errors since I went back to win10 again about two weeks ago
Sandboxie 5.19.4 personal lifetime license user || Win10 x64 Pro CU (up to date) || ESET SS 10+ x64 || AppGuard 4+ || Firefox 54+ x64 || UAC on
Who is online
Users browsing this forum: No registered users and 1 guest