Solved

wrdata folder


Userlevel 2
Badge +3
Anyone know if the wrdata folder can be cleaned out or deleted? It grows to an enormous size over time.
icon

Best answer by Kit 15 March 2012, 01:31

The db#### files directly relate to monitored processes.  In your situation, you will want to contact support so they can check over what is marked Unknown on your computer and determine it so it will no longer be monitored.  It's also possible that you did something like, for example, install a Service Pack without turning off the AV protection as the Service Pack installer demands you do.
 
In either case, though these files will normally be cleaned up automatically, you will likely want to expedite the cleanup by uninstalling, rebooting, then installing without importing settings.  Afterwards, cleaning up your temp folders would be a good idea.

View original

88 replies

Userlevel 7
Hi BradKilmer
 
Welcome to the Community Forums.
 
As 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.
 
I hope that something in the rambling reponse above is of assistance?
 
Regards, Baldrick
Userlevel 7
Badge +7
Good Morning ?, this is good info about the registry.  
 
I also check my wrdata folder from time to time, especially after installing new apps.  I have had good luck saving a scan log and searching for the xxxx in the dbxxxx.db to see what is lurking about.  
 
I know you are already aware but for BradKilmer's interest, it will look like this :  Thu 2015-09-10 07:39:12.0568 Monitoring process C:Program Files (x86)Common FilesAdobeAdobeGCClientAdobeGCClient.exe [40AE8622D89D27C4F704A324CA82AA70]. Type: 3 (XXXX)
 
From that, I can check the file against VirusTotal and or other means of verifying authenticity and determine if it is safe to delete the .db file, uninstall the app, or wait and see what WSA will ultimately do.  
 
Just one more way.
 
Thanks,
Dave 
Userlevel 7
Badge +55

@Baldrick wrote:
Hi Brad
 
I am looking forward to it.
 
Regards, Baldrick

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 @nic should check with the internal staff on this @BradW @Shawn. 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
Hi BradKilmer
 
That sounds about right but as has been said earlier in this thread you need to be very careful as in amongst the files being monitored there could be ones that genuinely need to be because they are 'undetermined' as to whether good or bad.
 
If you delete the journalling file for one of these and then WS determines that the file is bad, if you have deleted the associated 'dbnnnn.db' file then WSA will be unable to roll back any nefarious actions that the file/app may have been able to take in your system whilst being monitored, and so you will have lost a very useful facility.
 
Personally I would also add in a check for a list of files/apps, i.e., a control list if you will, that you know are good, i.e., the ones you are creating and only delete 'dbnnnn.db' files if the app in the EXE path matches one of the ones in your control list.
 
Just a thought.
 
Regards, Baldrick
Userlevel 7
Badge +55
I agree support is at it's best now, keep up the great work Webroot! :D
 
TH
Userlevel 7
Badge +55
Hello it's best if you Submit a Support Ticket as that tells me you have lots of unknown files that need to be whitelisted! Also they will let you know how to clean up the WRData folder afterwards.
 
Thanks,
 
Daniel ;)
Userlevel 7
Badge +55
I'm sorry everyone in reality no one should be in the WRData Folder that's why it's in a hidden area so I always tell users to: https://community.webroot.com/t5/Webroot-SecureAnywhere-Internet/wrdata-folder/m-p/124026#M2962 to be safe as it would be very upsetting to see someone make a mistake and trash there system in case WSA is monitoring any Malware IMO go through support!
 
Daniel ;)
Userlevel 7
Badge +55
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
Userlevel 7
Badge +55

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

 

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

 

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

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.
 
IMO,
 
Daniel
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
Userlevel 7
Badge +34
I will be careful - the eight I've just deleted all related to software that I had already removed from my PC!
 
As you say this thread is a great example of how we can all learn from the more senior members of the community and I really appreciate all the time and effort that they put in.
Userlevel 7
Badge +34

@TripleHelix wrote:
You can't say we didn't warn you if you muck up your system!
 
Daniel :D
 
 

You can't make it any clearer than that Daniel! :D
Userlevel 2
Badge +3
Webroot support logged on my system yesterday and fixed the wrdata folder problem. Now we will monitor it, and see if the fix holds. The Webroot support team does a great job and my compliments to them.
Snake
Userlevel 7
Hi D_J
 
But of course...I forgot about that way of doing things. :@
 
I am still looking for the Registry entries approach as that gives an even faster way of determining what is what and when I refind it I will advise back.
 
