I would recommend to try rebooting too as it releases all files from “in use” state.
I’m not sure whether it is possible to add the file “imdisk.sys” (besides the “imdisk.exe” and “imdsksvc.exe” file) to the exclusions too.
Maybe there are more files involved in ImDisk than the three aforementioned ones.
Which ImDisk files did you add to the exclusions?
Alright, will test it later.
I only added “imdsksvc.exe”, as I selected from the “running processes” list.
But I’ll add the other ones before restarting.
Unfortunately no success.
I added all files from ImDisk to the exclusion list and restarted the host.
Again there was no load at first but after around 90 minutes the CPU load goes up to 100% and stays there. :embarassed:
That’s a pity.
Do you know if the issue reproduces on Windows 7?
If it does I could try too and have a look at it.
Nope. Since Windows 7 went out of support, I don’t use it anymore.
Did a quick test and re-created the RAM disk with exFAT: CPU load normal.
For NTFS RAMDisk, does the RAMDisk size matter for the issue to occur?
Let’s say 2Gb instead of 22Gb?
I haven’t tested that yet, because I din’t remember a logical size limit for memory, as I’m on 64-bit and it is not a hard drive, e.g. Large Disk HOWTO: History of BIOS and IDE limits
But I can test that on-the-fly.
Maybe it is not exactly a memory limit which is causing the issue but just the fact that things are just getting (too) big in numbers (shouldn’t be but you never know).
It would be great if you could check whether RAMDisk size plays a role in the issue to happen. Maybe the issue behaves differently with smaller or bigger RAMDisk sizes, just thinking…
Thanks in advance for trying.
Hi FN2PGF,
We have already submitted the performace logs provided by you to the developers. They are looking into it. We will gte back to you as earlier as possible.
Hello! One month later I’m literally dying of curiosity…
Hi, I’m back to Comodo, and with latest 12.2.2.8012 the issue still persists.
My RAM drive is about 800MB and I’m not using ImDisk.
Using 12.2.2.8012 Firewall only.
I’ve created a NTFS RAMDisk with ImDisk on Windows 7 Ultimate 64-bit and copied some random files back and forth. ImDisk NTFS RAMDIsk is working fine for me, no high CPU usage.
It is randomly happening and in some cases it took a few days of running to see this issue for me, so it might be why you can’t see it.
RAMDrive is heavily used for storing temporal files.
As Digitama ans FN2PGF reported similar issue, it is clear the issue does exist at least in some conditions. I also see similar reports in Japanese BBS too.
I sent requested log about a year ago. It’s a quite disappoint to see nothing had changed since (including forum reactions :()
Maybe you are right, as I just did a quick file copy test the issue did not occur on my end but it might if I would run it longer and if used to store temporal files.
Have you ever seen it happen right after system boot or only after some days of running?
Do you know ways to trigger the issue to happen immediately?
In general, issues are difficult to fix when they only occur at random intervals and in random conditions maybe that’s one of the reasons why Comodo needs more time to find the cause and to fix it.
Unfortunately not. It’s 3 days of running since it happened last. I would say it’s almost random.
The most possible is just after (re)boot, there is a case that CPU usage go up when system booted, until ramdisk reset (or use of fsutil usn… command)
After 3 years, the problem still persists.
It is clear that Comodo doesn’t care anymore about their customers.
Time to move ahead to other products…
I totally confirm!
I was struggling with that cmdagent.exe problem for long time and always was asked for logs, screenshots or whatever they asked. I was surprised because this problem is here for so long and many people reported it, so I can’t understand why they STILL need logs (and more logs, and more logs).
Good programmer should look into code and figure out what is wrong based on sympthoms users described.
But - good news is - after I switched to exFAT for my ImDrive ramdisk, cmdagent.exe no longer eats my resources. I hope it stays that way. But it’s not a solution, it’s workaround (like when you have a car that stops at 3rd gear, so you switch from 2nd to 4th and producer says “well, problem solved!”).
And I know that problem is very old and this topic is old too - but I want to add that I thank you for investigate it and workaround.
The problem is they don’t ask for the right type of logs which would be a memory dump of cmdagent when high cpu usage is observed. Also this is not easy to reproduce as I never seem to get high cpu when I tried using ImDisk, even with the real-time AV enabled. It would also help to provide basic steps on how you can cause the issue to occur.
What if basic steps needs whole day of working?
It’s not that cmdagent is utilizing cpu from the beginning. It starts doing it after whole day of working (and not even every day). So I doubt that someone will reproduce 200 steps I made on my PC to reproduce problem.
As I said - symptoms and looking into code for bugs.
I get that but if you can pinpoint when it happens it would make it easier to identify what causes it, they can’t just look at the code if they don’t know what part of the code is causing the issue. Does it happen when writing large amount of data to the ram drive? Or does it happen when small but constant read or write access on the ram drive? Can it be replicated if you write a big file or copy/move a large file or large amount of files to or from the ram disk?
Edit: You can also check which thread(s) are using the most CPU that might point to which part of the code that needs to be looked at. Now obviously I’m not getting high CPU so this screenshot doesn’t really matter, but if the start address was within cmdagent itself or a comodo dll, then it should shed a light on what part of the code is trouble.
