Best answer by Kit
View originalwrdata folder
Anyone know if the wrdata folder can be cleaned out or deleted? It grows to an enormous size over time.
Page 1 / 4
Userlevel 7
Hi Nebula
Completely understand where you are coming from. Hopefully things will improve in that area in the future as I believe that the Development Team are looking at this whole area.
I try to temper things by remembering that the .db files in the WRData folder forma a valuable part of the insurance that WSA provides should an unknown fiel/app be found on your system and then prove to be malicious. ;)
Regards, Baldrick
Completely understand where you are coming from. Hopefully things will improve in that area in the future as I believe that the Development Team are looking at this whole area.
I try to temper things by remembering that the .db files in the WRData folder forma a valuable part of the insurance that WSA provides should an unknown fiel/app be found on your system and then prove to be malicious. ;)
Regards, Baldrick
Thanks for the information. I wish there was a way to tell webroot where to store these DB files because this took up almost the entirety of my SDD
Userlevel 7
Hi nebula
I have posted this before but cannot find the thread to direct you to so I will repost the information here.
If you are technical (and I believe that you are) then are there are other ways 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. But I should stress at the outset that you need to be careful when employing these approaches.
The first 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.
A second, alternative way which may be more accurate but takes longer is to run Save a Scan Log and from the text file produced do a search for ‘(nnnn)’ (without the ‘’ marks) where ‘nnnn’ is the ‘nnnn’ portion of the ‘dbnnnn.db’ file(s) found in the C:ProgramdataWRDATA folder. This should find an entry in the Log from which you can identify the application/file that is being monitored and to which the journal file concerned belongs;
Sat 12-09-2015 10:21:40.0098 Monitoring process C:BrowsersMaxthonPortableBinMaxthon.exe [63D4BC1DABF35B13C94A9FAE02D7C0FF]. Type: 3 (1235)
relates to file ‘db1235.db in the C:ProgramdataWRDATA folder.
Of course, this is not ideal in terms of dealing with many ‘dbnnnn.db’ files but if one can identify the largest of these files and start with those then one can reduce (safely) the size of the folder.
Hope that helps you with your space issue and the size of your WRData folder.
Regards, Baldrick
I have posted this before but cannot find the thread to direct you to so I will repost the information here.
If you are technical (and I believe that you are) then are there are other ways 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. But I should stress at the outset that you need to be careful when employing these approaches.
The first 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.
A second, alternative way which may be more accurate but takes longer is to run Save a Scan Log and from the text file produced do a search for ‘(nnnn)’ (without the ‘’ marks) where ‘nnnn’ is the ‘nnnn’ portion of the ‘dbnnnn.db’ file(s) found in the C:ProgramdataWRDATA folder. This should find an entry in the Log from which you can identify the application/file that is being monitored and to which the journal file concerned belongs;
Sat 12-09-2015 10:21:40.0098 Monitoring process C:BrowsersMaxthonPortableBinMaxthon.exe [63D4BC1DABF35B13C94A9FAE02D7C0FF]. Type: 3 (1235)
relates to file ‘db1235.db in the C:ProgramdataWRDATA folder.
Of course, this is not ideal in terms of dealing with many ‘dbnnnn.db’ files but if one can identify the largest of these files and start with those then one can reduce (safely) the size of the folder.
Hope that helps you with your space issue and the size of your WRData folder.
Regards, Baldrick
Hello, I'd just like to say that just this morning I had 20GB free of my 250GB SSD and after installing an update to an application of mine Webroot kept complaining about it and I had to allow access. However after this my HDD kept decreasing in size to only 700MB left and I discovered my WRData folder to be over 46GB in size. I want to know what can be cleared from this folder.
Userlevel 2
OK, keep me posted on your decision. I did some further work on it this weekend but didn't get it finished to my satisfaction quite yet. I will squeeze in some more time as I am able. If the development team wants to do this themselves, I understand; I'm not trying to step on anyones toes here, but I had to do something to reclaim that space on my HD (and I wasn't going to pick through 3900 files manually).
FYI, Here is an updated shot of the main window; the list is sorted by total size of db files associated with each exe, the blue db items are to be left alone, the red db items are to be recycled, the gray db items are referenced in the log but do not exist on disk.
There is now also a filter which allows the user to show only excluded exe & db files and also db files which are associated with exes which have been deleted (marked with the (FILE NOT FOUND) suffix):
If something similar could be added to WSA, that would be great; otherwise, I'm going to be using this.
FYI, Here is an updated shot of the main window; the list is sorted by total size of db files associated with each exe, the blue db items are to be left alone, the red db items are to be recycled, the gray db items are referenced in the log but do not exist on disk.
There is now also a filter which allows the user to show only excluded exe & db files and also db files which are associated with exes which have been deleted (marked with the (FILE NOT FOUND) suffix):
If something similar could be added to WSA, that would be great; otherwise, I'm going to be using this.
Userlevel 7
+56
@ wrote:
FYI, I already private messaged Nic on this subject to let him know that I will be sending him the link for approval before posing the link on this public forum.
@ wrote:
P.S. This utility is really targeted for programmers who have massive amounts of data accumulating in the WRData folder due to repetitive creation of EXE files (every time we compile a new version of our software). General-purpose users will not really need this, but on my system, the dbNNNN.db files were taking up nearly 20% of my 1TB drive.
I intend to continue using WSA, so this will be an ongoing issue for me. That's why I'm doing this.
I still don't agree sorry! The Webroot Developers are more and capable of doing what needs to be done and keeping the client as small it can be. It's already on there list for WSA to clean up it's own files. This is the Webroot Product support Forum not a forum where someone can come by and make a utility and offer it to staff or it's members.@ wrote:
Brad has reached out to me, and I will take his utility and run it by the folks here. We actually have lots of folks on our support team who do similar workaround utilities to fix issues, and they sometimes get incorporated in the product. So who knows - maybe we'll end up doing the same with your utility Brad!
IMO,
Daniel
Userlevel 7
Obviously I land with TH on this.. but all is good as long as given an "OK" after being reviewed. As for becoming a part of the product... that would be... pretty doggone cool if it works well and is polished enough to not remove rollback data that is still needed!
:)
:)
Userlevel 7
+56
Brad has reached out to me, and I will take his utility and run it by the folks here. We actually have lots of folks on our support team who do similar workaround utilities to fix issues, and they sometimes get incorporated in the product. So who knows - maybe we'll end up doing the same with your utility Brad!
Userlevel 7
Hi Brad
A good point well worth pointing out for those who might be confused or unsure. And use of this utility is very much on the basis that the user is warned that it could cause issues with the installation of WSA on their system, requiring a reinstall at the very least.
Regards, Baldrick
A good point well worth pointing out for those who might be confused or unsure. And use of this utility is very much on the basis that the user is warned that it could cause issues with the installation of WSA on their system, requiring a reinstall at the very least.
Regards, Baldrick
Userlevel 2
P.S. This utility is really targeted for programmers who have massive amounts of data accumulating in the WRData folder due to repetitive creation of EXE files (every time we compile a new version of our software). General-purpose users will not really need this, but on my system, the dbNNNN.db files were taking up nearly 20% of my 1TB drive.
I intend to continue using WSA, so this will be an ongoing issue for me. That's why I'm doing this.
I intend to continue using WSA, so this will be an ongoing issue for me. That's why I'm doing this.
Userlevel 2
FYI, I already private messaged Nic on this subject to let him know that I will be sending him the link for approval before posing the link on this public forum.
Userlevel 7
You make some valid and relevant points there Daniel, and it's difficult to envisage how Webroot could do other than advise against its usage.@ wrote:
Sorry but I have no interest with his cleanup tool and you know me I'm a realist and Brad could be breaking Webroot's EULA in some way and would not recommend anyone to use his tool if it ever comes to be and@ wrote:
Hi Brad
I am looking forward to it.
Regards, Baldrick
@ should check with the internal staff on this@ @ . Also we know it's on the Webroot's Developers list to make WSA clean it's own old files.
Just my opinion,
Daniel
Userlevel 7
+56
Sorry but I have no interest with his cleanup tool and you know me I'm a realist and Brad could be breaking Webroot's EULA in some way and would not recommend anyone to use his tool if it ever comes to be and@ wrote:
Hi Brad
I am looking forward to it.
Regards, Baldrick
Just my opinion,
Daniel
Userlevel 7
Hi Brad
I am looking forward to it.
Regards, Baldrick
I am looking forward to it.
Regards, Baldrick
Userlevel 2
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.
Userlevel 2
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):
Userlevel 2
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.
Userlevel 2
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).
Userlevel 7
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
Userlevel 7
+56
I can also run the script by our folks here to see if they have any concerns about it or suggestions for improvement.
Userlevel 7
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
Userlevel 2
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.
Userlevel 7
+7
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
Userlevel 7
+34
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
Userlevel 7
+56
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
Page 1 / 4
Reply
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.