Fatal interference with comctl32.dll

RESOLVED INVALID

Status

--
critical
RESOLVED INVALID
12 years ago
2 years ago

People

(Reporter: mikhail.zabaluev, Unassigned)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Xulrunner trunk as of 2006-05-18

In my embedding application on Windows, toolbars from the Common Controls DLL are used to invoke commands in an embedded editor (which resides in an MDI child frame).
When toolbar button state is updated, an access violation occurs in comctl32.dll. The innermost stack frame reported to belong to Mozilla is in _MD_CURRENT_THREAD, but this is shown to be called from within user32.dll, and the next Mozilla frame up is DetectWindowMove, below another bunch of user32.dll and comctl32.dll frames. See the attachment.
Embedding the editor without toolbars, or with toolbars not changing state in the course of idle handling, does not produce such a crash.


Reproducible: Always




Common controls version 6.0 is required in the application's manifest.
The _WIN32_IE compilation macro is set to 0x501.
(Reporter)

Comment 1

12 years ago
Created attachment 222484 [details]
Call stack as copied from a Visual C++ 2005 debugger window

Comment 2

12 years ago
erm. use windbg and !symfix+ c:\symbols
you can do the same thing for vc2k5, but i don't remember how.

do you have symbols for mozilla?
(Reporter)

Comment 3

12 years ago
Created attachment 222618 [details]
Call stack from WinDbg

OK, here is the call stack from WinDbg with some raw function arguments.
Xulrunner code does not seem to be directly involved. However, during a callback to DetectWindowMove the stack immediately up is:
USER32!DispatchHookA
USER32!fnHkINLPCWPSTRUCTA
USER32!__fnDWORD

The lowermost function then calls USER32!XyCallbackReturn which returns the control to the system, and then the crash occurs.

Thanks for your help, I'll try to simplify the UI to exclude the rebar and see if it fixes my problem.

Comment 4

12 years ago
fwiw, !analyze -v is my friend. (there are lots of other tricks too....)
(Reporter)

Comment 5

12 years ago
Sorry, it was my fault. Xulrunner is acquitted on all counts.
Windows Common Controls could be more robust against programmer's stupidity, however.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
(Assignee)

Updated

2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.