TAG

In the context of working with Shim Database (SDB) files, a TAG is Microsoft’s name for the first 16 bits of any one item in the file. Each item comprises the TAG, an optional size of data to follow, and then this amount of data. The high 4 bits of the TAG give its type. For some types, the size of data is implied by the type, such that the TAG is followed immediately by the implied amount of data. For others, the size is explicitly a dword immediately after the TAG and thus before the data.

Formally, a TAG is just a USHORT. What matters are the numerous possible values and the APPHELP versions for which these values are expected—and, from there, what any of them mean to whoever acts on them. This last part is not obviously well-defined, there being potentially many modules that interpret SDB files for potentially many different purposes. For the tables that follow, a TAG is regarded as defined for some APPHELP version if that version’s implementation of the SdbTagToString function produces a non-trivial string that doesn’t dismiss the tag as invalid. Version 1.0 refers to the SDBAPIU.DLL from Windows 2000 SP3 and SP4, which is the first known support for SDB files and is here taken as an APPHELP precursor.

For all the possible TAG values that were defined in this sense for Windows Vista, the symbolic names that Microsoft uses in its programming are known from contemporaneous documentation of the TAG. For all these values, what Microsoft documents as the programmatic name is TAG_name, where name is the tag-to-string conversion by the Windows Vista implementation of SdbTagToString. Extrapolation of this correspondence to later versions gives at least a reasonable guess at Microsoft’s names for the many values that Microsoft has since defined but not documented. Be aware, though, that this relationship is inferred by observation, not deduced by inspection. It cannot have been true before version 6.0 since in these earlier versions some tag-to-string conversions contain spaces or other characters that are invalid in C-language identifiers. The view taken here is that the symbolic name that Microsoft documented for version 6.0 was the symbolic name all along and that the tag-to-string conversions were changed for version 6.0 as deliberate tidying up. These cases are noted in the Remarks column.

As a quirk of version 6.2, the tables show two very different symbolic names as valid in that version for each of the three tags 0x4034, 0x6025 and 0x7020. This is because the table that the SdbTagToString implementation works from has two entries for each of these tags. Though the function can return a name only from one entry for each tag, it seems that both names are meaningful. Whether their assignment to the same numerical value was by design or oversight is not known, and they anyway get disambiguated in version 6.3.

Beware that this article’s measure of a tag’s validity in any version cannot be definitive. That a tag gets converted by the SdbTagToString function in some APPHELP version does not mean the tag actually does get used in that version, of APPHELP or of anything else from the same Windows version, though at least in such a case the tag evidently is defined. More difficult for enumerating the defined values is that a tag could be meaningful, even to APPHELP, yet somehow have got missed when preparing APPHELP’s tag-to-string conversions. Tracking down all cases would be impractical if not impossible, but one case is known. Though tag 0x4029 does not get a tag-to-string conversion from APPHELP until Windows 7, the APPHELP from Windows Vista knows it for other purposes, e.g., for its implementation of SdbReadApphelpDetailsData.

If tags 0x4028 and 0x4029 actually were defined for Windows Vista without having tag-to-string conversions, then Microsoft documented all the values that were defined for Windows Vista but has documented absolutely none that have been added since. Whether the reason that Microsoft ever documented any of the tags (or functions that work with them) truly did go away after Windows Vista is not known. Indeed, no reason is yet clear that Microsoft ever documented any values at all, even just for Windows Vista. It does seem fair to say, however, that Microsoft’s documentation was at best half-hearted, if not grudging. Conspicuously, the documentation’s definitions are not reproduced in any header from any known development kit. As usual at this website, the undocumented values are highlighted yellow.

NULL Tags

Tags whose high 4 bits are 0 are followed by no data. In effect, they are boolean, with nothing to say beyond being present or absent.

See that two of these NULL tags change for Windows 8 from one extreme to the other, i.e., from carrying no data to having so many attributes, potentially, that they are made into List tags instead. Meanwhile, their old numerical values are reused, with completely different interpretations. It is not known whether these (and similar) redefinitions have caused any real-world problem from having the APPHELP from one Windows version read an SDB file that was prepared for a different Windows version. Though such mixing may be rare in whatever real-world practice Microsoft intends, defence against it certainly is not reliable. For instance, in advancing from Windows 7 to Windows 8, the implementation of the exported SdbQueryBlockUpgrade function simply changes from looking for TAG_BLOCK_UPGRADE as the NULL tag 0x1007 to looking for it as the List tag 0x7029.

BYTE Tags

Tags whose high 4 bits are 2 introduce one byte of data—and, in a database whose major version is 2 or higher, a byte of padding so that whatever tag follows is word-aligned. However, no BYTE tags are known to be defined.

WORD Tags

Tags whose high 4 bits are 3 introduce one 2-byte word of data.

WORD tags have always had a second series in which the low 12 bits restart at 0x0801:

It seems to be merely conventional that the tags in such second series have special meaning to the large-scale structure of an SDB file and are plausibly the tags that are generated automatically when compiling an SDB file from XML input.

DWORD Tags

Tags whose high 4 bits are 4 introduce one 4-byte dword of data. Very many such tags are defined.

DWORD tags also have a second series:

QWORD Tags

Tags whose high 4 bits are 5 introduce one 8-byte qword of data.

String Reference Tags

Tags whose high 4 bits are 6 are followed by 4-byte dword of data that has a very particular interpretation as referring to a string in the database’s string table. Specifically, the dword is the offset, in bytes, from the beginning of the string table (tag 0x7801) to a string item (tag 0x8801).

List Tags

Tags whose high 4 bits are 7 are followed by a 4-byte dword and some variable amount of data. The dword is the size, in bytes, of the data. In turn, the data is a list of child tags.

This sequence has gaps at 0x701B and 0x701D. It may be that these were planned to be TAG_KDEVICE_WILD and TAG_KDRIVER_WILD, which are known from error messages in the Compatibility Administrator, compatadmin.exe.

List tags have a second series:

String Tags

Tags whose high 4 bits are 8 are followed by a 4-byte dword and some variable amount of data. The dword gives the size, in bytes, of the data. In turn, the data is a null-terminated Unicode string.

Binary Tags

Tags whose high 4 bits are 9 are followed by a 4-byte dword and some variable amount of data—and, in a database whose major version is 2 or higher, a byte of padding so that whatever tag follows is word-aligned. The dword gives the size, in bytes, of the data.

Binary tags have a second series: