Solved

Controlling WRData folder size - help needed


Hello,

I recently discovered that the gradually increasing size of my dive image files and decreasing SSD capacity were directly attributable to an enormous SecureAnywhere WRData folder.

I contacted support and received the following response: “To start it fresh you can uninstall Webroot SecureAnywhere normally and then delete the WRData folder and restart your computer, then reinstall Webroot and there will be a new WRData folder.”

I completed all steps as instructed. Between my November 20, 2013 reinstall and this post, the WRData folder has grown from a few megabytes to over 2.6 gigabytes. In comparison, the 2 day old and still growing WRData folder is roughly 4 times the size of all of my Norton Internet Security files/folder combined.

The above noted :
Is this normal for the WRData folder or do I have a problem?


Is there a way to reduce the number and/or limit the size of the database files in the WRData folder?

Any assistance would be greatly appreciated...
icon

Best answer by TripleHelix 10 August 2018, 23:10

View original

195 replies

Userlevel 7
@ wrote:
@ it's been in a WSA update so what happened? https://community.webroot.com/t5/Product-Releases/PC-Agent-release-notes-for-version-9-0-11-70/m-p/264182
 
Version 9.0.11.70 (Released August 15th, 2016)
Improved
  • Remove obsolete databases.
  • Bug fixes.
 


 
 http://answers.webroot.com/Webroot/ukp.aspx?pid=10&app=vw&vw=1&login=1&json=1&solutionid=857#901362
 
Further enhancements around database file cleanup is on the table for 9.0.19
Userlevel 7
Badge +56
@ wrote:
@ wrote:
@ it's been in a WSA update so what happened? https://community.webroot.com/t5/Product-Releases/PC-Agent-release-notes-for-version-9-0-11-70/m-p/264182
 
Version 9.0.11.70 (Released August 15th, 2016)
Improved
  • Remove obsolete databases.
  • Bug fixes.
 


 
 http://answers.webroot.com/Webroot/ukp.aspx?pid=10&app=vw&vw=1&login=1&json=1&solutionid=857#901362
 
Further enhancements around database file cleanup is on the table for 9.0.19
This has been going on since 2013 (4 years) so I hope the developers finely get it right? Seriously! :)
https://community.webroot.com/t5/Webroot-SecureAnywhere-Complete/Controlling-WRData-folder-size-help-needed/td-p/69357
Userlevel 7
Badge +56
Btw we are working on a ticketing system that has separate tickets for each issue, instead of one long thread that can have several issues going at once. It's in beta testing right now with some of the business endpoint customers.
Userlevel 7
@, I've created a support case on your behalf with our Team so they can properly classify the files that are being monitored excessively.
 
Do let us know once you've worked with them to resolve this!
Userlevel 7
Hi kliebor
 
This happens to us all and is most likely due to changes to certain files and/or executables when an application receives a patch or update...some of which happen silently so one would never know that they have occurred.
 
Whilst Webroot attempts to review and whitelist all file changes that occur daily it may well miss some and as a result we get some well known applications' files/exes being marked as undefined and therefore monitored.
 
The thing is that all monitored files are rechecked at each scan and once a file is determined to be good, i.e., whitelisted, the monitoring will stop. But what does not seem to happen is the removal of the journal file created by the monitoring process. I believe that they are supposed to be kept for a pre-determined period of time and then automatically removed/deleted but to be honest I have never seen that happen.
 
Hope that helps explain things a bit?
 
Regards, Baldrick
 
 
Userlevel 7
Hi uwantfries
 
Welcome to the Community Forums.
 
Thank yo for your views on this. Yes, it is frustrating but having said that I suspect that the issue is being reviewed and an appropriate approach developed. At one stage it was mooted that the process had been changed so that any no longer required .db files would be cleared after 30 days after the journaled file was determined to be 'good' and therefore no roll back would be required...but as far as I can tell there has been no evidence of this...so I am wondering if I imagined it.
 
Perhaps @ or @ can make some enquiries for us behind the scenes to find out how all of this should work and what, if any, changes are in the offing?
 
Regards, Baldrick
Userlevel 7
Badge +56
@ it's been in a WSA update so what happened? https://community.webroot.com/t5/Product-Releases/PC-Agent-release-notes-for-version-9-0-11-70/m-p/264182
 
