我认为静态链接(到 CRT，即 /MT编译器选项(在构建小工具时非常方便，这要归功于易于部署。(像Process Explorer这样的系统内部工具就是一个例子。
但是，有人让我注意到 CRT 使用了几种资源，这些资源可能会在插件架构(例如 shell 扩展(等上下文中耗尽：特别是，FLS 索引似乎是运行最快的索引，LoadLibrary()加载第 127 个 CRT 静态链接的 DLL 时可能会失败。
我已经构建了一些 shell 扩展，但我从未遇到过这个问题。
有没有人遇到过使用 CRT 静态链接的进程内 COM 服务器(如外壳扩展(的这种资源耗尽问题？
如果是这样，是否有"修复"(除了使用动态链接到CRT，不幸的是，这使部署复杂化，并且需要为VCRedist下载一些兆字节，而CRT静态链接的小东西只有几百千字节......
Hmya，这有点像担心您是否有良好的备份，以防流星撞击破坏机器。 你的 shell 扩展的用户不久前就会发现有些东西是错误的。 每次使用"文件 + 打开"对话框时，将 100+ DLL 注入到进程中并没有被忽视，该程序对世界已经死了 5 秒或更长时间。
所以要么他做点什么，用像SysInternals的AutoRuns这样的实用程序清理他的机器。 如果你的扩展足够有用，你将幸存下来。 或者用户不采取任何对策，并且很高兴有一个硬上限。 扩展将失败，但用户无法说出原因。 您可能会接到支持电话，您知道该怎么做。