Author Topic: Windows Repair task 04 (Register System Files) clobbering Vista VSS?? (Read 20270 times)

GLykos · « **on:** January 15, 2016, 08:43:56 pm »

Ran the first four tasks in the repairs library (WR 3.8.0). Believe as a result of that the Vista backup and restore function is broken.

Attempting to create backup in System Properties, System Protection says "The restore point could not be created for the following reason: Catastrophic failure (0x8000FFFF) Please try again."

App Event Log shows "Volume Shadow Copy Service error: The VSS event class is not registered. This will prevent any VSS writers from receiving events. This may be caused due to a setup failure or as a result of an application's installer or uninstaller."

Searching for fix to register the VSS event class, find "Beginning with Windows Vista and Windows Server 2008, Windows component installation is manifest-based, and most of the registry is locked down even to Administrator. ***However, the VSS binaries in Windows Vista and Windows Server 2008 still contain the code to perform self-registration. The code is removed in Windows 7 and 2008 R2.*** It is not recommended to re-register VSS binaries in Windows Vista and Windows Server 2008 or later operating systems."

Continuing, "Starting with Windows Vista and with Windows Server 2008, Windows component installation is manifest-based. Trying to manually register specific components, as described in the following steps, can have unexpected results that may require Windows be reinstalled to resolve."

That said - does task 04 re-register the Vista DLL's associated with the VSS event class, or does it exclude them from processing?

As a side note - now what??

Thanks,
George

P.S. Realized that the same problem was posted on 1/9. The additional information above may help to figure out what's going on.

In response to a query in a reply to that post -

vssadmin list writers returns: vassadmin 1.1 - VSCS administration cmd-line tool and copyright notice. No values

vssadmin list providers returns: Name: 'MS Sfwr Shadow Copy provider 1.0' Provider type: System. Provider Id: <b5946137-7b9f-4925-af80-51abd60b20d5>. Version: 1.0.0.7

Boggin · « **Reply #1 on:** January 17, 2016, 05:04:41 am »

I've contacted Shane for him to investigate this error for you.

Shane · « **Reply #2 on:** January 17, 2016, 08:51:34 pm »

So i looked up this error and checked on my vista system in vmware and was getting the same error.

Also when I ran vssadmin list writers in a cmd.exe window it came back blank.

So I opened my windows repair, unselected all the repairs and told it to only repair the volume shadow copy service. After that it started working just fine. Which is odd, as I dont know why it wasnt working in the first place. This is with Windows repair v3.8.0

So I have it running all the repairs and will see if the error comes back or not.

So try that as well, run the repairs but only run the 1 repair, repair volume shadow copy and let me know if that fixes it. So i know the repair fixes it I need to see if there is something else in a different repair that might be breaking it.

Shane

Shane · « **Reply #3 on:** January 17, 2016, 09:16:51 pm »

Ok so ran all repairs reboot and vss is working fine.

So now I am just running repair 4, the register system files, and after a reboot vssadmin list writers comes back blank.

So I am looking to why that is happening. Whats odd is why it is only happening on vista. I will see what i can find and get a fix out for it in the next update

Shane

Shane · « **Reply #4 on:** January 17, 2016, 09:57:07 pm »

Well that was the strangest bug I have seen lately lol

Ok I found the fix and will put out version 3.8.1 tomorrow.

So in the register system files is the same files as the vss repair, yet the vss repair would fix what the other repair broke. So i compared them and I noticed one small thing and decided to try something.

As an example, in the register system files.txt file I had these commands

eventcls.dll /i /s
eventcls.dll /s

The /s is for silent when registering a file and the /i is the DLLinstall command.

So you will see it does the /i first and then calls again to do a normal register.

So in the vss repair I noticed I had the /i 2nd instead.

So as a test I switched every file in the register system files that had a /i command to be 2nd instead (They where all first) I then ran that repair and guess what, VSS starting working properly again. I was a little shocked.

So for some reason calling a normal regsvr32 after doing the /i seems to break something in vista. I dont have this problem in 7 8 and 10.

But at least I found the fix for it, so I will have the update out tomorrow

Shane

