Tweaking.com Forums

Main Forum => Program & Site Requests => Topic started by: Willy2 on November 27, 2012, 09:45:19 AM

Title: Window Repair 1.9.2
Post by: Willy2 on November 27, 2012, 09:45:19 AM
WR v1.92 has a counting error/problem. When I tick a number of "File Associations" (let's assume 6) and hit "Start" then WR fails to count the proper amount of repair jobs. The counter will say that there're (6 plus 1=) 7 jobs to be performed. And then the counter will stop at "6/7".

I know why this happens. As soon as the user has ticked - at least - one of the "file associations" boxes then the box "Repair File associations" will be ticked as well. And that will be counted as an extra repair job. Hence the mismatch between the counter and the total amount of ticked boxes.
Title: Re: Window Repair 1.92
Post by: Shane on November 27, 2012, 02:43:57 PM
Bah! I thought I covered everything lol.

Thankfully I have you to find the things I miss :-)

I will get it fixed :wink:

Shane
Title: Re: Window Repair 1.92
Post by: Shane on November 27, 2012, 02:48:42 PM
OK easy fix. Instead of doing v1.9.3 I will just update the setup of 1.9.2 so you will need to redownload it to get the new exe. Give it a bit before you do as it takes time for the mirrors to update.

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on December 15, 2012, 02:28:48 PM
Here're more suggestions for WR v1.9.2:
1. Move "Reset Window Services to default" to the end of the list of repair jobs. Perhaps other repair jobs could have switched off one or more services and not switch those services back on. That's why moving that repair job to the end of the list could be a good thing. (at least, when the user wants those services to be set to their default.)

If I had the program code for the repair jobs then I could check which services are switched on again or not. I know that a number of services are dependent on other services and these services are therefore switched off as well. But are those dependent services switched on again ?

2. Perhaps you need to update/increase the amount of services that are set to their default value now Windows 8 has been introduced ? Does Black Viper (www.blackviper.com) have those (new) Win 8 services available ?

3. Question: Do you know which repair job in WR has an impact on the Win 7 wallpaper changer ? I ran WR (with a lot of boxes ticked) and suddenly the Win 7 wallpaper changer started working again (for a while at least). At least, I hope WR, at this particular issue, can make a difference.

4. Perhaps you need to block/grey out the button "Stop" as well as soon as the user has hit that button and WR is in the process of finishing the current active repair job ? After all, WR does display the message "Waiting for current repair to finish...".
Title: Re: Window Repair 1.9.2
Post by: Willy2 on December 15, 2012, 02:51:25 PM
I came across this program that supposedly fixes a number of errors in the windows task scheduler. Perhaps your able/willing to integrate it in WR ? Perhaps the author will allow you to integrate it into WR ? I ran the program because I have a number of small Task Scheduler issues (not anything fatal but merely annoying) and it said it had fixed 7 errors.

http://www.softpedia.com/get/System/System-Miscellaneous/Fix-My-Task-Scheduler.shtml

According to one source a file called "schedsvc.dll" is involved in the functioning of Task Scheduler. Perhaps registering that file (again) could solve a number of Task Scheduler issues ? Does WR register this file ?

http://www.win7dll.info/schedsvc_dll.html
http://www.win7dll.info/

But I didn't find that file (schedsvc.dll) in any of the system file directories. I found it in "c:\windows\winsxs\" subfolders four times. Weird !
Title: Re: Window Repair 1.9.2
Post by: Shane on December 26, 2012, 03:08:56 PM
"schedsvc.dll" is in the system32 dir and I checked and it doesnt have any reg info so regerstering it doesnt work. As for the program I looked at it but it doesnt say what it is doing.

Quote
3. Question: Do you know which repair job in WR has an impact on the Win 7 wallpaper changer ? I ran WR (with a lot of boxes ticked) and suddenly the Win 7 wallpaper changer started working again (for a while at least). At least, I hope WR, at this particular issue, can make a difference.

Hard to tell. Could have been the permissions and the reg system files might have done it :wink:

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on December 29, 2012, 02:53:02 PM
I can't find "Schedsvc.dll" in the "system32" folder. I have made a shortcut to Task Scheduler and it opens a file called "Taskschd.msc". Weird.
Title: Re: Window Repair 1.9.2
Post by: Willy2 on December 30, 2012, 06:39:23 AM
See also:

http://technet.microsoft.com/en-us/library/cc721931.aspx
Title: Re: Window Repair v1.9.2
Post by: Willy2 on January 04, 2013, 12:40:40 AM
 I know I have send you an email with the info below but in order to make sure you've got the right info, I post the info once more. I think I made a small error in the email.

Replace this code from "Register System files":

regsvr32.exe /s "C:\Windows\System32\Flash10t.ocx" 2>> C:\Tweaking.com_Windows_Repair_Logs\_Windows_Repair_Log.txt
regsvr32.exe /s "C:\Windows\SysWOW64\Flash10t.ocx" 2>> C:\Tweaking.com_Windows_Repair_Logs\_Windows_Repair_Log.txt


with:

for %%i in (%windir%\system32\Macromed\Flash\*.*) do regsvr32 /s %%i
for %%i in (%windir%\sysWOW64\Macromed\Flash\*.*) do regsvr32 /s %%i


Is it possible to add that command/switch that pushes the response of MSDOS to the WR log file ?
Note that there's only one switch ("/s"). The (missing) switch "/u" is meant to unregister a file ?
I use the "for ........... do .......... " command because the filename(s) change with every new version of Flash. Some files don't need registration and won't be registered. But MSDOS doesn't bother and simply moves on.
Perhaps the other files (e.g. *.cpl files) in the sysWOW64 folder need registration as well ?

When I installed the lastest version of Flash the following info showed up in the install log file.

