@ wrote:

Thanks Dermot7. The same happened to me only two and a half weeks ago.

But I assume you didn't get any whitelisting done?

 

And yes, certainly that is a huge size I agree, and that recurring issues like this should be addressed as a priority. 

 

Regards,   

 

Dermot 

 

---

Yes - I did gewhitelisting done then also by The Webroot Advanced Malware Removal Team. I have been through this process dozens of times over the last two or more years 🙂 but none has been as extreme as the last two WRData increases. Looking at my images this latest increase actually took place over two days, first an increase to 13GB or so, then 46GB the next dat.

---

Good advice from Baldrick here also, worth knowing.  

 

---

Thanks. Indeed good advice from Baldrick. I do regularly check 'Control Active Processes' and allow those I know are OK. Also allow all files I that I know about, or want excluded under block/alow files. I tend to use only Firefox and that is allowed under Application Protection. Next time I will wait for Support to do the whitelisting, before I reinstall, and see if WSA does indeed roll back the large dbnnnn files. If not, just delete them ...

---

Hello all, I am experiencing the same problem. Running a Bitcoin client for only 1 hour or so used around 20Gb from my boot drive. Only found out, because it exhausted my (small) SSD boot drive!

 

Since I have not read all pages, what can I do to deal with this?

 

* How can I get rid of this 20Gb?

 

* How can I execute the bitcoin client safely?

 

EDIT: Running: 9.0.5.8

 

Is this going to be solver "real soon"? I see this is an old thread and frankly, this is a huge issue, one that would prohibit me for recommending WSA to friends... You should not have to deinstall/reinstall for crying out loud. This affects installations in a big way (read: critical).

---

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

---

Can I simply whitelist the client and get over with it? I don't have the time to open a ticket each and every time something like this came up. I've passed from a zillion AVs and I definitely did not have to do this.

 

I really love the speed of WSA. However, if problems like this can not be solved, I can not keep using it. Stability and robustness should be priorities, especially for AV software.

 

- Is there any agenda to actually fix this?

 

- Can I simply "pass" this software, without opening a ticket? If I "pass" it, does this knowledge pass to your servers, for "learning" how to deal with this in other installations?

---

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.

---

Thanks for the info Nic. One last question, which is actually one unanswered one from my first post in this thread: my wrdata has some very large db files, one of them > 20Gb. How can I properly get rid of them, preferably without uninstalling and without opening a support ticket?

---

? 

 

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?

---

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. 

 

I hope a webroot developer can inform us on how to safely remove these files.

 

OT a bit: how does one go for opening a ticket, when another one is currently under investigation. Should I use a different mail address and the same password given to me in the other trouble report?

 

The WR ticketing is amazingly anti-ergonomic. Bugzilla was hip 15 years ago, it would be easy to implement something like that here...

---

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?)

 

 

 

 

---

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,

---

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.

---

? any Idea when WSA will clean up after itself from the developers? Because if you even set from Monitor to Allow it keeps on Monitoring hence the WRData folder still grows. ? this must answer your question above?

 

Thanks,

 

Daniel 😉

---

I haven't heard anything lately - I'll check and see if I can find out a status.

---

Thank you ?!

---

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.

Thanks, added a ticket description for this.

 

?: I hope you'll provide this system to home customers too.

 

 

---

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

---

@ 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

 

 

Wed 2015-10-28 21:27:59.0694 Monitoring process D:Program Files (x86)ChrisPC Win Experience IndexChrisPCWEI.exe i8ED6894F971B8B3514C02C1318404988]. Type: 3 (5874)

Wed 2015-10-28 21:27:59.0694 Monitoring process D:Program Files (x86)ChrisPC Win Experience IndexChrisPCWEI.exe i8ED6894F971B8B3514C02C1318404988]. Type: 4 (5874)

Wed 2015-10-28 21:27:59.0703 Monitoring process D:Program Files (x86)ChrisPC Win Experience IndexChrisPCWEI.exe i8ED6894F971B8B3514C02C1318404988]. Type: 8 (5874)

Wed 2015-10-28 21:27:59.0703 Monitoring process D:Program Files (x86)ChrisPC Win Experience IndexChrisPCWEI.exe i8ED6894F971B8B3514C02C1318404988]. Type: 6 (5874)

 

Wed 2015-10-28 21:03:08.0355 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe c9F2A593D974983A5F9CEEABEFEE2B582]. Type: 3 (3550)

Wed 2015-10-28 21:03:08.0355 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe c9F2A593D974983A5F9CEEABEFEE2B582]. Type: 4 (3550)

Wed 2015-10-28 21:03:08.0358 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe c9F2A593D974983A5F9CEEABEFEE2B582]. Type: 8 (3550)

Wed 2015-10-28 21:03:08.0358 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe c9F2A593D974983A5F9CEEABEFEE2B582]. Type: 6 (3550)

Wed 2015-10-28 21:03:08.0449 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe c9F2A593D974983A5F9CEEABEFEE2B582]. Type: 3 (3550)

Wed 2015-10-28 21:03:08.0449 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe c9F2A593D974983A5F9CEEABEFEE2B582]. Type: 4 (3550)

Wed 2015-10-28 21:03:08.0452 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe c9F2A593D974983A5F9CEEABEFEE2B582]. Type: 8 (3550)

Wed 2015-10-28 21:03:08.0452 Monitoring process C:UsersDanielDownloadsShockwave_Installer_Slim.exe c9F2A593D974983A5F9CEEABEFEE2B582]. Type: 6 (3550)

 

---

?nice info. Thing is that the biggest file is db3263. However, 3263 is nowhere to be found in the wrlog.log file...

---

Uninstalling and reinstalling should solve this issue. 

 

-Dan

 

 

---

It doesn't solve it, because the folder will grow huge again - at least for users that use many 'unknown' applications and had to resort to these manual patches in the first place.

 

Only Webroot can solve this, but it's taking them very long...

---

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

---

Maybe they don't know how to fix it 🙂

---