So I want to move this folder: C:\ProgramData\Comodo\Cis\lmdb
to my RamDrive where CIS can sloppy write ■■■■ all ■■■■■■■ day, I don’t care.
But I can’t move it because it’s constantly in use. “The process cannot access the file because it is being used by another process.”
If I safe startup my ramdrive isn’t there either, so can I install this in a certain fashion and remap these folders before the folder gets in use or something? Any program I can force to shutdown so I can remap?
C:\ProgramData\Comodo\Cis>rmdir /S /Q lmdb
lmdb\cmddata - The process cannot access the file because it is being used by another process.
lmdb\cmddata-lock - The process cannot access the file because it is being used by another process.
lmdb\cmdurl - The process cannot access the file because it is being used by another process.
lmdb\cmdurl-lock - The process cannot access the file because it is being used by another process.
lmdb\vcact - The process cannot access the file because it is being used by another process.
lmdb\vcact-lock - The process cannot access the file because it is being used by another process.
Ugh, I just ended a nasty 2-hour debug session with CIS Pro and SolidWorks 2020. :-TD So here is a word of caution to those brave enough to dive into the advanced settings and setting up their own CIS rules.
The reason I’m posting in this thread is I was having a somewhat similar issue with constant disk writes by CIS on my SSD-equiped laptop. The issue was that whenever I opened SolidWorks 2020, the CPU fan would pick up speed and there was constant periodic write access to my SSD. I opened Process Explorer to inspect what’s going on and looked at the disk access graph. The CPU usage was about constant 10% of which cmdagent.exe had 5%, but the I/O history was more interesting (see the attached image; blue are reads and purple are writes).
I could literally hear the CPU squeaking like every 10 seconds when the write spike was triggered. CIS logs didn’t show anything, but running Process Monitor showed constant WriteFile API calls to C:\ProgramData\Comodo\Cis\lmdb\cmddata by cmdagent.exe and during this debug session I managed to accumulate about 6 GB of disk writes to this file just by having SolidWorks open and minimized. The cmddata file itself didn’t seem special as it was roughly 100MB in size. Disabling CIS logging had no effect. I temporarily disabled HIPS with no effect either. Disabling antivirus or virus scope did not help. But when I disabled the auto containment, much to my surprise the writes stopped immediately, and even the CPU fan stopped as the CPU usage went down to nearly zero. I re-enabled auto containment while solidworks was still running, but that did not re-trigger the issue. My suspicions were correct when I re-enabled all protections and restarted SolidWorks to find out the disk writes returned. After disabling the auto-containment one more time I noticed that a new process appeared in the Process Explorer next to solidworks.exe.
C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS\cef\swCefSubProc.exe
It would seem that the creators of Solidworks forgot to digitally sign this file, and as a result, CIS determined that the file rating was “Unrecognized”. Therefore, every time this process started it would have to automatically start in a virtual environment. But coupling this situation with another bug that caused this process not to run made everything worse. Since Solidworks detected that the process didn’t start, it would try to restart it only to have it run in a virtual environment and fail to start again, ad infinitum. As soon as I disabled auto-containment, this process popped up in Process Explorer and the writes stopped. I tested it by closing solidworks and changing the “swCefSubProc.exe” file rating to Trusted in the advanced settings file rating list. After re-running Solidworks everything was fine and silent. I realize this was partially my fault since I was the one performing the advanced configuration and disabling the file rating cloud lookup as well as purging the vendor list of most non-microsoft entries, but these are the risks that come with oneself doing the rules manually. I ended up fixing the whole situation by adding the [b]C:\Program Files\SOLIDWORKS Corp[/b] folder to Auto-Containment ignore list.
Anyway, I hope someone finds this post useful, if they’re doing their own custom rules with CIS and see write spikes like those in the picture.
disabling the file rating cloud lookup as well as purging the vendor list of most non-microsoft entrie
I'm assuming from your point of view is that you want to control which apps go online and in some cases which ports its allowed to use. I have a good idea on what you want to do so heres a different approach instead of purging the vendors list. FIRST disconnect the internet. Then go to comodo settings --->click on firewall ---> click on firewall settings -->Add a checkmark on "Create rules for safe applications" ---> click ok. Put all executable files from where soldworks installed from on the firewall block list. Dont forget add the executable files from here too if any C:\Users\****\AppData. Then turn on the internet >:-D
My goal with this type of setup is not to control which apps can go online or not. That can be achieved by the firewall alone. The real reason I disabled cloud lookup and purged the trusted vendor cert list is to control the behavior of the HIPS component. As you may or may not know, CIS comes with a separate online version of its trusted file/vendor list (called Cloud Lookup). If this feature is enabled then the files that Comodo deems safe will be automatically added to the trusted file list (and some certificates will appear in the trusted vendor list as well). This kind of negates the fine control that I am seeking because HIPS is programmed to ignore all files that are assigned a trusted rating in the file rating list and does not show any alerts for them. But the fact is that if Comodo deems these files safe does not necessarily mean that I myself deem them safe as well.
Consider the following scenario. I have a program installed on my PC that does some networking stuff i.e. a web browser. Now suppose I leave the config at its default and CIS finds out that firefox.exe is safe and adds it to the trusted files list, thus disabling HIPS alerts for it. Now suppose I visit a website with an exploit present that manages to penetrate my browser and perform some remote code execution, dropping malicious executable files or modifying certain other files on my disk. This will potentially be missed by the antivirus program since HIPS ignores trusted files completely.
Now consider a second scenario where I configured my CIS the way I mentioned above. Even though firefox.exe is supposed to be safe, it is still watched over by HIPS and will show alerts for all its actions. But let’s say that I’ve already answered the majority of these alerts and am not seeing any new ones because the permissions are already in place. Then the exploit happens and firefox.exe tries to execute some code that drops an arbitrary executable file in my Windows folder. I will see a HIPS alert that firefox.exe is trying to modify a file in my Windows folder and immediately become suspicious of what’s happening.
This is how I’ve learned to configure CIS a number of years ago, and I’m sticking with this type of configuration. The fact that Solidworks ended up in this mess was merely a coincidence.
CISfan: No, it’s unticked.
Yes, I know that generates a crapload of alerts, but its only on first and few consecutive runs of an application. If I don’t want to receive alerts for a given program I just set it to “Allowed application” on first alert. I can also set similar permissions for all programs in a given folder and its subfolders. I can exclude a whole family of programs by simply adding a digital certificate to the trusted vendors list. Just recently I had an interesting session of rulemaking while trying to configure CIS for Atmel/Microchip Studio 7 that comes with its own avr-gcc toolchain where some executables are unsigned and the program creates new batch files with random filenames during compilation. Took me a while to get CIS not to complain.
The entry “C:\Users<user>\AppData\Local\Temp\make*.bat” has a custom HIPS ruleset. It is only allowed to execute files in the avr-gcc toolchain folder.
