Monday 18 January 2010

SVS and Multi-String Registry Values

I have been told there is a problem with Symantec's SVS Virtualisation solution regarding registry entries in the "Virtual File System" incorrectly over-lapping with the native registry. And, I am not sure if this problem is specific to SVS or is a problem that all virtualization technologies experience.


This problematic situation occurs when an application contains an particular type of registry setting that contains lists of items or more importantly attempts to update an existing list of registry items on the native workstation  or server environment.

To quantify the problem, here is a brief description of the types of registry settings support by the Windows registry  that has been sourced from a Microsoft Support page;

Name
Data type
Description
Binary Value
REG_BINARY
Raw binary data. Most hardware component information is stored as binary data and is displayed in Registry Editor in hexadecimal format.
DWORD Value
REG_DWORD
Data represented by a number that is 4 bytes long (a 32-bit integer). Many parameters for device drivers and services are this type and are displayed in Registry Editor in binary, hexadecimal, or decimal format. Related values are DWORD_LITTLE_ENDIAN (least significant byte is at the lowest address) and REG_DWORD_BIG_ENDIAN (least significant byte is at the highest address).
Expandable String Value
REG_EXPAND_SZ
A variable-length data string. This data type includes variables that are resolved when a program or service uses the data.
Multi-String Value
REG_MULTI_SZ
A multiple string. Values that contain lists or multiple values in a form that people can read are generally this type. Entries are separated by spaces, commas, or other marks.
String Value
REG_SZ
A fixed-length text string.
Binary Value
REG_RESOURCE_LIST
A series of nested arrays that is designed to store a resource list that is used by a hardware device driver or one of the physical devices it controls. This data is detected and written in the \ResourceMap tree by the system and is displayed in Registry Editor in hexadecimal format as a Binary Value.
Binary Value
REG_RESOURCE_REQUIREMENTS_LIST
A series of nested arrays that is designed to store a device driver's list of possible hardware resources the driver or one of the physical devices it controls can use. The system writes a subset of this list in the \ResourceMap tree. This data is detected by the system and is displayed in Registry Editor in hexadecimal format as a Binary Value.
Binary Value
REG_FULL_RESOURCE_DESCRIPTOR
A series of nested arrays that is designed to store a resource list that is used by a physical hardware device. This data is detected and written in the \HardwareDescription tree by the system and is displayed in Registry Editor in hexadecimal format as a Binary Value.
None
REG_NONE
Data without any particular type. This data is written to the registry by the system or applications and is displayed in Registry Editor in hexadecimal format as a Binary Value
Link
REG_LINK
A Unicode string naming a symbolic link.
QWORD Value
REG_QWORD
Data represented by a number that is a 64-bit integer. This data is displayed in Registry Editor as a Binary Value and was introduced in Windows 2000.

The key issue here is the  REG_MULTI_SZ registry type.  If you are a native application that as part of the installation process add or edits  a list of registry entries in a registry key with type  REG_MULTI_SZ (Multi-String Values) then you will successfully add, edit or replace ONE particular application setting. 

If you are a virtualized application, the capture (or sequencing) process  will OVERWRITE  existing list  of registry settings with the REG_MULTI_SZ  type. This may cause application or worse, OS settings to be lost, read in the wrong order or read altogether incorrectly.

So, I have demonstrated this application compatibility issue with SVS, but not yet with Microsoft's APP-V product. The question, is this "REG Multi-String" edit/over-write issue systemic to all virtualization technologies.


References







1 comment:

Randy said...

Do you have more details about what one does to see this happen? I haven't seen this before.

Thanks,

Randy Cook
Symantec