Log files

Speaking from a threat point of view any journaling information will be erased (which if your PC is clean wont be a problem)That said we can still look at the KC in our database and see what was detected (and what it did etc) so its not a total loss. I do know a huge amount about the password/sync features.

Thanks Roy. I am sure my PC is clean ... daily scans, using brain when online, quite safe surfing habits etc.
 
So If I correctly understand in other words it does mean that WSA will behave like after the clean installation, i.e. it will be journaling all executable actions to create a new baseline.
 
Will WSA re-create all logs again?

To be honest I have never removed the contents of the folder while the program is still installed :D Let me test this, one minute!

@ wrote:
To be honest I have never removed the contents of the folder while the program is still installed :D

Yeah, I was too thorough in cleaning old logs on my PC. 
 

@ wrote:
Let me test this, one minute!

It seems that these log files re-created itself in WRData folder:
SystemOptimizer.log
WRLog.log
 
However Sync folder is still empty even if I have run backup & sync. No log files. Strange.

So as I expected the client takes it in its stride:
 
Logs before:
 
Tue 2013-11-26 12:24:59.0408 Scan Results: Files Scanned: 1, Duration: 1s, Malicious Files: 0
Tue 2013-11-26 12:24:59.0689 Scan Finished: [ID: 28 - Seq: 28]
Tue 2013-11-26 12:25:41.0345 Saved the product log to C:Documents and SettingsAdministratorDesktops.log
Tue 2013-11-26 12:27:03.0877 Scan Results: Files Scanned: 20060, Duration: 2m 11s, Malicious Files: 0
Tue 2013-11-26 12:27:04.0205 Scan Finished: [ID: 27 - Seq: 2147000000]
Wed 2013-11-27 03:00:18.0383 Begin passive write scan (26 file(s))
Wed 2013-11-27 03:00:20.0071 End passive write scan (26 file(s))
Wed 2013-11-27 03:00:28.0602 Begin passive write scan (26 file(s))
Wed 2013-11-27 03:00:29.0289 End passive write scan (26 file(s))
Wed 2013-11-27 03:00:35.0477 Begin passive write scan (26 file(s))
Wed 2013-11-27 03:00:42.0774 End passive write scan (26 file(s))
Wed 2013-11-27 13:25:03.0866 Scan Started: [ID: 29 - Flags: 1575/0]
Wed 2013-11-27 13:26:58.0417 Scan Results: Files Scanned: 16283, Duration: 1m 54s, Malicious Files: 0
Wed 2013-11-27 13:26:58.0605 Scan Finished: [ID: 29 - Seq: 2147000000]
Thu 2013-11-28 14:17:14.0148 Saved the product log to C:Documents and SettingsAdministratorDesktopslb4.log
 
I then shutdown the client and deleted everything from the Wrdata folder:
 
Thu 2013-11-28 14:18:47.0554 Begin Installation
Thu 2013-11-28 14:18:47.0616 Installation successfully completed (WSAINSTALL.EXE/0)
Thu 2013-11-28 14:18:47.0663 >>> Service started [v8.0.4.24]
Thu 2013-11-28 14:18:48.0757 User process connected successfully from PID 4016, Session 0
Thu 2013-11-28 14:18:49.0069 Protection enabled
Thu 2013-11-28 14:18:51.0116 Connecting to 45 - 45
Thu 2013-11-28 14:18:58.0476 Saved updated configuration
Thu 2013-11-28 14:19:01.0054 Saved updated configuration
Thu 2013-11-28 14:19:07.0351 Loading package: 4/16777230
Thu 2013-11-28 14:19:08.0710 Saved updated configuration
Thu 2013-11-28 14:19:16.0319 Saved updated configuration
Thu 2013-11-28 14:19:18.0038 Saved updated configuration
Thu 2013-11-28 14:19:19.0163 Saved updated configuration
Thu 2013-11-28 14:19:19.0601 Protection disabled by the user
Thu 2013-11-28 14:19:19.0601 Saved updated configuration
Thu 2013-11-28 14:19:20.0929 Protection enabled
Thu 2013-11-28 14:19:20.0929 Saved updated configuration
Thu 2013-11-28 14:19:27.0382 Scan Started: [ID: 1 - Flags: 551/48]
 
