"Paul Vriens" paul.vriens@xs4all.nl wrote:
Process Explorer tries to load a dll with LoadLibraryA. This fails and NULL is returned. PE is however still trying to do GetProcAddress on this (not loaded) dll. Windows returns ERROR_PROC_NOT_FOUND, we get into an exception.
I will send a test tonight that confirms the above.
Changelog Return ERROR_PROC_NOT_FOUND if hModule is NULL
Probably the test also should confirm whether it's a responsibility of dlls/ntdll/loader.c,LdrGetProcedureAddress() to return STATUS_ENTRYPOINT_NOT_FOUND which will be converted by GetProcAddress to ERROR_PROC_NOT_FOUND.
"Dmitry Timoshkov" dmitry@baikal.ru writes:
Probably the test also should confirm whether it's a responsibility of dlls/ntdll/loader.c,LdrGetProcedureAddress() to return STATUS_ENTRYPOINT_NOT_FOUND which will be converted by GetProcAddress to ERROR_PROC_NOT_FOUND.
I suspect what is happening here is that GetProcAddress, like most other kernel functions, treats 0 as meaning 'main exe module', since passing other invalid module handles results in ERROR_MOD_NOT_FOUND as expected. Testing this will be a bit tricky since it requires building an exe with an export table, but that should be feasible with Mingw.
On Mon, 2005-07-11 at 16:07, Alexandre Julliard wrote:
"Dmitry Timoshkov" dmitry@baikal.ru writes:
Probably the test also should confirm whether it's a responsibility of dlls/ntdll/loader.c,LdrGetProcedureAddress() to return STATUS_ENTRYPOINT_NOT_FOUND which will be converted by GetProcAddress to ERROR_PROC_NOT_FOUND.
I suspect what is happening here is that GetProcAddress, like most other kernel functions, treats 0 as meaning 'main exe module', since passing other invalid module handles results in ERROR_MOD_NOT_FOUND as expected. Testing this will be a bit tricky since it requires building an exe with an export table, but that should be feasible with Mingw.
Hi,
in this is case it's definitly not a 'main exe module'. The trace (with patch) shows:
000c:Call kernel32.LoadLibraryA(0044a1a4 "aclui.dll") ret=0041c586 .... 000c:warn:module:load_dll Failed to load module L"aclui.dll"; status=c0000135 ... 000c:Ret ntdll.LdrLoadDll() retval=c0000135 ret=595674c6 000c:Call ntdll.RtlFreeHeap(7bde0000,00000000,7be3c920) ret=59557f92 000c:Ret ntdll.RtlFreeHeap() retval=00000001 ret=59557f92 000c:Call ntdll.RtlNtStatusToDosError(c0000135) ret=5956752d 000c:Ret ntdll.RtlNtStatusToDosError() retval=0000007e ret=5956752d ... 000c:Ret kernel32.LoadLibraryA() retval=00000000 ret=0041c586 000c:Call kernel32.GetProcAddress(00000000,0044a1b0 "CreateSecurityPage") ret=0041c589 000c:Call ntdll.RtlNtStatusToDosError(c000007a) ret=595678e7 000c:Ret ntdll.RtlNtStatusToDosError() retval=0000007f ret=595678e7 000c:Ret kernel32.GetProcAddress() retval=00000000 ret=0041c589
So the code just loads the module without checking and then does a GetProcAddress where it will check the GetLastError. (CreateSecurityPage is part of aclui.dll)
I will create a test for LdrGetProcedureAddress anyway.
Cheers,
Paul.
Paul Vriens Paul.Vriens@xs4all.nl writes:
in this is case it's definitly not a 'main exe module'. The trace (with patch) shows:
Oh sure, it's not a feature that normal apps would be using anyway, it just explains why the behavior of GetProcAddress is not identical to that of LdrGetProcedureAddress. BTW I managed to build a binary with mingw to confirm my theory, I'll put in a fix.
On Mon, 2005-07-11 at 20:37, Alexandre Julliard wrote:
Paul Vriens Paul.Vriens@xs4all.nl writes:
in this is case it's definitly not a 'main exe module'. The trace (with patch) shows:
Oh sure, it's not a feature that normal apps would be using anyway, it just explains why the behavior of GetProcAddress is not identical to that of LdrGetProcedureAddress. BTW I managed to build a binary with mingw to confirm my theory, I'll put in a fix.
OK that fixes it. One less segfault in Process Explorer :-).
Thanks,
Paul.
-
Alexandre Julliard -
Dmitry Timoshkov -
Paul Vriens