Open Bug 742113 Opened 10 years ago Updated 7 months ago
+++ 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
Depends on Bug 721264, but I'm not authorised to set that in the depends on field :-(
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!
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.
(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?
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.