We should use DETOUR_TRACE instead of OutputDebugStrring?

DETOUR_TRACE can not output any message if no define DETOUR_DEBUG, I use OutputDebugString to force output message for tell user to pay attention to this is a unnormal exe.

Should finish with a ] if it starts with [. Also OutputDebugString doesn't automatically append a new line, so you want to add \n at the end of the string.

\r\n is in next line, this is a const string concat operation.

DETOUR_TRACE can not output any message if no define DETOUR_DEBUG, I use OutputDebugString to force output message for tell user to pay attention to this is a unnormal exe.

So the users is going to just happen to be running under a debugger?
OutputDebugString only outputs a message if a debugger is attached.

It's not really detours job to emit messages as library.
I think it would make more sense to just return a rich
error code in LastError, and let the caller handle that case
explicitly.

Dbgview and many debug tools can capture the debug output statements of the application without being debugged.
In fact, it doesn't matter whether the user notices this message, it's like an MFC running warning.
like

		TRACE(traceAppMsg, 0, _T("Warning: calling DestroyWindow in CWnd::~CWnd; ")
		   _T("OnDestroy or PostNcDestroy in derived class will not be called.\n"));

in

CWnd::~CWnd()
{
	if (m_hWnd != NULL &&
		this != (CWnd*)&wndTop && this != (CWnd*)&wndBottom &&
		this != (CWnd*)&wndTopMost && this != (CWnd*)&wndNoTopMost)
	{
		TRACE(traceAppMsg, 0, _T("Warning: calling DestroyWindow in CWnd::~CWnd; ")
		   _T("OnDestroy or PostNcDestroy in derived class will not be called.\n"));
		DestroyWindow();
	}

The user cannot handle it because the only way to deal with it is to modify the PE file on the disk, but this file may contain a digital signature, and the modification may be illegal, and it only has a problem when it is launched through Detours' createwith API. The user uses Explorer. exe starts it, or directly calls the CreateProcess function to start it, there is no problem, these are enough to prove a defect of Detours.
The only improvement is that calling OutputDebugString in a non-debugging state may modify the value of LastError of the current thread, which has been fixed in the latest submission.

I think you could simplify this code by switching this to a do-while loop, that way the initial ReadProcessMemory doesn't need to be special cased.

I don't quite understand your expression, and here ImageImport.Name is a judgment condition, so I think it is more appropriate to use a while-do loop.

The loop maybe better:

for (int count=0;;++count) {
        if (!ReadProcessMemory(hProcess, pImageImport, &ImageImport, sizeof(ImageImport), NULL)) {
            DETOUR_TRACE(("ReadProcessMemory failed: %u\n", GetLastError()));;
            goto finish;
        }
        if (ImageImport.Name) {
            inh.IMPORT_DIRECTORY.Size += sizeof(IMAGE_IMPORT_DESCRIPTOR);  
            ++pImageImport;
            continue;
        }
        if(count) inh.IMPORT_DIRECTORY.Size += sizeof(IMAGE_IMPORT_DESCRIPTOR);  
        break;
}

Updated

Although the code becomes able to get the correct result after you update and fix it, but at the same time it is difficult to read. In my original code, only run inh.IMPORT_DIRECTORY.Size+=sizeof(IMAGE_IMPORT_DESCRIPTOR); under the condition of ImageImport.Name , and you changed this code but first executed inh.IMPORT_DIRECTORY.Size+=sizeof(IMAGE_IMPORT_DESCRIPTOR); and ignored the conditions of ImageImport.Name. It seems that it is just to make the result correct, so I think it breaks the readability and there is no need to modify it.

why, it's easy to unstand, just calc size until the name is null

Update again, the latest code logical is equal to your original code

OK, now the code has been adjusted to be more in line with official recommendations.