简介：这份C# WinForm示例压缩包面向希望把外部EXE程序集成进自有窗体的桌面开发者，聚焦统一界面下的多程序协同场景，适合已掌握C#基础、需要落地进程启动、窗口句柄挂接与简单进程间通信的初中级读者。包内共25个文件，约48KB，以7个cs源码、3个exe程序、2个resx窗体资源、2个pdb调试符号及csproj、sln、manifest、settings、suo等工程配置为主，另含resources、cache和说明文本，组成可直接打开调试的TestForm示例工程。该主题已有3147人学习，说明外部程序嵌入与窗口父子化是桌面集成中的常见需求。读者可从中获得解决方案与项目结构、窗体设计器代码、Process启动外部程序及SetParent改变父窗口的示例思路，并据此理解消息传递、事件处理、安全与性能边界，作为快速验证和二次开发的参考。

1. 从窗口句柄切入：这份 C# WinForm 嵌入外部 EXE 资源能解决什么

把 C# WinForm 外部EXE嵌入窗体 这件事说穿，核心不是“把 exe 变成控件”，而是拿到外部进程主窗口的 HWND，再用SetParent挂到 WinForm 的 Panel 里。很多人第一次做会以为嵌进去就完事，结果黑屏、错位、键盘没反应，根子都在窗口样式和消息边界。这份资源适合需要把既有桌面程序塞进自有壳工程的人：老工具复用、统一入口、减少窗口来回切。它把可运行的容器窗体、句柄查找、尺寸跟随和退出清理放在一起，能让你先把最小链路跑通，再按自己的 exe 补边界。

2. 原理先立住：SetParent 嵌入外部 EXE 的窗口层级与消息边界

2.1 嵌入不是“打包运行”：进程、窗口句柄和父子关系

外部 EXE 被启动之后，它仍然是一个独立进程，有自己的消息循环、自己的线程和自己的窗口树。WinForm 这边拿到的只是一个IntPtr句柄，SetParent改变的是窗口在系统里的父子关系，不会把外部进程的代码加载进当前 AppDomain，也不会让外部窗口变成 WinForm 的自定义控件。这个区别决定了后面所有问题的走向：外部程序弹模态框、创建新窗口、退出进程，宿主窗体不一定能自动感知，得靠我们自己补状态同步。

窗口句柄是这条链路里最关键的“钥匙”。顶层窗口有WS_POPUP、WS_CAPTION、WS_THICKFRAME这些样式，直接SetParent到 Panel 上，有些程序会看起来嵌进去了，但拖动、缩放、焦点全是乱的；有些程序会保持顶层窗口行为，跑到宿主窗口外面去。常见做法是先把目标窗口样式改成子窗口：加上WS_CHILD和WS_VISIBLE，去掉WS_POPUP、WS_CAPTION、WS_THICKFRAME，再调用SetParent。这一步不是形式主义，它决定了窗口消息往哪里走。

还有一个容易忽略的点：外部 EXE 的主窗口不一定在Process.Start返回后立刻可用。带启动画面、登录页、插件初始化的程序，MainWindowHandle可能先是 0，过几百毫秒才出现；有些程序主窗口出现后又重建一次句柄。实际项目里我一般会做“限时轮询 + 句柄稳定性检查”，而不是启动后马上SetParent。这份资源的示例工程把等待逻辑单独抽出来，就是为了后面换不同 exe 时不用把启动代码重写一遍。

2.2 为什么用 SetParent：与 WebBrowser/CEF/用户控件方案的选型对比

选型先看你要嵌的是什么。如果目标程序有源码，最稳的方案当然是把核心逻辑抽成类库或用户控件，重新接到 WinForm 里；如果目标程序是浏览器页面，CEF、WebView2 这类方案更合适；如果目标程序是第三方闭源桌面工具，且必须保留原界面和原交互，SetParent才是成本较低的入口。它的优势是改动小，不需要目标程序配合；边界也很明显，目标程序如果依赖独占全屏、硬件加速、特殊驱动或自绘窗口，嵌入后可能黑屏或者输入异常。

这张表里没有绝对赢家。我一般会先问一句：目标 EXE 能不能接受“窗口被重新挂载”这件事？如果它内部会主动SetWindowPos到屏幕坐标、会检测自己是不是前台窗口、会在启动时枚举顶层窗口，那SetParent后就要额外做兼容。资源里的示例不是万能胶，它更像一个可运行基线：先把进程、句柄、父窗口、尺寸同步四件事跑通，再针对具体 exe 补丁。

