Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - GLykos

Pages: [1]
1
Hello again.  May be operator error on my part, but started a thread on the captioned subject on 10/21, was last replied to by Boggin on same date advising that "Your suggestions have been taken on board and added to the queue for updates to the program."

It's now five months and maybe five program revisions later and the reported issues (to some of us) have not been addressed, it appears that this forum has very little activity, and I'm unable to reply to Boggin - it seems that topic, maybe all in this forum, are locked, hence this new posting to continue the existing thread.

The suggestions previously submitted were, effectively:  1.) when reinstalling Windows Repair, as in during an update, pay attention to where the user chose to install the previous version and associated menu folder and follow suit, and  2.) stop automatically scheduling a task during installation to run the program at computer startup.

Any news?

Thanks,
George

2
Have very much appreciated having Windows Repair available to count on when needed.  Have likewise very much appreciated the author's dedication in continuing to revise and update the program.

A request that stems from needing to continually adjust the installation of updates to my preferences:
1. Please preserve the user's choice of program installation and menu group folders.
2. Please resolve whatever is causing the program to run at startup after installation even though that was specifically not requested during installation.  Settings | Remove from Startup (click with no visual success indication) seems to achieve that after the fact.  Perhaps changing the two buttons (are they in fact independent functions?) under WR Tray Icon to be presented the same as Launch Tray Icon would simplify the UI and make those elections self-documenting at a glance.

These are trivial matters, but would simplify the updating process.  Am seeing this on Win 7, if it matters.

Thanks, and best regards,
George

3
Am on IE 9 due to still on Vista, started encountering crazy Google search webpage behavior some weeks (?) back.  Attempted to run WR IE repair to see if it helped, but a junction problem in my NTFS appears to have prevented it from executing.

While resolving the junction issue is on a back burner, chased after the search page issue (again) and finally discovered a useful discussion about the problem: https://productforums.google.com/forum/#!topic/websearch/S0V3xNkjFEI/discussion.

Turns out that it's not just IE 9 that's affected but most/perhaps all of the IE's.  Google's current webpage has some sort of issue, perhaps in its interaction with Java JRE.  Of the various work-arounds mentioned in the discussion, the one I found to be immediately helpful, integrating seamlessly with normal operation while not involving peripheral software settings, is the one adding google.com to to IE's Compatibility View Settings.  It causes Google to run as an earlier version described as the "black bar" search window (due to one being displayed across the top of the page).

This being the case, assume but can't (yet) verify that WR IE repair won't fix the Google search page issue, seemingly not an IE issue per se.

Regards.

4
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

Pages: [1]
anything