我有一个 dotnet 进程，它通过对非托管 dll 的调用与 Java 进程进行通信。
在某些情况下，Java 进程似乎正在崩溃并导致我的 dotnet 进程崩溃。没有引发异常，该过程就死了。崩溃时，java 正在创建一个名称为“hs_err_pid3228”等的日志文件。
没有从提供非托管 dll 和 java 进程的供应商那里得到任何满意，我只好试图减轻问题，这需要确保调用 java 进程，如果它们崩溃，不要取消我的进程.
阅读了各种文章后，appdomains 似乎是一个可能使用的候选者 - 我的理论是我可以通过一些工作将调用 java 进程的功能分开并在单独的 appdomain 中运行它，如果没有捕获 appdomain，这将有望让我下降，至少检测到它已经发生并重新启动该功能。
有没有人遇到过类似的问题？对于那些有更多 appdomain 经验的人来说，这种方法是否合理？
为了让它更有趣，Java 崩溃并不是真正可重现的——它看起来很随机，我仍在与如何测试分离到 appdomain 中的方法作斗争
这是对 AppDomains 的合理使用，您的建议将起作用。
与此类似，我曾经使用 AppDomains 创建一个应用程序，该应用程序会监视自身崩溃以进行异常报告。应用程序自己启动，创建了一个新的 AppDomain，然后在新的 AppDomain 中重新执行，然后检测到它在 AppDomain 中运行并正常执行。当该 AppDomain 发生异常时，通知原始进程，它会拆除向用户报告发生错误的子域，询问他们是否要报告它，然后重新启动并重新尝试。
编辑：为了让您抢先一步，如果您想查看该项目的 Program.cs，我在这里上传了一个精简版。（很长，所以我不认为我应该在这里发布。）
是的，在这里利用 AppDomains 很有意义。
我最近重新设计了我的 Windows 服务，以将其各种 WCF 服务加载为在它们自己的 AppDomain 中运行的插件。我在引导过程中有一些案例，我使用 MarshalByRefObject 对象来启动和运行，但是一旦加载了插件，使用 WCF 就可以非常轻松地在 AppDomain 之间进行通信。