Forum Discussion
Win32_DeviceGuard and Win32_TpmProvider triggering errors and network spikes since 20H2!
May I suggest that you at the Microsoft tech team change your policy globally on this matter:
Instead of simply telling people they have posted in the wrong forum (because that's not helpful to anyone), just go ahead and move the thread to the correct forum (which helps everyone). That way, others who find threads like this in the future won't hit a wall just because it was posted in the wrong forum.
Most people I believe find problem-solution threads by using a search engine, and not by navigating any specific forum. Search engines are always vastly superior to a forum's own navigational tools. It doesn't matter to a search engine what forum category the thread was posted in. So, since this thread exists, people might as well make use of it to try and reach a solution.
If you know of a similar thread in the correct forum category, please, put a link to that thread right here in this thread, so as to redirect future search engine users.
Thank you!
I have reinstalled fresh Windows 10 1903 and ironically this error is back. I thought it was exclusive with 1909 and 20H2 only. But I was wrong. Before the reformat or upgrade to latest version, this did not occur.
Maybe these errors are ignore-able, who knows. But I notice how whenever these 2 instances as information get logged on WMI Activity there is another error 1 second before them. Which, is once every day!
Win32_TpmProvider provider started with result code 0x0. HostProcess = wmiprvse.exe; ProcessID = 3188; ProviderPath = C:\Windows\System32\wbem\Win32_TPM.dll
And Win32_DeviceGuard provider started with result code 0x0. HostProcess = wmiprvse.exe; ProcessID = 3188; ProviderPath = %SystemRoot%\System32\Win32_DeviceGuard.dll
When that happens you will see WMIPrvSE.exe running in the background as a system process for at least 35 minutes before it will disappear.
I posted it on the Microsoft forums, but the problem is that because there are too many users posting threads themselves, my thread goes down and down and eventually disappears out of sight and no one is able to help.
Arexodiusadam deltinger
I have finally solved this mysterious error!!!!
Turns out this has absolutely nothing to do with the actual Device Guard Virtualisation as some advised me. This stupid error is triggered due to Device Information Task Schedule that is exclusive to Windows 10 only! You will not find this task schedule in Windows 7 or 8.1.
https://www.ghacks.net/2019/09/23/what-is-devicecensus-exe-on-windows-10-and-why-does-it-need-internet-connectivity/
This is basically another telemetry data collection that Microsoft uses to collect information about your system. This is why you get network spikes when this schedule runs.
The way I found out is that when the error occurred, it corresponded to the exact timing of the task schedule. I have observed this in my last error history that it matches the last task schedule run time. As soon as I disabled this task schedule, the error stopped occurring and you'll no longer get Win32_DeviceGuard and Win32_TpmProvider logged.
I have to say I am really disappointed that, no one was able to tell me that this was the issue triggering the error! Even Microsoft Support failed to give me the right answer. They were giving me the Device Guard advice. I know that had nothing to do with it.
Somehow when I upgraded initially from 1903 to 20H2 the task schedule was reset back to default. But I had no idea that Device Information task schedule was responsible for triggering this error! Now I know and hopefully this should be helpful to others as well!
- Well done!
Thanks for letting me know!
It's unfortunate that Microsoft is unable to provide much useful support on their own products... I don't know whether it's because they don't really value customer care all that much or if they just don't know how it should be done. At the very least, they don't seem to know much about their own products, which is very worrying... I hope I'm wrong but it doesn't look good from what I've seen on every Microsoft forum I've visited.
I went ahead and disabled this task as well and let's hope that won't prevent any useful updates later on.