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.

Messages - GLykos

Pages: [1] 2
Installing Windows Repair causes its tray icon to be task-scheduled for Windows startup - there is no choice at installation nor is that default behavior mentioned anywhere.  Once running, the program Settings - WR Tray Icon - Start and Remove buttons then immediately create/delete that task - but there is no indication in that box as to what is currently selected.  I don't follow what is so "nifty" about all this.

"Start [Tray Icon] With Windows" (and strictly speaking, the utilized task option is at logon) alone, checked/unchecked (unchecked as default) in lieu of two buttons would be self-documenting and unambiguous.  Having said that, what's the difference between "**launching** the tray icon at program startup" and "**starting** it with Windows"?  If you start the Tray Icon with Windows, does it persist when the program runs even if the Launch Tray Icon With Program is unchecked?  C'mon, guys.

Separately, suggesting that program reinstallation maintain previously user-specified program and shortcut folder names is a universal standard convention.


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?


The installation closes with an option to run (or not) the just-installed program upon completion.  Not selected, the program still loads.  If you then restart the computer, the program (or at least its icon) loads again (even though not requested by the user to do so)  This is illogical, as you would say...

The program checks self-integrity every time it starts (and makes a show of it, all of which is fine), and if a related issue is detected and reported, the user can take appropriate action (if the program hasn't already done so).

Beyond that, your several replies are incomplete with respect to the two items originally enumerated for consideration.  I follow that you may not see a problem by the way that you do like to do things - thanks for sharing.

That said, please pass along the original request - thanks!

Sequence of operations here was different.  The updated program was downloaded and then installed on top of the previously-installed version, which was not running.  During that manual (re?)installation, these gaps come to light - lost previous user customized data and an indeterminate startup state.  Try it.

In my experience, preserving such configurable data across reinstallations (manual or automatic) is a de-facto standard convention of contemporary programs.  You'd expect that if you didn't elect to run the program at the conclusion of reinstallation, all would be ready for next time.  As it stands, manual intervention (read:  typing previously-entered data in again) is needed here during installation, and then a cleanup pass running the program is needed to synch the boot startup behavior.

As mentioned, this is a trivial matter, but an on-going nuisance, and seems inconsistent with the high standards that the author maintains (and whose dedication is clearly recognized and valued by the user community).  If you always use automatic program updating, I guess you wouldn't know - now you do.

Thanks for team's consideration.

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,

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.

Yes, if you're not using the Google search page, you won't see the problem.  I use Google as my IE search engine and my start-up screen.  Seems a lot of people do use the Google search page.  There are numerous postings with threads elsewhere from people experiencing the same problem but this was the first useful discussion I found.

The problem manifests itself as allowing initial user input into a data entry port on the page, then refusing to accept any more;  scroll down on the search page, click a selection, and the page jumps back to the top.

The problem appears to be with the current Google search page, or in its interaction with Java, as accessed via IE and has existed for some months at this point.  For me, while I could awkwardly (for me) go to another browser to avoid the problem, having a work-around that allows using Google search in IE is very much appreciated.  The article includes a link to go directly from a browser to the previous black-bar Google search page to see what this is about.

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:!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 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.


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 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.


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:

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.

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...

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.

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,

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.

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.

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,

Pages: [1] 2