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

Pages: [1] 2
As I understand it you can import individual Tasks into Task Scheduler using an XML file via the Import function
- but these have to be created one by one using the Export function from within Task Scheduler
- which is OK for transferring a limited number of user created tasks.

The files stored by Windows are located at \Windows\System32\Tasks - but these are not the XML files you need for the import function within Task Scheduler. They are just part of the integrated Task Scheduler system - the full system comprises the above folder plus all the associated registry entries - and are keyed to a specific Windows install using a digital signature key. As far as I know this makes it impossible to transplant these files directly from one computer to another - as the digital key is invalidated - and the registry keys are not updated.

To reinstate the complete Microsoft library of standard tasks is very tricky and time consuming without the use of the RepairTasks utility and the associated Zip file containing the full Win7 standard tasks library.

Worked perfectly - 52 tasks fixed - no more errors.
I think the utility had to reload 2 tasks from the clean backup (ZIP) provided on the site
- all the rest it fixed without problems. 

Registry Backup v3.4 implemented a new feature - to backup (and restore) the security permissions of the registry files.
These permissions are (as you stated) saved in the SDDL.txt file - and re-applied during restoration of the registry files.

This new feature was introduced to prevent issues where Windows baulked at accessing the restored registry files due to "incorrect" security permissions. I reported a minor issue (with the user registry) under Win7 and various reports have been made about odd behaviour under Win10 - after restoration of the bare registry files. See,3865.msg27838.html#msg27838

Normally the "correct" security permissions of the registry files are inherited from the folder where they reside. These inherited permissions were not being applied to restored user registry files (system registry files were ok) - and in some cases the non-standard permissions were causing access problems for some Windows functions.

Problems only occurred when restoring from within the Registry Backup program (normal Windows start-up)   
- restoring from the Recovery Console (using the F8 Repair option) always worked correctly.
- the two restore methods use different commands to place the backup files in the correct folder locations
- the Recovery Console method triggers the default Windows behaviour to assign security permissions based on those of the parent folder.   

I had to assist a customer of mine today who had allowed his Win7 system to upgrade to Win10
The PC was suffering frequent total lockups with no obvious cause - other than the upgrade.
No event log clues or crash dumps were found - so hunt the bug or downgrade back to Win7 ??

I downgraded him back to Win7 and used GRC Never10 to keep him there.
Fixed a few corrupted applications and all was well

Except for one thing - the Task Scheduler had masses of corrupted task error messages
Apparently the revert from Win10 back to Win7 is known to cause this problem

I found a special utility that scans and repairs the Win7 Task Scheduler Library
The reviews look really good - might be worth a look if you encounter this issue

Doug Collins - Computer Support Engineer - London UK

It might be helpful if we actually mentioned the name of the utility
The utility is called TreeSize by Jam-Software
- and has both Freeware and Paid versions

It allows you to see the sizes of individual folders and also complete folder trees on your system
This allows you to understand which folders are consuming significant amounts of disk space
It is best to select the option to add TreeSize to the Windows Explorer Context Menu
That way you can right click on any drive or folder and display the folder tree from that point downward

I have used the free version for many years and install it on all the computers I configure.
The main page for TreeSize Free can be found here:

As always the devil is in the detail
I had not seen the Google notice re XP and Vista support

General & Misc. / Re: Advice Please on W8.1
« on: November 29, 2015, 07:24:58 AM »
The changes from Win8 to Win8.1 mostly affected the "New Style" (aka Metro) interface and Metro Apps
- so it is almost certain that if a classic application or utility works on Win8 it will be ok with Win8.1

Some manufacturers play safe and say Win8 (and/or Win7) is not supported for older versions of their software
- this can just be a ploy to make you purchase an upgrade or it can mean there are actually issues
- even Microsoft are guilty of this compatibility misinformation for there own applications (such as Office 2003)
- the only way to be certain is for someone to try it out
- either check yourself or look for reports by others on support forums

There is a potential risk is that malware will exploit a flaw in an older application to attack your system.
Another risk with older "unsupported" applications is that a future Windows update may break something
- not a high probability but if it happens you are then on your own as it is unlikely to be fixed

