[PATCH] kdecore crashes LoadLibrary calls

Ralf Habacker ralf.habacker at freenet.de
Wed Apr 1 10:06:36 CEST 2009


Ralf Habacker schrieb:
> Ralf Habacker schrieb:
>   
>> Patrick Spendrin schrieb:
>>     
>>> Hi,
>>>
>>> I have a small patch here which fixes a problem I recently got aware of:
>>> if you try to make a regsvr32 kdecore.dll it will fail saying that
>>> LoadLibrary was not achieved (simply try it). The correct error message
>>> would have been a missing entrypoint for DllRegisterServer though.
>>> After searching for quite a while I found the problem:
>>> When you load kdecore linked to an executable, the image will be located
>>> at the address 0x0040000. When you load kdecore directly via regsvr32,
>>> the image will have the address 0x10000000 (0x1 0x0) instead.
>>> When trying to read from the first one then you will obviously get a
>>> "crash". As I am unable to find out where our image is (this is the
>>> address of the HINSTANCE parameter in the DllMain) as the constructor of
>>> the static class will be called before running the DllMain, I have now
>>> changed it so that the code will be called from the DllMain with the
>>> parameter.
>>>
>>> As this patch might change the behaviour of your debug output, please
>>> check if it works for you | comment it.
>>>   
>>>       
>> patch is committed.
>>     
> reverted patch - some more tests with kde applications and this patch 
> shows that the HINSTANCE parameter is now always 0x10000000, which let 
> kdecore crashes :-(
>   
After digging a little more into this issue I found out that this patch 
did not fix the initial problem. The HINSTANCE value of DLLMain returns 
the image base address of the memory mapped dll. To detect the subsystem 
type is is required to get the image base address of the memory mapped 
executable e.g kate.exe or regsvr32.exe. For those cases the windows api 
function getModuleHandle(NULL) could be used - when calling with a NULL 
parameter it returns exactly the image base address of the executable.

I applied a patch to svn which fixes this issue this way.

Ralf



More information about the Kde-windows mailing list