@ wrote:

Indeed. This thread is nearly two years old - and still listed here as a Hot Topic!

I concur. This is not reassuring for us, especially considering we are talking about a security product here...

---

@ wrote:

@ 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 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. 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

 

 

Hi Daniel

 

I really can take little credit as I believe (memory failing me) that it was D_J who first posted this/brought it to my attention...all kudos are due to him.

 

Regards, Baldrick

---

Hi carmik

 

Cannot explain that...every single reference I have and have checked, which is 99% of them, matches/can be attributed to a .db file.

 

But perhaps the issue resides in the 1% I have not yet looked at.

 

I will check again and if I turn up anything by way of a flaw in this process I will post back.

 

Regards, Baldrick

---

Bumping up this thread, I wanted to ask: what happens to the large db files under programdatawrdata? Are they taken care of, in a garbage collection-like process? Or is uninstall/reinstall the only way to get rid of them?

---

As far as I understand it WSA is meant to clean up the dbnnnn files created via monitoring suspicious processes once they have been 'OK'd' but tbh my WRData folder keeps growing (once to 45GB!). I then ask support to whitelist any unknown processes and send them my wsalogs. Their advice previously was to uninstall/reinstall and run a scan afterwards. Recently, they said just run a full scan. But this does not clean up the dbnnnn files, and they confirmed that I could just delete these after whitelisting and running a scan. So I really don't know. Maybe our esteemed members can answer. All I know is I sometimes I have to do this weekly (quite tedious!), but it does not seem to be a general problem. Maybe that is why it is not getting attention.

---

Myself, I have deleted these large db files. If they are not deleteable, this means they are locked by Windows, so WSA is still monitoring an associated application.

 

Still, some housekeeping should be done by WSA itself. The user should not be required to do dangerous things, like deleting stuff that might be needed by the app. Nor should he/she need to uninstall-reinstall the app.

---

Webroot does do some garbage collection, but there are some cases where data still piles up so we're working on improving the process.

---

Thanks nic. I hope it will be improved, so that the following will not be necessary when uninfected. Carnik, here is a recent response from Support: ''There were quite a few files running on your computer that had not yet been classified in our determination database. When Webroot detects unclassified files and processes it will monitor these files for malicious behavior. It will also journal any changes made by the files so that when the files are eventually classified and if they are classified as bad the changes can be rolled back. This is the information that fills up the folder. After analyzing your logs, we have white-listed (classified as good) the unknown processes which SecureAnywhere had been monitoring on your system. You can go ahead and delete the .db files in the WRData folder and then run a new scan of your computer now to update. (click "Scan My Computer" in the Overview window of SecureAnywhere). This should resolve the issue.' You may have to shut down WSA protection to delete the db files. But always ask Support to whitelist your unknown processes/files before doing this.

---

The problem is that WSA monitors too many apps. Too many legitimate apps that is. In the very first day, WSA managed to fill my SSD with 40+ Gigs. In the next 7 days, WSA created similar but smaller files for quite common applications like fastboot and even apps necessary for .net 4!

 

Bottomline: WSA requires a LOT of user intervention:

* The user has to open a ticket for each and every application that gets monitored. This should be done by a user dialog, automatically. That is: app gets monitored ask user if it is a valid one. If it is, app should automatically open a whitelisting process.

 

* Critical things like starving the disk due to the huge dbXXXX files should be immediately notified to the user! It's preposterous that this was communicated via the Windows mechanism (ie "your disk ran out of space"...)

 

Like I said, even though WSA has a much simple interface, it requires much more user intervention than KAV, NAV, F-Secure and Avast...

---

Agree with all your points!

---

You shouldn't really have any apps in monitoring for any length of time. If you do see any in there, either whitelist them on your end, or contact our support to have them whitelisted in our database. What's the situation that's causing you to have so many new applications that are unknown by us?

---

@ wrote:

You shouldn't really have any apps in monitoring for any length of time. If you do see any in there, either whitelist them on your end, or contact our support to have them whitelisted in our database. What's the situation that's causing you to have so many new applications that are unknown by us?

I believe that you've got the actual issue here. It's not that WSA monitors apps (and, hence, creates dbXXXX files). It's that it does so for (a) lots and LOTS of (b) widely-deployed files.

 

@ wrote:

 What's the situation that's causing you to have so many new applications that are unknown by us?

I could joke about it (no sarcasm, here trust me) by stating that it's just that I use my rig for something besides solitaire...

 

I have all sorts of applications on my rig. The applications that got monitored are in a rather respectable to huge circulation. Like the official bitcore client, the official miflash application (used to flash Xiaomi phones), the fastboot.exe Android utility, parts of the official Microsoft distribution for .net under windows 10(!)

 

And I am talking about legitimate apps here, false positives if you prefer.

 

Only a couple of days ago, Firefox's plugin-container got monitored too:

 

Tue 10-11-2015 19:19:40.0237    Monitoring process C:Program Files (x86)Mozilla Firefoxplugin-container.exe [344CC9339BA1022F335B46B95AABF32F]. Type: 3 (6263)

