Question to plugin writers: Lister crash with TC7?

[ghisler(Author)]

This question goes to the writers of Lister plugins. In the TC7 beta forum, a lister crash was reported here:

http://ghisler.ch/board/viewtopic.php?t=12126

Unfortuantely I couldn't reproduce this error, neither on XP SP1, SP2 nor Windows 2000. I also tried with the DM2 tool mentioned in that thread, no luck.

Can anyone of you reproduce this error with your lister plugins?

[fg_2002fr]

Hello Christian,

some ways was investigate in the fileinfo topic, e.g. DLL version used , UPXed plugins ... but without success for the moment. I cannot reproduce this behaviour on my computer but it arise with both fileinfo and mmedia which use a common base of sources.

I ear that also SGviewer, IniEd, and excellence shows this error.
May be we could find a common point between all.
fileinfo and mmedia was developed with VisualC++ 6.0 using MFC libraries from microsoft.

[Norbert]

It's crashing in function LpkUseGDIWidthCache in C:\WINDOWS\system32\lpk.dll if you have installed "additional language support". German XP: "Systemsteuerung->Regions- und Sprachoptionen->Sprachen->Zusätzliche Sprachunterstützung"

[ghisler(Author)]

2Norbert
Do you mean the extra languages for Asian languages? I have installed them too, no problem!

LpkUseGDIWidthCache

I cannot find much information about this function. Can you see which higher level GDI function is calling it?

[Norbert]

2Norbert
Do you mean the extra languages for Asian languages? I have installed them too, no problem!

I have installed both, also the right-to-left option (Thai).

If I delete the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LanguagePack] branch and reboot there is no exception.

If I import the branch again and reboot, the exception is back.

Can you see which higher level GDI function is calling it?

TC catches the exception and shows a message box. Is there a switch in TC that the exceptions went to the debugger?

lpk.dll!_LpkUseGDIWidthCache@20() + 0x42 bytes
gdi32.dll!_GetTextExtentPointAInternal@20() + 0x134f0 bytes
gdi32.dll!_GetTextExtentPoint32A@16() + 0x18 bytes
totalcmd.exe!00420b31()
totalcmd.exe!005b279f()
totalcmd.exe!005b2914()
totalcmd.exe!005b20b6()
totalcmd.exe!005abd1c()
user32.dll!_CallNextHookEx@16() + 0x3b bytes
MSCTF.dll!SysGetMsgProc() + 0x83 bytes
user32.dll!_DispatchHookW@16() + 0x31 bytes
user32.dll!_CallHookWithSEH@16() + 0x21 bytes
user32.dll!___fnHkINLPMSG@4() + 0x25 bytes
totalcmd.exe!0043c4fc()
totalcmd.exe!00413752()
user32.dll!_InternalCallWinProc@20() + 0x28 bytes
user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes
user32.dll!_DispatchClientMessage@20() + 0x4d bytes
user32.dll!___fnDWORD@4() + 0x24 bytes
ntdll.dll!_KiUserCallbackDispatcher@12() + 0x13 bytes
user32.dll!_NtUserDispatchMessage@4() + 0xc bytes
user32.dll!_DispatchMessageA@4() + 0xf bytes
totalcmd.exe!00418b1f()
totalcmd.exe!00418b4a()
totalcmd.exe!00418d04()
totalcmd.exe!0060b147()
kernel32.dll!_BaseProcessStart@4() + 0x23 bytes

[ghisler(Author)]

I have installed both, also the right-to-left option (Thai).

OK, I have now also added the Thai option - no change, there is simply no crash.

GetTextExtentPoint32

It seems that TC is trying to measure some text width. I have put a breakpoint on all lines in Lister which call functions from the GetTextExtent family, but none was called when lister started up directly with a plugin. But from your stack dump we can clearly see that it was called by TC and not by a plugin...

[Norbert]

The error has gone, but I don't know why. I have installed/upgraded some programs (e.g. Irvanview 3.99) and installed the newest ATI drivers (6.11). Either the bug depends on where TC is lying in memory (uninitialized variable or pointer) or it was a bug of the ATI 6.10 driver. Unfortunately I have already deleted the old ATI drivers.

[ghisler(Author)]

And I could finally reproduce it - with Thai and far east languages on Windows XP SP1! It has to do with hiding the cursor - a function which was called even when the cursor was already hidden. It tried to find the cursor location screen, and it seems that GetTextExtent (which was used for that) had problems with the interpretation of some characters of the binary image file!

Thanks for your help, the reference to GetTextExtent gave me the right clue!

[Norbert]

And I could finally reproduce it

Hurray!

Thanks for your help, ...

You're welcome!