If you're a Windows OS administrator, you've probably run across the highly frustrating issue of suddenly having your desktop or server Event Log | Application Log fill up with error messages, all of which vaguely reference wmiprvse.exe or WMI specifically.  At the bottom of the article are just a few examples of these entries you might run into.  You may more abruptly discover you have the by way of a script failure or user application error that makes direct use of the WMI subsystem (either locally or remotely).  In any event, if you're like most people, your first thought was probably "how the heck does a Windows provided OS Subsystem corrupt", and second "how do I fix it"?

First thing to understand is that the corruption most likely occurred because of an application which introduced new components to the subsystem.  That said, don't start resolution by looking at the application specifically mentioned, start by verifying if the WMI subsystem is intact or not. Only if the WMI subsystem is functional should you then move on with application-specific troubleshooting. 

Microsoft's first recommendation is to use the local WBEMTEST.EXE utility to attempt a connection to the local subsystem.  Although it's good utility, it can also be a little confusing for new admins.  An easier utility is Microsoft's ScriptOMatic 2, which immediately upon launch locally will tell you if you have a problem, either by returning a general error about being unable to connect, or telling you that no classes are available.  In either case, if you can't connect, you need to rebuild the WMI Repository.

Although this can be done manually from the command prompt, it is much easier to script this.  The below script, saved as RebuildWMIRepository.cmd,  will rebuild the repository:

00    @ECHO OFF
01
02    REM Stoping The Windows Management Instrumentation Service
03    REM Includes all dependent services
04    REM ------------------------------------------------------
05
06    ECHO Stoping The Windows Management Instrumentation Service
07    NET STOP winmgmt /Y
08
09    REM Removing exiting repository
10    REM ------------------------------------------------------
11
12    ECHO Removing exiting repository
13    CD /d %windir%\system32\wbem
14    RD /S /Q repository
15
16    REM Reregister all DLLs
17    REM ------------------------------------------------------
18
19    ECHO Reregister all DLLs
20    for %%i in (*.DLL) do REGSVR32 -s %%i
21
22    REM Reregister all EXEs
23    REM ------------------------------------------------------
24
25    ECHO Reregister all EXEs
26    for %%i in (*.EXE) do %%i /RegServer
27
28    REM Recompile MOFs
29    REM ------------------------------------------------------
30
31    ECHO Recompile MOFs
32    for %%i in (*.MOF) do mofcomp %%i
33    for %%i in (*.MFL) do mofcomp %%i
34
35    REM Reboot
36    REM ------------------------------------------------------
37    ECHO Rebooting...
38    shutdown /f /r /t 1

First step is to shut down the WMI Subsystem (line 7) as well as any dependent services, which on servers can be many.  The /Y switch auto-answers the prompt which appears when the process needs confirmation for multi-process shutdown.  Once services are down, the repository itself needs deleting.  This repository is nothing more than a folder which is dynamically created, so removal is nothing more than deleting the contents and moving on (line 14).   All the DLLs within the WBEM folder must be properly registered, which may or may not be the case in your computers current state.  Line 20 ensures that all DLLs are registered - a DLL can be reregistered without issue.  Most of the EXEs within the folder also require registration, which is accomplished in line 26.  At this stage in the script the WBEMTEST utility will pop up because it is not a registerable executable - this will require manual closing to progress the script. Lines 32 and 33 recompile all MOF files, completing the rebuild of the WMI repository.  Lastly (line 38), the computer must be rebooted.  Although many will argue that you can simply restart the WMI Subsystem (wmimgmt), this only works on systems with zero dependencies on the WMI subsystem, and even then you may start seeing other errors until rebooted.  A restart is the only way to progress.

Once completed, monitor the Event Log and you should no longer see the errors.  If you do, or if they return again after an execution or process from one of the dependent services, you can try rebuilding the repository a second time, but at that point should also start to troubleshoot the application itself to see what action is corrupting the environment.

The Userenv 1090 Event

If the only error you are seeing is the Userenv 1090 error, you may not need to go as far as rebuilding the entire repository.  Your issue may be easily resolved by only reregistering and rebuilding that specific part of the subsystem:

00    @echo off
01
02    REM Reregister the userenv.dll
03    REM ------------------------------------------------------
04   
05    cd /d %windir%\system32
06    regsvr32 /n /i /s userenv.dll
07   
08    REM Recompile MOF
09    REM ------------------------------------------------------
10   
11    cd wbem
12    mofcomp scersop.mof
13   
14    REM Update group policy
15    REM ------------------------------------------------------
16   
17    gpupdate /force

A relatively simple approach: reregister the userenv.dll (line 6), recompile the associated MOF file (line 12) and lastly update the GPOs (line 17).  In this approach, a reboot is typically not required. 

You may discover after running this rebuild that you start to see warning messages in the Event Log | Applications Log:

Source: WinMgmt | Event ID: 5603
A provider, Rsop Planning Mode Provider, has been registered in the WMI namespace, root\RSOP, but did not specify the HostingModel property. This provider will be run using the LocalSystem account. This account is privileged and the provider may cause a security violation if it does not correctly impersonate user requests. Ensure that provider has been reviewed for security behavior and update the HostingModel property of the provider registration to an account with the least privileges possible for the required functionality.

This is a completely benign entry and can be ignored.

The download contains both these scripts.

Source: Application Error | Event ID: 1000
Faulting application wmiprvse.exe, version 5.2.3790.3959, faulting module HPWinHostedEthernetTeam.dll, version 2.1.0.0, fault address 0x00005e70.

Source: Userenv | Event ID: 1090
Windows couldn't log the RSoP (Resultant Set of Policies) session status. An attempt to connect to WMI failed. No more RSoP logging will be done for this application of policy.

Source: MsiInstaller | Event ID: 10005
Product: SMS Advanced Client -- Error 25100. Setup was unable to create the WMI namespace CIMV2\SMS
The error code is 8004100E