BUG: Type Library Corruption If It Has More Than 256 TypeInfos

• Microsoft OLE libraries included with:

      - Microsoft Windows NT version 3.51
      - Microsoft Windows 95
  

SYPTOMS

When a type library with more that 256 typeinfos is generated by using mktyplib or ICreateTypeLib/ICreateTypeInfo, a corrupt type library may be produced. This will usually happen on a fast computer like a Pentium when the type library is being saved to a fast storage medium like a local hard drive. It may not happen on a slower computer like a 486 or when the type library is saved to a slower storage medium like a floppy disk drive or a network drive.

CAUSE

A byte counter is used by OLE as part of a timestamp for each typeinfo that is written into the type library. If the type library generator is running on a fast computer and there are more than 256 typeinfos in the type library, more than 256 typeinfos could be written per second. This causes the counter to repeat itself, which causes the corruption.

ICreateTypeLib::SaveAllChanges will not return a faliure SCODE when this coruption occurs. A slower computer or a slower storage medium reduces the number of typeinfos written to 256 or less per second, so the problem is avoided.

WORKAROUND

A workaround to this problem is to limit the number of typeinfos in each type library to 256 or less. If a type library requires more typeinfos, it can create those typeinfos in other type libraries and reference those type libraries using the importlib directive.

Delaying the output using the Sleep() function in a type library generator that uses ICreateTypeLib/ICreateTypeInfo will not fix this problem because all the typeinfos are written when ICreateTypeLib::SaveAllChanges is called.

STATUS

Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.