TdzResourceDllLoader.GetProcAddressEx in u_dzResourceDllLoader looks up the entry point with its own GetEntryPoint, which walks the export table and never sets the last error. If the name is not found it calls RaiseLastOsErrorEx(GetLastError, ...), so the EOSError carries whatever error code was left over from some earlier, unrelated call.
Measured with Delphi 12 (Win32), using the image of kernel32.dll that is already mapped into the process as the DLL handle:
GetTickCount: found, same address as GetProcAddress
dzNoSuchFunction, SetLastError(0): EOSError ErrorCode=0 ... ERROR= 0, unknown OS error
dzNoSuchFunction, SetLastError(2): EOSError ErrorCode=2 ... ERROR= 2, The system cannot find the file specified
GetProcAddress for the same name: nil, GetLastError=127
In addition, TdzCustomDllLoader documents @raises ENoEntryPoint for both GetProcAddressEx overloads, but TdzDllLoader.GetProcAddressEx (u_dzDllLoader) and TdzResourceDllLoader.GetProcAddressEx both raise EOSError. For TdzDllLoader the error code is at least the right one (127, from GetProcAddress). Raising ENoEntryPoint would break callers that catch EOSError, so either the documentation or the code needs to change.
Not measured: GetEntryPoint casts pointers to DWORD and steps through the 32 bit export name table with a stride of SizeOf(Pointer), so it probably only works for 32 bit programs.
Fixed in revision #2424