Regards, Baldrick
Userlevel 7
I am afraid that currently here is not. I believe that there is however a Feature Request for that specific functionality and that it may be with us soon...but presently there is no indications on timescales.  All that we know is that "This one is in the works and is waiting on QA testing currently."
 
Please see here for more details on this.
 
Regards, Baldrick
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
Userlevel 7
Badge +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
Badge +7
Thanks ?,  I'm all for faster and better. :D
 
Dave
Userlevel 7
Badge +7
?, ?,
 
I keep tabs on WRData directory several times a week.  It doesn't take long and you can put a shortcut on your desktop to go right to it.  Sometimes I go days and days without any new db files being added.  By checking frequently it never grows to more than two or three .db files at most.  I can almost tell you when I am going to have them and what they are without even looking at the WRLog or Scan log.  For me, it is pretty much a one to one relationship to new or updated apps that I have had an active role in causing.  I do a quick check to verify I am on the right track, run the process of verifying the files as I mention in my other post, and if they are ok, I delete the .db files and don't look back.  If I can't tell for sure I leave the files for a while to see what WSA determines.  So far it has worked for me.
 
Dave
Userlevel 7
Badge +7
You are very welcome Nemo.  It was trial and error for me but it helped me to read posts from other senior members like TripleHelix and Baldrick.  Just play it safe and only delete what you are sure of, knowing that it is always a gamble to some extent.
 
Dave  
Userlevel 7
Badge +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
Userlevel 7
Badge +34
Thank you Dave - the fog has finally lifted for me regarding the db files and I have now been able to delete eight old ones, leaving just one. I know that one is safe but I will just see how long WSA keps monitoring before it deletes it automatically. :D
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.
Userlevel 7
I'm going to add an Official Voice here.
 
The WRData folder (Located under the appropriate System App Data location for the OS) contains the operational parameters of the software as well as all working sets.  For AV, it contains all quarantined files as well as all journalling information from unknown/monitored processes, configuration, logs, etc.  With WSAE and WSAC it also contains the Sync/Backup and Password components repsectively.
 
Quarantined data is obviously kept until deleted from Quarantine.  All Logs and Journalling data is kept for a time period and then automatically cleaned up.  This cleanup can be triggered by age and also by the unknown items being registered as Good.  Upgrade installs will never clean this up, since the Journalling data is critical to the ability to roll back infection actions in the case of an unknown being determined to be bad.
 
If you pkg directory is Big, that is the Extra Stuff (Password and Sync).  It should normally start at about 70-80 MB for a WSAC installation and is primarily affected by sync data.
If your dbl.db file is getting Very Big™️, that is quarantine.  Stop finding threats. ;)
If your dbp.db file is Really Big, much stuff is being monitored.  You can ask Support for assistance with cloud determinations specifically for your PC.  This data is cleaned up automatically as well.
Huge ace files mean that really-complicated threat actions were rolled back.
 
So the location of the size offenders gives the key to what caused them.  Have specific files that are Really Big?  Let me know.
Userlevel 7
Balders - We Webroot folks are sticking to the Community here for the most part.  Though I have lurked at Wilders for months (I was previously the person handling all of the Beta testing tickets), we're trying to avoid spreading ourselves too thin.  Plus, think of the reaction there would have been at Wilders if some "silly Webroot person" invaded Joe and TH's stomping grounds. ;) 
 
Please do feel free to forward the information over there though, with the understanding that it's subject to change (for example, I haven't seen res####.db files in weeks).
 
Snake - While it is true that it's not "normal", it's not impossible and not abnormal.  (I'd hope I have some idea what I'm talking about, since prior to QA, I was an Escalation Engineer. ^.^ )  For example, an unknown toolbar DLL injected into a browser will cause the WRData folder to grow to several hundred MB in short order from normal browsing.  A brand new, unknown copy of a torrent client will have an even more dramatic growth effect.  Also noteworthy that "should be sent to the cloud and then deleted" is halfway accurate.  As long as the item is marked as Unknown, your computer will keep a local journal for rollback purposes.  It only gets cleaned up once the item in question is determined to be good, and that process is not instant.  We'd have to find out from dev what the precise rules are for cleanup and database compacting, however I do know that it can take up to a month.  In general, the correction involves determining what the cause is and addressing that cause (Determintaions on unknowns, Quarantine, sync bloat, etc).
 
Normally I'd just pull up your ticket, but this new community system doesn't allow me to see email addresses, so I have no good way to locate ticket or logs (assuming they exist).  As such I will simply need to hope it's addressed well. :)

Reply

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept or continue browsing you agree to our cookie policy. Learn more about our cookies.

    Accept cookies Cookie settings