The only major change in compatibility is if you are changing from 32bit to 64bit Windows
- support for 16bit executable formats was dropped (both COM and 16bit EXE no longer function)

I really doubt that Google Chrome is to be discontinued - its a flagship product and forms the base for Chrome OS.
Not sure where you would have got that information - nothing I can find and it makes no sense.
Google Chrome is dropping support for Java and NPAPI browser plugins

General & Misc. / Re: Advice Please on W8.1
« on: November 27, 2015, 12:42:59 PM »
Been away for a few days - hence the delay in responding.

In terms of advantages of Win8.1 there are a few obvious areas:
- Support for the new full screen Apps and the Windows Apps Store
- Faster Startup (up to twice as fast) and Shutdown (up to 25% faster)
- Slightly faster performance overall (around 10%)
- Browser performance much improved (50%+) using hardware acceleration 
- Improved Battery life on laptops due to better energy saving methods 
- Upgraded Security features - more resistant to malware attacks     

I had not heard of Pokki before and having looked it wouldn't be my choice
- it may be that if its design appeals then Win8.1 would be better for you
Classic Shell replicates the traditional StartMenu interface which is my choice
- but does allow you to access the Win8 Start page at any time

The main things that annoy me about Win8.1 (once Classic Shell is installed)
- The half baked GUI, parts are "Metro" style while others are Classic style
- The random replacement of system controls with dumbed down "Metro" style panels 
- The new ribbon menus of Windows Explorer, I find it slower to access features 
- The dumbed down menu system for Internet Explorer (plus the two versions Desktop & Metro)
- Loss of some classic controls such as Manage Wifi Networks

Once you have started an application there is really little difference between Win7 & Win8
- until you trigger an external service like printing
- and a few older applications are more compatible with Win7, but most will run on either

As I said before if I had Win8.1 already installed I would likely stick with it
- but if installing from scratch my choice would be to go with Win7
- but this is really just personal preference for Classic Windows interface (stuck in my ways at 58)

GWX Control panel has been updated several times recently and is currently at v1.6.0.1
- and has just aquired an installer version in addition to the standalone exe version
- latest info here:

General & Misc. / Re: Advice Please on W8.1
« on: November 23, 2015, 04:38:54 PM »
You say you might choose to install Windows 7 - to replace the supplied Win8.1
- but you don't explain your reasons behind that suggestion
- and it is difficult to advise without knowing your requirements and expertise.

It does take a fair amount of preparation (downloading all the correct drivers and utils) and setup time to do that conversion
- and you can run into some install problems depending on how much experience you have.

While it can be satisfying to know exactly what drivers and software you have installed the process can take
most of a day to get everything installed and updated and that is just the basic install.
Then you have all your security and application software to install and configure.

If it is just the need to be back on a familiar GUI (Desktop and StartMenu) then my advice
would be to install the Classic Shell menu replacement.
For most day to day operations you can believe you are running Windows 7
- and it is only when you dig a little deeper you can tell the difference.

Windows 7 is supported until January 2020 for security updates
Windows 8 is supported until January 2023
See here:   

I have been installing Microsoft OS's since MSDOS v3.2 in 1986 and used Windows v2 (with 286 and 386 CPU's)
I myself will be sticking with Windows 7 for as long as I can, as I did with WinXP
- but have used the Win8.1 + Classic Shell combination for many of my customers
who wanted a classic Windows system on new  hardware.

The GWX Control Panel is a must have if you want to take control of the Win10 upgrade process

11 Programs & Site Help & Support / Re: uninstall
« on: November 20, 2015, 10:05:43 AM »
You could try reinstalling the same version of Windows Repair to the same (default?) folder
- this should fix the corrupted Uninstall entry.
Then try running Uninstall on the new version,  that usually works if the Uninstall is corrupted.

Well it seems you have your heart set on backing-up the permissions data
- I will view it as another extra feature over and above what ERUNT can do.

But I was curious as to how ERUNT manages to restore the User registry files successfully
- with all the correct permissions, and independent of the backup folder location
- initiated from within Windows, without any extra data.

I know ERUNT can do this trick with the User registry files up to and including Win8
- and it only uses the API's that were available in Windows XP (2005)

Tests show that ERUNT copies the User registry files in one step BEFORE the reboot
- it doesn't make use of any TEMP folder when restoring the User registry files

- the existing "live" files are copied to .bak versions alongside the originals
- the selected backup versions are Copied over the existing "live" files
- all while the current user is still logged on to that user account
- you MUST then reboot (which is prompted) or the User Account can be damaged.

ERUNT must restore the User files using elevated privileges of some kind (SYSTEM?)
- to allow it to copy the two User registry files with that User account still open
- plus maybe some other trick to stop Windows overwriting the restored files at shutdown 
FYI - my guide to configuring ERUNT for Win7 has been online for many years now
-  posted on my server here:

Note: The only reason ERUNT originally defaulted to backing up inside the Windows folder
was that this was the only folder location guaranteed to be accessible from the XP Repair console
In early versions of XP you had to set a registry key to unlock other folder trees during Repair.

Well it's your choice - re backing up the permissions - just seems to be solving a problem that doesn't really exist
- but your solution will obviously work.

The ONLY problem step we have is MOVING the files from a non-user TEMP folder which transfers the wrong permissions.
And as I pointed out the restore from the Recovery Console and ERUNT both work perfectly
- both making use of the default inherited permissions behaviour of Windows.

With my solution any "messed up" permissions on the backup versions wouldn't be an issue 
- as these would get reset when the files are Copied to the Users TEMP folder

With your solution my only worry would be that if someone messed up file permissions
and then did a backup then these incorrect permissions would be perpetuated
as the permissions would never be reset to the correct defaults.

Neither solution can protect from all possible "self inflicted " permissions screwups.

Just a couple of closing notes:
The COPY command was designed NOT to set attributes - that has always been its default behaviour.
The copied files collected their inherited permissions from the destination folder.

Re the documentation for the CopyFileEx ATTRIBUTE_SECURITY_INFORMATION flag
- it appears to say that this flag is not available in Win7 only for later Windows versions   
- so you would need workarounds for XP, Vista and Win7 if you started to rely on that.

I will update this thread with a solution once we have one.
Meanwhile you can follow the discussion here:,3830.0.html

There doesn't appear to be a CopyFile_Delay_Until_Reboot command - so let us analyse what we do have.

OK so the User registry files are copied to the main Windows TEMP folder first
This COPY operation will reset all permissions on the files - because new files are being created
- the files will be allocated the generic inherited permissions from that TEMP folder
- this means they will have no "Current User" entry for the User Profile they really belong to

Assuming the "MOVEFILE_DELAY_UNTIL_REBOOT" obeys the permissions rules for a "File Move"
- that is the permissions are carried with the file (because it has not been created just moved)
- then this is the step that carries the generic permissions from the Windows\Temp folder to the User folder
- so the User registry files  are restored without a "Current User" entry - which is the problem. 

When copying the User registry files is it possible to use a different TEMP folder?
- one inside the C:\Users folder tree
- the most obvious one would be C:\Users\All Users\TEMP

I believe this should create a flag for inherited permissions which includes the "Current User" entry
A basic test moving files between User folders shows that the inherited "Current User" entry
gets translated to the correct named user for the User Profile folder you move the file to - which is what we require.

The critical step is always the last MOVE command it must be moving files from a location where they have
the correct inherited permissions flag which includes a "Current User" entry
- the main Windows TEMP folder doesn't fulfil this need - a Users TEMP folder appears to provide this.

I think it would be worth testing this idea before going to the trouble of coding the backup/restore of permissions
- and if it works you will be replicating what restore from Recovery Console and ERUNT already do - both tried and tested solutions.
A number of things need to be true for this solution to work:
- you would need to be able to specify which TEMP folder is to be used - sounds likely
- and the C:\Users\All Users\TEMP folder would need to be available to the system early in the boot sequence
- and my theory about the translation of the "Current User" flag needs to be correct

Anyway have a think - this might be the quickest and neatest solution - without inventing extra work.
Live Long and Prosper - Doug

Pages: [1] 2