要解决太多静态链接的CRT的fls限制? [英] Working around fls limitations with too many statically linked CRTs?

问题描述

通过LoadLibrary加载外部DLL(不受我们控制)时，我们遇到了一个问题，即这些DLL中的静态链接CRT无法分配光纤本地存储.这类似于 mskb 193462 ，除了这是FLS，而且只有128个.

When loading external DLLs (not under our control) via LoadLibrary, we're hitting a problem where the statically linked CRT in those DLLs are failing to allocate fiber-local storage. This is similar to mskb 193462, except that this is FLS and there's only 128 of them.

是否有解决此问题的有用方法? CRT仍在使用GetProcAddress查找FlsAlloc(因为XP似乎根本不存在它)，所以它真的需要吗?

Are there any useful ways to work around the problem? The CRT is using GetProcAddress to find FlsAlloc anyway (since that apparently never existed in XP), so does it even really need it?

(这是在Vista中，实际上存在FlsAlloc； DLL似乎正在使用MSVC8)

(This is on Vista, where FlsAlloc actually exists; the DLLs appear to be using MSVC8)

推荐答案

坦率地说，这里没有解决方案，只能加载较少的dll.

There is frankly no solution here, short of loading less dlls.

您可以挂钩dll的导入地址表-但这将为时已晚，因为只有在LoadLibrary返回时才可以安装IAT挂钩，并且CRT初始化代码可能会响应已处理的DllProcessAttach而执行.

You could hook the dll's import address table - but that will happen too late as you can only install an IAT hook when LoadLibrary returns, and the CRT initialization code probably executes in response to DllProcessAttach which will already have been processed.

您可能会在内存中找到kernel32.dll模块，并修补GetProcAddress或FlsAlloc的导出地址以指向您的实现.但是这种方法正变得越来越骇人听闻.

You could I guess find the kernel32.dll module in memory, and patch the export address for GetProcAddress or perhaps FlsAlloc to point to your implementation. But that approach is getting seriously hackish.

这篇关于要解决太多静态链接的CRT的fls限制?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！