171063 - [ActiveX] crash with Norton AntiVirus DLL

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Description

[Adam Lock]

From Nick Bradbury - TopStyle Software.

I posted a question in the embedding newsgroup about this several days
ago, but since there hasn't been a reply yet I'm hoping you don't mind
email.

Lately I've been getting a large number of support questions from
TopStyle customers reporting a conflict between the Mozilla control and
Norton AntiVirus.  If the user has the Gecko preview enabled in TopStyle
and they then close the preview (which frees the control), they see an
error message stating "Access violation in NavShExt.dll."

NavShExt.dll is Norton's AntiVirus shell extension DLL.  I've sent a
query to Symantec hoping to find out more about this DLL, but I was
hoping in the meantime you might have a clue as to why this is
happening.

Comment 1

[Adam Lock]

Link to Symantec support thread:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?article=%3C1020826145030.4934372656%40servicenews.symantec.com%3E&autoconf=yes&autolink=yes&automail=yes&group=symantec.support.winnt.nortonantivirus2002.general&internetconnection=Cable+Modem&mini_version=nav_2002&product=nav&product_name=Norton+AntiVirus&servicepack=2&submit.x=121&submit.y=13&supportedoperatingsystem=Windows+2000&tpre=sg&version_name=2002+for+Windows+2000%2FNT%2FMe%2F98%2FXP&

Comment 2

[Bill Mason]

FWIW, I see this problem as well when using Gecko embedded in the current
HTML-Kit beta (http://www.chami.com/html-kit/beta/), but never when using Gecko
embedded in HomeSite 5.0.

I can reproduce this everytime on my Win98 system in TopStyle and HTML-Kit.

Comment 3

[Nick Bradbury]

Unlike Bill (#2), I see this problem with HomeSite 5.  In addition, Internet 
Explorer crashes due to this error when I view Adam's IE test page 
(http://www.iol.ie/~locka/mozilla/mozctltest1.htm).

Comment 4

[Adam Lock]

I managed to replicate in IE using the NS7.0 control. The stack trace (below)
suggests that NavShExt.dll is registered as a browser helper object. The Mozilla
control loads these up so helper objects can subscribe to events, trigger
browsing etc. just like they can in IE. For some reason the Norton DLL is
unhappy when the control tries to unload it and is crashing.

Perhaps I should just remove support for them altogether since they're not used
extensively.

The workaround for the time being is to run regedit and into
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Browser
Helper Objects" and disable the Norton extension. On my machine that's the key
starting with "{BDF3430...". A simple way to disable it is to stick a couple of
'x' characters at the front of its key.

Talkback ID is TB12775809H.

NavShExt.dll + 0x1509 (0x01191509)
CMozillaBrowser::UnloadBrowserHelpers
[d:\builds\seamonkey\mozilla\embedding\browser\activex\src\control\MozillaBrowser.cpp,
line 1435]
CMozillaBrowser::OnDestroy
[d:\builds\seamonkey\mozilla\embedding\browser\activex\src\control\MozillaBrowser.cpp,
line 456]
CMozillaBrowser::ProcessWindowMessage
[d:\builds\seamonkey\mozilla\embedding\browser\activex\src\control\MozillaBrowser.h,
line 169]
ATL::CWindowImplBaseT >::WindowProc
[C:\PROGRA~1\MICROS~2\VC98\ATL\INCLUDE\atlwin.h, line 2115]
USER32.dll + 0x1b60 (0x77e11b60)
USER32.dll + 0x2f29 (0x77e12f29)
USER32.dll + 0x2f4f (0x77e12f4f)
ntdll.dll + 0x2032f (0x77fa032f)
ATL::IOleInPlaceObjectWindowlessImpl::InPlaceDeactivate
[C:\PROGRA~1\MICROS~2\VC98\ATL\INCLUDE\atlctl.h, line 2477]
mshtml.dll + 0xd9b56 (0x70d29b56)
mshtml.dll + 0xa1d5b (0x70cf1d5b)
mshtml.dll + 0xd9682 (0x70d29682)
mshtml.dll + 0x6498c (0x70cb498c)
mshtml.dll + 0x645eb (0x70cb45eb)
mshtml.dll + 0x102f2f (0x70d52f2f)
mshtml.dll + 0x10397a (0x70d5397a)
mshtml.dll + 0xa6e03 (0x70cf6e03)
mshtml.dll + 0xa6bcc (0x70cf6bcc)
mshtml.dll + 0x1bc1 (0x70c51bc1)
USER32.dll + 0x1b60 (0x77e11b60)
USER32.dll + 0x1cca (0x77e11cca)
USER32.dll + 0x1ddf (0x77e11ddf) 

Comment 5

[Adam Lock]

Attachment: Patch

Patch changes what registry key the control reads for browser helper objects.
Instead of reading the IE list of BHOs the control reads Mozilla\ActiveX
Control\Browser Helper Objects. In other words BHOs must be explicitly
registered (and therefore must implicitly work) with the control. I've also
added some try/catch blocks around calls to the BHOs and also modified how the
array of BHOs is stored in the control.

I've also changed naming convention style on some constants from Hungarian to
Mozilla.

Reviews please?

Comment 6

[Adam Lock]

Comment on attachment 107010 [details] [diff] [review]
Patch

Hi, can I have an r/sr for this please?

Patch is essentially simple - I've just changed the registry key the control
reads browser helper objects from so it is won't pick up misbehaved ones. I've
also put in some try/catch blocks as well.

Comment 7

[Chak Nanga]

Comment on attachment 107010 [details] [diff] [review]
Patch

r=chak

Comment 8

[Adam Lock]

Attachment: Patch updated

Much cleaner patch updated after recent control upheaval.

Comment 9

[Mike Ruskai]

I've run into this bug big time with my program.

I just downloaded a trial version of NAV 2003, as well as the latest nightly
embedding build (mozctl.dll dated 1/5/2003 12:10).

I re-registered the control so it'd be using the latest version, and I still get
the access violation in navshext.dll when the control is unloaded.

I've verified (with a dependency walker) that the latest control DLL is being used.

Disabling the helper registry entry does, but that's not an ideal solution.

That, coupled with the fact that "ActiveX Control" doesn't exist under the main
Mozilla key, makes it clear that the patch you've created is not in the source
tree at all.

I'm downloading the nightly source right now, but I find it likely that it will
not be friendly to my compiler (BCB 6).

Does anyone have a compiled version of the fixed DLL that I can distribute?  How
sensitive to the build version is the control itself?

Comment 10

[Adam Lock]

Comment on attachment 109414 [details] [diff] [review]
Patch updated

Hi Chris, can you sr this simple fix to change where the control reads a list
of browser helper objects from and a few const naming conventions?

Comment 11

[Christopher Blizzard (:blizzard)]

Comment on attachment 109414 [details] [diff] [review]
Patch updated

sr=blizzard

Comment 12

[Adam Lock]

Fix is checked in

Comment 13

[Bill Mason]

Verified in build 2003010904 PC/Win98 with TopStyle 3.0.