=O====== M/11.5.502.135 2013-01-03+15-58-25.760 ========
0000 00000010 C:\Users\BRSLIM~1\AppData\Local\Temp\FlashPlayerUpdate.exe
0001 00000020 C:\Windows\SysWOW64\FlashPlayerCPLApp.cpl
0002 00000011 1
0003 00000013 C:\Windows\SysWOW6\Macromed\Flash\Flash32_11_5_502_135.ocx
0004 00000015 C:\Windows\SysWOW64Macromed\Flash\FlashUtil32_11_5_502_135_ActiveX.exe
0005 00000016 C:\Windows\SysWOW64Macromed\Flash\FlashUtil32_11_5_502_135_ActiveX.dll
0006 00000023 C:\Windows\SysWOW64\Macromed\Flash\activex.vch
0007 00000019 C:\Windows\SysWOW64\FlashPlayerCPLApp.cpl
0008 [W] 00001024 C:\Windows\SysWOW64\FlashPlayerCPLApp.cpl 183
0009 [W] 00001024 C:\Windows\SysWOW64\FlashPlayerApp.exe 183
0010 00000021 C:\Windows\SysWOW64Macromed\Flash\FlashPlayerUpdateService.exe
0011 [W] 00001024 C:\Windows\SysWOW64Macromed\Flash\FlashPlayerUpdateService.exe 183
0012 00000012
=X====== M/11.5.502.135 2013-01-03+15-59-13.706 ========
Title: Re: Window Repair 1.9.2
Post by: Shane on January 04, 2013, 02:50:00 PM
I have it in my notes :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 12, 2013, 06:54:37 AM
Perhaps "Register System Files" needs to include, besides the Flash files mentioned in an earlier post in this thread, a number of other Adobe files as well ? Keywords "Adobe Shockwave player". The pictures in the attachment give a good indication where those files are "hiding". The Shockwave folders have a number of subfolders as well and contain some 20 files (e.g. *.x32 and *.dll)
Title: Re: Window Repair 1.9.2
Post by: Shane on January 12, 2013, 12:59:01 PM
The repair is for Windows system files. DO you think adobe should be in it as well? Or instead have a new repair added just for adobe flash and shockwave?

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 12, 2013, 02:16:14 PM
Excellent question !!! And I fail to come up with a good answer. So, I posted questions out on the Piriform forum.

http://forum.piriform.com/index.php?showtopic=34060&#entry228296
http://forum.piriform.com/index.php?showtopic=28752&st=40#entry228281
http://forum.piriform.com/index.php?showtopic=28752

I also send "pwillener" a personal message. He's a volunteer for the "Adobe Help" forum. (Send him  an email ???)
http://forum.piriform.com/index.php?showuser=698

Just see what the responses are. How often do YOU come across problems with Flash & Shockwave ?

This is my personal opinion at this moment:
If Shockwave isn't used that often then you simply could add Adobe's Flash to "Register System Files". Otherwise it makes sense to add an extra "Adobe only" (shockwave + Flash) repair job.
Title: Re: Window Repair 1.9.2
Post by: Shane on January 12, 2013, 02:30:58 PM
I rarely run into flash problems.

Lets see what others say :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 14, 2013, 04:11:35 AM
There were three replies to the "Adobe & Shockwave" issue on the Piriform forum. See the links above. Just register the Adobe Flash files only in the "Register system files" and forget about (re-)registering Shockwave.
Title: Re: Window Repair 1.9.2
Post by: Shane on January 14, 2013, 12:21:35 PM
From reading some of those and from my own experience I dont think registering the files will do any good. The very old versions of flash use to be fixable by doing that. But Adobe has changed a LOT since then and havent ever needed that fix since.

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 25, 2013, 05:46:50 PM
Discovered another irregular behaviour. This is something some other members also have reported. Since I wasn't able to put my finger on why or when it occurred, I kept silent about it. But now I can show you a procedure how and when this irregular behaviour pops up.

Do this:
1). Start WR (v1.96) and go to the main repair screen.
2). Click on the name of a repair job and in the "Repair Info" pane a description of the job shows up.
3). tick the box "Set Services Back to Default" and hit "Start".
4). you'll notice that WR opens a CMD.exe window in order to execute a number of MSDOS commands. After it has closed this CMD.exe window, WR opens a CMD.exe windows for a second time and executes the same commands again.
5). Then the program says that the user must restart Windows. (Don't do this).

6). click on "Back" and then on "Start" again (with the same boxes ticked as under 3) ) and the behaviour of WR changes.

- You'll notice that repeating step 2) won't let the repair info show up.
- Repeat step 4) and you'll see that two CMD.exe windows are opened (almost) simultaneously.
- Step 5) occurs when the two CMD.exe windows are still busy executing commands.

The fact that the repair info is stored in separate files in a special folder gives me a clue where WR goes "off the rails". My best guess is that when the program has finished the last repair job or when the user clicks on "Back", or at some other crucial point, an internal "Path=....." gets corrupted/changed/reset. Then after that WR won't find the proper folder where the repair info is stored. Then WR also won't find e.g. "psexec.exe", "subinacl.exe", "Regini.exe" and "SetACL.exe". That would explain why the two CMD windows open (almost) simultaneously.

This corrupted/changed (internal) "Path=....." could also be the reason why WR needs to run the *.bat files/execute the MSDOS commands twice in order for these commands (e.g. registering files) to be effective.

A solution for this could be that WR executes this (internal) "Set Path=...." command again (!!!) after the user has clicked on "Start" (in "Start Repairs") and before the user enters the main repair screen, instead of directly at the very start of WR only. Perhaps this "Set Path=...." command needs to be executed at other spots in the program, as well ?
Title: Re: Window Repair 1.9.2
Post by: Shane on January 25, 2013, 07:27:31 PM
I will take a look at that, I put it in my notes.

Also read the changelog, some of the repairs do run twice on purpose :wink:

Once under the current user account and then again under the system account. It is in the changelog of why I did this.

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 26, 2013, 09:15:48 AM
Yes, I know why WR runs those batch files twice. And that's precisely the reason why - IMO - the program code must be improved. See below.

- Small typo: I see two ampersands (&) in "Repair Winsock ......".
- I know where WR goes "off the deep end". The program code that's executed when the user hits "Back" in the main repair window, seems to contain a command that changes the path and then WR can't find e.g. the "Repair info" files any more. Does WR need that "Set Path=...." command to execute e.g. "psexec.exe", "subinacl.exe",  ............... ? And does WR need that path to be able to repair/patch up the registry ?

Only when I (re-)start WR then the value of "Path=...." is set to its proper value. Does WR need that particular path value for "Step 1" through "Step 4" as well ?

- When two or more CMD.exe windows are running simultaneously then in - at least - one window (it doesn't happen in the CMD window that's opened first) error messages show up, e.g. "The process can't access the file because it's used by another process". No wonder, because the first CMD.exe is accessing one particular file, as well.
- There's another problem. Take e.g. "Repair WMI". I know WR executes three batch files for this repair job. Let's call them A, B and C. Currently the sequence of those batchfiles, as run by WR, is A,A,B,B,C,C. Don't you think that the sequence should be A,B,C (current user account) and then A,B,C again (system account) ?
I know that these batchfiles contain the commands "net stop ......." (in A) and "net start ....." (in C). Currently WR executes the following sequence:

(batch file C, first run)
1) ...............
2) ...............
net start ..........
3) ............................
(end batch file C)

(batch file C, second run)
1) .....................
2) .....................
net start ..........
3) .................
(end batch file C)

