Winmgmt ResetRepository File Already Exists

Solution

This error comes up because the WMI repository has been reset too many times, and windows runs out of file names.

Under "C:\windows\system32\wbem\" you'll see a bunch of "repository.###" folders. These are the backups windows makes of the repository whenever you reset it. However this seems arbitrarily limited to three digits, so once it hits repository.999 it can no longer back the wmi repo up before the reset, so the reset fails.

The quick and dirty solution is to delete the various repository.### folders then try the reset again. Better solution is to find out why the repository is having to be reset so often and try to fix the underlying cause of the WMI corruption.

Full Story

I have a number of problems with WMI repositories becoming corrupt and requiring to be reset. I've never been able to track down the precise cause of these corruptions, so I've just been doing my best to keep things up and running.

Today I ran into a fun problem. I had a VM that wouldn't allow logins (or logins would take forever). Closer inspection saw that it had the telltale signs of WMI problems (1 CPU core maxed out, high memory usage). I rebooted to safe mode to try the reset, but the reset (winmgmt /resetrepository) failed with the error.

WMI repository reset failed. Windows cannot create a file if that file already exists

Or something along those lines. I forgot to write down the exact error before rebooting the machine, sorry. 

Further investigation found the hundreds of "repository.###" folders in the wbem directory. Deleting these folders allowed the reset to run correctly. VM rebooted to normal mode without issue.

Windows RDS (Terminal Server) - Stuck Applying group policy

Had a lovely time yesterday when the terminal server (2008 R2 running RDS) that our users use to access programs/files from off site decided to tank. Luckily we have a backup server... except that one was tanking as well.

The short version is that, at some point over the weekend, the server began taking inordinate amounts of time applying group policy settings, making user log on take upwards of 5 minutes and killing server performance. Some of the error available in event viewer included

• warning|grouppolicy|eventid:1090|"Windows failed to record Resultant Set of Policy (RSoP) information, which describes the scope of Group Policy objects applied to the computer or user. This could be caused by Windows Management Instrumentation (WMI) service being disabled, stopped, or other WMI errors. Group Policy settings successfully applied to the computer or user; however, management tools may not report accurately."
• warning|winlogon|eventid:6005|"The winlogon notification subscriber <GPClient> is taking long time to handle the notification event (CreateSession)."
• warning|winlogon|eventid:6006|"The winlogon notification subscriber <GPClient> took xxx second(s) to handle the notification event (Logon)."

On the user side you would see "Applying user Policy..." for 5+ minutes while trying to login. When I tried to reboot one of the servers it took (quite literally) several hours to get past the "Applying computer settings" screen. On reboot, in task manager you'd see an svchost process using 2+GB of ram and 100% cpu (limited to one core, so it was ~13% in my case). Killing this process would cause all sorts of interesting errors to occur - best I can tell this was the GPclient service. 

After a few hours of trying different things - notably de-joining  from the domain, which didn't work and took forever - I finally figured out it had something to do with the WMI repository. From command line I tried:

winmgmt /verifyrepository

winmgmt /salvagerepository

Neither of these ever returned anything (let them both run, separately, for 30 minutes).  While either was running there would be a winmgmt.exe process in task manager using 100%/13% CPU and progressively more RAM. So, since neither of those worked I tried:

winmgmt /resetrepository

Boom! Everything was back to normal. It was almost disconcerting how quickly everything started working again. Rebooted the server and it shutdown and restarted in its normal couple of minutes. I have yet to discover exactly what caused the wmi repository to corrupt but at least for the time being users are able to get to their stuff.