| Read more to RegdatXP |
| Backup Registry |
| Repair corrupt registry file |
| Recreate Hive |
| Hidden Bytes |
| Remove or Save Slack |
| HKCU Pidls and BagMRU |
| Security Records |
|
Backup Registry | ||
|
A user with administrative rights can backup the Registry to a directory of choice. RegdatXP uses the following file names to backup Registry files: HKEY_LOCAL_MACHINE\Software With command-line arguments it can be used in the form which executes a registry backup to the directory C:\WINNT\Regdat. On Vista, additional flags -components, and -bcd have to be used in order to save also the Components and BCD files. Upon success a message is written to a text file regdatxp.ok. Errors will be written to regdatxp.err. The backup directory should be placed in %windir% (usually C:\WINNT) so that it is also accessible from the recovery console. Additional flags: The last backup date is taken from the file regdatxp.ini. To schedule the backup command you could put it simply into one of the Run registry keys as a startup option, or create a scheduled task, or maybe add it to an already existing script. Note that by default the security hive is not accessible to users even with administrative rights, but its access rights can be modified using Regedit/Regedt32 so that it can also be backuped. To restore a registry file from a backup directory you may use the "Replace Registry Hives" function from the Registry menu. When the Recovery Console is needed to replace, for example, the software hive one would do like change directory: | ||
SOFTWARE
|
Repair Corrupt Registry File | ||
|
If a registry file is severely damaged the system load process will usually result in a blue screen of death (BSOD), like the ones below, or even in an automatic reboot loop. If one of the user registry files ntuser.dat, or classes.dat, is corrupt then the user, upon logon, will be forced into a temporary default user profile and can no longer use his personal settings. A corrupted ntuser.dat file could also cause a reboot loop at startup. | ||
| ||
| ||
|
The above situation can be solved by replacing the corrupt registry file by a recent backup file. Backup files can be found in %windir% \ repair, or in %windir% \ repair \ regback if the ntbackup program was previously used. Usually, %windir% is C:\WINNT, or C:\Windows. On WinXP there is the System Restore utility which regularly creates Restore Points in the System Volume Information folders. These folders also contain backup files of the registry. In order to replace a registry file for a non bootable system, you could put the disk as a slave into another machine, use a parallel install, or use a BartPE Boot CD to get access to the disk. If the system is W2k or higher, and the file is not an ntuser.dat file, you could also use the Recovery Console, see MS Knowledge Base Article 307545 for more details. | ||
|
RegdatXP can be used to repair the corrupted file so that it can be loaded again by the system. On W2k you could also try the MS chkreg utility. Another option is to load the file as a hive in a higher OS version like W2k3. There exists a built-in repair function and the file will usually be repaired if the load process succeeds. In case repairing does not succeed the binary export function 'Recreate Hive' can still be used to recreate a non-corrupt registry file from the corrupted one. The unregistered version scans a file for corrupted items, the full version is needed for repair or export. | ||
|
Recreate Hive | ||
|
This saves a Hive to a new binary registry file. It should be used for corrupt registry files that can not be repaired, or when repairing them causes too much loss of data, or when RegdatXP does not find corrupted items. The new file will contain all information that still can be extracted from the corrupted file. You can choose to export security settings too, or, using default security settings instead. The user must have administrative rights. This is available in the full version. | ||
|
Hidden Bytes | ||
|
This searches for oversized strings containing embedded nulls or hidden bytes. Any string in the Registry has an associated length value. If this value happens to be larger than the actual length of the string, additional bytes can be stored after the end of the string. These bytes are normally not being displayed since they are located after a terminating zero, making it a so called embedded null. Most hidden bytes appear to be stored unintentionally, for example, file paths are sometimes stored with a length value of 260, though the real length of a given path can be much shorter. When a key- or value name contains an embedded null it becomes inaccessible, and hence can easily be detected. Natural targets for intentionally stored bytes are value data for strings having a fixed length, like Guids. Such value data can be viewed, or modified through Regedit by selecting ”Modify Binary Data..” instead of the usual ”Modify”. If the name of a Registry value has more than 255 characters, that value is possibly not being displayed by Regedit. Such values are therefore also included in the output list. This Regedit flaw was described by Franchuk 2005. | ||
|
Remove or Save Slack | ||
|
Slack means bytes that are not currently used by the structure. For example, if a Registry value gets deleted, it is not overwritten immediately, but just flagged as deleted, which is faster. It continues to contain the old value name until it's reused again by some other key or value. Remove Slack: This generates a copy of the registry file where all bytes not used by the current structure are overwritten with zero bytes. This can not repair a corrupt file. The user should check file integrity by testing if the hive can be loaded into the registry. Save Slack: This generates a copy of the registry file where the current registry contents is overwritten with zero bytes, or, with some other byte specified at Options. This is available in the full version. | ||
|
HKCU Pidls and BagMRU | ||
|
This retrieves information from Pidls found in HKCU. Pidls are general, variable-length structures that can be used to store, among others, file information like file names and modification dates. In the XP Registry, Pidls are used for the key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StreamMRU and on Vista for the sub keys LastVisitedPidlMRU, and OpenSavePidlMRU of HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32. In a split form, Pidls are also used for the sub keys Shell\BagMRU, and ShellNoRoam\BagMRU of HKCU\Software\Microsoft\Windows. When retrieving information from a Pidl the running system should correspond to the system that generated the Pidl. Some Pidls generated under Vista can possibly not be interpreted under XP, or, may have a different meaning. The registered version of RegdatXP can put together the split Pidls found in the BagMRU keys and save them to files. | ||
|
Security Records | ||
|
Permissions to registry keys are determined by security records where different keys may have the same security record. Each security record has a discretionary access-control list (DACL), and a system access-control list (SACL), where each list contains a number of Access Control Entries (ACEs.) Each ACE stores permissions for a unique SID along with a few flags indicating, for example, if the permissions are inherited to newly created sub keys. This has been documented in US Patent 6625603. Usually the allow/deny type ACEs make up the DACL, while the audit type ACEs are located in the SACL. RegdatXP can generate lists of all security records/ACEs of the opened files. It can display all ACEs for a specified SID. | ||
| Back | |