Author Topic: Improvements for WindowsRepair (Read 45462 times)

Shane · « **Reply #25 on:** December 10, 2011, 11:16:09 am »

My program doesn't mess with the path commands at all.

For some reason on your system it is messed up. But what a perfect thing to add to the windows repair :-D

http://www.computerhope.com/issues/ch000549.htm

The path should be stored in the registry.

What I could do is add the path command to the scripts in the windows repair. It wont fix your path in the system, but for the repairs it will tell cmd.exe what path to use. This way the repairs will still work when the path variable in the system is messed up.

Shane

Willy2 · « **Reply #26 on:** December 10, 2011, 12:33:32 pm »

Yes, I did already fear my system was messed up but I wasn't sure.

Willy2 · « **Reply #27 on:** December 11, 2011, 12:55:34 am »

Just a simple update.

Yep. PATH was indeed messed up. I changed it to ""C:\windows\system32;C:\windows\system32\wbem"" (is this the default for XP ? Do I need to add more ?) and WR behaved more normal. Now e.g. System Restore (Step 4) does create a Restore Point EVERYTIME (again !!) when I click on that button. And now WR waits with the ""Do you want to restart your system"" message until after the last repair job has been completed.

And SPB doesn't generate an error any more (i.e. netsh.exe and framedyn.dll).

Willy2 · « **Reply #28 on:** December 11, 2011, 10:36:42 am »

@echo on
copy /y c:\testfolder\print.pdf c:\print.pdf
copy /y C:\Program Files\PcWinTech\WR v1.53\files\subinacl.exe C:\
copy /y C:\Program Files\PcWinTech\WR v1.53\files\psexec.exe C:\
copy /y C:\ProgramFiles\PcWinTech\WRv1.53\files\subinacl.exe C:\
copy /y C:\ProgramFiles\PcWinTech\WRv1.53\files\psexec.exe C:\
takeown /F C:\subinacl.exe >nul
icacls C:\subinacl.exe /GRANT *S-1-1-0:F >nul
C:\subinacl.exe /subdirectories \*.* /grant=administrators=f /grant=system=f /grant=everyone=f /grant=users=f
pause

I ran a batchfile with this content (see above, in italics) in a separate window (CMD.exe) and the result is contained in the picture (see attachment). The 1st, 4th and 5th ""copy"" command worked (""1 bestand ......"" ) - IMO - because there wasn't a space between e.g ""program"" and ""files"" and between ""WR"" and ""v1.53"" like in the 2nd and 3rd copy command line. ""Takeown"" and ""Icacls"" generated an error ""command not recognized"". Then ""subinacl"" generated an error because ""de structuur van de beveiligings-ID is ongeldig"" (english: ""the structure of the security ID is invalid""). So, it seems a space throws CMD.exe ""off the rails"". That begs the question: why did thus work in a previous version of WR ?

Shane · « **Reply #29 on:** December 11, 2011, 12:55:33 pm »

When there are spaces in a path you need to use "

So
copy /y C:\Program Files\PcWinTech\WR v1.53\files\subinacl.exe C:\
should be
copy /y "C:\Program Files\PcWinTech\WR v1.53\files\subinacl.exe" C:\

Shane

Shane · « **Reply #30 on:** December 12, 2011, 08:22:28 am »

I will be updating Windows Repair today.

I will add this command to all command windows that are ran

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

This should make sure the repairs run on systems who's path is messed up

Shane

Willy2 · « **Reply #31 on:** December 14, 2011, 12:51:20 pm »

I am lost. I tried a number of things to get the commands (Psexec and subinacl), as specified above, run without generating errors. Tried to use no, one and two quotation marks, with and without ampersands (""&""). Tried to use PsExec.exe and subinacl in a number of configurations but to no avail.
When I look at the entire picture then the thing that would make the most sense to me is that WR would issue/issues a ""PsExec Subinacl ...... "" command for every main directory on the C: drive. But then the question becomes: what's the purpose of the other commands ?

Are the commands ""takeown"" and ""inacls" not found in XP and in e.g. Vista and Win 7 only ? Does the entire set of commands/repair jobs work without errors on Vista and/or Win 7 only ?
In WR v1.0.0 ""reset file permissions"" seemed to work. So, Because it worked in WR version 1.0.0 what major changes have been made after that version ? Or perhaps you could make a separate version for XP only ?

In WR v1.5.4 you introduced a fix for the ""PATH"" problem. But I came across that ""PATH"" problem in SPB as well. So, I think you should improve that program, bring out a new improved version as well.

Shane · « **Reply #32 on:** December 14, 2011, 12:54:53 pm »

Thats what I love about the bat files.

"takeown"" and ""inacls" is vista and 7. And if there is an error the bat file keeps on going, no harm no foul

Quote

In WR v1.5.4 you introduced a fix for the ""PATH"" problem. But I came across that ""PATH"" problem in SPB as well. So, I think you should improve that program, bring out a new improved version as well.

Yes in SPB the only bat commands are for the services since I have it using the SC command.

I have to rewrite how I have it doing it. Right now it just runs the sc command directly. It isnt making a bat file.