GLykos · « **Reply #5 on:** January 21, 2016, 03:11:55 am »

Thanks for having exercised this. The problem continues at my end.

- Updated to WR 3.8.1.
- Ran task 19 (repair VSC service) only, rebooted - initiating create restore point ends in same "catastrophic failure".
- Ran tasks 1-4, 19 for grins, rebooted - initiating create restore point ends in same "catastrophic failure".

vssadmin list writers still returns blank.

This is a docked Dell laptop E6400 running Vista Business with all updates.

Would be happy to assist with further information and/or actions if/as helpful.

Note that I received forum e-mail notification of Boggin's acknowledgement of my original post but none since - happened to revisit the thread and discovered the ensuing exchange.

Thanks all, and regards,
George

Willy2 · « **Reply #6 on:** January 21, 2016, 12:46:54 pm »

- Did you try "Beta System Restore" ? there's a button in the bottom right hand corner that opens "BETA Repairs" and leads you to the "BETA System Restore Repair". Try it (with the usual precautions (backup etc.)) and perhaps it could help.
- It seems you didn't run all repairs. Try running all repairs. All repairs would include "Repair WMI" and WMI is used to pull up A LOT OF info from your system.

GLykos · « **Reply #7 on:** January 21, 2016, 05:22:10 pm »

Correct - I first tried the fix approach described above and reported as successful, which was just the VSC Service repair. I then looped around and tried the fuller sequence, i.e. (re?)break it by (re)registering all services and then fixing it. Neither worked for me.

Thanks for your several suggestions re what to try next. Will exercise this over the next several days and report back.

Shane · « **Reply #8 on:** January 22, 2016, 01:16:54 pm »

Interesting. For me, in vista in my vmware I was able to replicate the problem every time I registered the system files and was able to fix it every time I ran the vss repair.

Then when i made the changes to the order of the dlls in the register system files i was no longer able to replicate the problem.

Of course one thing I didnt do, since my vista is bare bones with no 3rd party programs I ran the repairs in normal mode and not safe mode. Not sure if that would have anything to do with it.

Shane

GLykos · « **Reply #9 on:** January 24, 2016, 08:11:54 pm »

Well, have worked on this a bit - have more questions than answers, both in relation to the status of affairs on my computer and what WR is doing or not doing.