Tue 10-11-2015 19:19:40.0237    Monitoring process C:Program Files (x86)Mozilla Firefoxplugin-container.exe [344CC9339BA1022F335B46B95AABF32F]. Type: 4 (6263)

Tue 10-11-2015 19:19:40.0242    Monitoring process C:Program Files (x86)Mozilla Firefoxplugin-container.exe [344CC9339BA1022F335B46B95AABF32F]. Type: 8 (6263)

 

 

That's regarding my argument that too many widely deployed apps get monitored.

 

And with regard to how well monitoring works, right now I started Miflash to check what WSA would do. In the logs, it has started monitoring alright:

 

Fri 13-11-2015 19:30:02.0582    Monitoring process C:Program Files (x86)XiaomiMiPhoneMiFlash.exe [56103CBE92459C65375AB9BE161A26AA]. Type: 4 (5781)

Fri 13-11-2015 19:30:02.0582    Monitoring process C:Program Files (x86)XiaomiMiPhoneMiFlash.exe [56103CBE92459C65375AB9BE161A26AA]. Type: 5 (5781)

Fri 13-11-2015 19:30:02.0652    Monitoring process C:Program Files (x86)XiaomiMiPhoneMiFlash.exe [56103CBE92459C65375AB9BE161A26AA]. Type: 8 (5781)

Fri 13-11-2015 19:30:04.0132    Monitoring process C:Program Files (x86)XiaomiMiPhoneMiFlash.exe [56103CBE92459C65375AB9BE161A26AA]. Type: 4 (5781)

Fri 13-11-2015 19:30:04.0132    Monitoring process C:Program Files (x86)XiaomiMiPhoneMiFlash.exe [56103CBE92459C65375AB9BE161A26AA]. Type: 5 (5781)

Fri 13-11-2015 19:30:04.0136    Monitoring process C:Program Files (x86)XiaomiMiPhoneMiFlash.exe [56103CBE92459C65375AB9BE161A26AA]. Type: 8 (5781)

 

 

I opened WSA to check whether it was under PC Security gear -> Block / Allow files; nothing there. Don't know if that is a bug or a feature. But it does feel that something is ill-designed with the way the entire monitoring interacts with the system user.

---

That does sound unusual, especially since they are widely used apps. Would you like me to have support follow up to find out what is going on?

---

Sure, no problem. But I can't do that open-ticket-send-logs-and-do-it-again-and-again dance all the time. That's my grunt. The only other time I was involved more with AV issues in the last decade, was the 200 system network I manage at work, running Kaspersky Endpoint Security 10... Then again, it's to be expected considering the net size.

 

WSA has been making me running the hoops. It shouldn't if you ask me. And I consider myself quite experienced on the matter...

---

WSA striked again: after updating Bitcore to the official 0.11.2 (a security update mainly) it took 30" for a the setup and the main program to reach 1Gb of db files...

 

Fri 13-11-2015 20:04:01.0615    Monitoring process D:UsersmichaDocumentsAppsitcoinitcoin-0.11.2-win64-setup.exe [2FFF55520C7436FAE636585CC429AE29]. Type: 3 (6456)

Fri 13-11-2015 20:04:01.0615    Monitoring process D:UsersmichaDocumentsAppsitcoinitcoin-0.11.2-win64-setup.exe [2FFF55520C7436FAE636585CC429AE29]. Type: 4 (6456)

Fri 13-11-2015 20:04:01.0618    Monitoring process D:UsersmichaDocumentsAppsitcoinitcoin-0.11.2-win64-setup.exe [2FFF55520C7436FAE636585CC429AE29]. Type: 8 (6456)

Fri 13-11-2015 20:04:02.0759    Monitoring process D:UsersmichaDocumentsAppsitcoinitcoin-0.11.2-win64-setup.exe [2FFF55520C7436FAE636585CC429AE29]. Type: 3 (6456)

Fri 13-11-2015 20:04:02.0759    Monitoring process D:UsersmichaDocumentsAppsitcoinitcoin-0.11.2-win64-setup.exe [2FFF55520C7436FAE636585CC429AE29]. Type: 4 (6456)

Fri 13-11-2015 20:04:02.0760    Monitoring process D:UsersmichaDocumentsAppsitcoinitcoin-0.11.2-win64-setup.exe [2FFF55520C7436FAE636585CC429AE29]. Type: 8 (6456)

Fri 13-11-2015 20:04:10.0864    Begin passive write scan (3 file(s))

Fri 13-11-2015 20:04:11.0912    End passive write scan (3 file(s))

Fri 13-11-2015 20:04:17.0821    Monitoring process C:Program FilesBitcoinitcoin-qt.exe [6C2A937861198CE76AFAE38199EB8DC6]. Type: 3 (6460)

Fri 13-11-2015 20:04:17.0821    Monitoring process C:Program FilesBitcoinitcoin-qt.exe [6C2A937861198CE76AFAE38199EB8DC6]. Type: 4 (6460)