Commands 1) & 2) should be run with one (or more) service(s) stopped. But the consequence of the current sequence is that in the second run of batch file C command 1) & 2) are executed with this service running.

Are there more repair jobs that execute - at least - two batch files ? e.g. "Repair Firewall" ?
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 26, 2013, 04:29:11 PM
More things that - IMO - need to be adressed:
- When I leave the main "repair jobs" windows by clicking on "close window" (the "X" in the top right hand corner of the window) then WR seems to execute the same program code as when the user would hit the button "Back". And then the behaviour of WR changes for the worst as well.
- I would like to see the buttons "Back" & "Next" in the "Create Restore Point & Back up Registry" screen, blocked/greyed out, as long as WR is busy in this screen. Perhaps it's possible to block the other tabs as well ?
- block the button "Beta repairs" as long as WR is busy repairing.
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 27, 2013, 01:25:03 AM
Did you change the program code under "Unhide Non system file" in the last 1, 2 or 3 new WR versions ? Because in the past when I ran that repair job (almost) no files showed up. Currently a very significant amount of file names show up under the "Log info/Repair info" pane when this job runs. Does this mean that ALL these files were marked "hidden" ? But then it seems that WR does a lousy job because these file names show up the next time I run WR, again ! Weird !

Is this a "Set Path=....." issue as well ??

Perhaps you could register the file names that have been "unhidden" in the log file ?
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 27, 2013, 04:12:15 AM
And my brains keep churning out suggestions:

Under "Unhide Non System files":
- push the info generated (i.e. file names) to the log file.
- and instead of displaying the name(s) of the "repaired" file(s), just count the number of files that have been made "unhidden". Then you could add info to the log pane. E.g. "20 files made unhidden. Look for more info in the log file" or something along those lines.
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 27, 2013, 02:33:35 PM
Perhaps that (internal) "Set Path=......." problem (as described above) could be the reason you thought WR needed to run a number of batchfiles twice. Because in previous versions (before v1.9.4) that same "path" problem/bug was present as well. This "path" problem could be the reason why a number of repair jobs fail.

The result of that "path" bug is that WR opens/can open a number of CMD.exe windows simultaneously. And then one command in one batch file blocks/could block the access to a file, by another command in a second, third or more batch files that run simultaneously.

Perhaps even executing one command in the first batch file prevents a second batch file from using that same command (e.g. "regsvr32 /s .......") at the same time.

Remember the behaviour of a command in MSDOS/CMD.exe: if it can find a file or execute a command, it simply moves on to the next command in the batch file. The batch file doesn't stop/break down. And that could mean that when the batchfile uses e.g. the "regsvr32 /s ......." command, one or more files simply won't get registered.

In previous versions (before WR v1.9.4), as a result of that "path" bug", two or more batch files could run simultaneously, as well. Batch files for e.g. "Repair WMI", "Repair Firewall" and "Repair Internet Explorer". And then as a result of that running simultaneously one or more files won't get registered. And then the repair job(s) will fail to do what it's supposed to do.

So, therefore it's EXTREMELY important that you solve that "Path" bug/problem FIRST. That WILL prevent batch files from running simultaneously and that WILL - IMO - solve A LOT OF (among others) registration ("regsvr32 ......") problems. Then you should test whether now all files get properly registered. And then perhaps you could get rid of running a number of batch files twice. Speeds up the repair process, right ?
Title: Re: Window Repair 1.9.2
Post by: Shane on January 27, 2013, 05:05:30 PM
Quote
Did you change the program code under "Unhide Non system file" in the last 1, 2 or 3 new WR versions ? Because in the past when I ran that repair job (almost) no files showed up. Currently a very significant amount of file names show up under the "Log info/Repair info" pane when this job runs. Does this mean that ALL these files were marked "hidden" ? But then it seems that WR does a lousy job because these file names show up the next time I run WR, again ! Weird !

I just changed it to show the current file it is looking at :-)

I have this thread added to my list. I just did a new program and another program update. Sometime this week I will be hitting the other updates and programs. With so many programs, 2 forums and a computer repair business I try my best to work on this as soon as I can. So far I think I do ok. But thank god for my cigars lol :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 27, 2013, 10:48:40 PM
No problem. It's good to know this problem has your attention.
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 28, 2013, 04:35:35 AM
It's good that you don't update WR (v1.9.6) right away because it gives me more time to find more bugs. And I did find another bug today. When the user has run "Beta Repairs" (Repair System Restore) and the user closes that window then this ugly "path" problem pops up again. And then WR  shows that same changed, unwanted behaviour (as described above) again. This "path" problem actually occurs when the user closes a window.

(No need to reply).
And please, don't close this thread (yet).
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 28, 2013, 11:35:06 PM
The "path" bug also affects the WR log file. When I run WR with all boxes ticked then a number of repair jobs simply don't get registered in the log file. E.g. "Repair WMI", "Repair Internet Explorer".

However, according to the info in the "Repair log" pane "Repair WMI" and "Repair Internet Explorer" were executed. But according to the log pane, it took WR only 3 seconds to perform the WMI job. Without this "Path" bug, in normal circumstances, it takes the "Repair WMI" job much more time (2 to 2.5 minutes) to be completed.

In the attachment you'll find both the info from the log file and the log pane. Note that all jobs take remarkably/very little time to complete. A sign WR fails to do its job as it should.

More suggestions/thoughts:
- Get rid of the job counter. WR highlights the job that's being performed and that - IMO - suffices.
- Is it possible to put all WMI repair commands in one batch file ?
- Under "Unhide non system files":
   -- Display under the log pane the name of the last unhidden file until WR finds a new file that was "unhidden".
   -- register the names of the unhidden files in the log file as well.
   -- Like under "Reset File permissions", display the names of the main directories in the log pane.
   -- Does this job also "unhide" folders ?

(No need to reply now)
Title: Re: Window Repair 1.9.2
Post by: Shane on January 29, 2013, 12:16:55 PM
Ah found it. Wasn't a path bug. Was something else.

In the form unload event I have this

bExit = True
bStopWork = True

When those are true all jobs are skipped as the program thinks it is going to shutdown. So when you closed a window and went back in it thought it was finished and needed to close.

Easy fix is to put
bExit = false
bStopWork = false

In the form startup :-)