Client did its first scan and created a new set of logs. Its pretty much clean installation so I would advise not cleaning the folder 🙂 I dont use the backup feature so I cant comment on it, support would know more about it than I would.
 
 

OK Roy, that's what I had expected but I didn't erase ALL files in WRData folder, I deleted only *.log files!

Ah OK I went kinda nuclear on the delete!

Roy, 
 
So you mentioned that it is not a total loss due to the data on the Webroot side regarding detections: so that leads me to ask to what extent will recovery from a threat detected following the loss of the log in which the changes were first journaled be affected?
 
Awesome thread here guys... I am learning a lot sitting back reading!

😃 you were more thorough than me :D
 
OK now it is clear what I originally asked ... is it safe to clear *.log files from WRData folder and whether they will be automatically re-created? My so far findings is that all *.log files will re-occure except log files in Sync sub-folder.
 
Maybe someone of Webroot more accustomed to Backup & Sync features can shed more light.

It would be safe to clear the logs, however I would recommend keeping them as it can be very useful for diagnosing certain issues if we have a decent time period of logs to look through. A weeks logs arent as useful as a couple of months logs as we can see trends or patterns emerging.
 
As for if the journaling information being removed we can use the database (as a reference) to see what that infection has done in the past so we can manually repair system damage (i.e if an infecton or indeed a legimiate program has disabled a windows service etc) or point the client in the direction of dropped threats. If its a brand new threat that we havent seen before (its rare to run into this situation as we normally see threats in the wild before our customers) we may have to connect to have a look. 
 
 

@ wrote:
It would be safe to clear the logs, however I would recommend keeping them as it can be very useful for diagnosing certain issues if we have a decent time period of logs to look through. A weeks logs arent as useful as a couple of months logs as we can see trends or patterns emerging.

Yes Roy, agree. As I said I deleted them mistakenly so it won't repeat on my machine.
 

@ wrote:
As for if the journaling information being removed we can use the database (as a reference) to see what that infection has done in the past so we can manually repair system damage (i.e if an infecton or indeed a legimiate program has disabled a windows service etc) or point the client in the direction of dropped threats. If its a brand new threat that we havent seen before (its rare to run into this situation as we normally see threats in the wild before our customers) we may have to connect to have a look. 

Very interesting. Thanks!

An example of this was the damage the one of the newer variants of ZA. We were seeing it do the same things on PC`s (non-wsa protected ones) on it so we wrote a little tool to fix the various Windows Services. We used the data gathered from journaling and was able to see all the registry changes, files moved, services stopped etc to create a system repair tool. 

@ wrote:
An example of this was the damage the one of the newer variants of ZA. We were seeing it do the same things on PC`s (non-wsa protected ones) on it so we wrote a little tool to fix the various Windows Services. We used the data gathered from journaling and was able to see all the registry changes, files moved, services stopped etc to create a system repair tool. 

Thanks Roy! I love examples because they speak for itself and are more than any explanation/clarification.

@ wrote:

It seems that these log files re-created itself in WRData folder:

SystemOptimizer.log
WRLog.log
 
However Sync folder is still empty even if I have run backup & sync. No log files. Strange.

As a follow up to this issue I can confirm that also log files (*.log) reappeared in folder Sync today.
 
By this it is confirmed that ALL LOG FILES (*.LOG) in WRData folder including its sub-folders will resume itself. So if you mistakenly or purposely (but I don't recommend it) delete log files the WSA function and your protection isn't compromised and these log files will recreate on their own.
 
HOWEVER, to keep a sense of log files, i.e. to store history of actions what is necessary to troubleshoot many issues, IT IS HIGHLY RECOMMENDED TO KEEP ALL LOG FILES THAT WSA CREATES.

I haven't figured out what exactly is essential, but WSA can bootstrap itself from most any damage you make to it.