The most current update for Comodo clobbers Sandboxie’s Service Driver. I even tried starting the driver manually and received the following error:
“The Sandboxie Service service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs.”
Reinstalling Sandboxie does not fix the problem. The only fix is to re-install Comodo and not to update. Thinking it might have been a fluke, I tried updating again but just like before, Sandboxie’s driver couldn’t start.
Uninstall Comodo and install Sandboxie. Make sure everything is working and then install Comodo. Make sure that Sandboxie is still working expected. Now update and after you reboot, Sandboxie’s Service Driver will be clobbered.
Sandboxie is optional freeware or payware. Using Vista 32-bit but is likely to effect 64-bit also. Can any one confirm?
It appears the Sandboxie service starts the sandboxie driver which waits for the system to be idle before it places its hooks on kernel code, which CIS 4.1 stops so the driver cannot load and the sevice fails as it cannot start the driver.
What you guys mentioned is correct. From what I understand, Sandboxie must have access directly with the kernel or its security is compromised greatly - therefore defeating the whole purpose of using the application. Is there any work-around solution from the end users perspective or is it a programmer’s fix only?
from what I know I doubt it will ever work again with CIS, from what I can tell CIs is guarding the kernel very thoroughly ( and really that is it’s job) and any other program that wants access in the way sandboxie wants access will not work. CIS is almost working like patch guard is on the x64 bit edition of windows.
There has to be a solution here. No one should have to compromise their security by letting one or the other go. Both pieces of software are the best in their category and worked quite well together before this update. Dennis2 pointed out something interesting - he said that Sandboxie waits for the system to be idle before it loads the driver. It appears at this point, is when Comodo steps in and prevents the driver from loading, right? If Sandboxie’s driver loaded faster, would Comodo leave it alone?
why should i install a program that forbid me to use another program? if comodo defense+ is not asking if i want to let sandboxie run, then theres something wrong.
it would look, as if comodo wants to push their so called “sandbox”.
(and really, thats NOT its job).
no all they did is harden the security of the hooks in the kernel to resolve the KHOBE problem that was reported by Matousec. So what it basically did is make comodo into a kind of patchguard that comes on windows 64 bit.
CIS 4.1 causes more problems and incompatibilities than before.
The security offered by Comodo was good enough, and I don’t think this new “kernel hooking protection” is worth the tradeoff.
I’m back to version 4.0 for now and I hope to see an update that addresses these issues.
Probably yes if you’re paranoiac/security freak and have gazillions of security software installed. I’m perfect fine with FW and D+ alone and I feel no need for installing overwhelming security software.
But you have a point, CIS Free must be compatible with every piece of software/hardware in the world. ;D
I have Sandboxie 3.442 perfectly working with CIS 4.1 in my 32 bit XP SP3.
Of course, while installation of the Sandboxie, when sandboxie wanted me to disable the ‘security softwares’, I disabled both defense+ and sandbox for sometime. Once the sandboxie was installed, I re-enabled it and sandboxie is working without any problems.