I have my prefs set to move and save old logs instead of deleting them.
19_03_2012_04_03_49.sdb 10719232 3/19/2012 4:03 AM
19_03_2012_04_03_53.sdb 11673600 3/19/2012 4:03 AM
19_03_2012_04_04_33.sdb 10629120 3/19/2012 4:04 AM
19_03_2012_04_04_34.sdb 10629120 3/19/2012 4:04 AM
These look like some log files. Now, HOW do I view an .SDB file?
Use CIS’s external log viewer. This can be run using the More button found on any event log from within CIS itself or by running the external log viewer manually. It can be found at the following location for a default CIS installation…
[i]C:\Program Files\COMODO\COMODO Internet Security\cfplogvw.exe[/i]
These forums are mostly volunteer run. So, sometimes a bit of patience maybe required.
It could be that the logs were generated under a previous version of CIS and are incompatible, but I wasn’t aware of any recent changes of this nature. Which version of CIS do you have currently?
However, can you confirm what you’re seeing in the external log viewer (some pictures maybe)… the log viewer is actually broken into 6 distinct sections and is date sensitive (which I guess you already know). So, you don’t get the whole logged displayed at the same time.
I’m not sure that it would be useful looking at the file in a Hex (binary) viewer since it’s actually a database of mixed field types. As for the file/folder name you’re seeing… why not? CIS has a HIPS component and that needs to track the changes of files and the logs do contain a lot of different things (firewall, defense+, AV, alerts, tasks as well as config changes). But, I can’t be sure what we’re looking at here from what you’ve posted.
You can always email me a zipped log to see if I can read it.
edit: No, I don’t think it can be a compatibility issue. I just opened & viewed a log from last October and that worked fine.
edit2: But, I did note that it doesn’t update the Date Filter correctly on the left panel & the record count seems to be per log section for each opened log, not for the total log.
As you can see from the date in the log list, these logs are from 3/19 (a couple of days ago). They are from the most current version of Comodo firewall which is v5.10.228257.2253.
As I explained above, I used the binary viewer only because the Comodo viewer app claims that a 10MB file doesn’t contain any records. Well, it DOES contain data and Comodo put the data there. I didn’t do it.
I’ll email you the file and you can look at it. It reduces from 11MB to about 1MB.
I suggest that people who read this thread do some log exports and then see if you can actually open all of them successfully and if they contain data. If you have a 5MB logfile but Comodo says it can’t find any data, then you know that something is not working right.
I received the log, thanks. I can confirm that whilst being 10MB it does (according to the external log viewer) only contain one entry (see attached). On examining the log it does indeed contain many records relating to the C:\Windows\PCHealth folder. I’ve no idea what that is about or why they are there. But, I did note that the log also contains SQL commands for table creations as well, I suspect the log might actually contain what is needed to create a whole SQL database.
Your suggestion about using Export will unfortunately not work, because the external log viewer’s Export function only allows for selected records to be exported in HTML format. A better idea might be to reduce the log size to 1MB in CIS in order to provoke an earlier create/move operation.
The only other thing that I can recommend is that you report this to Comodo as a possible bug.
Even the logs that HAVE data in them have that PCHealth stuff showing in them!
But before I jump through all the hoops to officially report this as a bug, I was hoping that other people (such as yourself) could see if they are getting the same problem. It isn’t hard to do.
Just go to Preferences | Logging
The default log setting is to “Delete it and create a new file” when full. Instead, I ask that you change the setting to “Move it to…” (when full).
You can then open the external log viewer, then load the saved log and see if you get anything displayed. Or just look at with a binary viewer (that shows ASCII translations) and see if the file is littered with PCHealth garbage.
I do not know what you are referring to about “Export”.
I just got the latest log dumped to my collection folder. It is 52MB in size. It has 456 viewable Comodo records (hardly enough to justify a size of anywhere near 50MB).
Looking at the file in the binary viewer, I see much PCHealth junk. Either Comodo has an error or they are burying extra data in the log file as perhaps some sort of debugging help but they haven’t told people what else they are putting in the folder.
As I previously noted, when you open a saved (moved) log file in the external log viewer, it doesn’t seem to update the record count. I suspect that this record count is actually the current log that the external log viewer opened by default… which is actually a lot of records if the log file has just been changed. In fact, 50MB in just a few days also sounds very large.
Anyway, try looking the Configuration Changes of the saved (moved) log file in the external log viewer. Depending on CIS’s setting, there can be a lot of very big records in there.
Also with regards to the PCHEALTH folder, depending on Windows settings (error reporting) there can be a fair amount of dynamic activity (and file storage) in this folder.
ALL the FIREWALL records in that file are for Comodo trying to reach out to the licensing server (over and over and over and over…). We are discussing this issue in another thread.
However, you are correct. If I click on the “Configuration Changes” in the tab bar on top, there are 17 records there (from Defense + Application Policy) and if you double-click a record, a small window viewer comes up. This appears to be where all the data is hiding. But WHY is Comodo collecting this info? WHEN is it used and HOW is it used?
Almost all the changes logged in this tab occurred at 4:15AM my time on 3/22/12, which in and of itself is weird because I was fast asleep at that time.
If you’ve always blocked CIS from activating your free license then, I guess, it may keep trying. I’ve never done that myself, so I’m not entirely sure what it might do. Mind you, if you don’t trust a security product, or it’s vendor, then you probably shouldn’t be running it in the first place.
Configuration Changes log: Not exactly not hiding then. I believe the config change log is fairly straight forward… it’s displayed in an old and new style. With what the record looked like before and after the change… whatever that change was. Why? As I explained, usually because of the way you setup CIS (auto-learn in D+ Safe Mode with rule creation on can generate a fair bit) and it’s not exactly Comodo collecting that information… you are or rather your CIS installation is (Comodo doesn’t see it). But, it’s impossible for me to comment on something that I cannot see.
[shrug] Well, unless someone who actually works for Comodo jumps in here to explain what is going on, we are only left with guesswork and will never get the real answer.
Bottom line - There appears to be a lot of stuff other than actual Comodo log records in Comodo’s log files. Why this information is there? Who knows. Maybe sticking this info in log files has a performance impact on Comodo. Again, who knows.
A few thoughts. The part of the logs you provided deals with .xml files of various names which are most likely dynamically generated as part of self checks of Windows. D+ will log what happening under the hood but will only report blocks or when it asks the user. May be D+ logs store more of the under the hood activity than it reports.
In your other topic you report a problem that Radaghast could not reproduce.
You are also hinting at performance impact the logging activity might have. Are you experiencing performance problems which you think might be related to CIS?
In the other topic I suggested to try a clean install and see if the problem persists. That way we know if the problem was caused by a corrupted configuration or not. Seeing this topic I would like to stress even more so to do the clean install.
Since Windows checks seem to be a big part of the D+ logs I suggest to let Windows check the file system integrity by running chkdsk /f from the command prompt and let it check its system files integrity by running sfc /scannow from the command prompt. This is just to be sure Windows is running like it should before doing a clean installation of CIS.