问题标签 [domainunload]

如何发现哪些软件触发了 AppDomain.CurrentDomain.DomainUnload？我有一个在 IIS 8 上运行长时间任务的应用程序，我怀疑某些软件通过更改文件权限来触发上述事件。没有安装杀毒软件。但我们有 Nagios Client、New Relic 和 OCS（库存软件）。

我不明白为什么在我执行 AppDomain.Unload 后我的 DLL 仍然在程序的内存中。我可以做错事吗？

PS 我如何理解DLL保留在内存中？NETUnpack 告诉我。

我一直在使用 System.Runtime.Caching.MemoryCache 并且在处理监视器方面遇到了一些麻烦。所以一点上下文，我正在尝试实现一个缓存，其中项目通过使用基于 PubSub 架构的自定义ChangeMonitor（不，我不想使用）因文件更改而失效。HostFileChangeMonitor

我在 MemoryCache 上有 2 种类型的插入：

• 一次插入，应该在监视器更改或到期时删除：

  /li>

• 万岁插入，应该在监视器更改或到期时重新添加：

  /li>

这里是实现EncapsulateListenerCallback：

还有PubSubMonitor：

ISubscription对象将调用在OnMessage事件上注册的回调以通知更改。

我对这个实现的问题是，有时，当我的应用程序正在卸载时，这个堆栈System.NullReferenceException会抛出一个：MemoryCache

从我能够使用 DotPeek 进行故障排除的是，即使 MemoryCache 对象已经被释放，我的订阅也会引发 OnMessage。该订阅在处置时停止引发事件（通过处置和禁用引发事件 on FileSystemWatcher），并且我在更新和删除回调时执行处置。

添加了那些lockonPubSub监视器以保证我们在base.OnChange().

所有项目都从缓存中删除，并且它们的监视器被释放（从我能够分析的文档和源代码中），但不知何故有监视器没有被释放，或者某些缓存项目UpdateCallback/RemoveCallback没有被调用，因为文件更改事件仍在引发.

谢谢大家

我仍在尝试了解持续存在的问题，但它几乎可以概括为无法卸载 AppDomain。

它发生在将 ASP.NET WebAPI 部署到 Azure App Service 的过程中，我们观察到以下情况：

1. 进程 ID 不变，新部署托管在同一个进程中（AFAIU 是通过卸载旧 AppDomain 并使用更新的二进制文件启动新 AppDomain 来完成的）
2. Azure PaaS 诊断在错误部分显示以下内容：

“在 w3wp_12396.dmp 中，应用程序 /LM/W3SVC/1523308129/ROOT 的 HttpRuntime 正在关闭中。”

2. 分析内存转储，我们看到设置了IsAbortRequested标志的线程，但它们似乎从未完成（!threads此处 WinDbg 的输出：https ://pastebin.com/7CXYcffy ）

3. 在内存转储中，我们还看到很多带有“ UNLOAD_REQUESTED ”阶段的 AppDomain，它们似乎从未完成卸载（完整输出在!DumpDomain这里：https ://pastebin.com/kahZQuWN ）

4. 未检测到死锁!dlk（至少通过 WinDbg SOSEX 插件的命令，通常涵盖大多数死锁情况）

5. 没有代码取消线程中止（没有Thread.ResetAbort()调用）

我们现在可以解决问题的唯一方法是终止进程（停止 Azure AppService）。

AppDomain 无法卸载的可能原因有哪些？

更新。在线程堆栈中，我们得到一个提示，它可能与我们的自定义 Azure Blob Log4net 附加程序有关，我发现当创建此类附加程序时（每个应用程序一次），它会产生具有以下结构的新线程。

不确定我是否理解为什么它会导致完全无法停止的线程（因为ThreadAbortException不会被 catch 停止），但它看起来像改变while (true)以while (!Environment.HasShutdownStarted && !_stopping)解决问题（在调用_stoppingAppender 时设置，OnClose这是 log4net 的一种优雅关闭）......

我在这里写的是在 Github 上发布的同一个问题，因为我最近在那里没有看到太多的流量。

• .NET Core 版本：3.1.9 和 .Net 5
• Windows 版本：10.0.18363
• 该错误是否也在 .NET Framework 4.8 的 WPF 中重现？：不支持 AssemblyLoadContext

我正在尝试按需加载和卸载 Wpf App 库（以及所有相关的依赖项）。一切正常，但在调用 Unload 方法时没有任何程序集被卸载。如果我用包含一些示例方法的 .Net Core 库替换 Wpf 库，我可以看到在几次 GC 迭代后从 VS Modules 窗口中删除了该库。

如果我没记错的话，我应该期望 AssemblyLoadContext 加载 WpfLibrary 和相关依赖项（PresentationCore、PresentationFramework 等），但 WpfLibrary 是唯一加载的。所有其他依赖项似乎都加载到默认上下文中。可能是我误解了它是如何工作的，但在我看来，框架依赖项阻止了卸载。

此外，我不确定我报告的问题是否与this和/或this相关。

我附上了一个结构如下的示例项目：

项目 1（MainApp，一个添加了 System.Windows.Forms 引用以启用消息泵的控制台项目）

项目 2（代理接口）

项目 3（在项目 2 中实现接口的常规 wpf 库）

UnloadWpfLibrary.zip （“MainApp”文件夹内的解决方案文件）

进一步更新： DotNet 团队将该问题添加到“未来里程碑”中，因此我必须推断他们认为这是一个错误。我不知道我们什么时候会看到 Wpf 与 AssemblyLoadContext 一起工作。似乎有一种解决方法涉及将目标程序集拆分为两个单独的程序集。我附加了带有建议修改的项目，这次卸载了两个程序集之一，但所有其他程序集仍被加载，包括 WpfLibrary。

UnloadWpfLibraryWithWorkaround.zip

我认为对我来说是时候放弃并重新使用 IPC（命名管道）了，尽管我不确定这是否可以成为有效的替代品。可能是我遗漏了一些东西，而更专业的人可以做进一步的进展，并在此处附上正确修改的项目，这对所有想要使用 ALC 加载和卸载 WPF 的用户都有很大的好处。仅按需加载和卸载 wpf 程序集将总共有 4 个项目，这并不完全干净，但如果最终结果相同，那将是可以接受的。