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
Thanks for letting me know it apparently is not a problem.  Why then was it reported as one?  In looking through the forums in search of some ideas of what to make of this, I discovered that the general impression when the WR repair doesn't repair the reported issue the behavior seems to be shrug and keep moving ahead with no understanding of what just happened.  I happened to come across one such posting where there was a reference to a "silent error", which got me looking at this more closely, and realized I can easily implement the related MkLink operation, feeding it the arguments provided in the (false, apparently) WR error report, and then see the MkLink request get promptly knocked back in no uncertain terms.  Would have thought that falsely reported errors then purportedly corrected (but in fact silently uncorrected) are anathema to a diagnostic and repair function.  Makes you wonder how many more there are, in what areas?

Looking more closely, I see that C:\Users\User\ has both AppData\Roaming and Application Data directories.  The first is a normal-appearing directory structure, and the second advises that I don't have permission to access it (but can override that if desired).

mklink syntax is [options] <Link> <Target>, where target is the real directory, here User\AppData\Roaming, and User\Application Data is the link.

This appears to be set up correctly.  Why is WR reporting a problem to begin with, and what exactly is it?

Thanks again.

Sallying forth with a manual fix per guidance elsewhere in this forum:

mklink /J "C:\Users\User\Application Data" "C:\Users\User\AppData\Roaming"
errs out with "Cannot create a file when that file already exists."

Am imagining that the WR repair process did the same thing and silently encountered the same error.  Is this saying that the only problem is that there is no problem??


Scan Reparse Points

Problem - Missing Default Reparse Point
Repair To Do - Create [same]
Original Path - C:\Users\User\Application Data
Target Path - C:\Users\User\AppData\Roaming

Repair Selected
Process steps are echoed to screen, all completed.

Rerun Scan.  Error persists.  Reboot for grins.  Error persists.

Am presuming that the reported (continuing) error is valid (until I hear otherwise from you) - am going to take a look at how to manually fix this.  In the meantime, this is to make you aware of the occurrence.

WR 4.22. Win 7 32 bit.


Feedback / Various comments
« on: June 27, 2018, 12:50:16 AM »
Hello again!  Am using 4.22 free and am disappointed that you steadfastly refuse to clean up the setup re preserving user-defined installation directories and the tray icon display and configuration logic.  Guess standing pat has now become a matter of pride - in what exactly remains unclear.

Had occasion to reach for WR after buggering up Win 7 Pro 32-bit while trying some things out during a hard-drive migration without being properly prepared.  Blindly shotgunning, elected a number of basic repair options.  Seems to have gotten me moving forward, but was surprised in troubleshooting a resulting new WMI issue that the "repaired" registry ImagePath for service Winmgmt for some reason pointed to netsvcs rather than winmgmt.  Following troubleshooting guidance and trying to start the service resulted in a run-time error 1083:  "The executable program that this service is configured to run in does not implement the service." (in retrospect: d'oh, really?)  Happily, editing the path with the appropriate service name was sufficient to get it working again.  I'd have thought this to be a basic function in a mature product.  I presume this resulted from the WMI repair but did not loop back to test it to confirm where it got broken.

On a cosmetic user-interface level, spent a little time pondering the System Monitor line at the bottom of the repair screen while chunking through them.  Isn't apparently why the gray and blue backgrounds need to jitter around, but it's visual noise (or else I missed the point of it, also a possibility).  The percent value jumps nonstop from whole numbers like 50 to four-place decimals like 3.1354 and everywhere in between, with a blue-gray divide typically on top of that somewhere partially obscuring the number.  A constant numerical presentation format without multiple backgrounds sliding around would be less tiring to accompany and more easily decipherable while admiring progress.  The Monitor subdisplay is a common denominator across the modules.

Thanks for making WR available!


One other thing for awareness - on those occasions when I have (re)installed Windows Repair and not yet deleted the WR tray icon from Task Scheduler where it is inserted by default, when I go to soft-restart the computer while up, the shutdown pauses to warn that (only) the WR Tray program is still running, then after a brief delay clears it and continues to shut down.  Dell laptop Win 7 32-bit.


Right - thanks.

Hello again, Boggin!  Uninstalling WR 4.16/installing WR 4.17 produces the same results as previously reported above on April 2 (other than it's now the WR 4.17 installation screen at step 1.

As a gentle reminder, am bringing forward your closing reply to the predecessor thread to this one based on WR 4.08 at the time:
Global Moderator
Hero Member
Re: Preservation of some installation option elections

Reply #6 on: October 21, 2017, 01:36:03 PM

Your suggestions have been taken on board and added to the queue for updates to the program.


Further to previous exchanges -

1. WR 4.16 installation screen at reinstallation.
2. Prompt overwriting existing user-specified program folder.
3. Prompt overwriting existing user-specified shortcut folder.
4. Run at installation, view of untouched Options:  run tray icon not checked.
5. Task Manager view showing unrequested task:  tray icon run at logon.


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.

Pages: [1] 2