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]
I hope that helps.
OK, that works - sort of, somewhat.
You can see in the list in the 2nd column of my original post the file size for each file.
When I open the 1st file (10,468KB), I see 183 records spanning the time of 12:00Am to 4:00AM. For the very small amount of info in each line, it is hard to envision where the 10MB worth of data is.
When I open the 2nd file, nothing is displayed in the log viewer (even though there is supposedly 11MB of data there).
The third file displays only TWO records (at a time of 4:04:30 and 32 AM), despite being 10MB.
And the 4th file displays nothing.
So using a binary file viewer to look at the 2nd file (which shows up empty in the Comodo viewer) I see a lot of this stuff:
00006DD1 00006DD1 0 <File UID=“{68B1B446-E20E-4181-97D1-F8D013E51EAD}” Flags=“0” Filename=“C:\WINDOWS\pchealth\helpctr\DataColl\CollectedData
0000905A 0000905A 0 tableAlertsAlerts
0004BFCF 0004BFCF 0 <File UID=”{4AFE1DAE-D6CC
0004CE85 0004CE85 0 <File UID=“{649F9A9C-C38A-450B-AE63-973A02029CAB}” Flags=“0” Filename=“C:\WINDOWS\pchealth\helpctr\DataColl\CollectedData_40658.xml” DeviceName=“C:\WINDOWS\pchealth\helpctr\DataColl\Collecte
0004DEB9 0004DEB9 0 <File UID=”{E7700697-2142-4B42-AF75-8A683EFAE275}" Flags=“0” Filename=“C:\WINDOWS\pchealth\helpctr\DataColl\CollectedData_39777.xml” DeviceName=“C:\WINDOWS\pchealth
0004EF11 0004EF11 0 <File UID=”{4C575F26-5FBD-40BE-9123-83BAA0D24116}" Flags=“0” Filename=“C:\WINDOWS\PCHealth\HelpCtr\DataColl\CollectedDat
0004FF69 0004FF69 0 <File UID=”{9179031C-223E-42E6-8A00-E54FC3D70CEB}" Flags=“0” Filename=“C:\WI
00050FC1 00050FC1 0 <File UID=”{057FA2E6-9AD2-4E47-A
00051E77 00051E77 0 <File UID=“{405F04D4-002A-4E57-BC84-222A2EB34C0F}” Flags=“0” Filename=“C:\WINDOWS\PCHealth\HelpCtr\DataColl\CollectedData_40750.xml” DeviceName=“C:\WINDOWS\PCHealth\HelpCtr\DataColl\CollectedData_4
00052ECF 00052ECF 0 <File UID=”{BAF81244-5F82-46DA-9418-1D3F4336A911}" Flags=“0” Filename=“C:\WINDOWS\PCHealth\HelpCtr\DataColl\CollectedData_40766.xml” DeviceName=“C:\WINDO
00053F27 00053F27 0 <File UID=”{B6BF358D-19CA-4F7D-A091-A6234D4B0F08}" Flags=“0” Filename=“C:\WINDOWS\PCHealth\HelpCtr\DataColl\C
00054F7F 00054F7F 0 <File UID=”{FF2F9AA7-2193-4302-BDBE-BA265CE598EC}" Flags=“0” File
00055FD7 00055FD7 0 <File UID=“{B291BC67-
00056E8D 00056E8D 0 <File UID=”{BC3733A2-2647-4E55-B66A-8F50CE07230A}" Flags=“0” Filename=“C:\WINDOWS\PCHealth\HelpCtr\DataColl\CollectedData_40830.xml” DeviceName=“C:\WINDOWS\PCHealth\HelpCtr\DataColl\Coll
00057EE5 00057EE5 0 <File UID=”{CBF42179-AB1E-4726-AC36-EEE6D29158B4}" Flags=“0” Filename=“C:\WINDOWS\PCHealth\HelpCtr\DataColl\CollectedData_40848.xml” DeviceNam
00058F3D 00058F3D 0 <File UID=“{2B7920E3-F678-4036-A634-C9AB8B84D5E3}” Flags=“0” Filename=“C:\WINDOWS\PCHealth\HelpCtr
00059F95 00059F95 0 <File UID=”{AA102856-BD06-4B64-A27F-EC50D25D9E87}" Fla
0005AFED 0005AFED 0 <File UID=
0005BEA3 0005BEA3 0 <File UID=“{CD7A6A43-1C5E-41F0-8472-589488879597}” Flags=“0” Filename=“C:\WINDOWS\PCHealth\HelpCtr\DataColl\CollectedData_40906.xml” DeviceName=“C:\WINDOWS\PCHealth\HelpCtr\Da
0005CEFB 0005CEFB 0 <File UID=”{1E2FE4DE-B1A7-48A4-83D1-279A18565BCC}" Flags=“0” Filename=“C:\WINDOWS\PCHealth\HelpCtr\DataColl\CollectedData_40924.xml
0005DF53 0005DF53 0 <File UID=”{E875C908-F5CA-413F-8C80-946E0AEF7CBE}" Flags=“0” Filename=“C:\WINDOWS\PCHea
0005EFAB 0005EFAB 0 <File UID=”{021C06B8-FB17-4323-B214-01941C9
WHY would I see this in a file written by Comodo?
I haven’t looked at the Comodo log function in the past, but at least with the current version, it seems like there are some major problems with this whole module in a variety of different places!
So no one knows what this junk is in the log I sample I posted?
Does anyone really look at their Comodo firewall logs here?
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.
[attachment deleted by admin]
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.
More mysteries.
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.
Well, we know where the data is at least. I am still curious as to WHY Comodo is messing around with stuff in C:\WINDOWS\pchealth\helpctr\DataColl.
What is it doing with that data? WHY is it doing something with it? WHY is it putting it into a Comodo log file?
I suspect that CIS isn’t doing anything other than watching what Windows is doing, changing its rules (based on your settings) because of Windows actions and then logging those events.
CIS is storing it for you to look at, there is no other purpose. They’re your logs, not Comodo’s. Comodo never sees them unless you manually give them to Comodo.
[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.