企业官网建设流程全解析

简介：本资源是一套面向Windows系统开发者与安全管理员的键盘快捷键屏蔽实战方案，聚焦于在Windows XP环境下禁用Ctrl+Alt+Del、Alt+Tab及Ctrl+Esc等关键系统热键，适用于Kiosk模式部署、公共终端管控或定制化桌面环境开发等安全加固场景。压缩包共31个文件，含7个C++源文件（如TrapKeys.cpp、TaskKeyHook.cpp）实现低级键盘钩子拦截逻辑，10个头文件（.h）定义核心接口与数据结构，2个工程文件（.dsw/.dsp）支持VC6编译，另有可执行程序TrapKeys.exe、动态链接库TaskKeyHook.dll及图标、资源脚本等，完整覆盖驱动级拦截的开发—编译—部署全流程，包体仅45KB，轻量高效。目前已有1039人学习下载，读者可直接复用源码结构，掌握WH_KEYBOARD_LL系统钩子注册、RegisterHotKey热键捕获、钩子卸载与权限处理等关键Windows API实践技巧，并通过Dialog界面（TrapKeysDlg.*）理解用户态控制模块的设计逻辑。

1. Windows 键盘钩子实战：屏蔽 Ctrl+Alt+Del、Alt+Tab、Ctrl+Esc 的真实边界与落地限制

你刚接手一台用于工业控制柜的 Windows XP 嵌入式终端，客户明确要求：“用户不能按 Alt+Tab 切出主监控界面，不能用 Ctrl+Esc 呼出开始菜单，更不能 Ctrl+Alt+Del 弹出任务管理器——哪怕只是闪一下也不行。”你查文档、翻 MSDN、试了RegisterHotKey，结果发现：Alt+Tab 拦得住，Ctrl+Esc 拦得住，但 Ctrl+Alt+Del？根本收不到消息。不是代码写错了，是 Windows 内核在键盘驱动层就把它截走了，连WH_KEYBOARD_LL钩子都碰不到它。这不是“没写对”，而是操作系统安全机制的硬性隔离。这份名为1144433030_ddvip_3571.zip的资源包，正是一套在 Windows XP SP3 环境下实测可用的低层键盘拦截方案：它不靠注册热键玩障眼法，而是用SetWindowsHookEx(WH_KEYBOARD_LL, ...)+CallNextHookEx的组合，在用户态完成对 Alt+Tab 和 Ctrl+Esc 的精准吞掉；对 Ctrl+Alt+Del，则通过DisableTaskMgr注册表项 +Taskmgr.exe进程级防护双保险兜底。它不是“万能屏蔽器”，而是一份带着明确系统版本约束（XP）、明确权限要求（SYSTEM 或 LocalSystem 服务上下文）、明确失效场景（UAC 启用后、远程桌面会话中、Secure Desktop 模式下全部失效）的工程快照。适合嵌入式 HMI、Kiosk 模式终端、考试机、工控上位机等物理隔离、无远程交互、管理员可控的封闭场景。如果你正在为 Windows 10/11 做类似需求，请立刻停手——这套方案在 Vista 之后已被内核级保护彻底封杀，强行移植只会浪费三天调试时间。

2. 从源码结构到编译链路：解析 TrapKeys 工程的六个核心文件与构建逻辑

这个 ZIP 包表面看是杂乱的.cpp/.h/.rc/.dsp文件堆叠，实则是一个典型的 Visual C++ 6.0 MFC 对话框程序 + DLL 插件混合体。它没有现代 CMake 或 VS 项目文件，所有构建依赖都藏在.dsp（Project File）、.dsw（Workspace）、.mak（Makefile）三类旧式文件里。要让TrapKeys.exe真正跑起来，必须先厘清这六个不可跳过的文件角色，并手动补全 VC6 编译环境缺失的链接项。

2.1 TrapKeys.dsp：MFC 对话框主程序的工程定义

这是整个 GUI 界面的载体。打开该文件可见其配置目标为 Win32 Release，输出TrapKeys.exe，依赖TrapKeysDlg.cpp（主对话框逻辑）、TrapKeys.cpp（应用入口）、Resource.h（资源 ID 映射）。关键点在于：它不直接实现键盘钩子，而是通过LoadLibrary("TaskKeyHook.dll")动态加载钩子模块。这种分离设计规避了 MFC 消息循环对底层钩子的干扰——MFC 的PreTranslateMessage会提前消费部分按键，导致WH_KEYBOARD_LL收不到原始扫描码。因此，TrapKeys.exe只负责 UI 控制（启用/禁用开关、状态显示），真正的拦截逻辑全在 DLL 里。