As approximately suggested above, tried a relatively full repair set: tasks 1,2,3,4,5,7,19. Watching the CMD window, see a lot of errors go flashing by during the WMI repair. The associated log file shows repeated occurrences of some same nature of error - don't know what's to be done with it. Most of the log files, attached, show almost nothing and little detail (because "output suppressed to speed up execution" when in fact numerous errors were reported during execution of various repairs. Interrupting the WMI execution, can't get Snipping Tool to save a capture so manually transcribe one line to a text file, attached. System32\config\systemprofile\AppData\Local\Application Data\Application Data\Application Data ad nauseum is hosed (I presume) - directory capture attached. So in the case of WMI, two different sets of errors that don't intersect - in the case of IE repair, "batch file not found" - which batch files?. The VSC service repair log says the service is not started. Check the Services viewer, see it's in manual - after running the repair?

Try running the same repair set one more time, this time adding task 26 wondering how this interacts with VSC service repair leaving it in manual and stopped. Then checked again, is still in manual and stopped - the normal state?

So long story short, issues have cropped up in my system, from appearances over iterations with time. WR isn't feeding through the run-time errors it encounters (may be operator error), system issues continue to exist and indications are discarded when abnormal things occur during repair. Not sure how to best approach this, but sure wish I could get a report of all encountered repair run-time issues to at least get a feeling for scope of corruption. Would appreciate any other thoughts on how to best proceed.

Thanks, and regards,
George

P.S. Remembering the suggestion to try Beta Repair, looped back, read about it, ran it. No change in system behavior re create restore point catastrophic failure.

P.P.S. In looking through backups to see what was in Application Data previously, realize that AppData/Roaming and Application Data are tied together as/in (?) a junction, related to a reparse point (in my limited understanding). I do recall on one or more earlier WR repairs having stepped through Option 2 Pre-Scan, and it once having mentioned something related to reparse point corrective actions. Don't know if related to the oddball recursing hierarchy down to the System32 config etc. IE Restore folder.

P.P.P.S Updated attachment to include omitted directory pic as intended.

GLykos · « **Reply #10 on:** January 25, 2016, 01:20:12 pm »

Took another look at the WMI task reported path error to IE Recovery. Determined that the proper directory structure appears intact and operational, judging from time-stamps - screen capture attached. That said, don't know what was going on with the reported path-too-long error mentioned above - would seem either the reparse point junction ('AppData\Local' and 'Application Data') is messed up or else WMI repair took a wrong turn - just my uneducated guess but sharing if/as helpful.

P.S. Reflecting a little more on this, then comparing with another Vista PC - appears 'Application Data' shouldn't even be appearing in Windows Explorer.

Willy2 · « **Reply #11 on:** January 25, 2016, 03:20:08 pm »

- A LOT OF errors generated by "Repair WMI" and other repairs can be ignored.
- Just run "Repair WMI" and perhaps a number of other repairs.
- After this I am out of suggestions on how to fix this. Perhaps others have more suggestions ?

GLykos · « **Reply #12 on:** January 26, 2016, 01:20:22 am »

Thanks for your reply.

Discovered NTFSLinksView, looked around a bit, don't see anything obviously untoward with the junctions.

Don't mind (with some level of confidence) throwing stuff against the wall to see what sticks, but would sure like to be able to capture the run-time errors encountered by a diagnostic routine, at least on request. The errors may not be germane to the specific issue of interest, but can absolutely be of interest in detecting and perhaps later addressing other anomalies that happen to surface during the process.

Lessee, how does it go: Why break it if it works? To make it work better, right?

Just one person's viewpoint...

GLykos · « **Reply #13 on:** January 26, 2016, 05:40:39 pm »

In search of my unrecorded WMI repair run-time errors, turns out the DIR command (among others?) sends normal output to STDOUT and error output to STDERR. The WMI repair command window errors that flashed by but didn't get logged appear to have resulted from a DIR (or DIR-like) command. Running DIR from root-dir down, the errors are captured by doing an output redirect to 2> (rather than >, alternatively 1>). Here's a brief related MS article: https://support.microsoft.com/en-us/kb/110930#/en-us/kb/110930.

Next step is to try to understand current situation and contemplate corrective action(s) while wondering how I got here in the first place. The error output is attached for reference, if curious.

FYI, and regards.

GLykos · « **Reply #14 on:** January 26, 2016, 10:12:23 pm »

Re-examination suggests a corrupted junction point. NTFS Links View (attached) suggests bad first junction, creating recursive situation that is consistent with DIR errors and Win Explorer directory structure display.

Simple dump of system-drive junctions via DIR, with erred paths following (attached) provided for context. Those junctions created 7/2015 likely resulted from running then-current WR pre-scan.

Located a sample script file http://pcloadletter.co.uk/2012/03/20/corrupt-windows-7-junction-points/ which appears suitable to manually fix the junction error(s).

Will reflect on this, poke around a bit more, then make NTFS adjustments.

Don't know that this has anything to do with the originally reported (and still existing) system save/restore checkpoint function getting broken, but am going to push ahead, attempting to fix and clean up as I go, see what happens.

Regards.

Shane · « **Reply #15 on:** January 31, 2016, 09:26:46 pm »

Sorry for taking so long to reply. Every time I think I am caught up, 9 more things will hit me.

As you fine more info on this it might be a good idea to email me directly, I try to answer emails every day during the week if I am not out on jobs fixing computers. So I reply to email faster than I do forum posts

Shane

GLykos · « **Reply #16 on:** January 31, 2016, 10:33:06 pm »

Thanks very much to you and your team for your interest and support!

Will mention to close off my earlier comment in this thread about hoping to view (and log) all WR run-time errors - happened to discover while poking around in WR that CMD-window supressed output is a default WR state, and an option is available and readily accessible on the Settings tab under CMD.exe Options to see the "whole story" if desired. Have not gone back yet to see if it captures both the STDOUT and STDERR streams, hopefully chronologically merged.