I will also be going through your notes on here before I do an update. :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 29, 2013, 01:28:21 PM
The reason the job counter can be omitted is that the user can tick additional boxes as long as WR runs. Then the job counter is "out of sync" with the amount of boxes ticked.
In a previous version WR blocked all unticked boxes and then the job counter remained in sync with the amount of boxes.
Title: Re: Window Repair 1.9.2
Post by: Shane on January 29, 2013, 01:32:09 PM
I am keeping the counter but changed it to update it when it is unchecked. Working on a bunch of changes now and will give you the new exe to test before release :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Shane on January 29, 2013, 01:33:10 PM
Oh and I wont have it log every file it unhides. If a person had the whole drive hidden from a virus the log file would be huge!!

But I am adding count of how many it unhides :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 29, 2013, 03:13:05 PM
Cool !!!!!!
Title: Re: Window Repair 1.9.2
Post by: Shane on January 29, 2013, 04:58:10 PM
OK here is v1.9.7

I did some testing and it worked but couldn't do thoroughly yet as I have to head to the in laws for dinner. So tear into it :-)

Big changes in this one :-)

Change log:

v1.9.7
Fixed bug where if you opened the repair window, then closed it and then went back to it the repairs wouldn't work. This is because the program though it was in close down mode from closing the repair window. This has now been fixed.

Program now shows how many repairs are selected above the repair list. Example: "Repair Options (Selected: 10 of 35)"

The repair wmi was done in 3 steps to simply give a progress of what it is doing. Instead I have combined the 3 steps into 1.

Unhide none system files now gives a count of how many files it unhides. Also made a new status window to show when the unhide repair is running.

The Beta Repairs button will now be disabled when your running repairs.

The program now lists all fixed drives in the system for the Reset File Permissions and Unhide Non System Files repairs. Before it would only do the drive that Windows is on, now you can have it do other fixed drives as well. By defaul only the Windows drive is selected.

Shane
Title: Re: Window Repair 1.9.2
Post by: Shane on January 29, 2013, 06:51:23 PM
Making a few more changes, I will post the new version on here for you to test shortly.

Shane
Title: Re: Window Repair 1.9.2
Post by: Shane on January 29, 2013, 08:02:20 PM
OK here is the new version to test. Let me know if you like the changes I have done :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 30, 2013, 03:14:56 AM
What a relief !! No more change in behaviour after re-entering the main repair screen. Small bug, large consequences.

- Bug: WR forgets to unblock "Beta Repairs" when it has finished the repair jobs.
- Send you an email with my comments. A number of issues popped up.
- Love the new "Unhide info".  Not quite what I had in mind.
Suggestion: get rid of the top log pane ("Status: searching ......."), it no longer necessary because the log pane provides enough "moving" info. Get rid of the ")" character in the second pane (from the top) and replace "(Last ...." with "- Last ......". Much friendlier for the eyes.

When I look at the files that are unhidden:
- A number of files and one folder simply won't let themselves to be unhidden. Time and time again the same amount of unhidden files are reported. These files are predominantly in the "C:\Windows\winsxs\" folder. Permission problem ? Attribute problem ? I did switch my AV and the internet off.
- Is a "smart script" used ? Because the second time I run this repair job, it won't process a number of folders that were processed previously.
Title: Re: Window Repair 1.9.2
Post by: Shane on January 30, 2013, 10:54:42 AM
Quote
- A number of files and one folder simply won't let themselves to be unhidden. Time and time again the same amount of unhidden files are reported. These files are predominantly in the "C:\Windows\winsxs\" folder. Permission problem ?

If your on vista or 7 then yes. The trusted installer owns those files and since my program is running under the current user account it doesn't have permission to unhide the files there.

Quote
- Is a "smart script" used ? Because the second time I run this repair job, it won't process a number of folders that were processed previously.

No, does it happen when you run it and then run it again? What happens when you run it, close the program and then run it again?

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on January 30, 2013, 01:05:45 PM
I fail to replicate the "unhide" problem. I would suggest that you, for now, only adress the known bugs in v1.9.7 and other things that need to be patched up. Then v1.9.7 can be released.

I always can send you an email or post on this forum. Don't have too much time today anymore. We'll see what tomorrow brings.
Title: Re: Window Repair 1.9.2
Post by: Willy2 on February 03, 2013, 03:18:13 PM
First impression of v1.9.7:
- After running the "Reset File Permissions" the amount of files that were "unhidden" dropped from about 420 (in v1.9.6) down to 8.
Title: Re: Window Repair 1.9.2
Post by: Shane on February 04, 2013, 10:08:12 AM
If they where unhidden before then they wouldn't get unhidden again unless you hid some files since then :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on February 05, 2013, 05:14:43 AM
It's possible that as a result of the improved WR "permission" program code, WR was able to unhide more files in the "C\Windows\winsxs" folder.
Title: Re: Window Repair 1.9.2
Post by: Shane on February 05, 2013, 11:09:27 AM
Permissions code doesnt change if a file is hidden or not, it only adds permissions, nothing more :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on February 08, 2013, 12:19:31 PM
Is it possible to have the "Beta Repairs" window open on top of the main repair, even when the user has selected "Always on top" ?
Title: Re: Window Repair 1.9.2
Post by: Shane on February 09, 2013, 01:57:29 PM
Yeah should be able to :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on February 11, 2013, 05:59:41 AM
A. Perhaps you could add a "reset printer spooler" repair/flush repair job ? Are there other buffers/caches (e.g. DNS, .....) that can be flushed/reset in order to ensure a more stable and predictable Windows and that would fit in the scope of the WR program ? Or are those already covered/flushed in other repair jobs ?

B. Add a "Reset registry settings to default values" repair job ? With this job WR could reset a whole bunch of registry keys to their safe/default settings. Especially those that are changed by a virus.

C. Some Windows users have their own favourite settings for the Services in Windows. Perhaps you could introduce program code that would enable users to set the state of one or more Service back to their favourite setting. This could be done in 2 steps:
1). Run the usual "Set Services to default" repair job(s).
2). Make WR look for a text file with a special name (e.g. "User services.txt") and execute the commands in that file. The user could then specify in that file which services are to be set to which state ("Auto", "Demand" or "Disabled") using the "SC" command. If the program doesn't find that particular file then WR simply should move on to the next repair job.

