API Set Resolution may loop back to module being loaded

[TheWover]

There is a case where a DLL's API Set reference may resolve to the original DLL. An example is Kernel32.dll!InitializeProcThreadAttributeList, which forwards to api-ms-win-core-processthreads-l1-1-0.InitializeProcThreadAttributeList, which resolves back to Kernel32.dll!InitializeProcThreadAttributeList. This causes the API Set to not actually resolve and results in an error when attempting to call the function that was searched for.

[TheWover]

Fixed in a8a783e. Will be merged in v1.1

[ElephantSe4l]

May I ask why that if on 637-640 lines? You are declaring a local variable inside it, but you don't use it. Am I missing something? Maybe debugging purposes?

[TheWover]

Oops, yep, that was for debugging purposes. I'm going to make a few more changes today, so I'll remove that and any other stuff I added for debugging that I missed when pushing.

[TheWover]

@ElephantSe4l Fixed in latest version.

[djhohnstein]

Reopening this issue - has this been tested on Windows Server 2012 R2? Specifically, the InitializeProcThreadAttributeList function like you mentioned. I'm getting errors when trying to resolve it.

[djhohnstein]

To reproduce:

1. Download the dev branch zip file
2. Change the project properties to a Console Application, .NET 4
3. Add the following Program.cs to your project:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace DInvoke
{
    class Program
    {
        public static void Main(string[] args)
        {
            IntPtr fn = DynamicInvoke.Generic.GetLibraryAddress("kernel32.dll", "InitializeProcThreadAttributeList");
        }
    }
}

4. Run the application on x64 Server 2012 R2 instance. The application will bomb out on L627 of DynamicInvoke/Generic.cs as shown:
   

As a workaround, I used GetModuleA and GetProcAddress to get the address of InitializeProcThreadAttributeList