DSC Registry Resource Performance Issue

When we use the Registry resource vs Script resource to set state for a Registry entry, the WmiPrvSe.exe process spikes to 50% and it takes over 1 minute to enact. The same registry setting set with Script resource takes 5 seconds. It has improved with xPSDesiredStateConfiguration module v5.0. Registry resource took 35 seconds vs 61 seconds. And Script resource actually went up from 5 seconds to 11 seconds.

Has anyone experienced this same issue with the Registry Resource in their configurations?
Can the Registry resource time be improved?

Well, the Registry resource is presently open source, so you could certainly pop it open and have a look. Without knowing what you’re doing in the registry, it’s hard to say. For example, anything in the USER keys could be the result of the LCM starting without that set loaded, and so it has to burn time spinning it up. But you might look and see what code the resource is using, versus what you’re doing in your Script resource.

@Connie T, I’m having the same issue see (https://powershell.org/forums/topic/every-registry-resource-takes-25-seconds-to-set/). I still haven’t been able to pin point exactly what the issue is. It appears to be very deep inside the Registry resource. If I use a Script resource to change the exact same registry setting it takes under second.

Installing .NET 4.6.2 and WMF 5.1 Preview seems to have improved things. Can you verify the same?

I’d also be interested to know what AV solution you’re using and backend hardware?

The problem is described here: https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/13703175-get-psdrive-abnormal-i-o

If you are on Azure, the fact that registry takes a long time may not be a biggest of your problems:

This bug is fixed in WMF5.1 but there is also a workaround available.
Long story short - it requires cleaning up module cache, namely all files in:


We went down from ## seconds to milliseconds.

I can confirm xRegistry is now apply in milliseconds with PS 5.1. Finally it’s fixed!

Hi Bartek and Zuldan, thanks for the reply and follow up to this post. I’ll test today to confirm too!