所以,我写了以下代码：

using (var serviceController = new ServiceController(serviceName))
{
    var serviceHandle = serviceController.ServiceHandle;

    using (failureActionsStructure.Lock())
    {
        success = NativeMethods.ChangeServiceConfig2W(
            serviceHandle,
            ServiceConfigType.SERVICE_CONFIG_FAILURE_ACTIONS,
            ref failureActionsStructure);

        if (!success)
            throw new Win32Exception();
    }
}

P / Invoke声明如下：

[DllImport("advapi32", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern bool ChangeServiceConfig2W(IntPtr hService, ServiceConfigType dwInfoLevel, ref SERVICE_FAILURE_ACTIONSW lpInfo);

ServiceConfigType只是一个枚举,此特定成员的值为2. SERVICE_FAILURE_ACTIONSW结构定义如下：

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
struct SERVICE_FAILURE_ACTIONSW
{
    public int dwResetPeriod;
    public string lpRebootMsg;
    public string lpCommand;
    public int cActions;
    public IntPtr lpsaActionsPtr;

    [MarshalAs(UnmanagedType.ByValArray, SizeConst = 1)]
    public SC_ACTION[] lpsaActions;

    class DataLock : IDisposable
    {
        IntPtr _buffer;

        public DataLock(ref SERVICE_FAILURE_ACTIONSW data)
        {
            int actionStructureSize = Marshal.SizeOf(typeof(SC_ACTION));

            // Allocate a buffer with a bit of extra space at the end, so that if the first byte isn't aligned to a 64-bit
            // boundary, we can simply ignore the first few bytes and find the next 64-bit boundary.
            _buffer = Marshal.AllocHGlobal(data.lpsaActions.Length * actionStructureSize + 8);

            data.lpsaActionsPtr = _buffer;

            // Round up to the next multiple of 8 to get a 64-bit-aligned pointer.
            if ((data.lpsaActionsPtr.ToInt64() & 7) != 0)
            {
                data.lpsaActionsPtr += 8;
                data.lpsaActionsPtr -= (int)((long)data.lpsaActionsPtr & ~7);
            }

            // Copy the data from lpsaActions into the buffer.
            IntPtr elementPtr = data.lpsaActionsPtr;

            for (int i=0; i < data.lpsaActions.Length; i++, elementPtr += actionStructureSize)
                Marshal.StructureToPtr(data.lpsaActions[i], elementPtr, fDeleteOld: false);
        }

        public void Dispose()
        {
            Marshal.FreeHGlobal(_buffer);
        }
    }

    internal IDisposable Lock()
    {
        return new DataLock(ref this);
    }
}

(此类型在结构的末尾有一个额外的成员,它没有出现在本机结构定义中,lpsaActions,它简化了这个结构的使用,并且只导致最后编组的额外数据 – 数据底层API只是忽略,因为它假设结构已经在内存中结束.)

SC_ACTION的定义如下：

[StructLayout(LayoutKind.Sequential)]
struct SC_ACTION
{
    public SC_ACTION_TYPE Type;
    public int Delay;
}

..和SC_ACTION_TYPE是一个简单的枚举：

enum SC_ACTION_TYPE
{
    SC_ACTION_NONE = 0,
    SC_ACTION_RESTART = 1,
    SC_ACTION_REBOOT = 2,
    SC_ACTION_RUN_COMMAND = 3,
}

我传入的结构初始化如下：

var failureActionsStructure =
    new SERVICE_FAILURE_ACTIONSW()
    {
        dwResetPeriod = 60000, // 60 seconds
        lpRebootMsg = "",
        lpCommand = "",
        cActions = 6,
        lpsaActions =
            new SC_ACTION[]
            {
                new SC_ACTION() { Type = SC_ACTION_TYPE.SC_ACTION_RESTART /* 1 */, Delay = 5000 /* 5 seconds */ },
                new SC_ACTION() { Type = SC_ACTION_TYPE.SC_ACTION_RESTART /* 1 */, Delay = 15000 /* 15 seconds */ },
                new SC_ACTION() { Type = SC_ACTION_TYPE.SC_ACTION_RESTART /* 1 */, Delay = 25000 /* 25 seconds */ },
                new SC_ACTION() { Type = SC_ACTION_TYPE.SC_ACTION_RESTART /* 1 */, Delay = 35000 /* 35 seconds */ },
                new SC_ACTION() { Type = SC_ACTION_TYPE.SC_ACTION_RESTART /* 1 */, Delay = 45000 /* 45 seconds */ },
                new SC_ACTION() { Type = SC_ACTION_TYPE.SC_ACTION_NONE /* 0 */, Delay = 0 /* immediate, and this last entry is then repeated indefinitely */ },
            },
    };

当我在64位进程中运行此代码时,它可以正常工作.虽然我在32位进程中运行它(实际上我只在32位Windows安装上测试了32位进程 – 我不知道在64位32位进程中会发生什么Windows安装),我总是得到ERROR_INVALID_HANDLE.

我做了一些挖掘. ChangeServiceConfig2W API函数使用stdcall调用约定,这意味着当函数中的第一个操作码即将执行时,堆栈应包含：

>(DWORD PTR)返回地址
>(DWORD PTR)服务处理
>(DWORD)服务配置类型(2)
>(DWORD PTR)指向失败动作结构的指针

但是,当我将本机调试器连接到我的32位C#进程并在ChangeServiceConfig2W的第一条指令上放置一个断点(技术上是_ChangeServiceConfig2WStub @ 12的第一条指令)时,我发现堆栈包含：

>(DWORD PTR)返回地址
>(DWORD PTR)始终为值0x0000AFC8
>(DWORD)值0x00000001,而不是预期的2
>(DWORD PTR)实际上是指向失败动作结构的有效指针

我在一个简单的C应用程序中确认,[ESP]的第二个和第三个DWORD应该是服务句柄和常量值2.我尝试了各种替代的P / Invoke声明,包括使用int而不是IntPtr和ServiceConfigType作为前两个参数,但无法获得任何其他行为.

最后,我更改了第三个参数ref SERVICE_FAILURE_ACTIONSW,直接取代IntPtr,并使用Marshal.StructureToPtr手动将failureActionsStruct编组到一个用Marshal.AllocHGlobal分配的块中.有了这个声明,第一个和第二个参数现在正确编组.

所以,我的问题是,我在最初声明ChangeServiceConfig2W函数的方式上做错了什么,这可以解释前两个参数没有正确编组？可能性似乎很小,但我无法摆脱我在P / Invoke(特别是封送器)遇到实际错误的可能性.

奇怪的是,DWORD值0x0000AFC8是我传入的failureActionsStructure中的一个SC_ACTION结构的45,000 ms延迟.但是,它是该实例的最后一个成员,并且堆栈中0x0000AFC8之后的0x00000001将不是Type以下SC_ACTION.即使它是,我也看不出会导致这些值专门写入P / Invoke调用的参数区域的原因.如果它将整个结构序列化到内存中的错误位置并覆盖部分堆栈,是否会导致内存损坏并可能终止进程？

我很迷惑. 🙂

最佳答案 我相信我已经知道发生了什么.在我看来,它是P / Invoke编组程序中的一个错误,但如果微软的官方路线是“这种行为是设计的”,我也不会感到惊讶.

当您在结构中配置要封送的数组时,您的选项会受到很大限制.据我所知,您可以将UnmanagedType.SafeArray用于任何VARIANT基元类型,或者您可以使用UnmanagedType.ByValArray,它要求您指定SizeConst – 也就是说,编组器仅支持始终完全是相同的长度.

然后,Marshal.SizeOf函数在计算结构大小时,将数组的大小计算为SizeConst * Marshal.SizeOf(arrayElementType).无论实例指向的数组的实际大小如何,情况总是如此.

该错误似乎是封送程序始终复制数组中的所有元素,即使该数字大于SizeConst.因此,在我的情况下,如果你将SizeConst设置为1,但是提供一个包含6个元素的数组,那么它将根据Marshal.SizeOf分配内存,Marshal.SizeOf为数组数据分配一个插槽,然后继续编组所有6个元素,写过缓冲区的末尾并破坏内存.

参数的堆栈槽以这种方式被破坏的原因只能由编组器为堆栈上的序列化分配内存来解释.通过溢出该缓冲区的末尾,它然后在堆栈中进一步覆盖数据,包括最终写入返回地址的位置以及已经放入堆栈中的插槽的前两个参数.在这个编组操作之后,它然后将指向该堆栈缓冲区的指针写入第三个参数,解释了为什么第三个参数的值实际上是指向数据结构的有效指针.

我很幸运,在我的特定配置下,第6个元素的结尾发生在损坏堆栈中的其他元素之前,因为只有ChangeServiceConfig2W的前两个参数被损坏 – 在ChangeServiceConfig2W返回后代码能够继续执行关于句柄无效的错误.使用更大的数组或更简单的函数,其中由编组器分配的缓冲区更接近堆栈帧的末尾,它可能很好地覆盖堆栈中的重要数据,并导致ExecutionEngineException,如@GSerg所见.

在64位系统上,堆栈上必须有更多的可用空间 – 首先,所有指针现在都是64位宽,这样就可以解决问题.然后,写入缓冲区的末尾并没有达到堆栈的高度,并且没有设法破坏ChangeServiceConfig2W的第一个或第二个参数.这是这段代码在初始测试中的工作方式,看起来是正确的.

在我看来,这是封送者的一个错误;它有足够的信息来避免破坏内存(只是不要编组超过SizeConst元素,因为这是你已经分配的所有内存！),但是它会继续写入分配缓冲区的末尾.我可以看到逆向哲学,即“如果你告诉编组器SizeConst是1,那么就不要提供一个超过1个元素的数组.”但是没有明确的警告,这样做会破坏我阅读的任何文档中的执行环境.考虑到.NET为避免这种类型的腐败而采取的长度,我不得不将其视为封送器中的一个错误.

我已经通过更新DataLock类来使我的代码正常工作,该类暂时将lpsaActions数据准备为指向数组的指针(ChangeServiceConfig2W需要并且默认的P / Invoke编组程序似乎不支持),以隐藏真正的lpsaActions数组和用假1元素阵列替换它.这可以防止封送处理器编组超过1个元素,并且不会发生内存损坏.当DataLock对象为Disposed时,它会将lpsaActions恢复为其先前的值.

我将这个(工作)代码放入一个公共GitHub仓库,以及一个基本相同的C版本,我用它来比较寄存器和堆栈的状态,因为代码流在我的诊断过程中输入了ChangeServiceConfig2W函数：

> https://github.com/logiclrd/TestServiceFailureActionChange

要重现我遇到的问题,请从WindowsAPI / SERVICE_FAILURE_ACTIONSW.cs注释掉这些行：

            // Replace the lpsaActions array with a dummy that contains only one element, otherwise the P/Invoke marshaller
            // will allocate a buffer of size 1 and then write lpsaActions.Length items to it and corrupt memory.
            _originalActionsArray = data.lpsaActions;

            data.lpsaActions = new SC_ACTION[1];

然后,以32位进程运行该程序. (如果您使用的是64位操作系统,则可能需要调整构建配置,以便它指定“首选32位”或直接定位“x86”平台.)

Microsoft可能会也可能不会意识到并修复此错误.至少,微软更新UnmanagedType.ByValArray的文档以包含关于这种可能情况的警告是件好事 – 我不知道如何向他们传达这一点.鉴于.NET的当前版本具有它,我认为最好在将结构编组为非托管代码时避免提供长度不完全等于SizeConst的数组. 🙂