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:
Do you have more details about what one does to see this happen? I haven't seen this before.
Thanks,
Randy Cook
Symantec
Post a Comment