Problem and Symptoms:
In the error log, after you log on for the first time after Windows setup, you see errors like "The Windows Security Center Service was unable to establish event queries with WMI to monitor third party AntiVirus and Firewall." (code 1802 from SecurityCenter) or "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." (code 1090 from Userenv)
If you get the Security Center error, then Security Center will also complain about not being able to find your third-party firewall or AV (the third-party firewall/AV will continue to work without problems), but aside from that, this problem can easily go undetected.
I first learned about this problem from a post by jessjcee in my thread over a month ago. I have since encountered it myself, and beefy147 also reports seeing this problem.
Because this problem is intermittent and random (see Cause) and because its symptoms are generally not noticeable unless you get the Security Center error (you might only get the Userenv error without the SC error) and are also running a third-party firewall/AV, this is a problem that's easy to overlook.
Cause:
According to Microsoft's documentation, this is caused by a corruption of the WMI repository. As for what is causing this corruption, I have no idea. From online documentation and discussions, it seems that repository corruptions happen at random and that this repository corruptions have been happening for years.
And when I say "at random", I mean "at random". In other words, I could install Windows to a VPC and not encounter this problem at all. But then if I do the same install again, with the exactly same VPC, the exact same installation image, and the exact same installation procedure, the problem might come up. It's intermittent and totally unpredictable; sometimes the repository gets corrupted during setup, sometimes it doesn't. In my experience, most of the time, this problem doesn't come up. So not only is it random and intermittent, it's also infrequent, which makes noticing it very hard.
In order to improve the stability of the WMI repository, Microsoft publicly issued KB933062 to "reduce the probability that the repository could be corrupted." But it doesn't fix the problem because all of these reported errors are post-KB933062. Since I don't have any data on the frequency of this problem pre-KB933062 and post-KB933062, so I don't know if KB933062 is making things better, making things worse, or not changing anything.
Solution:
According to Microsoft, the proper way to fix a WMI repository problem is by deleting the repository, which would cause WMI to automatically rebuild it. Sorta like what you'd do if the Windows icon cache goes bonkers. So if we could force WMI to always rebuild its repository during the first bootup after setup completes (before the Security Center and other WMI-dependent things launch for the first time), then we can get rid of the problem of the repository being randomly corrupted during setup.
So the solution I came up with was to use Windows' own pending file operations functionality to schedule the repository for deletion at reboot. There are two reasons why I chose to do this. First, if these operations are scheduled during setup, then the repository will be deleted during the reboot between setup and first boot, which is exactly where we want it to be (after setup but before Security Center and other WMI-dependent things start up for the first time). Second, the repository can't be deleted while WMI is running (and WMI is running during Windows setup), so the only way to delete the repository is by either manually shutting the WMI service prior to deletion or to have the deletion happen during a reboot.
And so, here is resetwmi. It's a small 1 KB utility (source code is included) that will schedule the repository for deletion. So how do you use it? Simple: make sure that resetwmi.exe is run some time during setup, before the first boot. There are three ways to do this:
Option 1: Add resetwmi.exe to SetupHotfixesToRun (svcpack.inf)
Option 2: Add resetwmi.exe to cmdlines.txt
Option 3: Add resetwmi.exe to SetupParams
It doesn't matter which method you choose, since resetwmi only schedules the deletions with Windows; the actual deletions don't happen until reboot. (And no, RunOnce or RunOnceEx will obviously not work because those are run after the first boot, which would result in the problem being fixed by the second boot instead of being fixed by the first boot.)
Notes:
I've been using resetwmi for about a month now. Ever since adding it to my setup, the frequency of these setup WMI corruptions has dropped from infrequent to never-happens. Since nobody else posted about this problem, I never bothered to make it public until beefy147's post prompted me to do so.
Also, although the the problem of setup-stage repository corruption was the impetus behind resetwmi, this tool can also be used to repair post-setup repository corruptions. Just run it and reboot.
[Tool] Fixing WMI repository corruption issues
[Tool] Fixing WMI repository corruption issues
Last edited by code65536 on Mon Oct 13, 2008 4:08 pm, edited 3 times in total.
OH i'll give a try to your fix!
But for me
the cause:
-Since this KB933062
-When something goes wrong at t-13 or after (bad addon-bad .net 2 installation)
-I've notified : when this occur the time between t-13 and first boot is very speed.
FIX
That worked once (habitually i got this on VM and rewrite faulty addon before retry.. I've a user that use a beta build of my update pack and got this error. I fixed by installing .net 1.0 + 2.0 (an unattended version + fix) but but... And it's on a live machine used dayli, with a lot of apps.
I'll test your fix next time this happen to me.
ELrico
PS : i make a french updatepack and some addons for it. And i see this error in the same familly as framedyne.dll error.
But for me
the cause:
-Since this KB933062
-When something goes wrong at t-13 or after (bad addon-bad .net 2 installation)
-I've notified : when this occur the time between t-13 and first boot is very speed.
FIX
That worked once (habitually i got this on VM and rewrite faulty addon before retry.. I've a user that use a beta build of my update pack and got this error. I fixed by installing .net 1.0 + 2.0 (an unattended version + fix) but but... And it's on a live machine used dayli, with a lot of apps.
I'll test your fix next time this happen to me.
ELrico
PS : i make a french updatepack and some addons for it. And i see this error in the same familly as framedyne.dll error.
I had wondered if KB933062 may have been the cause, which would be ironic because it's supposed to fix this sort of problem. 
But I couldn't be sure because I hadn't done enough integrations before and after KB933062 to see if that was the cause, so thanks for the confirmation about that.
Since you say that KB933062 is the cause, I think I'm going to include resetwmi.exe as a standard part of my update addon (to be run from svcpack.inf); there's no harm in running resetwmi.exe when you don't need to, so I think it's better to just run it for all setups just to be on the safe side (I've included resetwmi.exe in cmdlines.txt for all my integrations for the past month).
But I couldn't be sure because I hadn't done enough integrations before and after KB933062 to see if that was the cause, so thanks for the confirmation about that.Since you say that KB933062 is the cause, I think I'm going to include resetwmi.exe as a standard part of my update addon (to be run from svcpack.inf); there's no harm in running resetwmi.exe when you don't need to, so I think it's better to just run it for all setups just to be on the safe side (I've included resetwmi.exe in cmdlines.txt for all my integrations for the past month).
@code
Just a thought but, could you post an addon for this? I would love to simply include it in an nlite or RVMI build sequence. In fact, if it performs transparently regardless of any corruption or not, it might be worth putting into the main RVM Update...??? If its transparent who cares if it is there or not...
Just some thoughts to help cut down on errors/corruptions.
And, thanks!!!
Just a thought but, could you post an addon for this? I would love to simply include it in an nlite or RVMI build sequence. In fact, if it performs transparently regardless of any corruption or not, it might be worth putting into the main RVM Update...??? If its transparent who cares if it is there or not...
Just some thoughts to help cut down on errors/corruptions.
And, thanks!!!
Next time i got this error i remove only the supicious file from my CD and restest.code65536 wrote:I had wondered if KB933062 may have been the cause, which would be ironic because it's supposed to fix this sort of problem.
Since you say that KB933062 is the cause, I think I'm going to include resetwmi.exe as a standard part of my update addon (to be run from svcpack.inf); there's no harm in running resetwmi.exe when you don't need to, so I think it's better to just run it for all setups just to be on the safe side (I've included resetwmi.exe in cmdlines.txt for all my integrations for the past month).
And i do a search once month ago but no result.
TY for quick reply
-
RogueSpear
- Posts: 1155
- Joined: Tue Nov 23, 2004 9:50 pm
- Location: Buffalo, NY
For the last several versions of my "Other Runtimes" installer I have been using Windows "pending moves" function to get new versions of locked files into system32. Since this is usually done from svcpack I'm wondering if my installer would overwrite the pending instructions of your utility - or the reverse.
-
Mitsuko Aninikkou
- Posts: 210
- Joined: Tue Dec 13, 2005 12:52 pm
- Location: The Netherlands (But running US WinXP, in case it comes up)
From looking at the source code that he graciously included, code65536's tool uses the MoveFileEx function to delete the files. This function places each of the files that need to be removed in this registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
I don't know what the syntax is for this key, but I'd say it's fairly safe to assume that each move action will have a unique name, so shouldn't interfere with any pending moves you're putting there.
By the way, code, why do you use a for loop here? Using a do-while loop should get the same result, and doesn't need the boolean variable. Not that it really matters in such a tiny application
I don't know what the syntax is for this key, but I'd say it's fairly safe to assume that each move action will have a unique name, so shouldn't interfere with any pending moves you're putting there.
By the way, code, why do you use a for loop here? Using a do-while loop should get the same result, and doesn't need the boolean variable. Not that it really matters in such a tiny application
-
RogueSpear
- Posts: 1155
- Joined: Tue Nov 23, 2004 9:50 pm
- Location: Buffalo, NY
Unfortunately I am not (yet) C/C++ literate 
My runtimes installer is VBscript and what I'm actually doing is constructing a string which is eventually passed on to reg.exe. An unfortunate limitation of reg.exe is that is seems to wipe clean a REG_MULTI_SZ value before populating it with whatever it is you want in there.
I wasn't sure if c64k's method left intact existing entries.
My runtimes installer is VBscript and what I'm actually doing is constructing a string which is eventually passed on to reg.exe. An unfortunate limitation of reg.exe is that is seems to wipe clean a REG_MULTI_SZ value before populating it with whatever it is you want in there.I wasn't sure if c64k's method left intact existing entries.
Re: overwriting
Since the entries are added via MoveFileEx, it's the WinAPI that ultimately does the registry editing, and it is done in a way that preserves any existing entries in there (it's okay to have duplicates, too; run resetwmi twice, and you'll see two sets of the same entries).
Re: for loop
It used to be a for loop for other reasons, but then I changed the code around but never bothered to change the for loop even though a do-while would suffice. But as you said, it doesn't matter, b/c the compiler optimized it to a do-while equivalent anyway.
Since the entries are added via MoveFileEx, it's the WinAPI that ultimately does the registry editing, and it is done in a way that preserves any existing entries in there (it's okay to have duplicates, too; run resetwmi twice, and you'll see two sets of the same entries).
Re: for loop
It used to be a for loop for other reasons, but then I changed the code around but never bothered to change the for loop even though a do-while would suffice. But as you said, it doesn't matter, b/c the compiler optimized it to a do-while equivalent anyway.
It's generally not a good idea to manually edit the PendingFileRenameOperations key because you risk clobbering any entries placed there by other apps and installers. The safe (and official) way to do this is via the WinAPI's MoveFileEx function, since it ensures that each entry is added correctly in the right format and that the new entry will not interfere with any existing entries.
However, in an environment where it's not possible to call MoveFileEx, (e.g., batch files), you will have to use a helper app, such as pendmove. It's a small 1 KB utility (source code is included) that will schedule a file move or delete at restart. It's basically a wrapper for the Unicode version of MoveFileEx (i.e., MoveFileExW) with the MOVEFILE_DELAY_UNTIL_REBOOT flag set. For more details about how pending file operations are handled, please consult the documentation for MoveFileEx.
To use, just run "pendmove ExistingFile [NewFile]". This will schedule ExistingFile to be moved to NewFile at boot. To delete ExistingFile, just omit NewFile.
For example, to replace an in-use shell32.dll, you'd do this:
pendmove "%windir%\system32\shell32.modded" "%windir%\system32\shell32.dll"
pendmove is similar to the Sysinternals movefile tool, except...
* pendmove is much smaller (1 KB vs. 143 KB)
* pendmove won't pop up an annoying EULA dialog at first run (the Sysinternals EULA dialog basically makes movefile useless for unattended environments)
* pendmove uses the GUI subsystem instead of the CUI (console) subsystem, so it won't pop up a console when you run it
However, in an environment where it's not possible to call MoveFileEx, (e.g., batch files), you will have to use a helper app, such as pendmove. It's a small 1 KB utility (source code is included) that will schedule a file move or delete at restart. It's basically a wrapper for the Unicode version of MoveFileEx (i.e., MoveFileExW) with the MOVEFILE_DELAY_UNTIL_REBOOT flag set. For more details about how pending file operations are handled, please consult the documentation for MoveFileEx.
To use, just run "pendmove ExistingFile [NewFile]". This will schedule ExistingFile to be moved to NewFile at boot. To delete ExistingFile, just omit NewFile.
For example, to replace an in-use shell32.dll, you'd do this:
pendmove "%windir%\system32\shell32.modded" "%windir%\system32\shell32.dll"
pendmove is similar to the Sysinternals movefile tool, except...
* pendmove is much smaller (1 KB vs. 143 KB)
* pendmove won't pop up an annoying EULA dialog at first run (the Sysinternals EULA dialog basically makes movefile useless for unattended environments)
* pendmove uses the GUI subsystem instead of the CUI (console) subsystem, so it won't pop up a console when you run it
Last edited by code65536 on Mon Oct 13, 2008 4:07 pm, edited 4 times in total.
-
RogueSpear
- Posts: 1155
- Joined: Tue Nov 23, 2004 9:50 pm
- Location: Buffalo, NY
I wasn't aware of that pendmove utility; only the SysInternals tool (yuck). I'm going to see if I can somehow make the native call through vbs, but failing that I'll like start to use pendmove. I always like to try and accomplish something in VBscript without resorting to outside tools. Although you could probably make the argument that by calling reg.exe I was resorting to something else Anyway thanks for the heads up on that.
Anyway thanks for the heads up on that.-
RogueSpear
- Posts: 1155
- Joined: Tue Nov 23, 2004 9:50 pm
- Location: Buffalo, NY
Waoo!!!
This can be good for deleting plugin.ocx (i use runonce and file delete section, because i want empty setuperr.log), this utility delete cache file too? And i can replace .modded by what i want?
And i just found a iso on my drive that give me these error in the event log. I'll make some test (after the work) :
-try on VM with replacing the kb file by original XP file.
-try with your resetwmi tool.
But two questions, when this error occur i notice that time between t-13 and first reboot of windows is less than 1 mn (versus 3-4 mn)
I must run this tool (resetwmi) at t-13? Or first reboot is safe?
And this short time is a problem? (sorry my english gramar and word knowledge is too short too for this last question)
ELrico
PS : i just remmeber : a friend use this iso on a live machine, i'll send him you're tool and give you feedback.
This can be good for deleting plugin.ocx (i use runonce and file delete section, because i want empty setuperr.log), this utility delete cache file too? And i can replace .modded by what i want?
And i just found a iso on my drive that give me these error in the event log. I'll make some test (after the work) :
-try on VM with replacing the kb file by original XP file.
-try with your resetwmi tool.
But two questions, when this error occur i notice that time between t-13 and first reboot of windows is less than 1 mn (versus 3-4 mn)
I must run this tool (resetwmi) at t-13? Or first reboot is safe?
And this short time is a problem? (sorry my english gramar and word knowledge is too short too
for this last question)ELrico
PS : i just remmeber : a friend use this iso on a live machine, i'll send him you're tool and give you feedback.
-
newsposter
- Posts: 1131
- Joined: Wed Sep 14, 2005 11:31 am
@elrico
Sure, pendmove can delete pretty much anything (except for non-empty directories).
The repository is first built right after the OC manager finishes installing (this happens long before T13). So resetwmi must be run some time after that and before the first boot, which is a pretty big window of opportunity. Since the deletions don't occur until boot, it doesn't matter when you run it, as long as it's run some time during that window of opportunity (either at T13/svcpack, T12/cmdlines, or T9/setupparams).
But there is one problem: My T13 stage is always the same length regardless of whether I get the WMI corruption or not. The things that I run at T13 are very simple (no .NET installers, for example), and they always succeed without any errors. So I don't think that your T13 errors are causing the WMI corruption; instead, I think that the WMI corruption is causing your T13 errors. Unfortunately, resetwmi will only fix WMI corruption problems after the first boot, so if WMI is causing your T13 errors, then resetwmi would not be able to help your T13 installers avoid those errors.
@newsposter
It's both (I assume you're asking about resetwmi). If you run it during setup, then it gets rid of any WMI corruption that might happen during setup. If you run it on a normal post-setup system, it can be used to correct WMI corruption problems (after a reboot).
Sure, pendmove can delete pretty much anything (except for non-empty directories).
The repository is first built right after the OC manager finishes installing (this happens long before T13). So resetwmi must be run some time after that and before the first boot, which is a pretty big window of opportunity. Since the deletions don't occur until boot, it doesn't matter when you run it, as long as it's run some time during that window of opportunity (either at T13/svcpack, T12/cmdlines, or T9/setupparams).
But there is one problem: My T13 stage is always the same length regardless of whether I get the WMI corruption or not. The things that I run at T13 are very simple (no .NET installers, for example), and they always succeed without any errors. So I don't think that your T13 errors are causing the WMI corruption; instead, I think that the WMI corruption is causing your T13 errors. Unfortunately, resetwmi will only fix WMI corruption problems after the first boot, so if WMI is causing your T13 errors, then resetwmi would not be able to help your T13 installers avoid those errors.
@newsposter
It's both (I assume you're asking about resetwmi). If you run it during setup, then it gets rid of any WMI corruption that might happen during setup. If you run it on a normal post-setup system, it can be used to correct WMI corruption problems (after a reboot).
Hi, sorry for the late reply, i was very busy.
I got the wmi error in my last beta, and your tool worked well (TY).
I change only the file rep..dll by the original XP SP2 version in the iso and the error was gone. I use always the same procedure for all my tests, and all was done on a VM.
But the strange things:
Between beta 1 and 2 i changed only 3 things on my updatepack:
-i add some lines on the inf for deleting "plugin.ocx" in system32\dllcache, but with this [DestinationDirs] FBCacheFiles.Del=65619, (don't work
next time i use 11,dllcache).
-added KB935708
-added a forgotten silent switch for flash (i don't use obsolet file section but redistribuable installer)
I don't understand why i got the error on b2 and not b1.
The second thing, no problem for t13 to the end time -WMI error or not- (but i never got this before this KB, and i tested a lot of (faulty )addons, coincidence??? or WMI error + heavy installer?).
Anyway thanks for restWMI, very good and usefull. (tried advice from MS but don't worked, your tool work like a charm). I'll think use it for my next pack.
ELrico
EDIT : i don't know already if i'll use you're tool, remove totally this KB (and provide an addon for it), or jump the install of it at first reboot...
I got the wmi error in my last beta, and your tool worked well (TY).
I change only the file rep..dll by the original XP SP2 version in the iso and the error was gone. I use always the same procedure for all my tests, and all was done on a VM.
But the strange things:
Between beta 1 and 2 i changed only 3 things on my updatepack:
-i add some lines on the inf for deleting "plugin.ocx" in system32\dllcache, but with this [DestinationDirs] FBCacheFiles.Del=65619, (don't work
next time i use 11,dllcache). -added KB935708
-added a forgotten silent switch for flash (i don't use obsolet file section but redistribuable installer)
I don't understand why i got the error on b2 and not b1.
The second thing, no problem for t13 to the end time -WMI error or not- (but i never got this before this KB, and i tested a lot of (faulty
)addons, coincidence??? or WMI error + heavy installer?).Anyway thanks for restWMI, very good and usefull. (tried advice from MS but don't worked, your tool work like a charm). I'll think use it for my next pack.
ELrico
EDIT : i don't know already if i'll use you're tool, remove totally this KB (and provide an addon for it), or jump the install of it at first reboot...
Ok i only changed FBCacheFiles.Del=65619 by FBCacheFiles.Del=11,dllcache)on rvmupd.inf, cabed it and replaced the file on my CD and i got only one error in event log (1805 about security center and WMI) Strange no?
For pendmove i've a request, can this utilisty add the key "allowprotectedrename" in session manager because i've got a lot of trouble with this (pendmove don't delete protected sfc file if this key is not set in the registry).
And one question :
When i use delfiles section in inf, the sfc/wfp protected file is deleted but copied in windir\lastgood, and restored less than 30 secondes after. Do you think if i use allowprotectedrename at 1 in registry the file is deleted for good? (i ask this because MS use this way for deletng plugin.ocx and the file is imediatly and defnitively deleted -before reboot) Or when we apply an update the directive of an inf are parsed differently?
I ask to you because you seem to know a lot of things about this
Sorry if don't ask all in the good place.
Bye and thanks for your usefulls tools.
For pendmove i've a request, can this utilisty add the key "allowprotectedrename" in session manager because i've got a lot of trouble with this (pendmove don't delete protected sfc file if this key is not set in the registry).
And one question :
When i use delfiles section in inf, the sfc/wfp protected file is deleted but copied in windir\lastgood, and restored less than 30 secondes after. Do you think if i use allowprotectedrename at 1 in registry the file is deleted for good? (i ask this because MS use this way for deletng plugin.ocx and the file is imediatly and defnitively deleted -before reboot) Or when we apply an update the directive of an inf are parsed differently?
I ask to you because you seem to know a lot of things about this
Sorry if don't ask all in the good place.
Bye and thanks for your usefulls tools.
The final word :
Now all is fine, plugin.ocx is delted, no setuperr.log and no event logs with red cross.
I changed only this on RVMUpPck.inf ("ELlauncher.AddReg" and "elfirstboot.AddReg" are in "AddReg=" of "[RVMUpdatePack]" section):
Before (beta2)
I think that WMI corruption occur when a little error come during setup.
If error occur again i say here.
Now all is fine, plugin.ocx is delted, no setuperr.log and no event logs with red cross.
I changed only this on RVMUpPck.inf ("ELlauncher.AddReg" and "elfirstboot.AddReg" are in "AddReg=" of "[RVMUpdatePack]" section):
Before (beta2)
After (beta4)[Firstbootrun]
DelFiles =FBCacheFiles.Del,FBSystem32Files.Del
[elfirstboot.AddReg]
HKLM,"%RUNONCE%","elfirstboot",,"REG ADD ""HKLM\%RUNONCE%"" /v ""elfirstboot"" /t REG_SZ /d ""rundll32.exe advpack.dll,LaunchINFSection %17%\RVMUpPck.inf,Firstbootrun"""
[SourceDisksNames]
1 = "ELrvmUPD",\win51,,\i386
[DestinationDirs]
FBSystem32Files.Del=11
System32Files.Copy=11
FBCacheFiles.Del=65619
[SourceDisksFiles]
flashie.exe =1
eltzupd.exe =1
elmsxml6.exe =1
[FBCacheFiles.Del]
plugin.ocx
[FBSystem32Files.Del]
plugin.ocx
flashie.exe
eltzupd.exe
elmsxml6.exe
[System32Files.Copy]
flashie.exe
eltzupd.exe
elmsxml6.exe
[ELlauncher.AddReg]
HKLM,"%RUNONCE%","elflash",,"flashie.exe /S"
HKLM,"%RUNONCE%","eltzupd",,"eltzupd.exe /quiet /passive /norestart /nobackup"
HKLM,"%RUNONCE%","elmsxml6",,"elmsxml6.exe"
And added pendmove in i386. I've just forgot a /f for an addreg (not trully unattended (a dos windows say me "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" AllowProtectedRenames. allready exist, overwrite?))[Firstbootrun]
DelFiles =FBSystem32Files.Del
[elfirstboot.AddReg]
HKLM,"%RUNONCE%","elfirstboot",,"REG ADD ""HKLM\%RUNONCE%"" /v ""elfirstboot"" /t REG_SZ /d ""rundll32.exe advpack.dll,LaunchINFSection RVMUpPck.inf,Firstbootrun"""
HKLM,"%RUNONCE%","elclean-1",,"REG ADD ""HKLM\SYSTEM\CurrentControlSet\Control\Session Manager"" /v ""AllowProtectedRenames"" /t REG_DWORD /d ""00000001"""
HKLM,"%RUNONCE%","elclean-2",,"pendmove %11%\dllcache\plugin.ocx"
HKLM,"%RUNONCE%","elclean-3",,"pendmove %11%\plugin.ocx"
[SourceDisksNames]
1 = "ELrvmUPD",\win51,,\i386
[DestinationDirs]
FBSystem32Files.Del=11
System32Files.Copy=11
[SourceDisksFiles]
flashie.exe =1
eltzupd.exe =1
elmsxml6.exe =1
pendmove.exe = 1
[FBSystem32Files.Del]
flashie.exe
eltzupd.exe
elmsxml6.exe
[System32Files.Copy]
flashie.exe
eltzupd.exe
elmsxml6.exe
pendmove.exe
[ELlauncher.AddReg]
HKLM,"%RUNONCE%","elflash",,"flashie.exe /S"
HKLM,"%RUNONCE%","eltzupd",,"eltzupd.exe /quiet /passive /norestart /nobackup"
HKLM,"%RUNONCE%","elmsxml6",,"elmsxml6.exe"
I think that WMI corruption occur when a little error come during setup.
If error occur again i say here.
pendmove has a bug that prevents it from moving protected files (in order to move a protected file, pendmove needs to first set a registry key that tells Windows that it's okay to move protected files (Windows automatically resets the key once the move has completed)--which is really silly because it doesn't improve the "protection" of protected files and just makes apps have to jump through one extra hoop). Anyway, I need to update pendmove so that it sets this key; it just hasn't been a priority so I haven't gotten around to it yet.
(This does not affect resetwmi, just pendmove)
(This does not affect resetwmi, just pendmove)
thanks, I've also found some infos at RogueSpear's site, in its "other runtimes" addon, he uses pendmove and manualy sets that reg entry when required
making this update to pendmove would be very useful for some people
however, since pendmove would let replace protected system files very easily (even if it was already possible before of course), could it be considered a potential security hole? I think the answer is no, but I just want to make sure
making this update to pendmove would be very useful for some people
however, since pendmove would let replace protected system files very easily (even if it was already possible before of course), could it be considered a potential security hole? I think the answer is no, but I just want to make sure
Nope. pendmove requires admin privs to run; if a potential attacker already has the ability to launch something with admin privs, then you've already lost. It does not allow someone to do something that they cannot already do.OuTman wrote:could it be considered a potential security hole?
pendmove has been updated to address this issue (which does not affect resetwmi and actually has nothing to do w/ resetwmi; I know, pendmove is a bit off-topic, but it's minor enough that it makes sense to piggyback on the resetwmi thread instead of getting a thread of its own). Thanks to those who reported the issue.code65536 wrote:pendmove has a bug that prevents it from moving protected files (in order to move a protected file, pendmove needs to first set a registry key that tells Windows that it's okay to move protected files (Windows automatically resets the key once the move has completed)--which is really silly because it doesn't improve the "protection" of protected files and just makes apps have to jump through one extra hoop). Anyway, I need to update pendmove so that it sets this key; it just hasn't been a priority so I haven't gotten around to it yet.
-
ricktendo64
- Posts: 3214
- Joined: Mon May 22, 2006 12:27 am
- Location: Honduras
code65536 IDK if your tool solves this problem (I cannot test, I already ran the script) but you should look into adding this fix to resetwmi if not already included
http://support.microsoft.com/kb/950375
http://www.msfn.org/board/topic/151029- ... p1-install
http://support.microsoft.com/kb/950375
http://www.msfn.org/board/topic/151029- ... p1-install
ResetWMI nukes the WMI cache to fix problems in which the cache becomes corrupt. From a cursory skim of the KB article (disclaimer: I did not read it very carefully), it seems that the problem there is with messages polluting the event log and a way to disable those specific messages. These are two very different issues, and it won't be appropriate to lump the latter into the former...
-
ricktendo64
- Posts: 3214
- Joined: Mon May 22, 2006 12:27 am
- Location: Honduras
-
ricktendo64
- Posts: 3214
- Joined: Mon May 22, 2006 12:27 am
- Location: Honduras
KB950375 update: ResetWMI WOULD! fix this problem bu I could not get it to work on Win7 x64 (I tried x86-64 with no luck) however I manually stoped the WMI service and deleted the contents of the \Repository folder, rebooted and the error is gone
Is ResetWMI compatible with Windows 7 x64?
Next time I install I will try deleting the \Repository contents in the mounted WIM see how that goes
Is ResetWMI compatible with Windows 7 x64?
Next time I install I will try deleting the \Repository contents in the mounted WIM see how that goes
All ResetWMI does is clean all files in Windows\System32\wbem\Repository\FS. You can manually do this via a cmd command if you don't mind watching a black cmd window flashes.
BTW, I looked at the redist package, there is a x64 release, it should be compatible with Windows 7 x64 if we ignore the file permissions. I can't find the FS directory on my Win7 32-bit OS, but the files in Repository directory are restricted to access by SYSTEM and Administrators. So if you have admin permissions, you are supposed to be able to do the job.
BTW, I looked at the redist package, there is a x64 release, it should be compatible with Windows 7 x64 if we ignore the file permissions. I can't find the FS directory on my Win7 32-bit OS, but the files in Repository directory are restricted to access by SYSTEM and Administrators. So if you have admin permissions, you are supposed to be able to do the job.
WMI.... ah the fun I've had with it. Note that this fix is not related to RVMI at all and is meant as an "after-the-fact" fix rather than preventive medicine to be incorporated into an update pack. Since I'm not an expert on the subject other than by means of simple trial and error I wanted to post what I've done so that hopefully either someone can explain why it works or they can take it and modify it to only use what's actually required. After many attempts to fix the random WMI problems that kept occurring in my workplace I came across two separate things that seem to be involved. *Note* all the following involve command line tools which means that batch files can be created for them.
1) Permissions
Who would've guessed that permissions could be involved with WMI problems especially when running as a local or even domain administrator?
With this command I have successfully resolved permissions related problems in WMI:
SC is the service control tool, SDSET sets the security descriptors, WINMGMT is the WMI service name.
Security descriptor information can be found out here: Jorge's Quest For Knowledge (Blog)
A brief description of the above security descriptor is simply that "BA", the built-in administrators group, "SY", the local system account, and "AU", the authenticated users group are all assigned permissions on the winmgmt service. For a more complete description the following site proved most useful: MSDN ACE Strings
Once permissions are set correctly you now have access to not only start and stop the winmgmt service but to verify that it's running and even use the windows WMI tools.
2) The WMI Repository
The most simple fix you'll probably find for this is just to use the command "winmgmt /resetrepository" however that hasn't always worked for me. Here's the complete list of commands that I've come across; some of them may not be necessary and some may be redundant but running all of them in the order posted here has always managed to fix the WMI repository for me.
At this point the WMI repository should be fixed. You can now run "sc query winmgmt" to verify that the service is running again and once it is you can then restart the firewall and security center services as needed.
Here is the complete batch file I created:
1) Permissions
Who would've guessed that permissions could be involved with WMI problems especially when running as a local or even domain administrator?
With this command I have successfully resolved permissions related problems in WMI:
Code: Select all
sc sdset winmgmt D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;AU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)Security descriptor information can be found out here: Jorge's Quest For Knowledge (Blog)
A brief description of the above security descriptor is simply that "BA", the built-in administrators group, "SY", the local system account, and "AU", the authenticated users group are all assigned permissions on the winmgmt service. For a more complete description the following site proved most useful: MSDN ACE Strings
Once permissions are set correctly you now have access to not only start and stop the winmgmt service but to verify that it's running and even use the windows WMI tools.
2) The WMI Repository
The most simple fix you'll probably find for this is just to use the command "winmgmt /resetrepository" however that hasn't always worked for me. Here's the complete list of commands that I've come across; some of them may not be necessary and some may be redundant but running all of them in the order posted here has always managed to fix the WMI repository for me.
Code: Select all
net stop winmgmt
(it may prompt you to stop the firewall and security center services as well, go ahead and do this as they can be restarted afterwards)
cd /d %windir%\system32\wbem
rmdir /s /q Repository
rmdir /s /q Logs
mkdir Logs
for %i in (*.dll) do RegSvr32 /s %i
for %i in (*.mof, *.mfl) do Mofcomp %i
for %i in (*.exe) do %i /RegServer
net stop winmgmt
winmgmt /resetrepositoryHere is the complete batch file I created:
Code: Select all
@COLOR 02
SC sdset winmgmt D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;AU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
net stop winmgmt /y
@if errorlevel 1 goto error
cd /d %windir%\system32\wbem
rmdir /s /q Repository
rmdir /s /q Logs
mkdir Logs
for %%i in (*.dll) do RegSvr32 /s %%i
for %%i in (*.mof, *.mfl) do Mofcomp %%i
for %%i in (*.exe) do %%i /RegServer
net stop winmgmt
winmgmt /resetrepository
net start sharedaccess
@if errorlevel 1 goto error
net start wscsvc
@if errorlevel 1 goto error
net start winmgmt
@goto end
:error
@echo An error occurred during the processing of one of the services.
@echo Please contact your system administrator with the details of
@echo this message.
@echo.
@pause
@goto end
:end