views:

117

answers:

1

This code causes the following exception, sometimes:

"Attempted to read or write protected memory. This is often an indication that other memory is corrupt"

private static TOKEN_GROUPS GetTokenGroups(IntPtr tokenHandle)
{
    var groups = new TOKEN_GROUPS();
    uint tokenInfoLength = 0;
    uint returnLength;

    var res = GetTokenInformation(tokenHandle, TOKEN_INFORMATION_CLASS.TokenGroups, IntPtr.Zero,
                                  tokenInfoLength, out returnLength);

    if (!res && returnLength > 0)
    {
        tokenInfoLength = returnLength;
        var tokenInfo = Marshal.AllocHGlobal((int) tokenInfoLength);
        res = GetTokenInformation(tokenHandle,
                                  TOKEN_INFORMATION_CLASS.TokenGroups,
                                  tokenInfo,
                                  tokenInfoLength,
                                  out returnLength);
        if(res)
        {
            groups = (TOKEN_GROUPS)Marshal.PtrToStructure(tokenInfo, typeof (TOKEN_GROUPS));
        }

        Marshal.FreeHGlobal(tokenInfo);
        CloseHandle(tokenHandle);
    }
    else
    {
        var error = new Win32Exception(Marshal.GetLastWin32Error());
        _log.WarnFormat("Failed evaluate the call to get process token information. {0}", error.Message);
    }
    return groups;
}

The line that fails is groups = (TOKEN_GROUPS)Marshal.PtrToStructure(tokenInfo, typeof (TOKEN_GROUPS)); I would say the exception happens in 1 and every 20 calls to this method. Once it begins happening every call afterwards will throw the exception. Restarting the process causes the error to go away.

IntPtr tokenHandle is the result of:

var processId = GetCurrentProcess();

            _log.InfoFormat("Process ID [{0}]", processId.ToString());

            if (processId != IntPtr.Zero)
            {
                IntPtr tokenHandle;
                if (OpenProcessToken(processId, TOKEN_READ, out tokenHandle))
                {
                    groups = GetTokenGroups(tokenHandle);
                }

EDIT Hopefully this isn't information overload but here's the pinvoke declarations:

     struct TOKEN_GROUPS
    {
        public uint GroupCount;
        [MarshalAs(UnmanagedType.ByValArray, SizeConst = 4000)]
        public SID_AND_ATTRIBUTES[] Groups;
    }

    [StructLayout(LayoutKind.Sequential)]
    struct SID_AND_ATTRIBUTES
    {
        public IntPtr SID;
        public uint Attributes;
    }

    [DllImport("advapi32.dll", SetLastError = true)]
    static extern bool GetTokenInformation(
        IntPtr TokenHandle,
        TOKEN_INFORMATION_CLASS TokenInformationClass,
        IntPtr TokenInformation,
        uint TokenInformationLength,
        out uint ReturnLength);

    [DllImport("advapi32.dll", SetLastError = true)]
    [return: MarshalAs(UnmanagedType.Bool)]
    static extern bool OpenProcessToken(IntPtr ProcessHandle,
        UInt32 DesiredAccess, out IntPtr TokenHandle);

    [DllImport("kernel32.dll")]
    static extern IntPtr GetCurrentProcess();

    enum TOKEN_INFORMATION_CLASS
    {
        TokenUser = 1,
        TokenGroups,
        TokenPrivileges,
        TokenOwner,
        TokenPrimaryGroup,
        TokenDefaultDacl,
        TokenSource,
        TokenType,
        TokenImpersonationLevel,
        TokenStatistics,
        TokenRestrictedSids,
        TokenSessionId,
        TokenGroupsAndPrivileges,
        TokenSessionReference,
        TokenSandBoxInert,
        TokenAuditPolicy,
        TokenOrigin
    }
+2  A: 

My guess is that the error is a result of not correctly freeing up resources, as is the case in your situation. I may be wrong in it being the cause, but it's probably a good idea to wrap the FreeHGlobal and CloseHandle in a finally block, to ensure proper cleaning up.

If the error then persists, it might be something else (wrong structure or wrong data layout in the declaration or wrong LayoutKind for TOKEN_GROUPS?) or wrong use of this particular API (which I'm not too familiar with).

Edit (after your edit)

The problem may very well lay in the necessary SizeConst attribute parameter. Consider the following: the GetTokenInformation has given the size returned in tokeInfoLength. You allocate this. This size is not likely equal to the SizeConst value. If SizeConst is larger than the required size, the Marshal.PtrToStructure will access further then the length that you allocated, because it knows only SizeConst, and this memory may be accessible, and may be not.

To resolve this issue, make sure that the AllocHGlobal call is at least the size of the whole structure as marshalled. Try, for instance, to add 4000 and see if the error returns (other, neater solutions exist, but let's keep it simple for a moment).

Abel
Ok I'll move those calls into the proper place. Good housekeeping either way ;). Thanks for the ideas.
Adam Driscoll
I've tried values of both 8000, 16000 and 20000 and the error still persists :|
Adam Driscoll
@Adam Driscoll: did you try them in AllocHGlobal, or in SizeConst? It should be within AllocHGlobal. But hold on, I'll try it a bit.
Abel
Well at first I tried it in SizeConst and that eventually blew up. I set AllocHGlobal to 4000 and it blew up on the first execution.
Adam Driscoll
I've reduced the array size to 1000 from 4000 and have run the code through 100 iterations without failure. I don't know why the size of the array was so large but I think it was exceeding some limit. I can't imagine a user will be part of 4000 groups ;).
Adam Driscoll
@Adam Driscoll: *I set AllocHGlobal to 4000 and it blew up on the first execution* >> that's more like it and as expected and what I meant ;-). Now we have *early degradation*, and there's a clear reason why it failed originally (allocated less than what the marshaller thought you allocated). Note, you should still make sure that the number you use is also allocated by AllocHGlobal, otherwise, sooner or later, it'll still fail.
Abel
Note: if the number in SizeConst becomes lower than tokenInfoLength there's no real problem, except that you will no fill the whole array with PtrToStructure.
Abel