Resource (e.g. FLS index) exhaustion with CRT-statically-linked COM InProc servers

Question

I think static-linking (to CRT, i.e. /MT compiler option) is very convenient when building small tools, thanks to easy deployment. (Sysinternals tools like Process Explorer are an example of that.)

However, someone made me note that the CRT uses several resources that might run out in contexts like plugin architectures (e.g. shell extensions): in particular, the FLS index seems to be the one that runs out quickest, and LoadLibrary() could fail when loading the 127th CRT-statically-linked DLL.

I've built some shell extensions, and I've never encountered this problem, though.

Has anyone ever experienced this resource exhaustion problem with CRT-statically-linked in-proc COM servers (like shell extensions)?

If so, is there a "fix" for that (other than using dynamic-linking to CRT, which unfortunately complicates deployment, and requires some megabytes download for VCRedist, when instead small stuff with CRT statically-linked is just a few hundreds kilobytes...).

Answer 1

Hmya, this is a bit like worrying if you have a good backup in case a meteor impact destroys the machine. The user of your shell extension would have figured out a while ago that something is a-miss. Getting 100+ DLLs injected into a process every time he uses the File + Open dialog does not go unobserved, that program is dead to the world for a good 5 seconds or more.

So either he does something about it and cleans up his machine with a utility like SysInternals' AutoRuns. You'll survive that if your extension is useful enough. Or the user takes no countermeasure and is happy that there's a hard upper limit. Your extension will fail but there's no way for the user to tell why. You might get a support call, you know what to do about it.