SO I either need to have it make a bat file then run with the path command or just put the full path of the SC and that should work as well

Shane

Willy2 · « **Reply #33 on:** December 14, 2011, 02:00:52 pm »

About the ""PATH"" problem. To make it more clear: It seems SPB generates an error when it wants to use/access the programs ""netsh.exe"" (in ""C:\windows\system32"") and ""framedyn.dll"" (in ""C:\windows\system32\wbem"") (in a *.bat file ?). Are those things services (SC command) related ?
If these two files are accessed with a *.bat file then I think adding ""set path= ... "" would suffice.

I understand the advantages of a bat file. Because you do the same whe one wants to set the Services back to a safe/default state. But then the ""subinacl"" problem remains in WR. It generates a "" ....... security ID ...."" error and skips those files. See one of my posts above. Is this XP related only ? I'll try WR on a Win 7 machine. Perhaps everything works on such machine.

And this ""subinacl.exe"" problem begs other questions. In what other repair jobs is this same command used. It seems it doesn't work in e.g. repairing registry permissons of one (two, three, ......) registry hives and it does work when it wants to repair one other registry hive. I know there's more than one hive and only when WR processes one (the last ??) hive it shows a screen that clearly indicates that it's going across the registry keys of that hive. It even repots that resetting some of those permissions has failed.

Im sorry, but now I start to question whether these batch files work in any of the other repair jobs in XP. Because during other repair jobs CMD.exe opens and then it closes so fast as well that I can't determine what commands are executed and which generate a (non fatal) error in CMD.exe. And I DO want this program to work in XP as well, not in Vista and Win 7 only.

, extremely

.

Shane · « **Reply #34 on:** December 14, 2011, 02:19:41 pm »

The program works just fine in XP.

subinacl.exe is a Microsoft file that is used for setting permissions. You will see some errors, on keys that it doesn't set or isn't allowed to set. Not a big deal. Some of the folders and and reg sections are small and so they get done very fast. The bigger reg sections and folders is where you will see the cmd window stay open longer. The windows directory and the hkey local machine are 2 large ones.

During the process of doing the repairs I found that on Windows 7 the trusted installer refused to let some keys get reset for the permissions. Only the system is allowed to touch them. Proble is when the permissions are messed up or changed by a virus. So the trick is then to use psexec.exe which is a sysinternals file that allows the cmd.exe to be ran under the system account. The repairs now have full permission on Windows 7 like they do on XP. (XP didnt have the annoying trusted installer)

I forgot about the netsh.exe in SPB, yes it is a another command that is called directly. And since the path isnt set on your machine you get the error. I just need to update SPB to point directly to the folder then it will be fine for you

Shane

Willy2 · « **Reply #35 on:** December 15, 2011, 05:41:47 am »

1. I changed the PATH= variable using the Windows GUI and now SPB doesn't generate an error any more. So, - IMO - adding a ""Set PATH= .... "" command to the batch file(s) would suffice.
2. Ah, that ""installer"" explanation makes more sense. No wonder, Windows is so extremely complicated. It's a world on its own. Thank god, I am a user only.
3. Perhaps because all file permissions have been reset already the WR is able to go through all the folders that fast ? I don't want to make a giant issue out of this but it DOES remain a question mark in the back in my head.
4. Perhaps you could look at the suggestions I gave in the previous posts in this thread for WR ? If you like them then I would suggest to makes the changes now. Then they're already incorporated and ready for a future version of WR.
5. Do I need to test more programs ?

Shane · « **Reply #36 on:** December 15, 2011, 10:04:30 am »

Quote

Do I need to test more programs ?

I am working hard on the new advanced system tweaker. WHich will have repairs, tweaks and more and all add on based.
Whats cool is as I am doing it I am coming up with new ways to do things and will be doing a very large update to the windows repair after wards. (New interface and such)

The new program is nearing testing phase.

Shane

Willy2 · « **Reply #37 on:** December 17, 2011, 11:29:07 am »

Tried something else. I used the ""subinacl"" command and step by step I added some arguments to it. You use this command with 4 ""/grant=...."" arguments. Both the arguments "" ..=user=f"" and ""... =everyone=f"" don't work, generate an error when I use them and then Subinacl says ""Error: ...... Security ID is invalid"". And then the command isn't executed.

When I omit those two arguments then the ""Repair file permissions"" command (subinacl.exe) take much more time (about 4 to 5 minutes). This begs the question: Do you use the arguments ""/grant=user=f"" and ""/grant=everyone=f"" in other repair jobs as well ? That could explain why e.g. ""Repair registry premissions"" and other tasks can complete in a record time as well. It seems that it was this you changed/added in a previous version of WR. Are these two arguments nescessary in Vista and Win 7 ?

Do I need to test the other batch file scripts as well for this kind of behaviour (in Win XP) ?

Shane · « **Reply #38 on:** December 17, 2011, 11:53:07 am »

http://ss64.com/nt/subinacl.html

You shouldn't betting getting an error that it isn't a valid security ID.

Looks like your PATH isnt the only thing that is messed up on the system.

The system should know the everyone group and users group. These are just default groups on your system, yet it appears they might be messed up on your system as well.

Shane