所以我正在尝试向我的鞋面演示该产品包含内存泄漏。但是，运行一个接触COM对象的脚本大约需要2个小时才能复制到OutOfMemoryException。为了使这个显而易见，我需要一个基线数据来表明它不是我的脚本本身导致内存问题，以及数据显示行为确实重复了内存泄漏。
我计划通过定期报告总计内存使用情况来进行日志文件。例如，在此框中我是我的Windows任务管理器 - ＆gt;性能选项卡显示我目前在2.00GB中使用1.67GB。这是我需要定期进入我的代码并在日志文件中转储的数字。
只有一个问题......我如何获得这条信息？
感谢您提供的任何帮助，即使告诉我这是不可能的：P。
UPDATE ：感谢有关COM内存问题的信息，但我所说的“基线”也以有效相同的方式触及COM对象，并且不会导致内存问题。特定行为的大小。只有我提出的问题的答案对我有帮助。
答案 0 :(得分：1)
更新，在回答OP的问题时，类System.GC有一种估算正在使用的内存量的方法：
System.GC.GetTotalMemory(false)
如果您在长时间运行的进程中使用COM（即没有空闲时间），那么将遇到内存泄漏，除非您定期致电：
Thread.CurrentThread.Join(100);
100当然可以改变，但是你的活动线程会在恢复之前“休眠”多长时间。来自文档：
阻塞调用线程，直到线程终止或指定的时间过去，同时继续执行标准COM和SendMessage抽取。
这是关键的最后一个条款。
参考：http://support.microsoft.com/kb/828988
如果基于单线程单元（STA）的控制台应用程序创建然后使用STA组件对象模型（COM）组件，并且控制台应用程序未执行足够的操作来泵送COM消息，例如调用监视器.Enter方法，Thread.Join方法等，可能会出现以下症状。此外，如果控制台应用程序执行长时间运行且不提取消息的操作（例如调用Console.ReadLine方法），则可能会出现以下症状：
- 可能会延迟COM组件的发布。
- 可能会延迟对垃圾收集器收集的对象的Finalize方法的调用。
- 对COM组件的调用可能会长时间阻止应用程序线程。 STA应用程序进程使用的内存量可能会随着时间的推移而增加。
- 调用GC.WaitForPendingFinalizers方法可能需要很长时间才能返回。