FYI, same issue; confirmed via WMI-Activity Trace event log entries. Restarting the WMI service does temporarily resolve the issue.
Avast calls create file on tzres.dll about 4000 times a second (shows as wmievent) .
confirmed here too.
ran mbam to see if it came from some malware - nothing - came clean.
removed AVAST - problem stopped !
I am sorry i love avast but can’t keep it when there is code that does this and slows my comp.
Been suffering through the WmiPrvSe.exe calling tzres.dll due to avast bogging down my laptop for over a month now. Came back to this thread as a last resort before uninstalling avast. Disappointing.
+1 for the same issue. Over 5000 people have looked at this thread and plenty have confirmed they’re seeing the same problem with tzres.dll being called by WmiPrvSe.exe.
I’ve uninstalled Avast and have been running without it for 2 weeks now. Since then, I’ve not had a repeat of the system choking that I was getting (Task Manager reporting 99% disk usage) and looking in ProcMon I find no reference to tzres.dll which was practically filling my screen previously.
I appreciate that problems are often not A+B=C, but making no other changes other than to uninstall Avast has removed this tzres issue so it looks pretty damning!
Unless I see something to make me confident that Avast have identified and fixed this issue, I will not be renewing my contract when it expires in January (3x PCs and 3x mobile devices).
CAN WE PLEASE HAVE AN UPDATE FROM ENDT OR OTHER STAFF AS TO CURRENT STATUS!
[quote author=Endt link=topic=150894.msg1205235#msg1205235 date=1429258222]
Posting in an old topic is never a good idea. This isn’t a problem if you’re running the latest version of Avast.
Please start your own topic and supply us with system and security related information so you can receive some help. 
Hi bob3160 - thanks for getting involved.
I was/am running the latest version of Avast - I’m pretty meticulous about that (but without jumping on beta releases) - and it is a problem.
I spoke with support about this two weeks ago, and they eventually told me it was a ‘known Windows issue’ which they could fix for me if I took out an annual contract. The upsell seemed to be all they were interested in telling me. It was at that point that I risked uninstalling and voila, manifestation of the problem went away.
I called them again today to let them know that uninstalling seemingly removed the problem, which suggested a strong association with Avast itself. When I discussed this thread with the operator, he said that as a member of staff (ENDT) had got involved in the thread, the likelihood was that there was a fix currently in process for the next release.
I don’t really see how raising a duplicate thread on a subject covered here - a thread which is still open and unresolved - is helpful.
My comment here was to encourage Avast to chime in and say “Yep. We’ve identified the problem and are working on a fix, hopefully for release by X date.”
You spoke to a third party support contracted by Avast but you didn’t speak to Avast.
To contact Avast directly use the following:
https://www.avast.com/en-us/support
(I am running Windows 10 Professional 64-bit and the latest version of Avast Free.)
While using Procmon (“Process Monitor” from SysInternals) to diagnose an unrelated issue, I noticed that my PC was accessing tzres.dll and tzres.dll.mui 100s of times a second via wmiprvse.exe.
Having spent most of the day trying to figure out what was causing the problem, I eventually stumbled across this thread. I temporarily disabled Avast (turned off self-defence, removed from start-up) and rebooted my PC. Success! Upon restarting Avast, the problem immediately returned.
It’s been a year since the last post in this thread; is there a proper fix for this problem yet? (Other than the workaround described by the link in post 10: manually restarting the “Windows Management Instrumentation” service.)
Bluto
I checked my parents’ laptop today: they also have Avast Free (12.3.2280 build 12.3.3154.19), but with Windows 10 Home rather than Professional.
Same problem with constant hard disk activity due to wmiprvse calling tzres.dll hundreds of times per second.
Assuming there isn’t a fix within Avast itself, does anyone know how to:
- Force the WMI service (“Windows Management Instrumentation”) to load after Avast while booting up Windows 10
or
- Get the WMI service to restart automatically at the end of booting up Windows 10?
Bluto
Just did a Windows 10 update. Then I enabled developer mode and installed bash on ubuntu on windows. Then I ran mv command that hanged the bash terminal. This is noted in a bug: https://github.com/Microsoft/BashOnWindows/issues/1261
Then I started seeing this problem of CPU high utilization of WmiPrvSe.exe and tzres.dll. DCOM Server Process was shown as the culprit. I stumbled upon this thread: http://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-auto-update-broke-computer/594c54f7-f54f-4084-bf8d-ee1adc12d6d0
This thread claims, “This issue may arise when some of the Windows components gets corrupted.” In fact, there are many other threads that don’t mention Avast as the culprit. So I thought mv command had corrupted Windows files. Did a scan using sfc /scannow but no problems were found.
Then I restarted my PC. Now, instead of “DCOM Server Process”, Avast was shown the culprit. I am inclined to think that Avast is the scapegoat. The problem occurred somewhere and “settled” at Avast.
I did a little experiment. I restarted PC. Before Avast had a chance to start, went to Services and manually stopped it. CPU was at 2%. A minute later I started Avast. CPU remained at 2%. Everything looks good. Possibly, a solution is to manually start Avast at boot up. But I am unable to change it to Manual mode due to Permission Denied error.
EDIT
I realize that even if Avast starts automatically, I could manual stop and start it from the icon tray. This returns the system to low CPU utilization.
Thank you for taking the trouble to reply.
I don’t think that Avast is a scapegoat in my case due the following:
[ol]- If Avast is allowed to start-up normally when rebooting, the problem appears
- If Avast is prevented from starting when rebooting, there is no problem… until Avast is started manually, in which case the problem appears.[/ol]
I’d be interested to know if other users reading this post have the same issue. It is easy to check with “Procmon”, a tiny (974 KB) download from Microsoft. Simply run Procmon, click “OK” on the filter box that appears, and then turn off the following from the main window:
- registry activity
- network activity
- process and thread activity
That should leave only “Show file activity” selected. If you have the same problem with Avast as me, your screen should very quickly look like the image in the post above from “thedrs”, with wmiprvse.exe accessing tzres.dll and tzres.dll.mui 100s of times each second.
Bluto
I’ve reported this topic to Avast let’s see if that get’s a reply from Avast.
Did you hear back from Avast?
I sent them a ticket about the problem shortly after you, but haven’t had a response other than an automatic reply. Of the four people I know personally who use Avast, all four experience the same issue. I’m guessing it’s very widespread.
Bluto
Post your ticket-ID.
Hi guys,
we have fixed this issue in Browser Cleanup component and it’ll be delivered through an emmergency update on Monday. We’ll let you know when it’s released.
Thanks
Many thanks for the info (I have also seen your email reply now) - much appreciated.
Look forward to the update.
Bluto
We just released minor update for this issue (for Avast 12.3.x version) – it’ll update AvastUI.exe file within 4-6 hours or immediately after several minutes when a user logs in to Windows. System restart is required to apply the patch, because AvastUI.exe process is running in background. Please verify the change and let us know if it helped.
Opening tzres.dll very frequently isn’t critical, because this file is small and already cached in system memory, but I agree Avast should avoid using WMI queries to cause these side effects in system.
I have just rebooted and can confirm that the fix seems to have done the trick.
The build is showing as 12.3.3154.22 now (rather than .21) and wmiprvse is behaving itself.
Many thanks for resolving this,
Bluto