792067 - crash in nsWindow::SetCursor with QuickGesture.dll (Asus Smart Gesture)

Status: REOPENED

(Core :: Widget: Win32, defect, P5)

Description

[Robert Kaiser]

This bug was filed from the Socorro interface and is 
report bp-30306783-9530-4c73-8de8-e34372120918 .
============================================================= 

Top 10 frames:

0 		@0x100530 	
1 	xul.dll 	nsWindow::SetCursor 	widget/windows/nsWindow.cpp:2349
2 	xul.dll 	nsEventStateManager::SetCursor 	content/events/src/nsEventStateManager.cpp:3760
3 	xul.dll 	nsEventStateManager::UpdateCursor 	content/events/src/nsEventStateManager.cpp:3577
4 	xul.dll 	nsEventStateManager::PreHandleEvent 	content/events/src/nsEventStateManager.cpp:1138
5 	xul.dll 	PresShell::HandleEventInternal 	layout/base/nsPresShell.cpp:6387
6 	xul.dll 	PresShell::HandlePositionedEvent 	layout/base/nsPresShell.cpp:6138
7 	xul.dll 	PresShell::HandleEvent 	layout/base/nsPresShell.cpp:5938
8 	xul.dll 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:865
9 	xul.dll 	PresShell::DispatchSynthMouseMove 	layout/base/nsPresShell.cpp:3395
10 	xul.dll 	PresShell::ProcessSynthMouseMoveEvent 	layout/base/nsPresShell.cpp:5177


This is pretty low volume, currently #91 in 15, but rising.

There's a pretty obvious correlation for Firefox 15.0.1 here:

100% (153/153) vs.   0% (191/157345) QuickGesture.dll

Comment 1

[Brian R. Bondy [:bbondy]]

Is it possible that a dll that loads itself into our process has a duplicate resource ID to something that is not a cursor?

I noticed in the MSDN documentation for LoadCursor, it can return a valid handle even if the resource is not a cursor.  I think replacing the calls with LoadImage would solve that.

> If lpCursorName is a pointer to any type of resource other than a cursor
>  (such as an icon), the return value is not NULL, even though it is not 
> a valid cursor handle.

Comment 2

[Jim Mathies [:jimm]]

Looks like it might be tied to this asus software package - 

http://driverscollection.com/?aid=44042845605f23a5f69d5853798

Comment 3

[Brian R. Bondy [:bbondy]]

