I’m using CIS 10.0.1.6258 on Win10/64, and Firefox 56.0.2 (64 bit).
Every time after logging into Windows and starting Firefox within the Sandbox, FF startup is delayed by 2-3 minutes. When closing FF and reopening it, the problem does not occur.
I saw that explorer.exe is busy at 25% (100% on one core) between clicking on the FF icon and it finally shows up. As a developer myself, I’ve analyzed the problem using WPR/WPA (Windows performance recorder/analyzer). I found out that most of the time is spent inside ntoskrnl.exe!RtlCompareUnicodeString. The relevant part of the callstack is:
So, the sandbox itself (cmdguard) excessively compares strings when interfering process creation. I was anticipating these strings are retrieved from disc. Looking at the file I/O operations shows that c:\windows\system32\drivers\fvstore.dat is heavily accessed during the same period of time within the CPU is busy.
Before reporting this as a bug - and I don’t want to reinstall anything again as the last time is not so long ago, or lose any data within the sandbox - I’d like to ask if this is a known issue or happens/-ed to someone of you, too.
You should update CIS to the newest version to check if issue still persists. But you have to uninstall and install using standalone installer because it is not currently offered through the internal program updater yet.
I always use the latest versions. I’ve just updated few days ago, so I didn’t check once again. Now I see it’s from 29 Aug. Impossible. … Ok, updated. Don’t know if that’s the one you mean (10.0.1.6294)
(BTW, your link “newest version” is empty)
First, I’ve reinstalled the version I had (10.0.1.6258). This made the problem disappear. Unfortunatelly, the uninstallation deleted all Sandbox data. I didn’t think about this before, but it would really have been nice if the uninstaller would at least point one to this fact. User data should never be deleted by an application, at least not without asking before. Anyway, now I’m running 10.0.2.* for a couple of days. The latest 10.0.2.6408 since it came out. I notice that the same problem occurs again, that means, FF start within the sandbox takes longer every day. The symptoms are equal to my first post.
Just for your info. I’ve been running FF in the Sandbox for several days with CIS 10.0.2.6408 with FF56 and now with FF Quantum . . . just timed it and it fully loads with 6 open tabs in 7 seconds. It was a few seconds slower with FF 56, but I never saw any load increase time over several days. This is with Win10 Pro 64
I’ve just tested again: After reboot+login, I start FF out of the sandbox. It shows up immediatelly. I close the instance and start FF within the sandbox. Startup takes one minute. Every consecutive start with no previous instance running is immediate.
Thanks again Ploget. BTW, the size of c:\windows\system32\drivers\fvstore.dat is 12,8 MB currently. If this matters. Just mentioning as the file is accessed all the time during this waiting period as written in my 1st post.
I didn’t use the Sandbox anymore due to the problems. Now I’ve tried again with newer versions available. I’ve uninstalled the firewall and even used the Comodo uninstaller 2.0.3 afterwards, this time. C:\vtroot does not exist anymore. Then installed the firewall again (10.0.2.6420) and started using the sandbox. Only Firefox 57.0.3 (64 bit) is running in the sandbox. But again, browser startup gets slower every day. Same symptoms as already described in detail in my initial post. This way it’s not usable for me.
How are you running firefox in containment? Do you open it from CIS widget, do you open virtual desktop and run from there, did you use run virtual task and selected create a virtual desktop shortcut to then open firefox using the virtual shortcut, or do you use run in containment on regular firefox shortcut?
Also when you are done using sandbox do you ever run the reset containment task?
Hi futuretech, thanks for asking. The first time I ran FF in containment was via Tasks → Containment → Run virtual. There, I’ve checked “Create a virtual desktop shortcut”. So I’ve got a link there with this command line:
"C:\Program Files\COMODO\COMODO Internet Security\virtkiosk.exe" -v "C:\Program Files\Mozilla Firefox\firefox.exe"
I always use that shortcut. Actually, I copied that shortcut to the quick launch taskbar (because desktop icons are always hidden), which I always click.
I’ve already tried resetting containment in the past, but it didn’t help. EDIT: Well, it does help, but then I’m back in time.
might seem like a silly question… are you really sure that explorer issue is caused by that driver? reason why I’m asking is because I experienced some similar issues with explorer not caused by CIS… although on different OS.
you’ll probably need to report it as performance issue and provide relevant data. (assuming some function is not blocked… maybe)
Thanks for your reply. What I see is that explorer.exe is stuck inside a call to CreateProcess. I can not debug it further because when I break into it, it’s inside a syscall. More detail is provided by the kernel logger showing that most time is spent inside ntoskrnl.exe!RtlCompareUnicodeString called by cmdguard.sys, which is obviously a Comodo file. During that period, fvstore.dat is accessed heavily. Unfortunatellly, that’s all I can provide at the moment.