2.3 最小可运行链路：启动进程、等待输入空闲、查找主窗口、挂载

最小链路可以拆成五步：启动进程、等待输入空闲、轮询主窗口句柄、修正窗口样式、挂到宿主 Panel。下面这段代码是压缩包里最核心的骨架，省掉了业务判断，保留可复现的 API 调用顺序。实际工程里我会把 P/Invoke 收进一个NativeMethods类，避免每个窗体都散落一堆DllImport。

using System; using System.Diagnostics; using System.IO; using System.Runtime.InteropServices; using System.Threading; using System.Windows.Forms; namespace ExeEmbedDemo { internal static class NativeMethods { public const int GWL_STYLE = -16; public const int WS_CHILD = 0x40000000; public const int WS_VISIBLE = 0x10000000; public const int WS_POPUP = unchecked((int)0x80000000); public const int WS_CAPTION = 0x00C00000; public const int WS_THICKFRAME = 0x00040000; [DllImport("user32.dll", SetLastError = true)] public static extern IntPtr SetParent(IntPtr hWndChild, IntPtr hWndNewParent); [DllImport("user32.dll", SetLastError = true)] public static extern int GetWindowLong(IntPtr hWnd, int nIndex); [DllImport("user32.dll", SetLastError = true)] public static extern int SetWindowLong(IntPtr hWnd, int nIndex, int dwNewLong); [DllImport("user32.dll", SetLastError = true)] public static extern bool MoveWindow( IntPtr hWnd, int x, int y, int width, int height, bool repaint); } internal sealed class ExeEmbedder { private Process _process; private IntPtr _childHwnd = IntPtr.Zero; public IntPtr Embed(string exePath, Control host) { if (!File.Exists(exePath)) throw new FileNotFoundException("目标 EXE 不存在", exePath); var startInfo = new ProcessStartInfo { FileName = exePath, WorkingDirectory = Path.GetDirectoryName(exePath), UseShellExecute = false }; _process = Process.Start(startInfo); if (_process == null) throw new InvalidOperationException("进程启动失败"); // 给目标程序一点初始化时间，带启动画面的程序尤其需要 _process.WaitForInputIdle(5000); _childHwnd = WaitForMainWindow(_process, 8000); if (_childHwnd == IntPtr.Zero) throw new InvalidOperationException("没有拿到目标窗口句柄"); int style = NativeMethods.GetWindowLong(_childHwnd, NativeMethods.GWL_STYLE); style &= ~(NativeMethods.WS_POPUP | NativeMethods.WS_CAPTION | NativeMethods.WS_THICKFRAME); style |= NativeMethods.WS_CHILD | NativeMethods.WS_VISIBLE; NativeMethods.SetWindowLong(_childHwnd, NativeMethods.GWL_STYLE, style); NativeMethods.SetParent(_childHwnd, host.Handle); NativeMethods.MoveWindow( _childHwnd, 0, 0, host.ClientSize.Width, host.ClientSize.Height, true); return _childHwnd; } private static IntPtr WaitForMainWindow(Process process, int timeoutMs) { var sw = Stopwatch.StartNew(); while (sw.ElapsedMilliseconds < timeoutMs) { process.Refresh(); if (process.MainWindowHandle != IntPtr.Zero) return process.MainWindowHandle; Thread.Sleep(100); } return IntPtr.Zero; } } }

这段代码里，exePath必须是本地绝对路径或可被系统解析的完整路径，WorkingDirectory要指向目标程序所在目录，否则它加载同目录 DLL 或配置文件时容易报错。WaitForInputIdle(5000)的 5000 是毫秒，适合一般桌面程序；如果目标程序启动很慢，不要盲目加大到几十秒，而是把等待拆成“进程未退出 + 窗口句柄出现”的轮询。WaitForMainWindow里的 100 毫秒是轮询间隔，8 秒是上限，真实项目可以按 exe 调整。

SetWindowLong这里改的是GWL_STYLE，WS_CHILD让窗口变成子窗口，WS_VISIBLE保证挂载后可见；去掉WS_CAPTION和WS_THICKFRAME是为了避免宿主里出现第二层标题栏和拖拽边框。SetParent的第二个参数必须是已经创建句柄的控件，Panel 没加到窗体上之前Handle可能还没生成。MoveWindow的坐标是相对新父窗口客户区的坐标，所以这里用0, 0和host.ClientSize，不是屏幕坐标。64 位工程如果遇到样式设置异常，可以把GetWindowLong/SetWindowLong换成GetWindowLongPtr/SetWindowLongPtr的封装，调用顺序不变。

3. 从启动到挂载：一份可复现的 WinForm 嵌入外部 EXE 实现

3.1 容器窗体布局：Panel、Dock 和尺寸同步的基线配置

宿主窗体不要直接把外部窗口挂到 Form 上。Form 本身有边框、标题栏、菜单和状态栏，挂上去之后坐标计算会被这些非客户区干扰，后面做 DPI 和缩放时非常难受。我一般会放一个Panel当容器，Dock = DockStyle.Fill，外部窗口只认这个 Panel 的客户区。Panel 背景色可以设成黑色或和目标程序接近的颜色，这样目标窗口重绘的瞬间不会闪出大片白底。

布局上还有两个细节：第一，Panel 不要加Padding或Margin去“美化”，外部窗口的MoveWindow用的是父客户区坐标，Padding 不会自动被目标窗口感知，最后就是错位；第二，如果宿主窗体有菜单栏或工具栏，把 Panel 放在它们下面，用Dock顺序控制，而不是手动算 Y 坐标。资源里的示例工程用TableLayoutPanel包了一层，但真正挂载点仍然是内部那个纯 Panel，目的就是隔离布局变化。

public partial class MainForm : Form { private readonly Panel _hostPanel; private readonly ExeEmbedder _embedder = new ExeEmbedder(); private IntPtr _embeddedHwnd = IntPtr.Zero; public MainForm() { InitializeComponent(); _hostPanel = new Panel { Dock = DockStyle.Fill, BackColor = Color.Black, TabStop = false }; Controls.Add(_hostPanel); _hostPanel.Resize += (_, __) => ResizeEmbeddedWindow(); Shown += (_, __) => StartEmbeddedExe(); } private void StartEmbeddedExe() { string exePath = Path.Combine( AppDomain.CurrentDomain.BaseDirectory, "Tools", "LegacyTool.exe"); _embeddedHwnd = _embedder.Embed(exePath, _hostPanel); } private void ResizeEmbeddedWindow() { if (_embeddedHwnd == IntPtr.Zero || _hostPanel.IsDisposed) return; NativeMethods.MoveWindow( _embeddedHwnd, 0, 0, _hostPanel.ClientSize.Width, _hostPanel.ClientSize.Height, true); } }

这段布局代码的关键参数是Dock = DockStyle.Fill和TabStop = false。Dock让 Panel 跟随窗体客户区变化，TabStop = false避免焦点先落到 Panel 上再传给外部窗口，减少一次焦点跳转。Shown事件里启动外部 exe，是因为此时宿主窗体和 Panel 的句柄都已经创建，SetParent不会因为父句柄为空而失败。ResizeEmbeddedWindow里先判断句柄和释放状态，再调用MoveWindow，否则窗体关闭阶段容易触发“句柄已失效”的异常。

注意，_hostPanel.ClientSize在窗体最小化时可能变成 0 或很小，直接MoveWindow会把目标窗口压成一条线。实际项目里我会加一个最小尺寸保护，比如宽高小于 32 时跳过移动，等恢复后再同步。这个保护看起来不起眼，但能避免一部分目标程序在极小尺寸下重绘崩溃。

3.2 进程启动与句柄获取：ProcessStartInfo、WaitForInputIdle 和 FindWindow 的配合

Process.MainWindowHandle对大多数 Win32 程序够用，但它有两个坑：一是它只认“主窗口”，有些程序启动时先显示一个 Splash 窗口，主窗口还没创建；二是目标程序如果有多个顶层窗口，MainWindowHandle可能指向你不想嵌的那个。更稳的方式是用EnumWindows按进程 ID 枚举顶层窗口，过滤掉不可见窗口、工具窗口和拥有者窗口，再取第一个符合条件的句柄。

下面这段代码是资源里对WaitForMainWindow的增强版。它不依赖窗口标题，因为标题会随 UI 语言和运行状态变化；也不依赖FindWindow的类名，因为第三方程序的类名不保证稳定。按 PID 过滤是更可靠的起点。

using System; using System.Collections.Generic; using System.Diagnostics; using System.Runtime.InteropServices; using System.Text; internal static class WindowFinder { private delegate bool EnumWindowsProc(IntPtr hWnd, IntPtr lParam); [DllImport("user32.dll")] private static extern bool EnumWindows(EnumWindowsProc callback, IntPtr lParam); [DllImport("user32.dll")] private static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint processId); [DllImport("user32.dll")] private static extern bool IsWindowVisible(IntPtr hWnd); [DllImport("user32.dll")] private static extern IntPtr GetWindow(IntPtr hWnd, uint cmd); [DllImport("user32.dll", CharSet = CharSet.Unicode)] private static extern int GetWindowTextLength(IntPtr hWnd); [DllImport("user32.dll", CharSet = CharSet.Unicode)] private static extern int GetWindowText(IntPtr hWnd, StringBuilder text, int maxCount); private const uint GW_OWNER = 4; public static IntPtr FindTopLevelWindow(int processId) { var candidates = new List<IntPtr>(); EnumWindows((hWnd, _) => { GetWindowThreadProcessId(hWnd, out uint pid); if (pid != processId) return true; if (!IsWindowVisible(hWnd)) return true; // 有 Owner 的通常是对话框或工具窗，不作为主窗口 if (GetWindow(hWnd, GW_OWNER) != IntPtr.Zero) return true; int len = GetWindowTextLength(hWnd); if (len <= 0) return true; candidates.Add(hWnd); return true; }, IntPtr.Zero); return candidates.Count > 0 ? candidates[0] : IntPtr.Zero; } }

这段枚举逻辑里，GetWindowThreadProcessId用来把窗口和进程对上，IsWindowVisible过滤隐藏窗口，GW_OWNER过滤有拥有者的窗口，GetWindowTextLength过滤没有标题的辅助窗口。参数GW_OWNER = 4是GetWindow的固定命令值，不要改成别的。实际项目里如果目标程序的主窗口标题为空，可以去掉标题长度判断，改成按窗口类名或窗口尺寸做二次筛选，但不要一上来就写死类名。

WaitForInputIdle和EnumWindows的配合方式是：先WaitForInputIdle给目标程序一个初始化窗口，再用短间隔轮询FindTopLevelWindow。轮询期间要检查process.HasExited，否则目标程序启动失败时你会白等 8 秒。轮询到句柄后不要立刻SetParent，先等一到两个 UI 消息周期，让目标程序完成第一次布局，再改样式，能减少一部分“嵌进去后窗口大小不对”的问题。

3.3 样式修正与尺寸跟随：SetWindowLong、MoveWindow 和 Resize 事件

样式修正不是越狠越好。去掉WS_CAPTION和WS_THICKFRAME能让界面看起来像原生嵌入，但有些目标程序依赖标题栏做拖动、双击最大化，去掉后用户会觉得“窗口死了”。我一般会把“是否去掉标题栏”做成可配置项：如果目标程序只是工具面板，去掉；如果它有自己的复杂窗口框架，保留标题栏，只加WS_CHILD，让它在 Panel 内部显示。资源里的示例默认去掉标题栏，是为了展示最小视觉干扰，不代表所有 exe 都必须这样。

尺寸跟随要处理两个来源：宿主 Panel 的Resize和窗口的DpiChanged。Resize里调用MoveWindow是常规操作，但要注意 Panel 的ClientSize是客户区尺寸，不包含边框；如果 Panel 有BorderStyle = FixedSingle，边框会占 1 到 2 像素，外部窗口和边框之间可能出现缝隙。我的做法是 Panel 不加边框，视觉边框交给宿主窗体或外层容器，挂载点保持干净。

private void ResizeEmbeddedWindow() { if (_embeddedHwnd == IntPtr.Zero || _hostPanel.IsDisposed) return; int width = _hostPanel.ClientSize.Width; int height = _hostPanel.ClientSize.Height; // 最小化或布局初期会拿到极小尺寸，跳过避免目标程序重绘异常 if (width < 32 || height < 32) return; NativeMethods.MoveWindow(_embeddedHwnd, 0, 0, width, height, true); } protected override void OnDpiChanged(DpiChangedEventArgs e) { base.OnDpiChanged(e); ResizeEmbeddedWindow(); }

MoveWindow的四个坐标参数里，x和y是相对父窗口客户区的偏移，width和height是目标窗口的新尺寸，最后一个true表示立即重绘。重绘会带来一点闪烁，如果目标程序自绘很重，可以改成false，等布局稳定后再手动触发一次重绘。OnDpiChanged里只做尺寸同步，不在这个时机重新SetParent，因为 DPI 变化时窗口句柄通常不变，重建父级关系反而容易把焦点弄丢。

4. 把嵌入做稳：输入焦点、DPI、权限与退出清理的工程化处理

4.1 焦点与键盘鼠标：SetFocus、SetForegroundWindow 和容器激活顺序

外部窗口挂到 Panel 后，鼠标点击通常能落到目标窗口上，但键盘焦点经常出问题：用户点一下宿主窗体，再按 Tab，焦点在 WinForm 控件之间跳，外部程序收不到按键；或者目标程序弹出一个模态对话框，对话框跑到宿主窗口后面，看起来像卡死。焦点问题的本质是：SetParent只改变父子关系，不改变前台窗口和焦点线程的归属，外部程序仍然在自己的 UI 线程里处理WM_SETFOCUS。

我一般会在 Panel 的MouseDown或宿主窗体的Activated事件里做一次温和的焦点转移：先激活宿主窗体，再对子窗口调用SetFocus，但不要每次鼠标移动都调用，否则会和目标程序自己的焦点管理打架。下面这段代码是资源里使用的简化版本，适合大多数 Win32 程序，不保证对所有自绘框架都有效。

[DllImport("user32.dll")] private static extern IntPtr SetFocus(IntPtr hWnd); [DllImport("user32.dll")] private static extern bool SetForegroundWindow(IntPtr hWnd); private void FocusEmbeddedWindow() { if (_embeddedHwnd == IntPtr.Zero || !IsWindow(_embeddedHwnd)) return; SetForegroundWindow(Handle); SetFocus(_embeddedHwnd); }

SetForegroundWindow(Handle)里的Handle是宿主窗体句柄，目的是把整个壳工程拉到前台；SetFocus(_embeddedHwnd)才把键盘焦点交给外部子窗口。这里没有用AttachThreadInput强行附加线程输入，因为那种做法副作用大，容易让两个 UI 线程的焦点状态互相污染。更稳的策略是让目标程序自己处理焦点，宿主只在用户明确点击容器时做一次转移。

如果目标程序有模态对话框，嵌入后对话框可能仍然以顶层窗口出现。常见做法是监听外部进程的窗口创建事件，或者在宿主窗体Activated时枚举该进程的可见顶层窗口，把对话框也SetParent到同一个 Panel。这个逻辑要谨慎，不要把所有弹窗都嵌进去，文件选择框、打印对话框这类系统对话框保持顶层更符合用户预期。

4.2 DPI 缩放与坐标换算：物理像素、逻辑单位和 Panel 边距

DPI 是外部 EXE 嵌入 WinForm 时最容易出玄学问题的地方。宿主窗体开了 PerMonitorV2，目标程序可能还是系统 DPI 感知，两者对同一块屏幕的像素换算不一致，结果就是嵌进去的窗口比 Panel 小一圈，或者鼠标点击位置偏移。排查时先看宿主进程和目标进程的 DPI 感知级别是否一致，再看MoveWindow传入的尺寸是物理像素还是逻辑单位。WinForms 控件的ClientSize在开启 DPI 感知后通常按设备像素参与布局，但不同 .NET 版本和 manifest 配置会有差异，不能凭感觉写。

实际项目里我会在ResizeEmbeddedWindow里记录一次日志：Panel 的ClientSize、MoveWindow的入参、目标窗口GetWindowRect的结果。三者对不上时，先判断是父窗口客户区坐标问题，还是目标程序自己做了 DPI 缩放。不要一上来就乘缩放系数，那样在 100% 缩放下没问题，到了 150% 会错得更离谱。资源里的示例把尺寸同步集中在一个方法里，就是为了让你只改一处、只打一处日志。

4.3 权限与进程生命周期：UAC 一致性、Job Object 和退出清理

权限问题很现实：宿主程序以管理员身份运行，目标 EXE 以普通权限启动，或者反过来，SetParent可能失败，或者嵌入后输入被 UIPI 拦住。最常见的现象是窗口能挂上去，但鼠标点击没反应，键盘也进不去。排查时先看两个进程的完整性级别是否一致，宿主和目标程序尽量用相同权限启动；如果目标程序必须提权，宿主也要提权，不要指望跨权限级别还能完整交互。

生命周期清理要分三层：关闭目标程序的主窗口、等待进程退出、兜底终止进程树。只调用Process.Kill()会留下目标程序拉起的子进程，尤其是带插件、带更新器的工具。.NET 5 及以上可以用Kill(entireProcessTree: true)，.NET Framework 下更稳的是 Job Object：创建作业对象，把目标进程分配进去，宿主退出时关闭 Job 句柄，系统会带走整个进程树。资源里的示例保留了CloseMainWindow加超时Kill的基础写法，同时给 Job Object 留了扩展位置。

private void MainForm_FormClosing(object sender, FormClosingEventArgs e) { if (_process == null || _process.HasExited) return; _process.CloseMainWindow(); if (!_process.WaitForExit(3000)) { try { _process.Kill(); } catch (InvalidOperationException) { // 进程刚好在等待期间退出，忽略 } } }

CloseMainWindow是礼貌关闭，给目标程序保存配置和释放资源的机会；WaitForExit(3000)的 3000 毫秒是等待上限，超过后再Kill。这个顺序不要反过来，直接Kill容易让目标程序留下锁文件或损坏本地缓存。关闭阶段还要把_embeddedHwnd置空，避免Resize事件在窗体销毁过程中再次调用MoveWindow。

5. 避坑排查：外部 EXE 嵌入 WinForm 后黑屏、错位、无法输入的 5 个现场

5.1 黑屏与“假嵌入”：窗口句柄拿错的三种情况

现象：调用SetParent之后 Panel 里一片黑，目标程序明明在任务栏里有窗口，但宿主里什么也看不到；有时候过几秒目标窗口又突然出现在屏幕左上角。

原因通常有三种。第一，拿到的是启动画面或隐藏窗口的句柄，真正的主窗口还没创建，SetParent挂了一个不可见窗口；第二，目标程序在初始化完成后重建了主窗口，旧句柄失效，新窗口仍然是顶层窗口；第三，Process.MainWindowHandle指向了工具窗口或拥有者窗口，挂载后尺寸为 0，看起来就是黑屏。黑屏不是渲染问题，很多时候是句柄生命周期问题。

解决：不要只依赖MainWindowHandle，用EnumWindows按 PID 枚举可见顶层窗口，过滤掉GW_OWNER非空的窗口，拿到句柄后等一个 UI 周期再挂。挂载后立刻用IsWindow和GetParent验证父子关系，如果GetParent返回 0，说明SetParent没成功或者目标窗口被重建了。对带 Splash 的程序，可以等主窗口标题出现后再挂，但不要把标题写死成某个语言版本。

5.2 错位与尺寸跳变：DPI 和边框样式叠加

现象：外部窗口嵌进去后比 Panel 小一圈，右下角露出宿主背景；拖动宿主窗体到第二块显示器，目标窗口突然变大或偏移；鼠标点击位置和视觉位置差十几像素。

原因：宿主和目标程序的 DPI 感知级别不一致，MoveWindow的尺寸来源混用了逻辑单位和物理像素；或者 Panel 有边框、Padding，外部窗口按父客户区坐标定位，视觉上就偏了。还有一种情况是目标程序自己响应了WM_DPICHANGED，又按自己的逻辑调整了一次窗口大小，和宿主的MoveWindow打架。

解决：先把 Panel 的边框和 Padding 清零，MoveWindow统一用host.ClientSize；在Resize、DpiChanged、Shown三个时机都做同步，并在日志里记录入参。宿主 manifest 开启 PerMonitorV2 后，不要手动再乘缩放系数，先确认目标程序是不是 DPI 感知，不感知的程序交给系统虚拟化，强行补偿反而会错位。多显示器场景下，把宿主窗体拖到目标屏幕后再启动外部程序，能减少一部分初始化 DPI 不一致的问题。

5.3 无法输入与焦点丢失：前台窗口锁与子窗口样式

现象：窗口嵌进去了，鼠标能点按钮，但键盘输入没反应；按 Tab 焦点跑到宿主窗体的其他控件上；目标程序弹出对话框后，对话框在宿主窗口后面，点不到。

原因：SetParent后没有设置WS_CHILD，目标窗口仍然按顶层窗口处理焦点；或者宿主窗体激活时把前台焦点抢走了，外部 UI 线程收不到WM_SETFOCUS。Windows 对SetForegroundWindow有前台锁限制，后台进程不能随便抢焦点，强行调用也可能失败。

解决：先确认样式里加了WS_CHILD，再去掉WS_POPUP；在 Panel 的鼠标点击事件里调用一次SetFocus，不要在MouseMove里频繁调用。目标程序弹模态框时，枚举该进程的新顶层窗口，把对话框挂到同一个 Panel，或者至少把它带到宿主前面。不要用AttachThreadInput作为默认方案，它会让两个线程的输入状态耦合，出问题时更难排查。

5.4 退出后残留与权限失败：进程树和 UAC

现象：关闭宿主窗体后，任务管理器里还能看到目标程序进程；目标程序以管理员权限运行时，嵌入后鼠标键盘都没反应；调试时一切正常，发布到用户机器上SetParent直接返回 0。

原因：只关闭了主窗口，没有处理目标程序拉起的子进程；宿主和目标 EXE 的完整性级别不一致，UIPI 拦截了输入消息；发布环境缺少目标程序依赖的运行库，进程启动后立刻退出，句柄自然拿不到。

解决：退出时先CloseMainWindow，超时后再终止进程树；.NET Framework 工程用 Job Object 兜底，别只Kill主进程。权限上让宿主和目标程序保持一致，目标程序需要提权时宿主也提权，不要跨级别嵌入。发布前在干净机器上跑一遍，检查目标 EXE 的依赖 DLL、配置文件和工作目录，启动失败时把Process.StandardError和退出码打出来，别只看黑屏。

6. 进阶验证：用 Spy++ 思路核对嵌入结果，并留一个可复用自检清单

嵌入做完后不要只看“看起来像”，要做一次句柄级验证。我的习惯是在调试构建里加一个自检方法，调用GetParent确认父窗口是不是 Panel，调用GetWindowRect看目标窗口矩形是否落在 Panel 客户区内，再用IsWindowVisible确认窗口可见。Spy++ 能看的东西，代码里用几个 API 也能看个大概，关键是把结果写进日志，出问题时不用靠猜。

[DllImport("user32.dll")] private static extern IntPtr GetParent(IntPtr hWnd); [DllImport("user32.dll")] private static extern bool GetWindowRect(IntPtr hWnd, out RECT rect); [DllImport("user32.dll")] private static extern bool IsWindowVisible(IntPtr hWnd); private void VerifyEmbeddedWindow() { if (_embeddedHwnd == IntPtr.Zero) return; IntPtr parent = GetParent(_embeddedHwnd); bool visible = IsWindowVisible(_embeddedHwnd); GetWindowRect(_embeddedHwnd, out RECT rect); Debug.WriteLine($"parent={parent}, panel={_hostPanel.Handle}, " + $"visible={visible}, rect={rect.Left},{rect.Top}," + $"{rect.Right - rect.Left}x{rect.Bottom - rect.Top}"); }

自检表可以固定成四项：父句柄是否等于 Panel 句柄、窗口是否可见、窗口宽高是否接近 Panel 客户区、关闭时进程是否退出。前两项失败，多半是SetParent或样式没生效；第三项失败，查 DPI 和MoveWindow入参；第四项失败，查进程树和关闭顺序。这张表不花哨，但能挡住大部分“嵌进去了但不好用”的问题。

从那以后我每次接新的外部 EXE，都强制走一遍“启动、等句柄、改样式、挂载、尺寸同步、退出清理”这六步，再补一次日志自检，不靠肉眼判断。如果你手头正缺一份能跑起来的 C# WinForm 外部EXE嵌入窗体示例，这个压缩包里的窗体容器、句柄封装和清理逻辑可以照着改，先把最小链路跑通，再处理目标程序自己的脾气。希望帮到你。

本文还有配套的精品资源，点击获取