Open Bug 742113 Opened 12 years ago Updated 2 years ago

crash DispatchHookW


(Core :: Widget, defect)

11 Branch
Windows NT



Tracking Status
firefox12 - ---
firefox13 - ---


(Reporter: nrc, Unassigned)



(Keywords: crash, Whiteboard: qa-not-actionable)

Crash Data

+++ 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 - 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 -

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
Depends on Bug 721264, but I'm not authorised to set that in the depends on field :-(
Keywords: reproducible
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!
Depends on: 721264
We only set hooks for GetWindowInfo, SetWindowLongPtrA, SetWindowLongPtrW, SetWindowLongA, SetWindowLongW, TrackPopupMenu, LdrLoadDll, VirtualAlloc, MapViewOfFile, CreateDIBSection. None of which seem to be involved here.
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.
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.
Removing from the top crash list.
Keywords: topcrash
(In reply to Sheila Mooney from comment #7)
> Removing from the top crash list.

Given that, untracking for release.
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?

There are bugs with DispatchHookW in the last 6 months

Closed: 3 years ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → ---
Whiteboard: qa-not-actionable

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.

Severity: critical → S3
You need to log in before you can comment on or make changes to this bug.