D. I ran WR with ALL boxes ticked and it took WR some 30 minutes to perform all the repair jobs. Especially the "reset file permissions" (think "C:\Windows\winsxs\" folder !!!!) repair job took LOTS of time to complete. Perhaps there's a need to add an explanation to one or more repair jobs ? In the repair info pane ? (e.g. "This job can takes a long time !!!").
Title: Re: Window Repair 1.9.2
Post by: Shane on February 11, 2013, 02:42:24 PM
Quote
A. Perhaps you could add a "reset printer spooler" repair/flush repair job ? Are there other buffers/caches (e.g. DNS, .....) that can be flushed/reset in order to ensure a more stable and predictable Windows and that would fit in the scope of the WR program ? Or are those already covered/flushed in other repair jobs ?

Can you give me a link showing the steps to reset the printer spooler? I think that would be a good repair to add.

Quote
B. Add a "Reset registry settings to default values" repair job ? With this job WR could reset a whole bunch of registry keys to their safe/default settings. Especially those that are changed by a virus.

Right now it adds permissions to the keys, doesnt remove any. There are over 1 million keys in a default install of Windows. Tracking down what each should be would be a big job, I could automate it, but then I would have a VERY large file with the program listing the permissions. Not sure if I want to do that yet.

Quote
C. Some Windows users have their own favourite settings for the Services in Windows. Perhaps you could introduce program code that would enable users to set the state of one or more Service back to their favourite setting. This could be done in 2 steps:
1). Run the usual "Set Services to default" repair job(s).
2). Make WR look for a text file with a special name (e.g. "User services.txt") and execute the commands in that file. The user could then specify in that file which services are to be set to which state ("Auto", "Demand" or "Disabled") using the "SC" command. If the program doesn't find that particular file then WR simply should move on to the next repair job.

What if instead I move the services repair that it does to a text file like I do the register system files, then the user can just edit that text file?

Quote
D. I ran WR with ALL boxes ticked and it took WR some 30 minutes to perform all the repair jobs. Especially the "reset file permissions" (think "C:\Windows\winsxs\" folder !!!!) repair job took LOTS of time to complete. Perhaps there's a need to add an explanation to one or more repair jobs ? In the repair info pane ? (e.g. "This job can takes a long time !!!").

Yeah depending on the system and the number of files those repairs can take a while. Fell free to edit the info txt file on them and send them to me on how you think they should be worded :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on February 11, 2013, 03:27:06 PM
Printer spooler reset:

:: Created by: Shawn Brink
:: http://www.sevenforums.com
:: Tutorial:  http://www.sevenforums.com/tutorials/89483-print-spooler-queue-clear-reset.html


net stop spooler
del /F /Q %systemroot%\System32\spool\PRINTERS\*
net start spooler


For Vista, Win 7 & 8. It could be this simple for XP as well. Does XP have a "spooler" service as well ?
Title: Re: Window Repair 1.9.2
Post by: Shane on February 11, 2013, 03:31:48 PM
I will get it added :-)

I will see about having the registry info for the spooler service as well.

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on February 11, 2013, 03:41:33 PM
These commands seem to work in XP as well.
http://www.axelscript.com/2008/02/09/how-to-clear-the-print-spooler-in-windows-xp/

I got the idea for this because my laser printer started printing (without my consent !!) as soon as it was "hooked up".

You're right. Ditch the idea of setting registry keys to their default values. Too much work and too complicated.

Still need to check a number of things in WR (error logs, you know). Don't have time right now. To be continued.
Title: Re: Window Repair 1.9.2
Post by: Shane on February 11, 2013, 03:42:22 PM
I am loading up each version of windows in vmware and grabbing the reg key for the spooler service as well to add to the repair.

Shane
Title: Re: Window Repair 1.9.2
Post by: neroilo on February 11, 2013, 03:59:10 PM
B. Add a "Reset registry settings to default values" repair job

Someone already did it:
http://www.techprone.com/reset-windows-registry-and-services-to-default-values-using-refreshpc/4288
Title: Re: Window Repair 1.9.2
Post by: Shane on February 11, 2013, 04:06:18 PM
Going to take a look at it, but when I did it closed my firefox and installed a add on in it without asking and wants to install a bunch of other stuff. Be careful with it. I have to go clear what it installed :wink:

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on February 12, 2013, 06:43:41 AM
I don't know which new version of "Set Services to Default" I like best. I like my own version only slightly more. What do other readers of this thread think of the two suggestions presented here ?
Title: Re: Window Repair 1.9.2
Post by: Shane on February 12, 2013, 10:46:18 AM
I already changed it. The program pulls the service list and their startup from the txt file. It will work like it always has, just now advanced users can tweak that file before they run the repair if they like :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on February 13, 2013, 12:30:31 PM
There's a reason for my "Set Services to Default" request. This WR repair job sets the "Index Searcher" service to "Auto" and then that service runs upon start up slowing down the machine even more. And that comes on top of RB and the AV program running. Is this the reason why a number Task Scheduler tasks (sometimes) fail to run ?

(BTW: Task Scheduler in Win 7 seem to contain one or more bugs as well.)
Title: Re: Window Repair 1.9.2
Post by: neroilo on February 13, 2013, 02:41:15 PM
I've an interesting addition for Windows Repair about the Disk space usage bar issue in My Computer on Windows 7.

http://answers.microsoft.com/en-us/windows/forum/windows_7-files/disk-space-usage-bar-in-my-computer-is-missing/457ab86b-54c4-4f11-ac52-49739978ad31

So I applied successfully this suggestion to solve my issue:
Quote
Now, I don't know if this is particular to my configuration I suceeded in solving the issue by deleting only 1 value:
HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\15\Shell\{5C4F28B5-F869-4E84-8E60-F11DB97C5CC7}\mode

After that, I recommend to re-create the same mode value, with the same default value setted to 1. It worked here. :smiley:
Title: Re: Window Repair 1.9.2
Post by: Willy2 on February 20, 2013, 02:15:08 PM
I already came across another bug in WR v1.9.9 log file feature. The logs normally are stored in the subfolder "Logs". But when the user starts fiddling with the "Log Location option" in the "Settings" tab then something strange happens/can happen. Then suddenly WR decides the logs are going to be stored in a (newly created) subfolder "Backups" while the tab keeps showing that WR assumes that the logs are stored in the "Logs" subfolder. Confusing !! So, the user can end up with log files in both the "logs" and "Backups" subfolders. Confusing ! Which are the latest logfiles ?

See attachment.
Title: Re: Window Repair 1.9.2
Post by: Shane on February 20, 2013, 02:29:59 PM
Good catch bud.

I had copied the code from my reg backup on the backup location to use for the log. I missed 1 line of code where it said backups instead of log. I found it and fixed it :-)

v1.9.10 will be out today. Here is the change log.

v1.9.10
Improved the "Repair Windows Firewall". The program use to only restore the core of the shared access service. It didn't put any policies or rules. While helping a user in the forum they had a virus completely delete the shard access service key, including all rules. When the shared access was put back the firewall worked but he was unable to share any files. This is because there is some core things that have to be in the firewall rules in order to work. I have now added those core rules to the repair and it got his file sharing working just fine. This now makes the repair even better than before.

