我们最近开始看到log4net.dll损坏的问题 - 具体来说，它是正确的大小，但包含所有零。这会导致BadImageFormatExceptions（最终包含在TypeInitializationExceptions中，因为我们倾向于在每个类中静态初始化我们的ILog实例）。这种情况偶尔发生，没有明显的模式。卸载并重新安装我们的应用程序似乎“修复”它，因为我们还没有（但）在同一台机器上看到过两次问题 - 但这可能只是巧合。
我们的应用程序包含一个Windows服务和一个“常规”Windows应用程序，它通过命名管道进行通信（没什么太不寻常的）。我们在常规应用程序中使用了log4net很长一段时间（在我加入项目之前），但最近才将log4net添加到服务中。我们在两个应用程序中使用相同的机制初始化它，特别是：
[assembly: log4net.Config.XmlConfigurator(Watch = true)]
我们通常在每个类中静态地实例化ILog实例，即：
private static readonly ILog _log = LogManager.GetLogger(typeof (SomeClass));
到目前为止，我们已经考虑过以下但没有任何确凿的证据可以让我们得出结论：
安装程序问题。我们使用的是非常标准的MSI安装程序，这个文件只是作为安装的一部分正常复制。它不是复制的第一个或最后一个文件。此外，我们已经看到至少一个实例，其中问题直到安装后一天左右才显现（而大多数事件发生在安装后不久或立即发生）。但是，我们最近清理了安装程序，因此有更改（不幸的是我无法详细说明它们，因为安装程序工作是由其他人完成的，MSI不是我非常熟悉的东西）
与防病毒软件的互动。我们在（4-5）上看到问题的所有机器都有相同的AV软件（Sophos），但在任何Sophos日志中都没有迹象表明log4net被标记或隔离。
与在Windows服务应用程序中使用log4net相关的内容。
正如你所看到的，我们有理由怀疑＃1和＃2，但尚未排除任何结果，并且几乎没有证据支持或反对＃3。由于这是我们在服务中使用log4net的第一个版本，显然我们现在看到DLL被破坏似乎很可疑 - 但是我们还使用了这个版本的早期迭代我们的dev，QA和beta测试人员在这个开始发生前几周，所以在变化的时间方面没有明显的相关性。
我们还尝试过自动化卸载/重新安装过程以反复运行，以查看是否可以解决任何问题（几千次安装后没有任何内容）。我们办公室里的所有用户都使用ProcMon，所以如果我们再次看到它，我们可以看到触摸文件的内容，但这意味着此时我们正在等待游戏。
关于我们如何更明确地统治我们可能的某些原因的想法，或者特别看到这个问题的人的任何信息，我们将不胜感激！
更新： 我们最近没有看到这个，尽管这可能至少部分归因于安装程序的使用率降低。但是，我们最近做出的一项重大更改是关闭了服务应用程序的发布者证据（请参阅此处：http://msdn.microsoft.com/en-us/library/bb629393%28v=VS.90%29.aspx）
我们进行了此更改（如上面链接建议的服务应用程序）以改善我们的启动时间，因为我们偶尔会看到服务超时并且无法启动。但是，由于我们进行了此更改，因此我们还没有看到log4net.dll损坏问题。是否有可能通过禁用此功能，我们绕过某种可能会破坏log4net.dll（这是一个强名称程序集）的操作？我们不想假设我们已经解决了这个问题只是因为我们没有在几周内看到它，因为我们没有任何确凿的证据，因此它可能只是巧合
再一次，任何想法都会非常感激。