Anyone know if the wrdata folder can be cleaned out or deleted? It grows to an enormous size over time.
Page 3 / 4
Hi BradKilmer
Welcome to the Community Forums.
As you are technical there is another way that avoids the uninstall/reinstall, which involves the review of the 'dbnnnn.db files in the C:ProgramdataWRDATA folder, and then the deletion of selected ones of this file type.
This is not ideal but it does avoid the uninstall/reinstall and also preserves to some extent the rationale for those files; as you may have surmised from the thread these files are the journal files produced when WSA sets a file/app to 'Monitor' and so are important in case WSA has detected a suspicious or an as yet undetermined (in terms of goodness/badness) file/app and then determines it is bad and then needs to roll back its activities, etc., in which case the relevant 'dbnnnn.db' file is required.
The problem is that we cannot easily tell which 'dbnnnn.db' relates to which file/app in the system (there is a way by looking in the Registry but I have lost my notes on that...must try to find them) so the best thing to do is to (i) check all places in WSA where files could be set to 'Monitor', decide whether they are OK or not (and if in doubt leave them as such), (ii) try to work out roughly when a file/app that is set to 'Monitor' was so set & (iii) then go to the C:ProgramdataWRDATA folder and carefully delete all 'dbnnnn.db' files that are either prior to a certain period, i.e., say more than 2 weeks old, on the basis that WSA should have been in a position to sort out if the journal is required or not, or delete everything except for the 'dbnnnn.db' files that are circa the dates that you believe that you 'Monitored' files/apps may have started to be monitored, etc.
The above may seem more convoluted that an uninstall/reinstall, but I have found that it seems to work well, and does give you a better chance of keeping 'dbnnnn.db' files that may be needed; after all an uninstall/reinstall should clear all the files in that folder regardless of whether they are needed or not.
I hope that something in the rambling reponse above is of assistance?
Regards, Baldrick
Welcome to the Community Forums.
As you are technical there is another way that avoids the uninstall/reinstall, which involves the review of the 'dbnnnn.db files in the C:ProgramdataWRDATA folder, and then the deletion of selected ones of this file type.
This is not ideal but it does avoid the uninstall/reinstall and also preserves to some extent the rationale for those files; as you may have surmised from the thread these files are the journal files produced when WSA sets a file/app to 'Monitor' and so are important in case WSA has detected a suspicious or an as yet undetermined (in terms of goodness/badness) file/app and then determines it is bad and then needs to roll back its activities, etc., in which case the relevant 'dbnnnn.db' file is required.
The problem is that we cannot easily tell which 'dbnnnn.db' relates to which file/app in the system (there is a way by looking in the Registry but I have lost my notes on that...must try to find them) so the best thing to do is to (i) check all places in WSA where files could be set to 'Monitor', decide whether they are OK or not (and if in doubt leave them as such), (ii) try to work out roughly when a file/app that is set to 'Monitor' was so set & (iii) then go to the C:ProgramdataWRDATA folder and carefully delete all 'dbnnnn.db' files that are either prior to a certain period, i.e., say more than 2 weeks old, on the basis that WSA should have been in a position to sort out if the journal is required or not, or delete everything except for the 'dbnnnn.db' files that are circa the dates that you believe that you 'Monitored' files/apps may have started to be monitored, etc.
The above may seem more convoluted that an uninstall/reinstall, but I have found that it seems to work well, and does give you a better chance of keeping 'dbnnnn.db' files that may be needed; after all an uninstall/reinstall should clear all the files in that folder regardless of whether they are needed or not.
I hope that something in the rambling reponse above is of assistance?
Regards, Baldrick
Good Morning ?, this is good info about the registry.
I also check my wrdata folder from time to time, especially after installing new apps. I have had good luck saving a scan log and searching for the xxxx in the dbxxxx.db to see what is lurking about.
I know you are already aware but for BradKilmer's interest, it will look like this : Thu 2015-09-10 07:39:12.0568 Monitoring process C:Program Files (x86)Common FilesAdobeAdobeGCClientAdobeGCClient.exe [40AE8622D89D27C4F704A324CA82AA70]. Type: 3 (XXXX)
From that, I can check the file against VirusTotal and or other means of verifying authenticity and determine if it is safe to delete the .db file, uninstall the app, or wait and see what WSA will ultimately do.
Just one more way.
Thanks,
Dave
I also check my wrdata folder from time to time, especially after installing new apps. I have had good luck saving a scan log and searching for the xxxx in the dbxxxx.db to see what is lurking about.
I know you are already aware but for BradKilmer's interest, it will look like this : Thu 2015-09-10 07:39:12.0568 Monitoring process C:Program Files (x86)Common FilesAdobeAdobeGCClientAdobeGCClient.exe [40AE8622D89D27C4F704A324CA82AA70]. Type: 3 (XXXX)
From that, I can check the file against VirusTotal and or other means of verifying authenticity and determine if it is safe to delete the .db file, uninstall the app, or wait and see what WSA will ultimately do.
Just one more way.
Thanks,
Dave
Hi D_J
But of course...I forgot about that way of doing things. :@
I am still looking for the Registry entries approach as that gives an even faster way of determining what is what and when I refind it I will advise back.
Regards, Baldrick
But of course...I forgot about that way of doing things. :@
I am still looking for the Registry entries approach as that gives an even faster way of determining what is what and when I refind it I will advise back.
Regards, Baldrick
Thanks ?, I'm all for faster and better. :D
Dave
Dave
I had a look in the WRLog.log and saw that the bulk of the activity is centered around the repeatedly changing EXE files in my working folders (every time I compile a new EXE, more activity).
The perfect solution to this problem would be to allow me to specify my working folder tree to be off-limits to WSA scans; I never install 3rd party software into my working folder tree and some days I recompile my apps dozens of times.
Is there a way to specify an off-limits folder?
Thanks
The perfect solution to this problem would be to allow me to specify my working folder tree to be off-limits to WSA scans; I never install 3rd party software into my working folder tree and some days I recompile my apps dozens of times.
Is there a way to specify an off-limits folder?
Thanks
I am afraid that currently here is not. I believe that there is however a Feature Request for that specific functionality and that it may be with us soon...but presently there is no indications on timescales. All that we know is that "This one is in the works and is waiting on QA testing currently."
Please see here for more details on this.
Regards, Baldrick
Please see here for more details on this.
Regards, Baldrick
I think I see what I need to do; I'm going to write a clean-up app to automate this process.
Let me know if you think the following steps sound OK:
Let me know if you think the following steps sound OK:
- Load the WRLog.log file
- Scan for all of the 'Monitoring process' lines
- Extract the EXE path and (NNNN) information into a data table
- Compare EXE path info to Off-Limits-Folder list (to build list of NNNNs to delete)
- Delete all dbNNNN.db files in deletion list.
Hi BradKilmer
That sounds about right but as has been said earlier in this thread you need to be very careful as in amongst the files being monitored there could be ones that genuinely need to be because they are 'undetermined' as to whether good or bad.
If you delete the journalling file for one of these and then WS determines that the file is bad, if you have deleted the associated 'dbnnnn.db' file then WSA will be unable to roll back any nefarious actions that the file/app may have been able to take in your system whilst being monitored, and so you will have lost a very useful facility.
Personally I would also add in a check for a list of files/apps, i.e., a control list if you will, that you know are good, i.e., the ones you are creating and only delete 'dbnnnn.db' files if the app in the EXE path matches one of the ones in your control list.
Just a thought.
Regards, Baldrick
That sounds about right but as has been said earlier in this thread you need to be very careful as in amongst the files being monitored there could be ones that genuinely need to be because they are 'undetermined' as to whether good or bad.
If you delete the journalling file for one of these and then WS determines that the file is bad, if you have deleted the associated 'dbnnnn.db' file then WSA will be unable to roll back any nefarious actions that the file/app may have been able to take in your system whilst being monitored, and so you will have lost a very useful facility.
Personally I would also add in a check for a list of files/apps, i.e., a control list if you will, that you know are good, i.e., the ones you are creating and only delete 'dbnnnn.db' files if the app in the EXE path matches one of the ones in your control list.
Just a thought.
Regards, Baldrick
?, ?,
I keep tabs on WRData directory several times a week. It doesn't take long and you can put a shortcut on your desktop to go right to it. Sometimes I go days and days without any new db files being added. By checking frequently it never grows to more than two or three .db files at most. I can almost tell you when I am going to have them and what they are without even looking at the WRLog or Scan log. For me, it is pretty much a one to one relationship to new or updated apps that I have had an active role in causing. I do a quick check to verify I am on the right track, run the process of verifying the files as I mention in my other post, and if they are ok, I delete the .db files and don't look back. If I can't tell for sure I leave the files for a while to see what WSA determines. So far it has worked for me.
Dave
I keep tabs on WRData directory several times a week. It doesn't take long and you can put a shortcut on your desktop to go right to it. Sometimes I go days and days without any new db files being added. By checking frequently it never grows to more than two or three .db files at most. I can almost tell you when I am going to have them and what they are without even looking at the WRLog or Scan log. For me, it is pretty much a one to one relationship to new or updated apps that I have had an active role in causing. I do a quick check to verify I am on the right track, run the process of verifying the files as I mention in my other post, and if they are ok, I delete the .db files and don't look back. If I can't tell for sure I leave the files for a while to see what WSA determines. So far it has worked for me.
Dave
Thank you Dave - the fog has finally lifted for me regarding the db files and I have now been able to delete eight old ones, leaving just one. I know that one is safe but I will just see how long WSA keps monitoring before it deletes it automatically. 😃
You are very welcome Nemo. It was trial and error for me but it helped me to read posts from other senior members like TripleHelix and Baldrick. Just play it safe and only delete what you are sure of, knowing that it is always a gamble to some extent.
Dave
Dave
I'm sorry everyone in reality no one should be in the WRData Folder that's why it's in a hidden area so I always tell users to: https://community.webroot.com/t5/Webroot-SecureAnywhere-Internet/wrdata-folder/m-p/124026#M2962 to be safe as it would be very upsetting to see someone make a mistake and trash there system in case WSA is monitoring any Malware IMO go through support!
Daniel 😉
Daniel 😉
I will be careful - the eight I've just deleted all related to software that I had already removed from my PC!
As you say this thread is a great example of how we can all learn from the more senior members of the community and I really appreciate all the time and effort that they put in.
As you say this thread is a great example of how we can all learn from the more senior members of the community and I really appreciate all the time and effort that they put in.
You can't say we didn't warn you if you muck up your system!
Daniel :D
http://users.isp.com/oberto/assets/images/Guy_bashing_his_compter.gif
http://www.computerhospital.com/medcin_g2.gif
Daniel :D
http://users.isp.com/oberto/assets/images/Guy_bashing_his_compter.gif
http://www.computerhospital.com/medcin_g2.gif
You can't make it any clearer than that Daniel! 😃@ wrote:
You can't say we didn't warn you if you muck up your system!
Daniel :D
Nobody will ever know if I muck-up my system. I'll never tell :D
I am careful but also responsible, so I have daily restore points, image backups, file and folder syncs to fall back on. I don't believe in loosing data.
If you are going to gamble you need a fallback plan.
Dave
I am careful but also responsible, so I have daily restore points, image backups, file and folder syncs to fall back on. I don't believe in loosing data.
If you are going to gamble you need a fallback plan.
Dave
Well after much coding and finger crossing, I have a utility:
And more importantly, I have 185 GB of unwanted dbNNN.db files in my Recycle bin :)
...and WebRoot came back up without any errors.
I need to put a few finishing touches on the util (along with a short write-up); if anybody is intereseted, I'll put it up for download in a day or so.
And more importantly, I have 185 GB of unwanted dbNNN.db files in my Recycle bin :)
...and WebRoot came back up without any errors.
I need to put a few finishing touches on the util (along with a short write-up); if anybody is intereseted, I'll put it up for download in a day or so.
Hi Brad
Well, I for one would be interested in seeing how this works and whether it is workable in terms of my system usage, even though I do very much subscribe to Daniel's view that the hidden Webroot folders are dangerous place to go if one does not know what one is doing...which is the case for most users.
Regards, Baldrick
Well, I for one would be interested in seeing how this works and whether it is workable in terms of my system usage, even though I do very much subscribe to Daniel's view that the hidden Webroot folders are dangerous place to go if one does not know what one is doing...which is the case for most users.
Regards, Baldrick
I can also run the script by our folks here to see if they have any concerns about it or suggestions for improvement.
Hi NIc
I cannot speak for Brad but I for one would say that if that is possible then it would be much appreciated.
I have often wondered whether or not they could produce something that, using the Registry entries that track what 'dbnnnn.db' relates to what file/app, could check for any journaling that was no longer required and then purge them, perhaps as part of the System Optimizer, and I know that there is a Feature Request along those line that is open and I believe under consideration.
But as with everything we cannot know how the Development team can or need to move forward etc....I am very sure that they have good reasons for doiing what they do and when..., but perhaps the two can come together to once and for all 'resolve' this small area of contention?
Regards, Baldrick
I cannot speak for Brad but I for one would say that if that is possible then it would be much appreciated.
I have often wondered whether or not they could produce something that, using the Registry entries that track what 'dbnnnn.db' relates to what file/app, could check for any journaling that was no longer required and then purge them, perhaps as part of the System Optimizer, and I know that there is a Feature Request along those line that is open and I believe under consideration.
But as with everything we cannot know how the Development team can or need to move forward etc....I am very sure that they have good reasons for doiing what they do and when..., but perhaps the two can come together to once and for all 'resolve' this small area of contention?
Regards, Baldrick
I'd be happy to let you check it out in a couple of days; however, I just ran it on my Windows 7 test machine and found a couple of bugs:
- It didn't handle a network file path correctly (i.e. "\WIN8BOXShareScadaPhoneInstall.exe"); When the exclude list contained a network path, my app would not delete anything; when I removed the \WIN8BOX items from the list of excluded folders, it worked.
- After running this on my Windows 7 test computer and finishing a long sequence of db file recycling, my app coughed-up an "out of memory" error and subsequently saved the WRLog.log as a file of zero bytes (oops).
P.S. After accidentally wiping out the WRLog.log file on my Win7 machine; WSA did not display any errors when it was restarted and the file is once again being populated with information.
P.P.S. My util is written in Delphi and it relies heavily on my company's library code; I can share some of the source (the parts specifically used by the WebRootLogCleaner app) but not all of the source necessary to compile the whole enchilada (29,340 lines):
I did some additional work on the utility and it now refrains from overwriting the WRLog.log; instead it saves the cleaned log to the TEMP folder and gives the user the opportunity to manually overwrite the old file with the new (if so desired). This enabled the removal of the "Run As Administrator" requirement (overwriting the WRLog.log file requires elevated privileges). I figured that the omenous UAC Prompt might somewhat alarming to many users.
The only "destructive" action now performed is the moving of the dbNNNN.db files to the Recycle Bin.
I also added code to disable the scan if the WRSVC service is running; if WRSVC is running, the user is instructed to shut down WSA before scanning.
I have been absolutely slammed with work this week and I will try to finish this off with an explanitory doc on Saturday.
The only "destructive" action now performed is the moving of the dbNNNN.db files to the Recycle Bin.
I also added code to disable the scan if the WRSVC service is running; if WRSVC is running, the user is instructed to shut down WSA before scanning.
I have been absolutely slammed with work this week and I will try to finish this off with an explanitory doc on Saturday.
Hi Brad
I am looking forward to it.
Regards, Baldrick
I am looking forward to it.
Regards, Baldrick
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.