Added some more settings for the "Repair Windows Firewall". While helping a user in the forum the firewall was working but he couldn't get the firewall to open and would get a Group Policy error. While helping him I found the 2 reg keys that where needed to fix it. This keys are only on Vista and 7. They are not on Xp, 2003 or 8. The repair now puts these keys in on Vista and 7 only.

Added Windows Defender to the "Restore Important Windows Services" repair.

Shane
Title: Re: Window Repair 1.9.2
Post by: neroilo on February 21, 2013, 02:39:57 PM
A little feature suggestion for the next version.
I'd like a checkmark in the installer to not have a desktop shortcut after I install Windows Repair.
Title: Re: Window Repair 1.9.2
Post by: Shane on February 21, 2013, 04:28:34 PM
Are you installing the program from a bat file, or doing a lot of installs?

Shane
Title: Re: Window Repair 1.9.2
Post by: neroilo on February 22, 2013, 02:00:42 AM
Are you installing the program from a bat file, or doing a lot of installs?

Shane

Multiple installs on the same user account, every time there is a new version I delete desktop shorcut manually.
Title: Re: Window Repair 1.9.2
Post by: Shane on February 22, 2013, 10:37:05 AM
Ah I see. I will see what I can do :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Shane on February 22, 2013, 10:59:54 AM
Done, It will be in the next update and part of the setup for now on :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 02, 2013, 03:39:13 AM
Suggestion for the next WR version:
- For the "Repair spooler" job:  Reset/flush the "Server" subfolder as well. Perhaps other sibling folder can be flushed as well ?

I was looking at the folder in which the "Spool-ed" files are stored and discovered it has a sister subfolder called "Server". Thanks to GOOGLE I came across this info:

1. "Also bear in mind, "%systemroot%\system32\spool\PRINTERS" will only show the print jobs if the printer is a local printer (USB/Parallel connection), if this printer is connected via Ethernet controlled by a print server or shared from another PC, then it will likely to (temporarily) store the print jobs in "%systemroot%\system32\spool\SERVERS" directory""
Source: http://www.city-data.com/forum/computers/1496676-help-spooler-subsystem-laptop-flash-server.html

2. http://www.techienewsnetwork.com/fixing-or-cleaning-the-problematic-windows-print-spooler/
Title: Re: Window Repair 1.9.2
Post by: Shane on March 02, 2013, 10:28:40 PM
Thanks, I will get it added :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 03, 2013, 01:15:37 AM
More info on "Cleaning the Spooler":

http://members.shaw.ca/bsanders/CleanPrinterDrivers.htm

On the top left hand of the page there's more links on printing problems.
Title: Re: Window Repair 1.9.2
Post by: neroilo on March 03, 2013, 03:12:58 PM
A new feature suggestion for the next version.
I'd like a checkmark in "Windows Repair (All in One)" and "Registry Backup" installers with this option:
Maintain Registry Backup settings.

It's nasty to lose all RB custom settings after an update.
Title: Re: Window Repair 1.9.2
Post by: Shane on March 03, 2013, 03:16:31 PM
All the settings are stored in the settings.ini file.

IN the "Registry Backup" installer I have it set to never overwrite the settings.ini

But int he windows repair installer I did have it set to overwrite the reg backup settings.ini that is with the program. I changed it to never overwrite :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: neroilo on March 03, 2013, 03:21:34 PM
Thank you Shane!  :cheesy:
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 04, 2013, 04:28:32 AM
A number of things/suggestions came up when I "tortured" WR v1.9.11:

1. The "Set Services to Default" batch file contains a command "ListServices" and that generates an error ("Command not recognized"). Needs to be removed, IMO.

2. On my laptop, WR v1.9.11 is installed in a subfolder of "C:\Program files (x86)\". This subfolder name and a scroll bar show up in the CMD.exe window when a batch file is run under the "User Account". But when the batch file is run under the System Account then I see no scroll bar and the subfolder name that shows up in the CMD.exe window is "C:\Windows\system32\".

E.g.:

User Account:
"C:\Program files (x86)\PcWinTech\WR v1.9.11>SC config SharedAccess start= .........."

System Account:
"C:\Windows\system32>SC config SharedAccess start= ............."

Is this normal ?

3. Make "Register system files" the (second) last repair job and a job that's ALWAYS run. I.E. don't provide a box that can be ticked. I know it registers a number of "low level" system files (remember the "Dependency Walker" program ??).
 
4. Make "Set Services to Default" the (second) last repair job. In the other repair jobs a number of services are disabled and after that enabled. When "Set services to default" is the second last repair job, then the (advanced) user can use this job to exit WR with all his/her favourite Service settings without any other repair job interfering. The (advanced) user can also add its own Services as well.

E.g. I have an Hewlett Packard laptop and HP has installed a number of extra services that are dependent on other (Windows) services and as a result of that dependency these HP services are automatically switched off when one or more repair job are run. But they are NOT switched on when those Windows services are switched on again.

5. Repair job "Restore Important Services": Does this repair job confine itself to restoring the default registry information or does this job also (re-)start ("net start ......." or "SC config ...." ) these Services ?

6. Move the subfolder "file associations" one level higher (directly under "files") and rename "reg files" to e.g. "restore services". Makes more sense, IMO.

7. Currently WR calculates the time it took to perform all the repair jobs. WR has to take into account that not all users have the same time format. I would say just grab the time from the "elapsed time" counter and put it in the log file (pane).
Title: Re: Window Repair 1.9.2
Post by: Shane on March 04, 2013, 11:17:05 AM
Quote
1. The "Set Services to Default" batch file contains a command "ListServices" and that generates an error ("Command not recognized"). Needs to be removed, IMO.

Found it, ListServices is the name of the listbox that the program loads the txt file to. For some reason the name was in the listbox by default. I have it fixed :-)

Quote
2. On my laptop, WR v1.9.11 is installed in a subfolder of "C:\Program files (x86)\". This subfolder name and a scroll bar show up in the CMD.exe window when a batch file is run under the "User Account". But when the batch file is run under the System Account then I see no scroll bar and the subfolder name that shows up in the CMD.exe window is "C:\Windows\system32\".

Thats normal. When the cmd.exe is being ran under the system account the default location for system is the system32 folder.

Since I make sure to add this to every bat file

"set path=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem"

It isnt a problem :-)

Quote
3. Make "Register system files" the (second) last repair job and a job that's ALWAYS run. I.E. don't provide a box that can be ticked. I know it registers a number of "low level" system files (remember the "Dependency Walker" program ??).

Cant do that, one of the reasons so many malware cleanup forums recommend my tool is they have control to tell the user which repairs to run.

