• 所有社区 - 中文
    • 所有社区 - 中文
    • 论坛
    • 创意
    • 博客
高级

不是您要找的? 咨询专家!

此论坛帖文需要解决方案。
好评0

22.17.0.183 reintroduces diStRptr.dat problem

I'm opening this thread to expand on comments I made in the current thread relating to problems with Norton automatic background tasks following the release of 22.17.0.183:  https://community.norton.com/en/forums/automatic-background-tasks-not-working#comments

Since the update to 22.17,  Product Maintenance generally runs at 30 minute intervals, as before, but, at least once a day, there is a pause of 2 - 3 hours in which it doesn't run.  Occasionally, it runs twice within 2-3 minutes.     Also, when  Product Maintenance does run, it is running for much longer than usual (particularly after those 2 -3 hour pauses).   This had drawn my attention to the fact that 22.17 has partially re-introduced another old problem - the growth in size of the diStRptr.dat file, which Norton Community Watch uses to store its statistical submissions when it is unable to access the stats.norton.com server to post those submissions.  Product Maintenance also attempts to access that server in order to clear the backlog from the diStRptr.dat file.

Back in 2015 and 2016 I posted threads on this subject (https://community.norton.com/en/forums/progressive-slowing-nis-gui-launch and https://community.norton.com/en/forums/norton-community-watch-needs-entry-hosts-file-function-correctly).   With that original problem, neither Community Watch nor Product Maintenance could contact the server but now it seems that Community Watch can't contact the server, meaning that diStRptr.dat builds up in size, but Product Maintenance can make contact, leading to the extended run times while it clears the backlog from diStRptr.dat.

Since I resolved the original issue, I have never seen diStRptr.dat grow bigger than its base size of 34KB and the run times of Product Maintenance have only rarely exceeded 1-2 seconds but, since the update to 22.17, diStRptr.dat can now grow to over 1MB and the run times of Product Maintenance are sometimes over 2 minutes.

Are other Norton users seeing the return of this issue?

Another question is whether 22.17 has deliberately introduced a change in approach such that caching the statistical submissions in diStRptr.dat is now the default method rather than the fallback, or should the product still work as before?   An answer from Norton/Symantec would be welcome.  Are you there, Sunil_GA? 

One thing I did discover while following up on this issue is that stats.norton.com is no longer a physical Norton server but is now an alias for statsipv6.eastus.cloudapp.azure.com.   (Or sometimes  statsipv6.westus.cloudapp.azure.com.)  Use of Windows Resource Monitor and its Network Activity tab suggests that all IP addresses that the Norton product now uses map back to Microsoft Azure cloud services.  What I don't know is whether this switch to using cloud servers rather that dedicated Norton servers came with the release of 22.17  or whether it pre-dates it.  If the change is a consequence of 22.17 then it raises the question of whether the various problems being reported with 22.17 are issues within with the product itself or issues with the cloud servers.

(For information, my setup is a Dell Optiplex 790 running Windows 7 Pro 64bit.)

回复

好评1 Stats

Re: 22.17.0.183 reintroduces diStRptr.dat problem

It seems that this issue has now been pretty much resolved by the release late last week of the NGC Product Update which appears to have fixed the automatic background tasks issue. (See  https://community.norton.com/en/forums/automatic-background-tasks-not-working#comments )

Since that update, the diStRptr.dat  file has remained at its base size of 34KB with just the occasional growth of a few kilobytes, which is then cleared by the next run of Product Maintenance.

After receiving the NGC Product Update, all background tasks are running at their normal intervals. Live Updates are running every hour with an occasional 2-hour gap.  I've noted that those two hour gaps coincide with similar pauses in the runs of Product Maintenance (usually every 30 minutes) and with the run times of Norton Insight and the Full System or Quick Scans.   It is at those times that the residual occurrences of the growth of the diStRptr.dat file size happen .   It kind of suggests that the Norton product is now suspending some background tasks (or network access for those tasks, e.g., Norton Community Watch) when a task that needs extensive network or specific server access is due.   (Some of my observations of Norton network activity with Resource Monitor also seem to fit with this idea.)   Maybe that was the problem - the suspension/unsuspension process had got fouled up in the previous NGC Product Update release.  Whatever, the latest version seems to have fixed it.

The other thing that has fallen out of the recurrence of this diStRptr.dat problem is that I have discovered that the fix I implemented back in 2016, with a hosts file entry mapping stats.qalabs,symantec.com to the IP address of stats.norton.com, is no longer necessary.  I'm pretty sure that's because, back then, my ISP's DNS servers featured an error redirection service so that a failed DNS lookup did not return a RFC-compliant not-found response but redirected to a third party site intended to assist with web browsing..  The Norton product relies on the failed lookup of stats.qalabs.symantec.com (presumably only available on their internal networks for testing/QA work) before moving on to stats.norton.com.    I have now opted out of that error redirection service and, if I monitor my PC's DNS cache, I can now see the failed lookup of stats.qalabs.symantec.com immediately followed by a lookup of stats.norton.com.

So, for now, things appear to be stable and fixed.

This thread is closed from further comment. Please visit the forum to start a new thread.