Fri 13-11-2015 20:04:17.0821    Monitoring process C:Program FilesBitcoinitcoin-qt.exe [6C2A937861198CE76AFAE38199EB8DC6]. Type: 5 (6460)

Fri 13-11-2015 20:04:17.0825    Monitoring process C:Program FilesBitcoinitcoin-qt.exe [6C2A937861198CE76AFAE38199EB8DC6]. Type: 8 (6460)

Fri 13-11-2015 20:05:58.0346    Monitoring process C:Program FilesBitcoinitcoin-qt.exe [6C2A937861198CE76AFAE38199EB8DC6]. Type: 2 (6460)

 

The interesting thing is that again no app is shown to be monitored under PC Security -> Block/Allow files.

---

Ok I'll get someone who is good to take a look. They will still need your log files so they can see what is getting monitored, but I'll get the logs to someone who can really dig into it properly.

---

Excuse my ignorance but where / how do I get to that log / report to see what is being monitored? Re nic's question: If I save a scan log and look at the unknown processes, it seems to be mainly Nirsoft Utilities (see http://blog.nirsoft.net/2015/10/18/antivirus-statistics-and-scores-according-to-false-positives-of-nirsoft-tools/ where WSA is not alone - but why do they come up again and again after repeated whitelistings). Also I run some beta softs, that WSA does not seem to have in their determination database, even though these should not be 'unknown'.

---

Excuse my ignorance but how do I get to that report to see what is being monitored? @: If I save a scan log the [u] files seem to be mainly Nirsoft Utilities (see this link: http://blog.nirsoft.net/2015/10/18/antivirus-statistics-and-scores-according-to-false-positives-of-nirsoft-tools/). But these keep coming back after repeated whitelistings. Also I run a few beta softs that may not be initially known in the determination database, but are not 'obscure' programs.

---

Is it possible to move the WRData file to a drive where I have more room? My C drive is very small. My D and E drives are very big.

---

Hi db999

 

Welcome to the Community Forums.

 

I think that the WRDATA folder must be on the drive that WSA is installed on and therefore protecting. I believe that one can, at install time, used the advanced install options to locate the install of WSA to another drive, whilst still protecting the C: drive, but I have not tried that myself.

 

Let us know if yo would like to try...the worst that can happen is that you have to uninstall/reinstall WSA TWICE rather than just once if what I have suggested does work, and we can provide instructions on how to do this.

 

Regards, Baldrick

---

I don't think the WRData Folder can be put on any other drive but C because it goes into ProgramData Folder and it's hidden but we can ask ? ? ?

 

Thanks,

 

Daniel 😉

---

You could try setting up a symbolic link, but as far as I know there's no setting to change this natively within the application.

---

I am really confused. I see reports of this issue going back to 2013. All kinds of simple and arcane usuer steps are recommended. Allegedly, programmers are being told about the issue with a task to keep the file incheck. As my disk space is eaten by WebRoot my question is - Is there a solution that I may have missed since I do not have the patience to read several years of emails on the subject?

 

---

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 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.

 

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

---

Hello!

 

After being a Kaspersky user for +half-a-dozen years I got fed up with it's cumbersome upgrade policy (I don't get it why I can't get a proper discount as a loyal several years user and it's cheaper to buy a new version every single year, getting the same product for 1/3 of the upgrade price) and also noticing that it is getting bigger and bigger every year made me look around for another security program.

 

Webroot doesn't appear in that many reviews and keeps a low profile, but whenever it shows up it had good reviews so I decided to try it out. I fell in love with it right away! Not because it was all green 🙂 but because it was "green" in terms of resource management: small install size, low memory consumption (probably 1/10 of Kaspersky!) and a ton of intuitive options, so I loved it so much that I bought it already even if the trial period didn't expire yet.

 

And I regret it already!

 

Because of this topic's problem! As a power user, I also keep a very low system partition size and install all I can in other partition, not to mention specific partitions for gaming, media files and actual work. So I had around 20Gb free out of an 100Gb system partition. After a couple days of Webroot usage I noticed I had a disk space problem. After digging around I found that Webroot was the problem and keeps huuuuge files around. I'm deleting them as soon as I can. (I don't know what they are doing but it didn't seem to complain if I deleted them as it writes them back). But the problem is that some times there is more than one, and several Gb each. Right now I have "only" one big file of 11.6Gb. I wouldn't even care if those wwere temp files that could be redirected to another drive, but like this it's unbearable.

 

It's not honest to advertise the program as lightweight (and it is in terms of memory and installation size) but then uses humongous amounts of space as temp files! 

 

PS: Don't know if this helps, but after searching through the scan log for the number of "dbxxxx.db" I found thousands of entries for "Monitoring process d:utils (x86)IDriveWindowsid_img.exe". This is a very small exe file (18Kb) but IDrive is making a ~600Gb backup now (and will keep going for several days). Will that scan stop bothering with it after IDrive finishes the backup?!

---