Version 9.0.11.70 (Released August 15th, 2016)
Improved
  • Remove obsolete databases.
  • Bug fixes.
 


 
 http://answers.webroot.com/Webroot/ukp.aspx?pid=10&app=vw&vw=1&login=1&json=1&solutionid=857#901362
 
Userlevel 7

 
As Nic noted, really the very best way to do this is via a Trouble Ticket.
 
As for without a Trouble Ticket....I am not positive on safely manually removing the db files, but I THINK this will help keep the db files from growing so large in the future.  
 
NOTE: This should only be done if you are VERY sure of what you are doing and VERY sure of what files and processes can be trusted.  Remember, without the db files, damage done by malware may not be able to be fixed after the fact through a rollback.
 
NOTE:  You will probably have to recheck all of the below every time there is an update to affected files/processes.  This is NOT a permanent fix.
 
NOTE:  This will not likely remove the existing db files.  The best way to clear all existing db files is to take the 10 minutes to do a Clean Re-Install of WSA.  The steps below will, again, help the db files from growing following the reinstall.
 
  • Open WSA
  • Click the gear tool next to PC Security
  • Click the Block/Allow Files tab
  • Look over the list for items marked to "Monitor".  If there are files there you trust 100% marked for Monitor, change those to Allow.
  • Return to the main WSA screen (Use the back arror at the upper left corner)
  • Click the gear tool next to Utilities
  • Click the System Control tab
  • Make sure the programs you usually use (especially the bitcoin application in your case) is running
  • Click the "Start" button under Control Active Processes
  • Look over the list for items marked to "Monitor".  If there are files there you trust 100% marked for Monitor, change those to Allow.
 
Again, make sure you know exactly what an application is and what it does, and that it is 100% trustworthy BEFORE you remove it from monitoring.
 
This may not remove the db files, but it should help keep them from growing and coming back.
 
?, do you happen to know how long the db files are kept from monitored processes before being removed one the process is changed from Monitored to Allowed?
Userlevel 7
Badge +56
I haven't heard anything lately - I'll check and see if I can find out a status.
Userlevel 7
Badge +56
@ wrote:
Hi David
 
There is an alternative way (originally highlighhted by D_J...if memory serves me correctly) 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. This is especially the case where you can see that the monitored file is one that you trust but may just be a new version that has been recetly downloaded and has yet to be whitelisted.
 
I throw this one in the ring...for what it is worth (with thanks to D_J, of course).
 
EDIT: I should have also mentioned that 'playing' in this folder & with these files is risky and could cause WSA to stop working if the wrong files are deleted...so caution is advised as well as having a system backup and/or a system image.
 
Regards, Baldrick
Solly you're so right they do match from the scan log and in the WRData Folder!
 
Thanks,
 
Daniel :D
 
 
Wed 2015-10-28 21:27:59.0694 Monitoring process D:Program Files (x86)ChrisPC Win Experience IndexChrisPCWEI.exe [8ED6894F971B8B3514C02C1318404988]. Type: 3 (5874)
Wed 2015-10-28 21:27:59.0694 Monitoring process D:Program Files (x86)ChrisPC Win Experience IndexChrisPCWEI.exe [8ED6894F971B8B3514C02C1318404988]. Type: 4 (5874)
Wed 2015-10-28 21:27:59.0703 Monitoring process D:Program Files (x86)ChrisPC Win Experience IndexChrisPCWEI.exe [8ED6894F971B8B3514C02C1318404988]. Type: 8 (5874)
Wed 2015-10-28 21:27:59.0703 Monitoring process D:Program Files (x86)ChrisPC Win Experience IndexChrisPCWEI.exe [8ED6894F971B8B3514C02C1318404988]. Type: 6 (5874)
 
Wed 2015-10-28 21:03:08.0355 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe [9F2A593D974983A5F9CEEABEFEE2B582]. Type: 3 (3550)
Wed 2015-10-28 21:03:08.0355 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe [9F2A593D974983A5F9CEEABEFEE2B582]. Type: 4 (3550)
Wed 2015-10-28 21:03:08.0358 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe [9F2A593D974983A5F9CEEABEFEE2B582]. Type: 8 (3550)
Wed 2015-10-28 21:03:08.0358 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe [9F2A593D974983A5F9CEEABEFEE2B582]. Type: 6 (3550)
Wed 2015-10-28 21:03:08.0449 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe [9F2A593D974983A5F9CEEABEFEE2B582]. Type: 3 (3550)
Wed 2015-10-28 21:03:08.0449 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe [9F2A593D974983A5F9CEEABEFEE2B582]. Type: 4 (3550)
Wed 2015-10-28 21:03:08.0452 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe [9F2A593D974983A5F9CEEABEFEE2B582]. Type: 8 (3550)
Wed 2015-10-28 21:03:08.0452 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe [9F2A593D974983A5F9CEEABEFEE2B582]. Type: 6 (3550)
 

