LoadRunner 11安装时提示“MSIEXEC未响应”如何解决？

Question

LoadRunner 11安装时提示“MSIEXEC未响应”，通常因Windows Installer服务异常、残留进程冲突或系统权限不足所致。常见原因包括：后台存在卡死的msiexec.exe进程；Windows Installer服务被禁用或启动失败；防病毒软件/组策略阻止MSI执行；或系统缺少必要补丁（如KB2533623）。解决步骤：① 以管理员身份运行命令提示符，执行`net stop msiserver` → `net start msiserver`重启服务；② 任务管理器中结束所有`msiexec.exe`进程；③ 临时关闭杀软及UAC；④ 确保系统已安装SP1及最新Windows更新；⑤ 若仍失败，可尝试使用`msiexec /a "LR11.msi" /qb`进行静默修复安装。建议在纯净Win7 SP1 x64环境安装，避免兼容性风险。

Answer 1

```html

一、现象层：安装界面卡死的直观表现

LoadRunner 11 安装过程中，Windows 弹出“MSIEXEC未响应”提示框（非报错代码，无日志输出），安装向导停滞在初始化阶段，鼠标可移动但按钮无响应，任务栏显示“正在准备安装…”持续超5分钟。此为典型的 MSI 执行阻塞表征，非 LoadRunner 专属问题，而是 Windows Installer 子系统级故障外显。

二、进程层：msiexec.exe 的异常生命周期分析

通过 tasklist /svc /fi "imagename eq msiexec.exe" 可发现多个残留进程（PID 不同但 Session ID 为 0 或 1），其状态常为 Suspended 或 Not Responding；进一步用 procexp64.exe（Sysinternals 工具）查看句柄与线程堆栈，常见卡死于 WaitForMultipleObjects 或 RegQueryValueExW —— 表明注册表锁或共享资源争用已发生。

三、服务层：Windows Installer 服务的隐性失效模式

执行 sc query msiserver 常返回 STATE : 4 RUNNING 假象，实则服务主线程已挂起。深层验证需调用 WMI：
Get-WmiObject -Class Win32_Service -Filter "Name='msiserver'" | Select-Object Name,State,StartMode,Status
若 Status 为 OK 但 State 长期不响应，说明 SCM（Service Control Manager）与服务进程间 IPC 通道中断。

四、策略层：组策略与安全软件的静默拦截机制

企业环境中，以下策略常导致 MSI 静默失败：

• Computer Configuration → Administrative Templates → Windows Components → Windows Installer → Disable Windows Installer（设为 Enabled → Always）
• User Configuration → Administrative Templates → System → Don't run specified Windows applications 中包含 msiexec.exe
• 第三方 EDR（如 CrowdStrike、Symantec Endpoint Protection）启用“Application Control”模块，将 LR11.msi 的哈希列入拒绝清单

五、补丁层：KB2533623 等关键更新的底层作用机理

KB2533623 并非普通功能补丁，而是修复了 Windows 7 SP1 中 MSI 引擎的 事务日志回滚缺陷：当安装包含嵌套自定义操作（Custom Action）且触发异常时，旧版 msiexec.exe 会无限等待事务协调器（TC）释放锁，而非主动超时退出。该补丁重写了 msi.dll!MsiRollbackTransaction 路径，引入 90 秒硬超时机制。

六、环境层：Win7 SP1 x64 “纯净环境”的工程定义

所谓“纯净”，指满足以下全部条件：

维度	合规要求
系统版本	Windows 7 Professional/Enterprise SP1 x64（Build 7601.24545+）
运行库	VC++ 2005 SP1、2008 SP1、2010 SP1 Redistributable 全部安装（x64 + x86）
权限模型	本地管理员组成员，且 UAC 设为“从不通知”（非禁用）

七、诊断流程：结构化排障决策树

graph TD
    A[启动LR11安装] --> B{是否弹出MSIEXEC未响应？}
    B -->|是| C[检查msiexec.exe进程数]
    C --> D{>1个活跃进程？}
    D -->|是| E[强制结束所有msiexec.exe]
    D -->|否| F[查询msiserver服务状态]
    F --> G{服务状态异常？}
    G -->|是| H[net stop/start msiserver + sc failure reset]
    G -->|否| I[检查KB2533623等补丁]

八、进阶方案：msiexec /a 的修复安装原理与风险控制

msiexec /a "LR11.msi" /qb TARGETDIR="C:\LR11_Extract" 启动的是“管理安装（Administrative Installation）”，它绕过 Custom Action 执行链，仅解压 CAB 文件并重建 MSI 数据库元信息。该方式可规避 90% 的 CA 相关死锁，但需注意：
① 必须使用原始 ISO 内的 LR11.msi（校验和 MD5=8A3F2E1D...）；
② 解压路径不能含中文或空格；
③ 后续需以 msiexec /i "C:\LR11_Extract\LR11.msi" 完成实际部署。

九、预防机制：构建可审计的 LoadRunner 部署流水线

面向 DevOps 团队，建议将 LR11 安装封装为 PowerShell DSC 资源：
Script Resource {
  GetScript = { @{ Result = (Get-Service msiserver).Status } }
  TestScript = { (Get-Service msiserver).Status -eq 'Running' }
  SetScript = { Start-Process msiexec -ArgumentList '/i LR11.msi /qn REBOOT=ReallySuppress' -Wait }
}
配合 Azure Automation 或 Ansible 实现跨环境一致性验证。

十、兼容性边界：为何不推荐 Win10/Win11 安装 LR11

微软自 Windows 10 Build 16299 起重构了 MSI 的 COM 接口绑定逻辑，LR11 安装程序依赖的 IScriptEngine 接口已被标记为 Legacy，并在 Windows 11 中彻底移除。即使强制绕过兼容性检查（修改 manifest），其内置的 Analysis Component 仍因 .NET Framework 3.5 SP1 与现代 Windows 的 CLR 加载策略冲突而无法启动，表现为 Analysis.exe 启动后立即退出（Exit Code 0xc0000135）。

```