(In reply to Brian R. Bondy [:bbondy] from comment #1)
> Is it possible that a dll that loads itself into our process has a duplicate
> resource ID to something that is not a cursor?
> 

I don't think that's possible since you would have to use a handle to the dll in question where the resource exists, but I can't see how else this would happen so that's why I mentioned it.

Comment 4

[Brian R. Bondy [:bbondy]]

Perhaps an API hook, maybe ensuring what we loaded is in fact an icon is a good idea.

Comment 5

[Saurabh Anand [:sawrubh]]

@Brian So replacing LoadCursor with LoadIcon wouldn't work ? Ideas about what needs to be done. I would like to work on fixing this.

Comment 6

[Brian R. Bondy [:bbondy]]

We could try that, I'm not confident it will actually solve the problem.  Jim do you think it would be worth doing?

Comment 7

[Jim Mathies [:jimm]]

Really seems to be correlated to the Asus quick gesture code, comments in the crash reports seem to back this up.

Maybe some outreach to asus to try to get a hold of their engineers would be a good first step. If it's crashing fx, it might be crashing other programs considering how run of the mill this code is.

http://www.iobit.com/process/q/9/quickgesture-exe-67368.html

https://crash-stats.mozilla.com/report/list?product=Firefox&platform=windows&query_search=signature&query_type=contains&query=nsWindow%3A%3ASetCursor&reason_type=contains&date=12%2F05%2F2012%2013%3A55%3A59&range_value=1&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=nsWindow%3A%3ASetCursor%28nsCursor%29

Another option would be to blocklist QuickGesture.dll and/or MinHook.32.dll. 

cc'ing Kev Needham. Kev, not sure if you're still doing outreach. If not hopefully you know who is.

Comment 8

[Brian R. Bondy [:bbondy]]

I was thinking of block listing QuickGesture too but not sure what negative effects that will have without having the hardware that uses it.

Comment 9

[Robert Kaiser]

  nsWindow::SetCursor(nsCursor)|EXCEPTION_ACCESS_VIOLATION_EXEC (277 crashes)
    100% (277/277) vs.   0% (353/145097) QuickGesture.dll
          0% (0/277) vs.   0% (8/145097) 1.0.0.4
          0% (0/277) vs.   0% (9/145097) 1.0.13.0
        100% (277/277) vs.   0% (334/145097) 1.0.24.0
          0% (0/277) vs.   0% (2/145097) 1.0.3.0

So there's a single version of that DLL that is apparently correlated to this crash.

And this signature is #26 on 17.0.1 desktop and a startup crash so it qualifies for topcrash.

Comment 10

[Scoobidiver (away)]

Here are the latest correlations per version in 18.0:
  nsWindow::SetCursor(nsCursor)|EXCEPTION_ACCESS_VIOLATION_EXEC (107 crashes)
    100% (107/107) vs.   0% (126/60471) QuickGesture.dll
          0% (0/107) vs.   0% (1/60471) 1.0.0.4
          0% (0/107) vs.   0% (1/60471) 1.0.13.0
        100% (107/107) vs.   0% (124/60471) 1.0.24.0

The latest Asus Smart Gesture version is 1.0.36: http://support.asus.com/Download.aspx?SLanguage=en&m=Smart+Gesture that is currently unaffected.

Comment 11

[Scoobidiver (away)]

It's #24 top browser crasher in 20.0.1, #48 in 21.0b3, and #25 in 22.0a2 so no longer a top crasher.

Comment 12

[Iulian Timis]

This crash is really annoying and reproducing allot on my FF21 (Win 7) and I'm using the latest drivers on my ASUS notebook.
This is the crash report that I've submitted https://crash-stats.mozilla.com/report/index/2bdd1ffc-8ca2-402c-ac16-759122130606
Thank you.

Comment 13

[Scoobidiver (away)]

Iulian, disable Asus Smart Gesture.

Comment 14

[Iulian Timis]

(In reply to Scoobidiver from comment #13)
> Iulian, disable Asus Smart Gesture.

But I need to use the Asus Smart Gesture. Is there any change on this bug getting fixed soon? Thanks

Comment 15

[Robert Kaiser]

It's very much possible that ASUS Smart Gesture is actually the cause of this crash and not our code - could you report the problem to them and ask them if they can fix it?

Comment 16

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

Crash volume for signature 'nsWindow::SetCursor':
 - nightly (version 51): 0 crashes from 2016-08-01.
 - aurora  (version 50): 1 crash from 2016-08-01.
 - beta    (version 49): 77 crashes from 2016-08-02.
 - release (version 48): 273 crashes from 2016-07-25.
 - esr     (version 45): 18 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       0       0       0
 - aurora        0       0       1
 - beta         30      31       8
 - release      90      79      35
 - esr           0       0       0

Affected platform: Windows

Crash rank on the last 7 days:
           Browser     Content   Plugin
 - nightly
 - aurora
 - beta    #708
 - release #214
 - esr     #1877

Comment 17

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

Crash volume for signature 'nsWindow::SetCursor':
 - nightly (version 53): 0 crashes from 2016-11-14.
 - aurora  (version 52): 7 crashes from 2016-11-14.
 - beta    (version 51): 105 crashes from 2016-11-14.
 - release (version 50): 1610 crashes from 2016-11-01.
 - esr     (version 45): 26 crashes from 2016-07-06.

Crash volume on the last weeks (Week N is from 01-02 to 01-08):
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       0       0       0       0       0       0       0
 - aurora        0       0       0       4       0       0       0
 - beta          4       4      11      23      21      25      11
 - release     207     210     239     263     271     231     100
 - esr           1       0       0       1       2       0       1

Affected platform: Windows

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly
 - aurora  #718
 - beta    #713
 - release #225
 - esr     #3474

Comment 18

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

Closing because no crashes reported for 12 weeks.

Comment 19

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

Closing because no crashes reported for 12 weeks.

Comment 20

[Calixte Denizet (:calixte)]

There are still some crashes so reopen it.

Comment 21

[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.