Userlevel 7
Badge +35
Uninstalling and reinstalling should solve this issue. 
 
-Dan
 
 
Userlevel 7
Badge +56
Webroot does do some garbage collection, but there are some cases where data still piles up so we're working on improving the process.
Userlevel 7
@ I've created a ticket on your behalf with our Support Team. They'll be reaching out to you shortly!

Cheers,
Userlevel 5
Hi monstertruckpa
 
Welcome to the Community Forums.
 
If I may pick up on the point you made about the non resizable nature of the WRSA UI...this is due to the way that & in what WRSA is written in as a programming language. IT was designed from the outset to have as small a footprint/impact on the computer it is installed on, and in terms of the .exe that does most of the work it is remarkable that so much is done by something that is barely over the 1Mb mark in terms of size.
 
Now whether this policy or approach will change in the future I do not know but I believe that there a feature request already lodged (HERE) in the Ideas Exchange which you could support/add you comments to. The Development Team regularly review the ideas & features requested and if enough support is garnered there is a chance that they take the idea onboard.
 
Hope that helps?
 
Regards, Baldrick
Userlevel 7
@ wrote:
So the "Solution" after 4 years is:
 
1) Open a support ticket - so I can manually try to whitelist something and waste my time due to the fact I am developer and the exes filling this up are probably the ones I am writing.
2) Uninstall - not an option as I am a business user who gets this pushed down by GPO
3) Manually trawl thru an 11MB text file manually cross referencing xxx with xxx.db?
 
Honestly; that's pretty shoddy really.
 
How about an automatic disk cleanup util added to the UI and protected by the normal "Do you know what you are doing?" Enter a Captcha and a bunch of disclaimers to cover yourselves and then everyone will be happy and this 17+ page epic can end.
 
 
We have two improvements coming down the pipe:
  1. The removal of old database files after they have been whitelisted
  2. Resolving the overlogging of override files in wrlog.log
These updates are tentatively set for version 9.0.19 but this is always tentative.
Userlevel 3
Badge +1
Yeah. I kinda gave up on WSA because of the WRData issue, which plagued me mainly I think because I have a lot of beta and little known portable software, and the constant requests for whitelisting became tiresome. If the default retention period before cleanup is quite long, I guess my WRData could still become quite large.
Userlevel 7
Badge +36
@ wrote:
@ wrote:
https://mysupport.webrootanywhere.com/supportwelcome.aspx
THAT linked worked, allowing me to create a ticket WITHOUT asking for a password (nor clearing my browser stuff). THANKS! I just uploaded a bunch of applications that are valid, mostly dealing with Microsoft SQL Server, 3rd party tools for that product, and the entire windows 10 SDK.
Are you all set now or do you still need help creating a ticket/getting a hold of support?
Userlevel 7
Badge +56
It's probably monitoring the bitcoin client - contact support and they should be able to whitelist it so that it stops doing that:
http://www.webroot.com/us/en/support/contact
Userlevel 7
Badge +56
Yeah you can just whitelist it locally if you prefer. That doesn't change anything on our end, but our threat team will get to any unknowns as they process them. Putting in a ticket just speeds things up.
Userlevel 7
It is unusual for a Dev to comment on the Community in regards to something like this, especially as one must be VERY careful when removing the db files as noted previously in this thread.  That is why you really want to take the Trouble Ticket method.  It is not likely we will get an answer posted here on that.
 
Your "OT" is NOT  OT.. since you have a ticket open already.  VERY good question, and you are right in that you probably do not want to go there at it would possibly impact the already open one.  There are a couple options here.
 
You might try to call support instead of the ticket option.
 
A better idea, in this case, might be for ? or ? to review the situation.  (Since he already has an open ticket for a different reason, he is not really able to open a new ticket for this.  Is it possible for one of you to either check on the existing ticket, or somehow communicate the new issue to Support to have it added to the existing ticket?)
 
 
 
 
Userlevel 7
Hello,
 
