742113 - crash DispatchHookW

Status: REOPENED

(Core :: Widget, defect)

Description

[Nick Cameron [:nrc]]

+++ This bug was initially created as a clone of Bug #733892 +++

This bug was filed from the Socorro interface and is 
report bp-93934f25-a07e-4139-9056-e25392120307 .
============================================================= 

Seen while looking at B5 crash stats. This has been around in previous releases - https://crash-stats.mozilla.com/report/list?signature=DispatchHookW links to the reports. In the past day this ranked #24 in Beta 5 crashes.

__fnHkINLPMOUSEHOOKSTRUCTEX shows up in crash stats as a signature on its own - https://crash-stats.mozilla.com/report/list?signature=__fnHkINLPMOUSEHOOKSTRUCTEX

Frame 	Module 	Signature [Expand] 	Source
0 		@0x6d7172e3 	
1 	user32.dll 	DispatchHookW 	
2 	user32.dll 	CallHookWithSEH 	
3 	user32.dll 	__fnHkINLPMOUSEHOOKSTRUCTEX 	
4 	ntdll.dll 	KiUserCallbackDispatcher 	
5 	ntdll.dll 	KiUserApcDispatcher 	
6 	user32.dll 	_PeekMessage 	
7 	shell32.dll 	shell32.dll@0x160bb1 	
8 	shell32.dll 	shell32.dll@0x328a6 	
9 	shell32.dll 	shell32.dll@0x2240e 	
10 	shell32.dll 	shell32.dll@0x21dc9 	
11 	shell32.dll 	shell32.dll@0x21ee1 	
12 	shell32.dll 	shell32.dll@0x21e6f 	
13 	xul.dll 	nsLocalFile::Launch 	xpcom/io/nsLocalFileWin.cpp:2856
14 	xul.dll 	XPCNativeMember::GetCallInfo 	js/xpconnect/src/XPCWrappedNativeInfo.cpp:59
15 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
16 	xul.dll 	xul.dll@0xfb31f 	
17 		@0x6 	
18 	mozjs.dll 	JS_DefinePropertyById 	js/src/jsapi.cpp:3544
19 	xul.dll 	DefinePropertyIfFound 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:452
20 		@0xffffff86

Comment 1

[Nick Cameron [:nrc]]

Depends on Bug 721264, but I'm not authorised to set that in the depends on field :-(

Comment 2

[Nick Cameron [:nrc]]

Makoto Kato or Mike Hommey could one of you please take a look at this and let us know if there is anything we are doing with Windows global hooks or the dll blocker that might be contributing to this crash? Thanks!

Comment 3

[Mike Hommey [:glandium]]

We only set hooks for GetWindowInfo, SetWindowLongPtrA, SetWindowLongPtrW, SetWindowLongA, SetWindowLongW, TrackPopupMenu, LdrLoadDll, VirtualAlloc, MapViewOfFile, CreateDIBSection. None of which seem to be involved here.

Comment 4

[Makoto Kato [:m_kato]]

When crashing from calling by DispatchHookW, I think that hook procedure is gone away.

I think that a DLL (maybe 3rd party DLL) doesn't call UnhookWindowsHookEx then DLL is unloaded.  So hook procedure is out of memory, so it will crash.

If we trace SetWindowHookEx call (by hook this API), we can analyze this crash.

Comment 5

[Makoto Kato [:m_kato]]

s/SetWindowHookEx/SetWindowsHookEx

Comment 6

[Sheila Mooney]

I only see 19 crashes in 12b4 which is WAY down from previous volumes. We removed the tracking and top crash keyword for bug 733892. Do we do the same for this one or did we leave it as tracking for a particular reason.

Comment 7

[Sheila Mooney]

Removing from the top crash list.

Comment 8

[Alex Keybl [:akeybl]]

(In reply to Sheila Mooney from comment #7)
> Removing from the top crash list.

Given that, untracking for release.

Comment 9

[(no longer active)]

I think the right way to fix these kinds of crashes is to figure out how SetWindowsHookEx injects DLLs into our address space, and then defend against that using our existing blocklist mechanism.

I still expect LdrLoadDll to be called when a DLL is hooked into our address space by a global hook.  Nick, could you please verify that by creating a test app which installs a global hook and breaking inside patched_LdrLoadDll to see if gets called when the hook is installed?

Comment 10

[Pablo]

There are bugs with DispatchHookW in the last 6 months

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.