Author Topic: Repair of WMI Issue (SOLVED) (Read 11479 times)

bigaluk · « **on:** October 01, 2016, 04:12:54 pm »

When running the repair of the WMI, the search for things to add falls foul in the following circumstance:

If there are any "alternate paths" to hard drives set up as folders via the Computer Management : Disk Management plugin, then the repair searches those as well! It really needs to leave that stuff alone! I don't know how easy it would be to check such "links" as being volume mount points, but I had a situation where the repair was looking for MOF files on drives it really shouldn't be going to (containing Win10 and WinXP operating systems, as well as one that was the same as the Win7 it was trying to repair!).

In the end, the only way I could get the WMI repair to run without producing reams of error messages (and presumably also making some bad entries into WMI) was to entirely unmount all such folder-based mount points on the OS hard drive and move that folder structure somewhere safe.

bigaluk · « **Reply #1 on:** October 01, 2016, 04:26:31 pm »

After correcting this, a serious problem that was raising a property page error whenever I tried to start the System Protection applet (System Restore) disappeared.

So good news: the repair worked.

Bad news is that I suspect the problem was originally CAUSED by the WMI repair tool CORRUPTING stuff due to the aforementioned issue of folder-based mount points on the OS drive to other drives containing other OS installations.

I really do think the Tweaking.COM repair tool needs this issue addressed at the earliest opportunity.

bigaluk · « **Reply #2 on:** October 01, 2016, 04:35:42 pm »

In addition, a secondary problem whereby running the Credential Manager (inducing the VaultSvc.DLL) would cause LSASS to blue screen was ALSO solved by this same correction.

Basically it appears that the existence of volume mount points in folders on the OS drive causes your WMI repair tool to actually cause damage rather than do a repair!

Once these mount points are removed, the repair succeeds and all is well again.

bigaluk · « **Reply #3 on:** October 01, 2016, 04:43:43 pm »

I could of course find myself being misled by symptoms - as in the existence of these mount points could I suppose have been causing three problems:
1) The failure of your WMI repair tools
2) The property-error when starting the system restore applet
3) The vaultsvc/lsass bluescreen when accessing the credential manger.

However, the contra-indications are:
1) I use similar mount points on another PC that did not exhibit these problems.
2) I never ran the WMI repair tool on that other PC
3) I never had the two fatal issues on that PC
4) Removing the mount points from the problem PC and re-running the WMI repair fixed everything.

So, whilst it is still obviously guess-work here, it does appear that the WMI-repair needs to be a little bit more careful in its searching out of MOF files.

Boggin · « **Reply #4 on:** October 03, 2016, 03:21:34 pm »

Passed onto Shane but he's knee deep in computer repairs from his business, so not sure when there will be a reply.

Shane · « **Reply #5 on:** October 03, 2016, 04:57:21 pm »

The repairs are ran in bat files. I only have so much control over the commands I am able to run. So in the bat file the cmd to search the drive for the mof files is ran, not a lot of options with it.

Perhaps I need to see about changing the repair to where the program itself first goes and searches for the files, that way I can have it skip symbolic links and then some. Then it can output the files to be add back the wmi in the bat file and not have the bat file do the file search.

One way I could tell that this works is if any of the file scanners in the program itself dont have any problem with searching the drives (They are set to skip junctions and symbolic links) the unhide hidden files repairs is one, the check rephrase points is another.

Shane

bigaluk · « **Reply #6 on:** October 04, 2016, 03:35:28 am »

Thanks for looking into this.

I agree with the direction of your solution: it needs something to limit the MOF search, then all will be ok and no damage will be caused. It might even be worth putting up a warning to users in the pre-test checks you provide that such mount points are potentially hazardous to tools that use "indiscriminate" searching to do automated repair work

. Your tool won't be the only one in the world to fall foul of this. Indeed if the mount point is recursive (one of mine was at one point: the mount point was to the drive on which the mount point resided) then a tool may never even complete - until it eventually crashes due to ridiculously long recursive path names.

You can test the problem scenario by using C:\Windows\System32\diskmgmt.msc to set up NTFS Path mount points to drives such that these paths are then folders on the C: drive. I actually have to do this on my system because I sometimes have too many drives (many of them are USB) to provide drive letters for, and this is sometimes the only way I can mount such drives consistently to fixed locations.

Since encountering this problem I have decided that 'C' is perhaps not the best drive to use for such mount-point folders.

Indeed, doing so is probably asking for trouble. Hence my suggestion that detection and warning users in your "Pre-Scan" checking suite might be a useful addition to the tool: Perhaps with a suggestion that the user only ever uses a non-OS drive for such folder-based mount points.

Shane · « **Reply #7 on:** October 04, 2016, 02:00:27 pm »

I put it at the top of my to do list, not sure when I will have it done as I will have to build a new tool for it, but I have it at the top of the list

Most users dont ever set mount points, it is the power users like yourself that do and who need more control over the automation of the repair. I will come up with some ideas when I make the new repair for it. I just dont have a time frame yet.

My computer repair business has been insanely busy and I am struggling to get caught up on all the programming

Shane