一个晦涩难解的难题，但这绝对让我发疯：

我正在MOSS中创建自定义信息管理策略。我已经实现了IPolicyFeature，并且我的策略功能通过配置新的SPItemEventReceiver来愉快地注册自己。我的图书馆中的所有新项目都会按应有的方式触发事件，并且一切正常。

IPolicyFeature也有一个ProcessListItem方法，应该将策略追溯应用到库中已经存在的项目中(至少，只要它一直返回" true"，就应该这样做)。除非不是。它仅将策略应用于库中的第一项，我绝对不知道为什么。

它似乎并没有引发异常，它确实从处理第一个项目中返回了true，我想不出还要看什么。任何人？

编辑：下面的科里(Cory)的答案使我走上了正确的轨道。确实确实有其他失败-我没有发现什么，因为我的windbg-fu不是应该的，但是我怀疑这有点像"在迭代过程中修改集合"。我的代码是修改传递到ProcessListItem的SPListItem，然后在其上调用SystemUpdate。一旦我更改了代码，使其创建了自己的变量(指向完全相同的SPListItem)并使用了该变量，问题就消失了……

解决方案

回答

我只能想到几件事。首先，我们是否正在开发可以使用Visual Studio进行调试的工具箱？因此，只需逐步执行即可。

假设情况并非如此，我将在注册策略之前启动WinDBG并将其添加到进程中。启用首次机会异常，以便在发生异常时都将其中断。我们可以通过在被破坏时发出命令" sxe clr"来做到这一点。这是有关WinDBG的更多信息：

http://blogs.msdn.com/tess/archive/2008/06/05/setting-net-breakpoints-in-windbg-for-applications-that-c​​rash-on-startup.aspx

然后，我要做的是监视是否会引发First Chance异常，并执行！PrintException来查看发生了什么。我的猜测是，某个地方抛出了一个异常，导致该应用程序停止处理其他项目。

ProcessListItem的逻辑是什么样的？我们是否尝试过只做一次true来确保它能正常工作？

回答

那里有一些不错的主意，谢谢。 Visual Studio调试器没有显示异常(为了防万一，我将所有内容包装在try / catch块中)，但是我没有想到尝试使用Windbg ...