对于那些感兴趣的人，以下是我对这个问题的发现的更新:

For those interested, here is an update of what I found out with regards to this problem:

看来，***的解决方案是对我们的数据块进行池化以减轻垃圾收集器的压力，所以我做到了.

It appeared that the best solution was to implement pooling of our chunks to relieve pressure on the garbage collector, so I did this.

结果是该加载项的工作稍有增加，但不幸的是，它仍然很快耗尽了内存.

The result was that the add-in got slightly further in its task, but unfortunately it still ran out of memory fairly quickly.

再次查看WinDbg，我能看到的唯一真正的区别是，我们合并的托管堆大小一直较小，大约为200MB，而池化之前为大约250MB.

Looking in WinDbg again, the only real difference I could see was that our combined managed heap size was consistently smaller, at around 200MB compared to around 250MB before pooling.

.NET可用的内存量几乎随着时间的推移而减少，因此实现池化只是延迟了内存用尽.

It was almost as if the amount of memory available to .NET was decreasing over time, and so implementing the pooling had simply delayed running out of memory.

如果这是真的，那么明显的罪魁祸首是一个COM组件，我们使用该组件将数据加载到内存中.我们对COM对象进行了一些缓存，以改善对数据的重复访问时间.我删除了所有缓存，并确保在每次查询数据后都释放所有内容.

If this was true the obvious culprit was a COM component which we use to load the data into memory. We do some caching of COM objects to improve repeated access time to the data. I removed all the caching and ensured everything was released after every query of the data.

现在关于内存的一切看起来都不错，但是速度要慢得多(接下来我将要解决).

Now everything looks fine with regards to memory, it is just much slower (which I will have to solve next).

事后看来，我猜想COM组件应该是内存问题的第一个可疑对象，但是我从中学到了一点:)而且，从另一方面来说，池化对于减少GC开销仍然很有用，所以值得这样做也是

I guess in hindsight the COM component should have been the first suspect for the memory issues, but hey I learned something :) And on the plus side, the pooling will still be useful to decrease GC overhead, so that was worth doing as well.

谢谢大家的评论.