I know this is not a new subject but I don't see an answer - there are several >20GB db files in the WRData folder that are messing up my backups and defrag. I'd like to remove some of them or stop WR creating such alrge ones. Reading older complaints about this I don't see if this is possible or not?
Can someone advise please?
Thanks
Mike
Page 1 / 1
Hi effingpot
Welcome to the Community Forums.
The current official answer to your question is to uninstall WSA and then clean reinstall it, as that will clear out the WRData folder. However, if you are somewhat technical in terms of Windows
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 t63D4BC1DABF35B13C94A9FAE02D7C0FF]. 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.
And this is not an officially sanctioned way to deal with the position...but there for you to try if you would like.
Hope that helps?
Regards, Baldrick
Welcome to the Community Forums.
The current official answer to your question is to uninstall WSA and then clean reinstall it, as that will clear out the WRData folder. However, if you are somewhat technical in terms of Windows
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 t63D4BC1DABF35B13C94A9FAE02D7C0FF]. 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.
And this is not an officially sanctioned way to deal with the position...but there for you to try if you would like.
Hope that helps?
Regards, Baldrick
Hello and Welcome to the Webroot Community!
To have that much in the WRData Folder to add what Baldrick said I would suggest you Submit a Support Ticket and get your files whitelisted especially the programs that are not well known to the Webroot Cloud Database.
Thanks,
Daniel 😉
To have that much in the WRData Folder to add what Baldrick said I would suggest you Submit a Support Ticket and get your files whitelisted especially the programs that are not well known to the Webroot Cloud Database.
Thanks,
Daniel 😉
Thanks Baldrick!
How do I do this part?
> (i) check all places in WSA where files could be set to 'Monitor', decide whether they are OK or not
If the steps are documented somewhere please let me know and I'll do what you suggest,
The biggest file has grown to 30GB since posting the first time so I need to do something
Currently best thing seems to move to another product as this one needs too much user intervention :-(
But I'll try your cunning plan first.
Cheers
Mike
How do I do this part?
> (i) check all places in WSA where files could be set to 'Monitor', decide whether they are OK or not
If the steps are documented somewhere please let me know and I'll do what you suggest,
The biggest file has grown to 30GB since posting the first time so I need to do something
Currently best thing seems to move to another product as this one needs too much user intervention :-(
But I'll try your cunning plan first.
Cheers
Mike
Submit a Support Ticket and ask them to remove the related data files after whitelisting them as if you remove them they will start growing again.
Thanks,
Daniel 😉
Thanks,
Daniel 😉
HI effingpot
There are essentially 3 key areas where this can happen/a user can override WSA. These are essentially reached, from the main WSA panel, as follows:
But I must add a word of caution here; DO NOT make a change unless you are certain that it s OK to do so/that the file/process concerned is safe...and if doubt then leave well alone, and take Daniel's advice of notifying the Support Team so that they can professional check out the file/process and then whitelist if indeed it is safe/the monitoring is precautionary.
Regards, Baldrick
There are essentially 3 key areas where this can happen/a user can override WSA. These are essentially reached, from the main WSA panel, as follows:
- PC Security > Block/Allow Files
- Identity Protection > Application Protection
- Utilities > System Control > Control Active Processes
- "Allow"
- "Protect/Monitor"
- "Block/Deny"
But I must add a word of caution here; DO NOT make a change unless you are certain that it s OK to do so/that the file/process concerned is safe...and if doubt then leave well alone, and take Daniel's advice of notifying the Support Team so that they can professional check out the file/process and then whitelist if indeed it is safe/the monitoring is precautionary.
Regards, Baldrick
Already done - thank you 🙂
Thanks - looking in those 3 places all I see is BACKBLAZE being monitored. It's my back up SW.
I did the support ticket earlier so will see what they say
Ta
Mike
I did the support ticket earlier so will see what they say
Ta
Mike
Indeed, effingpot...they should be able to pick that one up and do the necessary.
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.