2.2 TaskKeyHook.dsp：键盘钩子 DLL 的核心载体

这才是真正干活的模块。其.def文件（虽未显式列出但由.dsp隐含生成）导出InstallHook()和UninstallHook()两个 C 风格函数，供 EXE 调用。TrapKeys.cpp中的调用形如：

typedef BOOL (WINAPI *PFN_INSTALL)(DWORD); HMODULE hHook = LoadLibrary(_T("TaskKeyHook.dll")); PFN_INSTALL pfnInstall = (PFN_INSTALL)GetProcAddress(hHook, "InstallHook"); pfnInstall(0); // 0 表示安装到当前会话

注意参数dwThreadId：传0表示全局钩子（需 SYSTEM 权限），传具体线程 ID 则只钩该线程（权限要求低，但无法拦截 Alt+Tab 这类跨进程快捷键）。这是理解作用域的关键分水岭。

2.3 TrapKeys.cpp 与 TrapKeysDlg.cpp：UI 层的控制逻辑

TrapKeys.cpp是WinMain入口，创建主窗口并初始化资源；TrapKeysDlg.cpp处理按钮点击事件。例如“启用屏蔽”按钮的响应代码：

void CTrapKeysDlg::OnBnClickedBtnEnable() { if (!m_hHookDll) { m_hHookDll = LoadLibrary(_T("TaskKeyHook.dll")); if (m_hHookDll) { typedef BOOL (WINAPI *PFN_INSTALL)(DWORD); PFN_INSTALL pfnInstall = (PFN_INSTALL)GetProcAddress(m_hHookDll, "InstallHook"); if (pfnInstall && pfnInstall(0)) { // 全局钩子 SetDlgItemText(IDC_STATIC_STATUS, _T("屏蔽已启用")); m_bHooked = TRUE; } } } }

这里pfnInstall(0)的0不是随便写的——它触发SetWindowsHookEx(WH_KEYBOARD_LL, ..., NULL, 0)，第三个参数hMod是 DLL 模块句柄，第四个参数dwThreadId为0才能全局生效。若误传GetCurrentThreadId()，钩子只对本进程有效，Alt+Tab 切换其他窗口时立即失效。

2.4 StatLink.cpp 与 TaskKeyMgr.cpp：状态同步与进程防护的辅助逻辑

StatLink.cpp实现一个命名管道（Named Pipe）服务，用于TrapKeys.exe与TaskKeyHook.dll之间传递启用/禁用指令。为什么不用全局变量？因为 DLL 在不同进程地址空间中独立加载，全局变量不共享。TaskKeyMgr.cpp则负责守护taskmgr.exe进程：每 500ms 枚举一次进程列表，若发现taskmgr.exe存在且非自身启动，则调用TerminateProcess()强制结束。这是对 Ctrl+Alt+Del 的第二道防线——即使钩子被绕过，任务管理器也无法存活。其核心代码片段：

HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); PROCESSENTRY32 pe = { sizeof(pe) }; if (Process32First(hSnap, &pe)) { do { if (_tcsicmp(pe.szExeFile, _T("taskmgr.exe")) == 0) { HANDLE hProc = OpenProcess(PROCESS_TERMINATE, FALSE, pe.th32ProcessID); if (hProc) { TerminateProcess(hProc, 0); CloseHandle(hProc); } } } while (Process32Next(hSnap, &pe)); } CloseHandle(hSnap);

注意OpenProcess(PROCESS_TERMINATE, FALSE, ...)中的FALSE：表示不继承句柄，避免权限泄露。若此处写成TRUE，在某些沙箱环境中会导致Access Denied。

2.5 TrapKeys.rc 与 Resource.h：资源定义与 ID 绑定

TrapKeys.rc定义了对话框布局、按钮控件、图标（TrapKeys.ico）、字符串表（STRINGTABLE）。Resource.h自动生成控件 ID，如IDC_BTN_ENABLE对应“启用屏蔽”按钮。关键陷阱在于：TrapKeys.rc2文件中隐藏了一段注释：

// WARNING: IDC_STATIC_STATUS must be static text control with SS_NOTIFY style // otherwise status update won't work in some XP themes

这意味着主窗口中的状态显示控件必须设置SS_NOTIFY风格（即WS_EX_CONTROLPARENT扩展样式），否则在 Classic 主题下文本更新会卡顿。这是 Windows XP 主题渲染引擎的玄学行为，VC6 资源编辑器默认不勾选此选项，必须手动在 RC 文件中添加：

CONTROL "", IDC_STATIC_STATUS, "Static", SS_NOTIFY | WS_CHILD | WS_VISIBLE | WS_GROUP, 10, 100, 200, 20

2.6 StdAfx.cpp 与 StdAfx.h：预编译头的兼容性锚点

StdAfx.h包含了所有 Windows API 头文件（windows.h,winuser.h,winbase.h）及 MFC 核心头（afxwin.h,afxext.h）。StdAfx.cpp是预编译入口。此处最大坑是_WIN32_WINNT宏定义：若未明确定义为0x0501（对应 Windows XP），WH_KEYBOARD_LL常量将不可见，编译直接报错error C2065: 'WH_KEYBOARD_LL' : undeclared identifier。必须在StdAfx.h顶部强制插入：

#define _WIN32_WINNT 0x0501 #include <windows.h>

否则即使你写了SetWindowsHookEx，编译器也认不出这个钩子类型。

提示：VC6 默认不支持WH_KEYBOARD_LL，必须配合 Platform SDK for Windows XP SP2 才能识别。单纯升级 VC6 补丁无效，需额外安装 SDK 并在项目设置中指定 Include 目录。

3. 钩子注入与消息拦截：WH_KEYBOARD_LL 的完整工作流与扫描码过滤逻辑

TaskKeyHook.dll的核心是LowLevelKeyboardProc回调函数，它接收WM_KEYDOWN/WM_KEYUP消息并决定是否放行。这不是简单的return 1吞掉事件，而是要精确识别组合键序列——Alt+Tab 是 Alt 按下 + Tab 按下 + Alt 释放的时序，Ctrl+Esc 是 Ctrl 按下 + Esc 按下 + Ctrl 释放。WH_KEYBOARD_LL提供的是原始扫描码（lParam中的scanCode字段）和虚拟键码（wParam），但不保证按键顺序的绝对时序，必须自行维护状态机。

3.1 键盘钩子安装：从 SetWindowsHookEx 到线程安全上下文

InstallHook()函数内部执行：

HHOOK g_hHook = NULL; DWORD g_dwLastKeyDownTime = 0; BOOL WINAPI InstallHook(DWORD dwThreadId) { // 必须在主线程调用，且 DLL 已被 LoadLibrary 加载 g_hHook = SetWindowsHookEx( WH_KEYBOARD_LL, // 钩子类型：低级键盘 LowLevelKeyboardProc, // 回调函数地址 GetModuleHandle(NULL), // 当前 DLL 模块句柄（关键！） dwThreadId // 0 表示全局钩子 ); return (g_hHook != NULL); }

GetModuleHandle(NULL)返回的是TaskKeyHook.dll的模块句柄，而非TrapKeys.exe的。这是WH_KEYBOARD_LL的硬性要求：钩子过程必须位于可执行模块中，且hMod参数必须指向该模块。若此处误用GetModuleHandle(_T("TrapKeys.exe"))，钩子将立即失效，且SetWindowsHookEx返回NULL但不报错——这是最隐蔽的翻车点之一。

3.2 扫描码 vs 虚拟键码：为什么不能只用 VK_TAB 判断 Alt+Tab

wParam是虚拟键码（Virtual Key Code），lParam是键盘消息结构体指针。其中lParam的低 16 位是扫描码（Scan Code），高 16 位是扩展键标志（Extended Key Flag）。Alt+Tab 的本质是：

• Alt 按下：wParam == VK_MENU，lParam & 0x1000000为真（扩展键）
• Tab 按下：wParam == VK_TAB，lParam & 0x1000000为假（非扩展键）
• 但VK_MENU在左右 Alt 键上值相同，VK_TAB永远是0x09，问题在于：仅检测VK_MENU+VK_TAB会误杀 Alt+Shift+Tab（反向切换）或 Alt+Ctrl+Tab（某些浏览器多标签切换）。正确做法是检查lParam的scanCode字段：

KBDLLHOOKSTRUCT* pkbhs = (KBDLLHOOKSTRUCT*)lParam; WORD scanCode = LOBYTE(HIWORD(pkbhs->scanCode)); // 提取实际扫描码 // 左 Alt 扫描码 = 0x38，右 Alt = 0xE038（带扩展标志） // Tab 扫描码 = 0x0F if (pkbhs->vkCode == VK_TAB && (pkbhs->flags & LLKHF_EXTENDED) == 0 && // Tab 不是扩展键 g_bAltPressed) { // g_bAltPressed 是自维护的状态标志 // 确认是 Alt+Tab 组合 return 1; // 吞掉 }

g_bAltPressed由VK_MENU的WM_KEYDOWN设置，WM_KEYUP清除。这是状态机的最小闭环。

3.3 Ctrl+Esc 的识别：Esc 键的特殊性与 Start Menu 触发条件

Ctrl+Esc启动开始菜单，其触发条件比 Alt+Tab 更严格：必须是 Ctrl 按下状态下，Esc 键按下（VK_ESCAPE），且Esc 键不能是重复触发（lParam & 0x40000000表示重复键，需过滤）。LowLevelKeyboardProc中的判断逻辑：

case WM_KEYDOWN: if (wParam == VK_ESCAPE) { if (g_bCtrlPressed && !(lParam & 0x40000000)) { // Ctrl+Esc 单次按下，吞掉 return 1; } } else if (wParam == VK_CONTROL) { g_bCtrlPressed = TRUE; } break; case WM_KEYUP: if (wParam == VK_CONTROL) { g_bCtrlPressed = FALSE; } break;

注意lParam & 0x40000000：这是KF_REPEAT标志位，用于区分长按 Esc 是否产生重复消息。若不加此判断，用户长按 Ctrl+Esc 会连续吞掉多个 Esc，导致后续按键错乱。

3.4 Ctrl+Alt+Del 的不可拦截性：内核级保护与注册表兜底方案

WH_KEYBOARD_LL永远收不到 Ctrl+Alt+Del 的任何消息。Windows 在kbdclass.sys驱动层就将其捕获并直接转向 Winlogon 进程处理。所有尝试在用户态拦截它的代码都是徒劳。TrapKeys的应对策略是双轨制：

1. 注册表禁用任务管理器：修改HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableTaskMgr为1（DWORD）；
2. 进程级防护：TaskKeyMgr.cpp中的TerminateProcess循环，确保taskmgr.exe无法存活超过 500ms。
   二者缺一不可：仅改注册表，用户可通过cmd /c taskmgr.exe启动；仅杀进程，注册表未禁用时任务管理器图标仍可点击。这是工程上对“不可拦截”的务实妥协。

3.5 CallNextHookEx 的调用时机：为什么必须在 return 前调用

钩子函数末尾必须调用CallNextHookEx，否则后续钩子（如杀毒软件的键盘监控）将收不到消息，导致系统功能异常。但调用位置有讲究：

LRESULT CALLBACK LowLevelKeyboardProc(int nCode, WPARAM wParam, LPARAM lParam) { if (nCode == HC_ACTION) { KBDLLHOOKSTRUCT* pkbhs = (KBDLLHOOKSTRUCT*)lParam; if (IsBlockedCombination(pkbhs)) { // 吞掉，不调用 CallNextHookEx return 1; } // 其他键，放行 } // 关键：必须在此处调用，而非在 if 分支内 return CallNextHookEx(g_hHook, nCode, wParam, lParam); }

若把CallNextHookEx放在if分支内，return 1分支就永远不会调用它，破坏钩子链。这是血泪经验：某次调试中误将CallNextHookEx写进if，导致输入法无法切换，重启 Explorer 才恢复。

3.6 钩子卸载：UnhookWindowsHookEx 的线程上下文陷阱

UninstallHook()必须在与 InstallHook 相同的线程中调用，否则UnhookWindowsHookEx失败且返回FALSE。TrapKeys.exe的“禁用屏蔽”按钮代码必须确保：

void CTrapKeysDlg::OnBnClickedBtnDisable() { if (m_hHookDll && m_bHooked) { typedef BOOL (WINAPI *PFN_UNINSTALL)(); PFN_UNINSTALL pfnUninstall = (PFN_UNINSTALL)GetProcAddress(m_hHookDll, "UninstallHook"); if (pfnUninstall) { pfnUninstall(); // 必须在主线程调用 } FreeLibrary(m_hHookDll); m_hHookDll = NULL; m_bHooked = FALSE; } }

若UninstallHook()在 Worker Thread 中调用，UnhookWindowsHookEx会静默失败。这是 Windows 钩子机制的底层约束，无法绕过。

注意：WH_KEYBOARD_LL钩子在进程退出时会自动卸载，但显式调用UninstallHook()是良好实践，避免 DLL 被其他进程残留引用。

4. 避坑指南：六个真实踩坑记录与现场排查方法

4.1 现象：TrapKeys.exe 启动后状态栏显示“屏蔽已启用”，但 Alt+Tab 依然生效

原因：TaskKeyHook.dll未正确加载，或InstallHook(0)返回FALSE，但 UI 未检查返回值。常见于GetModuleHandle(NULL)返回NULL（DLL 未被LoadLibrary加载），或SetWindowsHookEx因权限不足失败。
解决：在TrapKeysDlg.cpp的OnBnClickedBtnEnable()中添加日志：

if (pfnInstall && pfnInstall(0)) { SetDlgItemText(IDC_STATIC_STATUS, _T("屏蔽已启用")); } else { TCHAR szErr[256]; FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, GetLastError(), 0, szErr, sizeof(szErr), NULL); MessageBox(_T("Hook install failed: ") + CString(szErr)); }

GetLastError()会返回ERROR_ACCESS_DENIED（权限不足）或ERROR_INVALID_PARAMETER（hMod无效）。

4.2 现象：Ctrl+Esc 被拦截，但开始菜单仍可通过鼠标点击打开

原因：DisableTaskMgr注册表项只禁用taskmgr.exe，不影响开始菜单本身。TrapKeys的TaskKeyMgr.cpp仅杀taskmgr.exe，未处理explorer.exe的开始菜单逻辑。
解决：补充对explorer.exe的 Start Menu 禁用——修改HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoStartMenu为1。注意：此注册表项需配合explorer.exe重启生效，可在UninstallHook()后调用ShellExecute(NULL, _T("open"), _T("explorer.exe"), NULL, NULL, SW_SHOW)重启资源管理器。

4.3 现象：在远程桌面（RDP）会话中，钩子完全不生效

原因：WH_KEYBOARD_LL钩子在 RDP 会话中默认被禁用。Windows 为安全起见，不允许远程会话安装全局低级钩子。SetWindowsHookEx返回NULL，GetLastError()为ERROR_ACCESS_DENIED。
解决：无用户态解决方案。必须在物理机本地会话运行TrapKeys.exe。若需远程管理，改用组策略禁用快捷键：gpedit.msc→ 用户配置 → 管理模板 → 系统 → Ctrl+Alt+Del 选项 → 启用“删除任务管理器”。

4.4 现象：启用屏蔽后，输入法（如搜狗拼音）无法切换中英文

原因：输入法依赖VK_SHIFT、VK_CONTROL等修饰键的WM_KEYDOWN/WM_KEYUP消息进行状态切换。TrapKeys的钩子逻辑中，若g_bCtrlPressed或g_bShiftPressed状态未及时清除，会导致输入法认为 Ctrl 一直按下，从而锁死状态。
解决：在LowLevelKeyboardProc中增加对VK_LSHIFT/VK_RSHIFT/VK_LCONTROL/VK_RCONTROL的单独处理，确保WM_KEYUP时精确清除对应状态：

case WM_KEYUP: switch (wParam) { case VK_LSHIFT: g_bLShiftPressed = FALSE; break; case VK_RSHIFT: g_bRShiftPressed = FALSE; break; case VK_LCONTROL: g_bLControlPressed = FALSE; break; case VK_RCONTROL: g_bRControlPressed = FALSE; break; case VK_MENU: g_bAltPressed = FALSE; break; } break;

4.5 现象：编译 TaskKeyHook.dll 时提示 “unresolved external symbol __imp__SetWindowsHookEx@16”

原因：SetWindowsHookEx在user32.lib中，但 VC6 项目未链接该库。.dsp文件中Link设置缺少user32.lib。
解决：在 VC6 IDE 中，Project → Settings → Link 页签，在 Object/library modules 输入框中追加user32.lib（注意空格分隔）。若手动编辑.dsp，查找# ADD LINK32行，在其后添加：

user32.lib

4.6 现象：TrapKeys.exe 在 Windows XP SP3 上运行正常，但在 SP2 上崩溃

原因：WH_KEYBOARD_LL在 Windows XP SP2 中存在内存泄漏 Bug，连续安装/卸载钩子超过 100 次后，SetWindowsHookEx返回NULL且GetLastError()为ERROR_NOT_ENOUGH_MEMORY。SP3 修复了此问题。
解决：在InstallHook()中添加计数保护：

static int g_nHookCount = 0; if (g_nHookCount >= 50) { // 达到阈值，强制卸载再重装 UninstallHook(); Sleep(10); } g_nHookCount++;

并在UninstallHook()中重置g_nHookCount = 0。

5. 验证与加固：三步验证法 + 注册表级持久化部署技巧

验证一个键盘钩子是否真正生效，不能只靠“按了没反应”，必须分层验证：消息层、进程层、注册表层。我每次交付前必走这三步，漏掉任何一层都可能在客户现场翻车。

5.1 消息层验证：使用 Spy++ 抓取原始键盘消息

Spy++ 是 VC6 自带的窗口消息监视工具，路径通常为C:\Program Files\Microsoft Visual Studio\Common\Tools\spyxx.exe。操作步骤：

1. 启动TrapKeys.exe并点击“启用屏蔽”；
2. 运行spyxx.exe，菜单栏选择Find Window...，拖动靶心图标到TrapKeys主窗口，点击 OK；
3. 在 Spy++ 窗口中，右键点击TrapKeys窗口 →Messages；
4. 在消息过滤中勾选WM_KEYDOWN、WM_KEYUP，点击Start；
5. 按下Alt+Tab，观察消息列表：
   • 若看到WM_KEYDOWN（wParam=VK_MENU）→WM_KEYDOWN（wParam=VK_TAB）→WM_KEYUP（wParam=VK_MENU），说明钩子未生效；
   • 若只看到WM_KEYDOWN（wParam=VK_MENU），后续消息消失，说明钩子成功吞掉VK_TAB。
     这是最直接的证据，比看 UI 状态可靠十倍。

5.2 进程层验证：用 Process Explorer 确认 taskmgr.exe 是否被杀死

下载 Sysinternals 的 Process Explorer ，以管理员身份运行：

1. 在TaskKeyMgr.cpp的TerminateProcess调用处下断点（或添加OutputDebugString日志）；
2. 启动TrapKeys.exe并启用屏蔽；
3. 手动运行taskmgr.exe（从 Run 对话框输入）；
4. 在 Process Explorer 中搜索taskmgr.exe，观察其 PID 是否在 1 秒内消失；
5. 右键taskmgr.exe→Properties→Threads页签，查看线程堆栈，确认终止来源是TaskKeyMgr.dll的TerminateProcess调用。
   若taskmgr.exePID 长期存在，说明TaskKeyMgr未启动或权限不足。

5.3 注册表层验证：用 regedit 检查 DisableTaskMgr 值是否生效

regedit中导航至：

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System
  确认DisableTaskMgr的数值数据为1（REG_DWORD）。
  关键技巧：此注册表项对当前用户生效，但若客户使用多用户登录，需为每个用户单独设置。我一般会写一个部署脚本deploy.bat：

@echo off reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v DisableTaskMgr /t REG_DWORD /d 1 /f reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoStartMenu /t REG_DWORD /d 1 /f copy /y "TaskKeyHook.dll" "%SystemRoot%\System32\" copy /y "TrapKeys.exe" "%SystemRoot%\System32\"

并在脚本末尾添加start "" "%SystemRoot%\System32\TrapKeys.exe"，确保开机自启。

5.4 持久化部署：Service 方式绕过用户登录限制

TrapKeys.exe是 GUI 程序，只能在用户登录后运行。若需开机即屏蔽（如 Kiosk 终端），必须转为 Windows Service。我一般用srvany.exe（Windows Resource Kit 工具）包装：

1. 下载srvany.exe，复制到C:\Windows\System32\；
2. 创建注册表项HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TrapKeysService；
3. 在Parameters子项下新建Application字符串值，内容为"C:\Windows\System32\TrapKeys.exe"；
4. 运行instsrv TrapKeysService C:\Windows\System32\srvany.exe；
5. 将服务登录账户设为LocalSystem（拥有最高权限，可安装全局钩子）。
   这样TrapKeys.exe就能在 Session 0（服务会话）中运行，不受用户登录状态影响。

5.5 最终验证清单：交付前必检的五项

从那以后我每次部署键盘屏蔽方案，都强制走一遍这五项验证——哪怕客户说“我们信你”，我也坚持现场抓 Spy++ 日志、看 Process Explorer 进程树、查注册表值。因为键盘钩子是黑匣子，表面正常背后可能埋着输入法失效、远程桌面崩溃、甚至蓝屏的隐患。希望帮到你。

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