I was able to locate your ticket and see that an agent is currently reviewing it at this time.
 
The issue with the WRData growing is usually caused by excessive monitoring on the system, which I do see when I check the logs.

You can always update an open ticket with a new issue and thats generally advised.
 
I would say to hold tight and you should get a response with further instructions shortly.
 
Regards,
Userlevel 7
Thank you ?!
Userlevel 7
@ wrote:
@ 
 
As Nic noted, really the very best way to do this is via a Trouble Ticket.
 
As for without a Trouble Ticket....I am not positive on safely manually removing the db files, but I THINK this will help keep the db files from growing so large in the future.  
 
NOTE: This should only be done if you are VERY sure of what you are doing and VERY sure of what files and processes can be trusted.  Remember, without the db files, damage done by malware may not be able to be fixed after the fact through a rollback.
 
NOTE:  You will probably have to recheck all of the below every time there is an update to affected files/processes.  This is NOT a permanent fix.
 
NOTE:  This will not likely remove the existing db files.  The best way to clear all existing db files is to take the 10 minutes to do a Clean Re-Install of WSA.  The steps below will, again, help the db files from growing following the reinstall.
 
  • Open WSA
  • Click the gear tool next to PC Security
  • Click the Block/Allow Files tab
  • Look over the list for items marked to "Monitor".  If there are files there you trust 100% marked for Monitor, change those to Allow.
  • Return to the main WSA screen (Use the back arror at the upper left corner)
  • Click the gear tool next to Utilities
  • Click the System Control tab
  • Make sure the programs you usually use (especially the bitcoin application in your case) is running
  • Click the "Start" button under Control Active Processes
  • Look over the list for items marked to "Monitor".  If there are files there you trust 100% marked for Monitor, change those to Allow.
 
Again, make sure you know exactly what an application is and what it does, and that it is 100% trustworthy BEFORE you remove it from monitoring.
 
This may not remove the db files, but it should help keep them from growing and coming back.
 
@, do you happen to know how long the db files are kept from monitored processes before being removed one the process is changed from Monitored to Allowed?
Hi David
 
There is an alternative way (originally highlighhted by D_J...if memory serves me correctly) 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. This is especially the case where you can see that the monitored file is one that you trust but may just be a new version that has been recetly downloaded and has yet to be whitelisted.
 
I throw this one in the ring...for what it is worth (with thanks to D_J, of course).
 
EDIT: I should have also mentioned that 'playing' in this folder & with these files is risky and could cause WSA to stop working if the wrong files are deleted...so caution is advised as well as having a system backup and/or a system image.
 
Regards, Baldrick
Userlevel 7
Hi boleyd
 
You are quite correct...this is an 'issue' that has been going on for some time now and there are a number of routes to effectively slimming down the size of the WRData folder re. the .db files. These are:
 
1. Open a Support Ticket so that the Support team can review what is being monitored and whitelist any files that may need so doing so that the next time that you run a scan WSA should recognised that the item(s) being monitored are not longer 'undertimed' and then WSA should effectively stop monitoring the file(s) and remove the jornal (.db file).
 
2. Uninstall WSA, check to see if the WRData folder has been deleted and if not then delete it manually, and then do a clean reinstall WSA (we can provide instructions on how to do that).
 
3. If 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.
 
An 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.
 
None of the above are a 'solution' in itself but may assist with you reclaiming space from the WRData folder.
 
Hope that helps?
 
Regards, Baldrick
Userlevel 7
Hi VirtualFM
 
The best thing in the circumstances is to follwo the advice given in this thread which is essentially to Open a Support Ticket and get the Support Team to review and whitelist, where appropriate, those items on your system that are identified as 'Undetermined (prefixed with a [u] in the Scan Log) as these are the items that will be journalled and therefore create the .db files.
 
Alternatively, one can follow the guidance provided to allow the .db files to be associated back to the files that are being monitored and if one knows that these are safe then to (i) change the 'Monitoring' status to 'Allow' & (ii) delete the relavnt .db file(s).
 
Am afraid that the thread is pretty complete in terms of options until the Developemnt Team decide to provide a more permanent 'solution'.
 
Regards, Baldrick
 

Reply