我正在尝试使用远程性能监视器在 Compact Framework 应用程序中查找内存泄漏的来源。我设法删除了一些与画笔和其他图形对象相关的小问题，但我仍然不清楚是什么导致了主要问题。
在这一点上，唯一似乎永远不会回到原始计数的对象是 System.String 对象。我觉得这很奇怪，因为我认为为了使这些对象保持未被收集，包含它们的对象也必须保留，但似乎没有其他类型的对象随着系统.字符串。
我试图找出哪些新字符串对象是应用程序返回其原始状态（即登录屏幕）后保留的对象。问题是，最初，应用程序加载了大约 2200 个字符串对象，然后在进程“X”之后又增加了 70 个左右，这些对象永远不会被收集。我不知道如何识别这 70 个新对象，以便找出谁在持有它们并进行适当的更正。
有没有人有没有收集字符串的经验？有什么方法可以将在进程“X”期间创建的新对象与应用程序最初需要的对象分开，以便我可以知道哪些正在泄漏？任何意见，将不胜感激。
谢谢
**更新
好的...发生了一些非常奇怪的事情。我开始怀疑是否有泄漏。
假设我在登录屏幕上拍摄内存快照，这是应用程序的原始起点。假设此时内存中有 1000 个字符串对象。现在，如果我登录并从菜单中选择一个选项，我将在新屏幕加载后拍摄快照。假设加载此表单会使字符串计数增加 50 个对象。当我注销并在登录屏幕上再次拍摄快照时，仅收集了其中的 25 个对象，其余的将从那时起保留在内存中。
奇怪的是，如果我继续重复这个过程，就不会再积累更多的字符串对象了。此时字符串数不会增加 50，而是仅添加 25 个，并且一旦我返回登录屏幕，将收集相同的 25 个。我在想，如果这是一个真正的泄漏，那么每次我打开那个屏幕时，字符串数都会永久增加 25，但这只是第一次发生。
在我打开的每个新屏幕上都会发生这种情况。起初，总的字符串数会持续小幅增加，但是一旦我加载了该特定屏幕，一旦我返回登录屏幕，就会收集执行期间字符串数的任何增加。
所有这一切让我相信，也许这些字符串是 CLR 内部工作的一部分或类似的东西。它可能是运行时完成的某种缓存吗？也许它正在存储我的字符串常量以加快加载速度？类似的东西？我希望这不会太混乱。