IShellItemImageFactory :: GetImage卡在多线程环境中

Question

我为多个后台线程中的文件夹中的每个项启动IShellItemImageFactory :: GetImage方法。代码看起来像这样：

HRESULT GetImage(IShellItemImageFactory* pImgFactory,
                 SIZE Size, COLORREF BkColor, HBITMAP *phbm)
{
    if (pImgFactory == 0 || phbm == 0)
        return E_POINTER;
    *phbm = 0;

    HBITMAP hBmp = 0;
    HRESULT hr = pImgFactory->GetImage(Size, SIIGBF_BIGGERSIZEOK, &hBmp);
    if (SUCCEEDED(hr) && hBmp)
    {
        *phbm = CPicture::StretchBitmap(hBmp, Size, BkColor);
    }

    return hr;
}

有时我会将所有16个线程卡在pImgFactory-＆gt; GetImage中，用于不同的项目。它们都卡在同一个地方，可以在提供的堆栈中看到。我检查了不同的线程处理不同的项目。造成这种奇怪现象的原因是什么？ 编辑： 在David Heffernan的回复之后，我意识到IShellItemImageFactory接口本身可能不是线程安全的。我们的线程子系统自动将每个线程初始化为STA（通过调用CoInitialize（0）函数）。但可能是，对于IShellItemImageFactory我需要MTA线程。有没有办法发现IShellItemImageFactory的coclass CLSID，以便在Registry中找到它的线程要求？

EDIT2： 可能，我们的线程机制以某种方式与问题相关。在这个特定情况下，我们使用一个名为“Job Queue”的引擎。它是非阻塞FIFO队列，其中的元素描述了一个作业。该描述包含作业算法和作业数据的指针。通常（但不是必需）主线程将作业放入队列。来自线程池的空闲线程可以从队列中获取元素并执行该作业。这个机制已经好几年了。但可能是，它以某种方式影响图标提取。可能是，我在定义图标提取算法和数据方面不够精确。我不知道如何确定它。

Answer 1

这种现象并非真正的僵局。在提取文件夹中的子文件夹图像时会发生这种情况，该文件夹尚未被Windows缓存。假设存在具有20个子文件夹F1，F2，...，F20的文件夹F，每个子文件夹包含20多个其他子文件夹和文件。如果未缓存文件夹F，则提取其子文件夹的20个图像可能需要15 - 25分钟（在我的Win10 8核计算机上）。在一次提取所有图像之后，快速执行对该文件夹F中的图像的重复请求。