Upgrade to 6.0 — map editor crash?

[Derek Read]

We've been working with two different clients via standard support that have told us now that having McAfee VirusScan Enterprise installed with the “ScriptScan” feature enabled will cause easily reproducible crashes in XMetaL Author Enterprise. In both cases the specific version of McAfee VirusScan Enterprise is 8.7i patch 3. Disabling “ScriptScan” stops the crashes.

If you have this software installed, and specifically this version, and can disable this feature it is very much worth trying. This software also has a way to identify folders to skip during this scanning, so in theory it should be possible to leave the feature on but configure it to play nicely with our software.

We're still trying to figure out what McAfee is doing exactly, but we suspect at this point the software is either renaming, deleting files in our installation folders or otherwise stopping our software from reading them. If this is the case that would explain the crashes.

Reply

[AndrewinKC]

McAfee VirusScan seems to be the issue. We were able to resolve the issue after we uninstalled, and then reinstalled the McAfee VirusScan (exact version referenced in Derek's e-mail). Our Tech noticed that some of the McAfee features were not working properly and that the log files contained a lot of garbage characters.

So for now, the problem seems to have been resolved by reinstalling McAfee. ScriptScan is enabled on my machine without any issues.

Reply

[gcrews]

Is the “processes on enable” on the first option tab checked or not? I know that when I was doing some testing on a clean system there didn’t seem to be any issues when that was unchecked as it is by default Xmetal does not seem to crash but found that if it is checked then Xmetal starts to crash.  I tried un-checking it on my main computer that I work on though and Xmetal still crashed when that was unchecked. I wonder if it has something to with the performance when more stuff is running.  It seems to be some kind of issue with timing collision issue.

Reply

[gcrews]

Interesting Microsoft kb I found that give a little more insight into what the ScriptScan is doing:
http://support.microsoft.com/kb/890736

“This problem is typically caused by McAfee VirusScan Enterprise 8.0i. Specifically, the problem may occur when the McAfee Scriptscan.dll component scans a script that calls an ActiveX control.

The McAfee ScriptScan component replaces the Windows Script Host component with its own proxy component. The McAfee ScriptScan proxy component (ScriptProxy.dll) scans JavaScript and Visual Basic Scripting Edition (VBScript) scripts. When a script is executed and passes through the scan as clean, the script is passed on to the appropriate Windows Script Host.

However, the ScriptProxy.dll component may cause an access violation when it parses the Active Directory Management Pack scripts in the MOMHost.exe process that calls ActiveX controls. When the ScriptProxy.dll component stops responding, the MOMHost.exe process that is running the script also fails. The MOM service tries to restart the failed MOMHost.exe process, and the access violation is repeated.”

Reply

[Derek Read]

Interesting find gcrews. I've found this article as well:
http://support.microsoft.com/kb/891604

It lists the following McAfee KB articles that may be of interest:
kb40067, kb47302, and kb40049.

McAfee seems to have changed those numbers however. Searching for them on McAfee's site will turn up the following…

An article called “Third-party application stops responding when ScriptScan is running”. This seems old (2008) but might still apply, or perhaps a similar issue has re-appeared in newer versions:
https://kc.mcafee.com/corporate/index?page=content&id=KB55961

“Problem 4” in the following article (also from 2008) lists a few applications that are known to crash when ScriptScan is enabled:
https://kc.mcafee.com/corporate/index?page=content&id=KB58564

This newer article from May 2010 discusses various workarounds for issues related to ScriptScan:
https://kc.mcafee.com/corporate/index?page=content&id=KB55963

At this point perhaps people suspecting McAfee is crashing our product should communicate their findings directly to McAfee so they are aware of the issue. Hearing an issue from multiple sources always gets the attention of a software vendor, and you can give them the exact details they might ask for (I don't know what they would want to know specifically about any system).

I have yet to reproduce any problems. Our latest suspicion is that it might be because I have been testing on a VM and not a real machine and that McAfee's software may function differently on real hardware. I am in the process of setting up some tests on a real machine. So, at the moment I don't have much to tell them. As soon as I have a reproducible test case I will be contacting them myself.

Reply

[gcrews]

I did some testing and even with one core CPU system it still crashes. There does seem to be a fair amount of issues with McAfee and ScriptScan. I think the issues may just be more prominent in XMetaL because of its extensive JavaScript usage and calls. When I do stack traces of the debug the last call is almost always to OLEAUT32!VariantClear(… In the jscript.dll Garbage collection stuff. To me that’s seems more like an issue with the way the ScriptScan proxies the stuff and not per say any coding in XMetaL. We will see what MacAfee can figure out.

Reply

[Derek Read]

I've finished configuring a real test box and I can now reproduce the crashes, extremely easily as long as McAfee “ScriptScan” is enabled.

Please go ahead and contact McAfee and provide whatever info they need. The issue is reproducible with XMetaL Author Enterprise 6.0 running in 30-day trial mode so they can easily get a copy.

In the meantime, at least I have something to show our developers too, so they'll be looking into it as well in case there is something we can do.

The only solution I have at the moment for avoiding these crashes is to turn the McAfee ScriptScan feature off, which is the same solution McAfee has recommended for various other issues listed in their Knowledgebase that look very similar (to me). Here's what McAfee says about that:

[quote=https://kc.mcafee.com/corporate/index?page=content&id=KB55961]IMPORTANT: There is a security risk in disabling ScriptScan. Certain applications, like Outlook and Internet Explorer, can render and execute scripts before a file has been created on the local system, thus executing before the On-Access scanner can prevent them. The On-Access scanner can stop the payload of attacks via this medium, but ScriptScan prevents a legitimate threat from executing in the first place.

Reply

[gcrews]

I'm glad you were able to reproduce the issue on your side.
Thanks for all the help trying to debug this issue.

Additional information:
We have  4 other writers extensively using XMetaL 5.5 during the day with the same McAfee version, settings, and policies with no issues. There must have been something changed in XMetaL 6 that  introduced this issue.

The host system I ran my VM test on was an Intel q6600 with VT-x,  witch may attributive to it crashing on  my test vm and not on your side.

Here is the last stack trace after a crash: ( you can probably get this info now)
Faulting application xmetal60.exe, version 6.0.0.122
faulting module oleaut32.dll, version 5.1.2600.5512
fault address 0x00004942.
[email protected]()  + 0x52 bytes
jscript.dll!VAR::Clear()  + 0x47 bytes
jscript.dll!GcAlloc::ReclaimGarbage()  + 0x77 bytes
jscript.dll!GcContext::Reclaim()  + 0x17e bytes
jscript.dll!GcContext::Collect()  – 0x225 bytes
jscript.dll!CScriptRuntime::Run()  – 0x6368 bytes
jscript.dll!ScrFncObj::Call()  + 0x85 bytes
jscript.dll!NameTbl::InvokeInternal()  + 0x5a95 bytes
jscript.dll!VAR::InvokeByDispID()  + 0x1f7d bytes
jscript.dll!CScriptRuntime::Run()  + 0x5592 bytes
jscript.dll!ScrFncObj::Call()  + 0x85 bytes
jscript.dll!NameTbl::InvokeInternal()  + 0x6b bytes
jscript.dll!VAR::InvokeByDispID()  + 0x1f7d bytes
jscript.dll!VAR::InvokeByName()  + 0x6566 bytes
jscript.dll!VAR::InvokeDispName()  + 0x40 bytes
jscript.dll!VAR::InvokeByDispID()  + 0x54 bytes
jscript.dll!CScriptRuntime::Run()  – 0x1c65 bytes
jscript.dll!ScrFncObj::Call()  + 0x85 bytes
jscript.dll!NameTbl::InvokeInternal()  + 0x6b bytes
jscript.dll!VAR::InvokeByDispID()  + 0x1f7d bytes
jscript.dll!VAR::InvokeByName()  + 0x6566 bytes
jscript.dll!VAR::InvokeDispName()  + 0x40 bytes
jscript.dll!VAR::InvokeByDispID()  + 0x54 bytes
jscript.dll!CScriptRuntime::Run()  – 0x1c65 bytes
jscript.dll!ScrFncObj::Call()  + 0x85 bytes
jscript.dll!NameTbl::InvokeInternal()  + 0x6b bytes
jscript.dll!VAR::InvokeByDispID()  + 0x1f7d bytes
jscript.dll!VAR::InvokeByName()  + 0x6566 bytes
jscript.dll!VAR::InvokeDispName()  + 0x40 bytes
jscript.dll!VAR::InvokeByDispID()  + 0x54 bytes
jscript.dll!CScriptRuntime::Run()  + 0x5592 bytes
jscript.dll!ScrFncObj::Call()  + 0x85 bytes
jscript.dll!CSession::Execute()  – 0x398 bytes
jscript.dll!COleScript::ExecutePendingScripts()  + 0x141 bytes
jscript.dll!COleScript::ParseScriptTextCore()  + 0x1a6 bytes
jscript.dll!COleScript::ParseScriptText()  + 0x2b bytes
xmetal60.exe!00a16f32()
[Frames below may be incorrect and/or missing, no symbols loaded for xmetal60.exe]

Here is a hack I came up with: (reset the WHS reg keys, open XMetaL, set WHS keys back)
As long as you don't open Iexplorere or Outlook during the time the keys are changed and you don't surf the web in in the preview pane after clinking a link in a document I don't think there is much of a security risk.

REGEDIT.EXE /S “%~dp0reg.reg”
rem reg.reg
rem Windows Registry Editor Version 5.00
rem [HKEY_CLASSES_ROOTCLSID{f414c260-6ac0-11cf-b6d1-00aa00bbbb58}InprocServer32]
rem @=”C:\WINDOWS\system32\JScript.dll”
rem [HKEY_CLASSES_ROOTCLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}InprocServer32]
rem @=”C:\WINDOWS\system32\VBScript.dll”

start “XMetaL” /B “C:Program FilesXMetaL 6.0Authorxmetal60.exe”
PING 1.1.1.1 -n 1 -w 20000
REGEDIT.EXE /S “%~dp0mc.reg”
rem mc.reg
rem Windows Registry Editor Version 5.00
rem [HKEY_CLASSES_ROOTCLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}InprocServer32]
rem @=”C:\Program Files\McAfee\VirusScan Enterprise\scriptsn.dll”
rem [HKEY_CLASSES_ROOTCLSID{f414c260-6ac0-11cf-b6d1-00aa00bbbb58}InprocServer32]
rem @=”C:\Program Files\McAfee\VirusScan Enterprise\scriptsn.dll”

Reply

[estir]

Hi
I do have McAfee, however ScriptScan is already disabled

Reply

[Derek Read]

I have read some KB articles at McAfee's site that suggests unchecking the “enable ScriptScan” checkbox does not actually do anything (for some versions).

We're certain that having ScriptScan on will cause the problem discussed in this thread (very easily reproducible here). This makes it more difficult because now I don't know if I trust that ScriptScan is really off in your case, or whether you are seeing some other issue.

If possible, you may wish to try the procedure detailed here in “Workaround 2” that describes how to unregister the McAfee “scriptproxy.dll”:
https://kc.mcafee.com/corporate/index?page=content&id=KB55963

Reply

[Su-Laine Yeo]

Hi everyone,

I've put a summary of the issue here: http://forums.xmetal.com/index.php/topic,915.msg2883.html#msg2883

Reply

[Author]

Posts