There is a very severe bug in VB whereby the compiler/linker emits multiple sections in the import table for a single imported dll. This happens if you use different casing for the same dll in multiple typelib module sections. In some cases, you end up in a situation where the functions in one section are improperly bound by the OS loader code and end up crashing badly. Most of the time is a sleeper bug, which makes it even more insidious. For example, if compiling on NT4 SP4 introduces the conflicting import entries, you don't see a crash until you move the executable to a Windows 2000 machine.

The CheckImportCasing.dll add-in does a quick scan of the import table after you build to make sure that you haven't introduced this bug. You will not see any UI unless a problem is detected, in which case you will receive a warning with the option of viewing the functions imported under each version of the Dll name. The subsequent form shows the function names and the type library module declarations that they might have come from. The function names you see are equivalent to the Alias clauses in VB, or the Dll Entry field in the type library editor. Since multiple functions can alias the same Dll function, you might see multiple type library possibilities listed for a single function.

This bug is much easier to hit with the type library editing tools than without, so you should leave this add-in loaded at all times. It registers with startup and command-line options so, after registration, you don't have to do anything--until the add-in catches a problem for you.

Note that the original VBoost type libraries hit these bug because VBoostTypes used 'kernel32.dll', while ThreadAPI used 'kernel32'. VB automatically tacked on .DLL in the import table, resulting in a conflict between 'kernel32.dll' and 'kernel32.DLL'. Also note that other common type libraries, like Bruce McKinney's Win.tlb that is mentioned on page 422, use all upper case Dll names. The latest VBoost type libraries have been changed to follow the upper case convention. It would be a good idea for you to do the same with yours. I'd recommend keeping this add-in loaded just in case. The import table check adds very little overhead unless it actually finds a conflict.

The Microsoft Knowledge Base describes this bug in article number Q281913. A patch is provided, but requires the correct VB service pack to be installed.