Closed GoogleCodeExporter closed 8 years ago
Check new version. If the problem is still there, tell me and I would send you a
Debug version.
Original comment by crendk...@gmail.com
on 16 Mar 2010 at 1:56
Unfortunately it still has the same problem.
Original comment by ibrahimk...@gmail.com
on 16 Mar 2010 at 5:59
Please try 0.6. If cannot reproduce the problem in my environment (Windows 7
Ultimate
x64).
Original comment by crendk...@gmail.com
on 18 Mar 2010 at 3:21
Hi Crendking,
I also find a crash of explore.exe (x64 bit) in W2k8 R2 when gdipp is installed
as a
service. After build and deploy a debug DLL, I find that the crash stems from
the
function: ExtTextOutW_hook() with the parameters are: x=20, y=0, lprect=NULL,
and
the "lprect = NULL" will be passed down to "FillRect(hDC, const RECT *lprc,
HBRUSH
hbr)" where the real crash happens (access viloation).
Now I try to fix this issue in function "ExtTextOutW_hook()" by adding the
following
code at the beginning:
//
// The text will not be rendered if the area of the rect is zero.
//
if (x == 0 || y == 0 || lprect == NULL) // Or just "if (lprect == NULL)"
return TRUE;
Then I find that the crash disappears, but all the fonts on the explorer.exe UI
will
not be rendered, living all the UI to have only icons as the attached picture
shows.
I am wondering is it valid to have lprect equals NULL and the length or width
of the
rect is zero here. If it is not valid, maybe the bug is from easyhook. If it is
valid, I am still confused to think about how to render fonts in such zero-area
region.
So Crendking, would you please go on to investigate this issue.
Expecting your ideas, ......
Thanks,
Gary
Original comment by huyueju...@gmail.com
on 19 Mar 2010 at 11:11
Attachments:
Very nice try. However, the logic of ExtTextOutW is far more complicated than
your
thought. It is totally OK if any x, y and string are provided while lprect is
NULL.
According to MSDN
(http://msdn.microsoft.com/en-us/library/dd162713%28VS.85%29.aspx),
lprect is used to draw background rect and clipping. The background drawing
occurs
only if ETO_OPAQUE is specified in the options parameter. Therefore if both
lprect ==
NULL and ETO_OPAQUE is specified, the crash happens.
It is more considered as a bug in the code that calls ExtTextOutW, not gdipp's
fault.
gdipp simply believes the parameters are already checked by caller. It is still
surprising the caller is explorer.exe, since this never happens to me. I guess
this
could be more possible to be caused by plugins, extensions and hooks that lives
in
explorer.exe process space.
It is not a pain to do a bit checks in gdipp. I will fix it in the next
release. Thanks!
Original comment by crendk...@gmail.com
on 19 Mar 2010 at 12:11
Thanks. I will do a study about this:).
There is another singleton issue I mentioned in the themex thread:
http://bbs.themex.net/showthread.php?p=985656#post985656
If you have time, you can take a look at it.
Original comment by huyueju...@gmail.com
on 19 Mar 2010 at 2:32
I used the latest snapshot in the repository and it works great. There is still
one
problem though. When I log in the computer first time, desktop shows a blue
background for a few seconds before it shows the wallpaper. It does not happen
if I
remove gdipp.
Original comment by ibrahimk...@gmail.com
on 22 Mar 2010 at 4:06
0.7.1 works like a charm for me too without crashing explorer.exe gdipp is a
godsend :)
Original comment by Mpdre...@gmail.com
on 25 Mar 2010 at 10:10
Original comment by crendk...@gmail.com
on 7 Apr 2010 at 3:10
Original issue reported on code.google.com by
ibrahimk...@gmail.com
on 10 Mar 2010 at 3:24