Quote
4. Make "Set Services to Default" the (second) last repair job. In the other repair jobs a number of services are disabled and after that enabled. When "Set services to default" is the second last repair job, then the (advanced) user can use this job to exit WR with all his/her favourite Service settings without any other repair job interfering. The (advanced) user can also add its own Services as well.

The other repair jobs, like repair windows updates disables the services it uses while the repair is running, because sometimes they would start back up before the repair was finished.

At the same time the restore important services would replace any changes, but those are default services anyways and would normally be on. But now that the user can edit the service default file I guess it would be a good idea to make that repair last.

Quote
5. Repair job "Restore Important Services": Does this repair job confine itself to restoring the default registry information or does this job also (re-)start ("net start ......." or "SC config ...." ) these Services ?

All reg files, which you can see int he files folder. And in those reg files is the service startup setting. This is why I am moving the set default startups to the last :-)

Quote
6. Move the subfolder "file associations" one level higher (directly under "files") and rename "reg files" to e.g. "restore services". Makes more sense, IMO.

Why would I do that when they are all reg files?

Quote
7. Currently WR calculates the time it took to perform all the repair jobs. WR has to take into account that not all users have the same time format. I would say just grab the time from the "elapsed time" counter and put it in the log file (pane).

Program uses the "Now" variable which pulls date and time from the current system and its format. Also when it does the math to see time it is using the correct format of the system. I fixed this back when I added the time elapsed. It is the same way the time elapsed works.

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 04, 2013, 03:27:01 PM
Makes sense.

Another way to re-arrange those reg files: re-group those reg files in such a way that each repair job has a separate folder with its own reg files. just a suggestion !  :wink:

I know for sure that - at least (!!!) - three help forums of dutch computermagazines have recommended Windows Repair as well to solve the problems of dutch computer users. They were all very positive about the program.  :smiley: :cheesy:
Title: Re: Window Repair 1.9.2
Post by: Shane on March 04, 2013, 03:43:40 PM
Quote
Another way to re-arrange those reg files: re-group those reg files in such a way that each repair job has a separate folder with its own reg files. just a suggestion !

Some repairs use the same reg files, I like them the way I have them, the files are for the program, they are there just for the advanced users who want to see. :-)

Quote
I know for sure that - at least (!!!) - three help forums of dutch computermagazines have recommended Windows Repair as well to solve the problems of dutch computer users. They were all very positive about the program.  :smiley: :cheesy:

Very nice!

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 05, 2013, 04:32:03 AM
I already have added those HP services to "Set Services to Default". The way this is set up allows me to add not only "SC Config ....." commands but "net start ...... " commands as well. Very nice !!! :cheesy:
Title: Re: Window Repair 1.9.2
Post by: neroilo on March 05, 2013, 11:53:18 AM
New version is great.
Just a little imperfection, you need to update repair info related to the Printer Spooler adding this code in the command description:

Code: [Select]
del /F /Q %systemroot%\System32\spool\SERVERS\*
Title: Re: Window Repair 1.9.2
Post by: Shane on March 05, 2013, 01:07:20 PM
Got it :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 06, 2013, 05:24:18 AM
At the start of "Repair WMI" and "Repair Firewall" some services are stopped. But there're some other Services that are dependent on these Services and then these are stopped as well. But they're not started again (net start .... ???).

The dependent Services that are stopped as well, on my HP laptop (Win 7) are:

Under Repair WMI:  (as a result of stopping "Winmgmt")
- Security Center (wscsvc)
- IP Helper (iphlpsvc)
- HP Wireless Assistent Service (a Service installed by HP)

Under Repair Firewall: (as a result of stopping "BFE")
- IPsec Policy Agent ("Policy Agent")
- IKE and AuthIP IPsec Keying Modules ("IKEEXT")

Are these Services important ? Must a "net start ...... " command for these services, be included in the appropriate batch files as well ? (No need to issue a new version now, though.)
Title: Re: Window Repair 1.9.2
Post by: Shane on March 06, 2013, 11:04:27 AM
Some services stop when the service they need stops.

This isnt a big deal as you need to reboot after the repairs anyways and the services will be started back up :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 09, 2013, 05:53:15 PM
WR v1.9.12 can be improved. I know WR (re-)registers a number of files to make things work (again). But WR does not always target the proper (sub-)folder. E.g., some files are not located in "c:\windows\system32" and then those files won't get (re-)registered.

Watch your email. To be continued.
Title: Re: Window Repair 1.9.2
Post by: Shane on March 10, 2013, 01:09:32 PM
I have it purposely doing system32 and syswow64 folders, this is to handle both 32 bit and 64 bit and all OS's. So some dlls may not be on the version of Windows, but the nice thing about the register system files is if the file isnt there it is simply gives an error that the file isnt there and moves on :-)

Really was just a simpler way to make the repair instead of making that repair 4 times bigger and harder by putting in so many checks for each version of Windows.

I got your mail and will be looking over it soon :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 10, 2013, 04:26:31 PM
I wasn't clear enough. I need to rewrite my previous post. WR assumes one file is located in the "syswow64" and/or "system32" subfolder. But that particular file is actually located in a "%commonprogramfiles%" subfolder only.

Again, watch your email box in the coming days/week, for more details. I'll need to put "Dependency Walker" to work.
Title: Re: Window Repair 1.9.2
Post by: Shane on March 11, 2013, 11:40:41 AM
Ah! Gottcha :-)

By the way I am making a word game that will be part of tweaking.com

