我有一个应用程序（C＃+ WPF）试图夺取对作为输入传递给它的任何进程的图形界面的控制，并为我自己的目的调整大小/重新定位。
我认为它的工作做得相当好。在预期终止（基类继承自IDisposable）时，“捕获”进程被释放 - 其父级被设置为原始，其窗口样式被重置等。
实际上，在测试中，我可以根据需要多次捕获，释放，重新捕获等同一个进程，没有任何问题。
然而，一旦意外终止（说另一个进程强行杀死它），该过程永远不会重新获得其图形界面！我可以告诉它仍在运行，但我永远不能将该过程恢复到原始状态。
看起来这个过程似乎不响应基于窗口的Win32 API调用再设置特定的窗口功能（例如，我可以使用GetParent，GetWindowThreadProcessId等获取信息，但无需调用ShowWindow或相关结果）。
有关为什么会发生这种情况的任何建议？我猜测，因为我将进程的父进程设置为我的WPF应用程序（然后意外关闭），这会导致尝试恢复初始界面时出现问题？
This是它发生的原因（或者，至少，表明为什么我自己很难找到问题）;我能从中恢复过来吗？如果是这样，怎么样？
编辑 -
IInspectable在评论中提出了一个很好的观点，调整了问题以使这个特定的应用更有意义。
看来我得到了答案;所以，为了完整起见，我会发布我已经收到的内容，以防其他人有类似的问题。
根据IInspectable和here中here提供的信息（评论中有更多上下文），似乎我在这里尝试做的事情（分配一个新的父交叉过程）本质上是不受支持的行为。
我的解决方案
恢复（至少在我正在谈论的那一点 - 即意外的崩溃或退出）可能是不可行的，因为我们已经在未确定/未知的行为中走了尽头。所以我决定选择预防路线。
我们当前的项目已经使用Nancy框架来跨服务器/进程进行通信，所以我将为我的部分程序“改进”我们的关闭程序，以允许它更优雅地退出。
在真正意外终止的情况下，我仍然处于亏损状态。我可以重新启动进程（实际上是带有控制台输出的服务，在我们的例子中，但是没有），但我的应用程序只是一个GUI /接口，与这些进程所服务的功能相比并不是很重要。我可能会制作某种信号量文件，指示是否成功关闭并关闭我的代码，以便它指示在下次重新启动之前进程不再可见。