Click here to Skip to main content
13,146,934 members (61,345 online)
Click here to Skip to main content


72 bookmarked
Posted 26 Oct 2002

Import/Export registry sections as XML

, 21 Jan 2003
Export registry sections as XML to simplify registry diffs
DISCLAIMER: This document is provided "as is", without any guarantee whatsoever towards functionality, correctness, ability to increase your monthly income, or make the world a better place. Thank you.
COPYRIGHT NOTICE: This sentence informs you of the absence of any copyright on this document, allowing you to do almost anything with it. Printing it and using the hardcopy to make paper planes is, however, expressly prohibited. Thank you.
COPYRIGHT NOTICE (cont'd.): Although using the hardcopy for other artistic purposes is allowed. Thank you.

Update History

The last update was on Tuesday, August 7th, 2000. Deletion of keys and values (courtesy of Stephan Meyer) and more RegEdit bugs found out by myself - the hard way, unfortunately.

The previous update was on Thursday, January 22th, 1998. I added some information for binary values and corrected some mistakes and omissions pointed out by Per Mellstrand (thanks for that). I've also added a special remark for Martin Friemann :-) and somewhat expanded my knowledge on RegEdit for Windows 3.x.

The initial version of this document was written on Friday, October 10th, 1997, by me, Jeroen Mostert. You can reach me by mailing to

The .REG file format

1 Introduction 
The .REG file format is used by RegEdit, the program supplied with Windows 3.x, Windows 95/98, and Windows NT, to import and export settings from the registry. Note that I will not explain what the registry is, how it works, or what it can be used for. There are other documents describing the registry and it's most interesting parts all over the 'net - check out some of the links at the end of this document. 

Also, I will not provide you with information on RegEdit for Windows 3.x. I know that it exists, but it differs significantly from the 'new' RegEdit - the information in this document does not apply to it. Besides, the registry was much less interesting on Windows 3.x - it was only used as an OLE registration database, and rarely required user editing (die hard Windows 3.x fans will excuse me for speaking about it in the past tense).

Finally, most information contained in this document has been verified using my installation of Windows (that is, Windows 98 First Edition). Other versions of Windows may have different RegEdit's, and information on bugs and other strange behavior may subsequently be inappropriate. As it goes, 'your mileage may vary'.

2 Description 
The file is formatted as plain ASCII text. Every line is ended with a CR/LF combination. That means every line - including the last one.

2.1 Header 
It starts with REGEDITx, where x is RegEdit's version number - so far, on 95/98/NT/2000, it's 4, making the string REGEDIT4.

This is also the only part of the file actually checked by RegEdit when it's importing - if the file contains any formatting errors, RegEdit will not notify you and simply skip the settings that contain errors.

In particular, RegEdit will pretty much accept anything as long as it starts with REGEDITx, and ignore anything erroneous. Yes, that does add up to the Microsoft Stupid Mistakes list. I guess they're just protecting the poor luser from that oh so complicated registry.

2.2 Keys 
Key names are exported as they are encountered, but need not be in any order. Subkeys are explicitly named. For example, if you had the key HKEY_CLASSES_ROOT\CLSID and it's subkey HKEY_CLASSES_ROOT\CLSID\{21EC2020-3AEA-1069-A2DD-08002B30309D} (which represents the ClassID of the Control Panel, by the way), they would be exported as:



For a key name to be valid, it must start with one of the root key names: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS, HKEY_CURRENT_CONFIG and HKEY_DYN_DATA.

A key name may only contain printable ASCII characters (that is, characters with values from 32 through 127) and may not contain spaces, backslashes \ or the wildcards * and ?. Note that you can create keys containing an illegal character, but Microsoft's documentation specifies that you should not use them. If you're wise, you'll stick to the rules and won't get hurt later.

Every key name is followed by it's values, starting on the line directly following it. The list of values is terminated with an empty line, and may be empty itself.

For example: 




If a key is specified which does not exist, it is created, along with any parent keys that do not exist. For example, if the key HKEY_USERS\Jeroen\Test\Subkey is specified, and only the key HKEY_USERS\Jeroen exists, the key HKEY_USERS\Jeroen\Test is also created.

Note that it IS possible to delete keys. To delete a key, specify it as before, but use a minus (-) before it's name, like this:


This will delete the key and all it's subkeys. Note that this syntax makes it impossible to create keys that start with a minus or to export and import them successfully.

2.3 Values 
There are three kinds of values in the registry: strings, binary values, and DWORDS. They represent a collection of characters, a collection of bytes, and a 32-bit integer, respectively.

Values consist of a name, enclosed in quotes "", followed by an equal sign = , followed by the value contents.

Every key, even if created empty, contains at least one string value - this is the value shown as (Default) in RegEdit. To set it's value, use @ as the value name, and omit the usual quotes around the value name.

Example: @="This is the default value."

Values can be deleted by specifying an unquoted minus (-) as the value contents. Note that specifying "" does not delete a value - it simply sets it to the empty string. Finally, note that the default value cannot be deleted - at least not with this syntax.

@=- 		[ Default value is *not* removed ]
@=""		[ Default value is set to the empty string ]
"Test"=-	[ Value 'Test' is removed ]
"Test"="-"	[ Value 'Test' is set to a minus character ]

2.3.1 Strings 
Strings are represented within quotes "", and contain normal ASCII characters. They may be any size, although the RegEdit used on Windows 95/NT cannot import strings longer than about 200 characters. Beware of this serious bug, as RegEdit will corrupt keys rather than ignore the string! The newer versions of RegEdit that come with Windows 98 and Windows NT 5.0... whoops, I mean Windows 2000, have this bug corrected and can handle strings of any size.

The quote " and backslash \ are also allowed in strings - however, they must be represented as \" and \\, respectively. Also, RegEdit can import and export all characters except for linefeed (or newline, ASCII code 10). Should a linefeed end up in a string, RegEdit will export this as a real newline, splitting the string in two lines. When reimporting this string, RegEdit will only read the first line. The moral of the story: don't store linefeeds in strings.

Examples of strings: 

2.3.2 Binary values 
Binary values are used where strings and DWORDs fail. They can be used to represent any type of data. They are represented as hex:xx,yy,zz,... where xx,yy and zz are hexadecimal representations of single bytes. They may be any length.

Lengthy binary values can be divided into multiple lines using the C line separator \. For example: "Bar"=hex:48,00,00,00,01,00,00,00,0a,00,0a,00,0a,00,0a,00,0a,00,0a,00,0a,\ 

Also take note that this is only allowed with binary values. In particular, you cannot divide strings this way. And yes, this IS pretty stupid.

Although I usually ignore Microsoft, they recommend you shouldn't store more than around two kilobytes of binary data at most, and I agree with them for once. The registry is big enough without you putting your picture collection in it :-)

Example of binary values: 
"Foo"=hex:aa,de,ca,de,0f,ca,fe,ba,be Types of binary values 
Along with 'regular' binary values, there are also some special types of data which RegEdit represents as special binary values, like this:


where type is a number ranging from zero to ten in the current versions of Windows, as follows:

Type        Name 
0           REG_NONE 
1           REG_SZ 
2           REG_EXPAND_SZ 
3           REG_BINARY 
6           REG_LINK 
7           REG_MULTI_SZ 
8           REG_RESOURCE_LIST 
REG_NONE means 'no defined value type'. No, I don't know what it's good for - REG_BINARY is already a catch-all type for everything that has no type. Perhaps it's used for values that have no contents, although I can't imagine what THAT would be good for. REG_SZ 
A null-terminated string. This is the same as the string type, represented as bytes. For example, these definitions are equal:

"BarFoo"=hex(1):41,42,43,44,00 and "BarFoo"="ABCD"

See also 2.3.1, Strings. Note that you cannot get around the 200-or-so character limit in the older versions of RegEdit by using this syntax. REG_EXPAND_SZ 
A null-terminated string that contains unexpanded references to environment variables. When an application reads this string from the registry, it can let Windows replace the references with the environment variable value.

For example, the following value


represents the string "%PATH%;Something". When this string is read, the "%PATH%" section can be replaced with the contents of your PATH variable. REG_DWORD, REG_DWORD_LITTLE_ENDIAN 
Represents a little-endian DWORD (the common format of Windows DWORDS). In little-endian format, the most significant byte of a word is the high-order byte. See also 2.3.3, DWORDS. REG_DWORD_BIG_ENDIAN 
Represents a big-endian DWORD (used on Macintoshes, for example). As you can probably guess, in big-endian format, the most significant byte of a word is the low-order byte. REG_LINK 
Represents a Unicode symbolic link. Windows isn't Unix, though, where the concept of a symbolic link is actually *used*, and I have no idea what its purpose in Windows is. I probably don't want to know either. REG_MULTI_SZ 
A collection of null-terminated strings, null-terminated. For example:


Represents two strings: "ABCD" and "EFGH". REG_RESOURCE_LIST
A device driver resource list. Another one in the category "don't know and don't want to know." REG_FULL_RESOURCE_DESCRIPTOR 
Undocumented. It's probably meant for Windows itself only, as device driver stuff. REG_RESOURCE_REQUIREMENTS_LIST 
Undocumented. It's probably meant for Windows itself only, as device driver stuff.

2.3.3. DWORDs 
DWORDs are 32-bit integers represented as dword:xxxxxxxx, where x is a hexadecimal digit. They're pretty boring, as that's all I can tell about them.

Example of DWORD values: 


3. The End 
That's about it - the .REG format is pretty simple, but it works. RegEdit does a less than adequate job reading and writing these files properly. Be careful with what you export. In particular, I strongly recommend against using RegEdit to export the entire registry for backup purposes - chances are, you'll never get your precious keys back the way they were. The newer RegEdit supplied with Windows 98 and Windows 2000 seems a lot more reliable, but you're still better off just copying the appropriate .DAT files.

Should you find any unclarities, mistakes or things you think are missing, contact me by emailing to "".

4. Well, Almost, We Still Need The Links 
Oh yeah, here are the links I promised, listed in no particular order. They were all valid on August 7th, 2000.

This is the registry section of If you already know, you won't need any more introduction. Otherwise, I suggest you visit as well and check out this large site, which offers information and links on just about everything.

This is Amazons home page, "Earth's Biggest Bookstore". Try their search function to search for "windows registry" - this will provide you with more than enough literary references. No online information, however.

This is the tips section of Although it doesn't contain just registry tips, it's really worth checking out. But then again, all of is worth checking out. If you have Windows, be sure to visit it. OK, I'll admit I only added this one because I'm promoting Got a problem with that?

By viewing downloads associated with this article you agree to the Terms of Service and the article's licence.

If a file you wish to view isn't highlighted, and is a text file (not binary), please let us know and we'll add colourisation support for it.


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Addicted to reverse engineering. At work, I am developing business intelligence software in a team of smart people (independent software vendor).

Need a fast Excel generation component? Try xlsgen.

You may also be interested in...

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.170915.1 | Last Updated 22 Jan 2003
Article Copyright 2002 by Stephane Rodriguez.
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid