Using latest SBIE in conjunction with AppGuard latest build. On 32 bit systems (Vista and XP) they compliment each other extremely well. However on Win 7 64 bit there are issues with forced launches. Right click and send to works fine but force launch generates rcpss and dcomlaunch issues where they fail to start.

SBIE2204 Cannot start sandboxed service RpcSs (-1)
SBIE2204 Cannot start sandboxed service DcomLaunch (-1)
SBIE2204 Cannot start sandboxed service RpcSs (-1)
SBIE2204 Cannot start sandboxed service RpcSs (-1)
SBIE2204 Cannot start sandboxed service RpcSs (-1)

Pretty sure AppGuard is properly configured to ignore SBIE executables in the memory guard and gaurded apps are allowed to write to the sandbox. That works on XP & Vista 32.

Does SBIE intercept the forced launch in a different way on 64 bit or is it a Win 7 issue perhaps that is triggering the conflict not apparent on other OS's? Resource Access Monitor appended.

Anyone got round this?

Thanks

snipped. --tzuk

I am having exactly the same problem as Chris. Hopefully, someone here can point us to a possible solution.

Thanks!
Dave

I need a few more details about your problem. You didn't say which version of Sandboxie you use, and what is AppGuard, and where it can be downloaded. Thanks!

Tzuk, 3.60 x 64. Information on AppGuard and download here - http://www.blueridgenetworks.com/products/appguard.php .

sandboxiercpss.exe. sandboxiedcomlaunch.exe, sandboxiecrypto.exe need to ne added to the memory guard exclusions and the sandbox container has to be added with read/write permissions in the guarded apps protected, exclusions, restrictions settings.

Basically it separates User Space and System Space and denies execution from user space from anything other than guarded apps which run with stronger than LUA restrictions. The apps you guard are also likely the apps you will sandbox.

Let me know if you need anymore.

Thanks

Thanks for the link and the advice about checking the configuration. I will probably have some answer in a few days.

I did not see the SBIE2204 errors that you report cj716 and Dave53, but I did see erroneous behavior with AppGuard.

Anyway, the problem has to do with the WINSXS mechanism in Windows, which resolves DLL dependencies. Or more accuarely, with Sandboxie's implementatoin of WINSXS, which lives in the SandboxieRpcSs.exe program.

Case (1) When you use Run Sandboxed, SandboxieRpcSs.exe is invoked by Start.exe.
Case (2) When you invoke a forced program, SandboxieRpcSs.exe is invoked by the forced program.

You probably don't have Start.exe in your Guard Apps rules, but you definitely have the browsers listed there.
This means that in case (1), SandboxieRpcSs.exe is not a guarded app. In case (2), it is a guarded app.

* * *

BOTTOM LINE: In the Guarded Apps tabs, modify the browser settings to have Privacy=No. Also, add SandboxieRpcSs.exe to the Memory Guard exceptions in the Advanced tab.

I don't know to what extent this affects the protection of AppGuard, but it is the only way to make a guarded SandboxieRpcSs.exe talk to a guarded browser process.

Thanks Tzuk, but I had SandboxieRpcSs.exe in the Memory Guard exceptions and changing privacy to 'no' made no difference. Throws a SBIE2399 DcomLaunch fails with error 1066 then freezes up for a while then throws SBIE2204 Cannot start sandboxed service RpcSs (-1), SBIE2204 Cannot start sandboxed service DcomLaunch (-1) and SBIE2204 Cannot start sandboxed service RpcSs (-1) over and over until you force termination.

I'll try forcing in the default box to make sure its not my customisations.

Cheers

Edit: Tzuk, your suggestion works when AppGuard is set to high which is the default. I use locked-down. This may mean I can't use both together, Interested in your thoughts?

Not sure what else I can suggest. I explained the problem:

When SandboxieRpcSs.exe is started by a guarded process, it seems to inherit the guarded status, and this causes AppGuard to interfere with correct operation of the Sandboxie WINSXS mechanism.

I think you have to contact AppGuard and ask them for a "strong" exception, i.e. a list where you can say that even though SandboxieRpcSs.exe was started by a guarded process, it should not be considered a guarded proces itself.

As always thanks for the time you have spent on this issue which is in effect nothing to do with your product. Your commitment to making Sandboxie compatible with other, even relatively obscure, products is laudible.

I will contact BRN. Before doing so though, as this is only an issue on 64 bit machines, can you confirm if Sandboxie works differently in this regard on 32 bit systems. If not it is likely the way BRN have chosen to implement 64 bit protection rather than differences in your own product causing different reactions on different OS's.

Thanks

This aspect of Sandboxie works the same on 32-bit and 64-bit, but what fails in SandboxieRpcSs is actually Windows code from the SXS.DLL that is being invoked. I can't tell you if SXS.DLL on 32-bit Windows behaves differently than its 64-bit counterpart, but I don't think so. In any case, and as far as I know, that code in SXS.DLL shouldn't be trying to communicate with other processes.

Brilliant. Thanks

Thanks for taking the time to look into this tzuk. If the problem has nothing to do with variables in 64-bit Win 7, I wonder if it may be caused by differences in the way AppGuard works in a 64-bit environment. Hopefully their developer will have time to review this.

Your support is stellar as always.

Dave

No problem guys. With so many complex interactions between programs on the PC, I look at every problem report as a potential to make Sandboxie a bit better.

I updated the Known Conflicts page to list AppGuard, please let me know if you have any updates on this problem.

We'll keep you posted tzuk.

From Blue Ridge Networks:

We do have the concept of Power Applications in our enterprise version of AppGuard. Power Apps are immune from AppGuard protection whether launched from a guarded application or directly. We'll consider exposing this feature in the future for the consumer version, but we are really trying to keep the consumer version as simple as possible.

Looks like it might be on Known Conflicts for a while.

Cheers