C#在Process.Kill()期间只完成了ReadProcessMemory或WriteProcessMemory请求的一部分

Question

我一直在广泛研究这个问题,似乎无法找到答案.

我知道Only part of a ReadProcessMemory or WriteProcessMemory request was completed当32位进程尝试访问64位进程时会抛出异常,而对于64位进程修改32位进程则会抛出异常.

该问题的解决方案是将平台目标更改为"任何CPU".我试过这个,不幸的是这并没有解决我的问题.

下一个代码块是不断抛出异常的原因.运行此代码的程序用于在远程计算机上打开应用程序,并保留程序本身打开的所有进程的列表,这样我就不必遍历所有进程.

Process processToRemove = null;
lock (_runningProcesses)
{
    foreach (Process p in _runningProcesses)
    {
        foreach (ProcessModule module in p.Modules)
        {
            string[] strs = text.Split('\\');

            if (module.ModuleName.Equals(strs[strs.Length - 1]))
            {
                processToRemove = p;
                break;
            }
        }
        if (processToRemove != null)
        {
            break;
        }
    }
    if (processToRemove != null)
    {
        processToRemove.Kill();
        _runningProcesses.Remove(processToRemove);
    }
}

这些过程可以并且很可能是32位和64位混合在一起.

我有什么我不应该做的事情,或者是否有更好的方法来做所有这些？

Answer 1

正如Process.Modules和此线程的MSDN页面的注释中所详述的那样,在Process.Modules从64位进程枚举32位进程时存在一个已知问题,反之亦然:

.NET内部的Process.Modules使用PSAPI.dll中的EnumProcessModules函数.此函数有一个已知问题,它无法跨32/64位进程边界工作.因此,从32位进程枚举另一个64位进程(反之亦然)无法正常工作.

解决方案似乎是使用该EnumProcessModulesEx函数(必须通过P/Invoke调用),但此功能仅适用于Windows的更高版本.

我们通过向PSAPI.dll(http://msdn2.microsoft.com/en-us/library/ms682633.aspx)添加一个名为EnumProcessModulesEx的新函数来修复此问题,但我们目前无法在这种情况下使用它:

• 它仅适用于Windows Vista或Windows Server 2008
• 目前.NET 2.0 Framework没有Service Pack或修补程序来使Process.Modules使用这个新API