Off the norm I know, but I always wanted to make a game and in 1 short week it is already playable lol. If your up to it you are welcome to test it when it is ready :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 12, 2013, 02:02:19 AM
In response to another thread on this forum where someone had trouble with one Service (file) (http://www.tweaking.com/forums/index.php/topic,934.0.html), another thought/suggestion surfaced.

I came across this piece of programcode in one of the WR repairs:

"MSIExec /unregister"
"MSIExec /regserver"
"regsvr32.exe /s %windir%\system32\msi.dll"



This has led me to the following suggestion: Perhaps you can add to WR, program code that (re-)registers ALL MS/Default system files, that execute/control the default (system) Services.
E.g., in the "Set Services to Default" repair job ? Or at any other ((more) appropriate) spot in WR ?
E.g., at the beginning of WR ? In either a separate (clickable/tickable) repair job or a repair job that's simply always executed/always runs, no matter what the user chooses ??

It could solve A LOT OF problems !!!!
Title: Re: Window Repair 1.9.2
Post by: Shane on March 12, 2013, 11:19:07 AM
When I made the very first version of the Windows repair I had the register system files do every dll and ocx file in the system 32 dir.

And the oddest thing would happen. It broke things!!! I was shocked.

For my system and a couple of others one of the dll files when simply registering it would cause the language file to show up on the task bar in Windows. Another one caused the components manger not to work. And there was some other very odd things that happened.

So I changed the repair, this time I decided instead of doing all the files in the system32 folder I will make a list of safe files to register. I thought about having it do allt he files and making a dont register list but decided it was not a good idea as you never know what would be on a users system.

So to make the list of safe files to register I searched on Microsoft website for any help articles that had the register command in them and grabbed every file that was in them. And thats how I got the list.

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 14, 2013, 05:23:03 AM
A number of things popped up when I went through all the WR batch files. A number of issues surfaced.

1. One complete repair ("Register system files") and some commands in other repairs will always fail when the Windows OS wasn't installed on the logical C: drive but instead on e.g. the D: or E: drive. And then it doesn't matter whether or not this batch file and these commands are executed under the System account or a User account.

2. Another complete repair ("Repair Internet Explorer") MUST be run under an account with Administrators rights in order to not fail.

3. The time WR needs to run, all but three, repairs can - IMO - be reduced by say 50%. If the issues metioned above are resolved then, I think, all the batch files simply don't need to be run twice.

The solution to solve the issues mentioned above, require changes in the program code of the batch files. I already have send you an email with some details of what needs to be changed.

4. I think "Repair WMI" can be improved. The internet provided some interesting info.

5. WR tries to register a number of files but fails because it targets the wrong folder(s) (See reply #80 in this thread). I used a program "SearchMyFiles" to determine in which folder(s) a number of files are located on my Win 7 machine. It also can show e.g. hidden & system files. Excellent program, IMO. Much better than e.g. "Everything" (www.voidtools.com).
Source: http://www.nirsoft.net/utils/search_my_files.html

6. The thoughts behind the suggestion to register "Service" files are these: I noticed that a number of names in Task Manager (Services) and files in the "System32" folder are similar. Thatīs why I thought these Files\Services could/can be (re-)registered.

Watch your email inbox for more/additional details !!
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 14, 2013, 08:39:32 PM
I experienced another weird thing. It could be "psexec.exe" related.

When I run WR with e.g. only "Set Services to Default" selected then two CMD.exe windows open to run a number of commands. In both cases the header of the CMD.exe window says "Administrator: ....".

But I see a different behaviour when I manually open CMD.exe under my User Account. Then there's no text "Administrator" in the header of CMD.exe. Windows also offers the opportunity to run CMD.exe with Administrator rights (right click). Then in the header that word "Administrator" does show up.

Consider the next 4 commands:
"net stop ........."
"net start ........."
"sc config ......... start= ......."
"pause"


When I (manually) run a batch file with these 4 commands in a CMD.exe window under my (default) User Account the first three commands all generate an error ("Access Denied"). But when I (manually) run these commands with Administrator rights then no error is generated. Windows "swallows" those commands without any comments.

All this behaviour, as described above, leads me to believe that "psexec.exe" could "push" WR into "Administrator Mode". And that could explain why a number of repairs (with e.g. "net start" commands) won't fail in spite of being run under my User Account.
Title: Re: Window Repair 1.9.2
Post by: Shane on March 15, 2013, 06:30:20 PM
The manifest file with the program tells windows to run my program with administrator rights. But it is still under the current user account.

psexec.exe is used to run cmd.exe under the system account. Which also has administrator rights and then some.

So the cmd.exe window will say administrator at the top for both. Thats just how they made it. I dont think they ever though cmd.exe would be run under the system account so it doesnt say. It saying administrator in the title is just a way to let you now that cmd.exe has higher permissions than normal.

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 16, 2013, 01:42:21 AM
Ah. your reply eliminates enough (not all) question marks.

I've gone through all the batch files and I have a found a number of issues. I found that not only "Register System Files" and "Repair Internet Explorer" - in some special circumstances - could/would fail. I found that "Repair MSJET & MDAC" can fail also in some circumstances, as well. The proposed code changes will - IMO - improve the reliabilty of those repairs.

When the program code has been updated/improved (following my proposals) then you can - IMO - get rid of running the batch files twice. Saves - IMO - a significant amount of time.

See the emails I have sent you. I am done. I can't find any flaws/bugs in the batch files anymore. Now it's up to you to see whether you like the proposals or not. And to include them in the programcode.
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 16, 2013, 06:07:57 AM
I'll provide more details why "Repair IE" & "Repair MSJET & MSDAC" fail when run under a user account. Take e.g. the line (in "Repair Internet Explorer"):

- "regsvr32 -s dispex.dll"

The "Path=" command tells Windows in what folders to look for the "Regsvr32" command/file. But "Path=" doesn't tell Windows in which folder the file "dispex.dll" is located. So, Windows starts looking for this file in the active folder. And that's where the problems begin. The active folder, when WR runs under a user account, could be "C:\Program files\WR v1.9.12". But Windows can't find ""dispex.dll" in that active folder. Surprise, surprise. Because "dispex.dll" is located in the "%windir%\system32" and/or "%windir%\syswow64" folder.

So, in order to make the registration of this file work, this particular line should be replaced by two lines:
- "regsvr32 -s %windir%\system32\dispex.dll"
- "regsvr32 -s %windir%\syswow64\dispex.dll"

And then - IMO - you could get rid of running the batch files twice. Saves time, right ? And there're a number of other "active folder" & "path" problems as well. Again, see my email.
Title: Re: Window Repair 1.9.2
Post by: Shane on March 16, 2013, 01:47:01 PM
You know, your my best tester. Why is it we have never just talked on chat instead of email and the forums? lol

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 16, 2013, 05:11:42 PM
What about time differences ? You're on Pacific Standard Time (US West Coast). The capitol of the Netherlands (the country I live in) is Amsterdam. And the time difference is 9 (!!) hours. See the weblink below.

http://www.timeanddate.com/worldclock/
Title: Re: Window Repair 1.9.2
Post by: Shane on March 17, 2013, 01:50:28 PM
Yes but I have crazy freaking hours that I keep lol. Sometimes I go to bed at 11 PM, sometimes I go to bed at 5 am. Sometimes I am awake at 6 am and sometimes I wake up at 11 am LOL

Running a computer repair business, 2 websites, 2 forums, over 60 programs and my 4 kids and my wife I dont have a clue what a normal sleep schedule is like :-)

Shane
Title: Re: Window Repair 1.9.2
Post by: Willy2 on March 22, 2013, 07:22:49 AM
One thing that annoys me (a tiny) bit and that can be improved: when the user has ticked the option "Restart/Shutdown System when finished" then the log pane still says "You must restart the program". Perhaps you can let WR check whether this option has been ticked and if that's the case then don't display that text.