No, I disabled “Enable realtime scanning of files on network” as I aware of the performance issue.
I read from the other thread on USN journaling issue causing the cmdagent.exe high cpu usage issue, thus I set the IMDisk to create an EXFAT RAMDrive instead of NTFS for time being.
So far, EXFAT RAMDrive is doing well. Let see if this will fix the issue.
Just FYI, I reinstalled Windows and set up almost same configurations: issue appears again.
I use Everything (always monitors file changes) and BigMIND (backup software, also monitors file changes) that might involved in.
For now I run following command at boot and when cmdagent.exe starts eating CPU, which immediately drops CPU usage:
fsutil usn deleteJournal /n R:
fsutil usn deleteJournal /n S:
25 September 2020:
Using EXFAT filesystem as RAMDrive for the past 4 days = no cmdagent.exe 100% CPU usage.
Just now, I tested with NTFS RAMDrive again and within 1 hour +, cmdagent.exe 100% CPU usage again.
Conclusion = stick with EXFAT.
Eventually, I just gave up and use EXFAT file system for the RAMDrive. The cmdagent.exe high cpu usage never come back after changing to EXFAT.
deleteJournal is just a temporary solution as NTFS will recreate the journal and the cmdagent.exe high cpu usage happen again.
EXFAT doesn’t have journaling feature, but with RAMDrive, that feature is hardly matter. Hmmmm…
You’re right, stop using NTFS for RAMDrive is one of the available options.
For my case I have to use NTFS compression for S: so completely avoiding NTFS is not possible, but I indeed changed R: filesystem to FAT32 (because RAMDrive software does not support exFAT as default filesystem) and high CPU usage problem loosen a bit now.
Oh…if you require NFTS compression, then there isn’t any choice. 
As for EXFAT, ImDisk Toolkit RAMDrive supports EXFAT. It is open source too. ImDisk Toolkit download | SourceForge.net
Better use EXFAT since FAT32 has 4GB single file size limitation. ;D
Same issue here:
So I unmounted it and recreated it with exFAT.
Now the CPU load is normal again.
Digitama, thanks for the workaround! :-TU
But since I’m on 12.2.2.7062 the problem does still exist.
The issue still exists and easily produceable. 
Glad that workaround can help others with similar issue. 
Hi FN2PGF & Digitama,
Our developers are trying to solve this issue.
Could you please provide us the performance log for further investigation.
We will reach you through Private message to get required logs. Thanks in advance.
Update:
I need to use symbolic links, so I’m back to NTFS as they don’t work with exFAT.
Now I’m on 12.2.2.7098 and the problem persists.
I recreated the RAM Disk on the running system and now the 100% has disappeared.
Let’s see if and when it returns.
This does seem to be an ImDisk issue as I’ve tried to replicate this with a different RAM Disk provider and various formats, with no problems showing and I’ve been using a RAM Disk for years for Temp Files and Folders
I’m using Comodo Firewall much longer than ImDisk.
This issue hasn’t been there since the beginning, it may have come with an update.
While Comodo provided some updates last year, ImDisk hasn’t been updated for years.
Let’s see if I can provide some information with the performance log.
By the way:
I have the same issue on two different computers.
Just wondering out loud. Could you check if ImDisk is being logged in HIPS being blocked from accessing Comodo processes in memory?
As you can see from the dates between my replies, the issue disappeared magically - and is now back.
Unfortunately not, as I use only firewall.
Auto-Containment, HIPS, VirusScope and Website Filtering are disabled.
But I got a message from development in January and I enabled the Perfomance Toolkit, so I can now follow the instructions and return the trace files.
Did you recently make changes to your system that could account for the change?
Nothing except the usual monthly Windows updates.
I’m glad if I can use the computer with no issues.
I would like to add info about my setup:
Comodo info
Comodo Firewall 12.2.2.7098
Firewall - Enabled, Custom Ruleset
HIPS - Disabled
Auto containment - Disabled
Viruscope - Disabled
Antivirus - Not installed
Windows
Windows 10 Pro 20H2 64-bit 19042.928
Other security software
none (only built-in Windows Defender)
Machine specs
Intel Core i7-7700 3.6 GHz, 4 cores + HT
64GB RAM
Additional info
ImDisk RAM Disk with 22 GB
After a restart it works fine first. The high CPU load comes later after a while.
EDIT:
After a restart and an uptime of 96 minutes with normal operation the 100% CPU load came back.
EDIT2:
I attached an image how it looks like in Process Explorer.
Just thinking out loud…
Wouldn’t adding ImDisk (and other parts of it) to “Don’t detect shellcode injections in these applications” do the trick?
Help link: Miscellaneous Settings, Virus Protection Software | Internet Security | COMODO
If no restart is required, then: no, it does not.
If yes, then I have to reboot and see if the setting brings any joy.