Die Core Leute

Warning: This blog is not maintained any more (no update of content or links – as well as information are might deprecated / not valid any more).

[Kurz erwähnt] CScript.exe Absturz mit Referenz auf wshom.ocx

Hallo Blog-Leser,

heute möchte ich kurz über ein Problem berichten, welches bei einiger unserer Kunden aufgetreten ist.

Der CScript.exe-Prozess ist bei Ausführung von VBS-Skripten mit Verweis auf wshom.ocx auf Windows 2008 R2 Servern unerwartet terminiert.

Fehlerinformation:

            Faulting application name: CScript.exe, version: 5.8.7600.16385, time stamp: 0x4a5bca2a
            Faulting module name: wshom.ocx_unloaded, version: 0.0.0.0, time stamp: 0x4a5be0b4
            Exception code: 0xc0000005
            Fault offset: 0x000007fee4b84e3d
            Faulting application path: C:\Windows\System32\CScript.exe
            Faulting module path: wshom.ocx

Im ersten Schritt haben wir versucht, alle wichtigen DLLs zu re-registieren:
regsvr32.exe jscript.dll
regsvr32.exe vbscript.dll
regsvr32.exe wshom.ocx
regsvr32.exe msxml3.dll
regsvr32.exe -i shell32.dll
regsvr32.exe OLEAUT32.DLL

            Hinweis: wshom.ocx kann nicht re-registriert werden – dies wird mit 0x80040201 quittiert.

Der Windows Error Reporting Service (WER) war aktiviert, allerdings war nur der Typ Mini-User-Mode-DUMP aktiviert (somit hat der DUMP nicht so sehr viele Informationen hergegeben).

Der generelle Stack hat mir nicht weitergeholfen, da dieser nur auf wshom.ocx verwiesen hat:

            Child-SP          RetAddr           Call Site
            00000000`02f0f8f0 00000000`00000000 <Unloaded_wshom.ocx>+0x4e3d

Im Anschluss habe ich mir die Threads des CScript-Prozesses angeschaut – hierbei ist mir aufgefallen, dass im Thread 2 auf eine DLL verwiesen wird, die mir bis zu diesem Zeitpunkt nicht bekannt war:

            00000000`0180f820 00000000`00000000 <Unloaded_ScriptSn.20110429220238.dll>+0x645d

Parallel hat mir ein Kunde ein ProcMon-Log bereitgestellt, den ich mir nun anschaute.
Hier habe ich folgendes gefunden zu der DLL:

Event Class: Registry
Operation: RegQueryValue
Result: SUCCESS
Path: HKCR\CLSID\{B54F3741-5B07-11CF-A4B0-00AA004A55E8}\InprocServer32\(Default)
TID: 14948
Duration: 0.0000120
Type: REG_SZ
Length: 152
Data: C:\Program Files\Common Files\McAfee\SystemCore\ScriptSn.20110429220238.dll

Bei der Klasse ({B54F3741-5B07-11CF-A4B0-00AA004A55E8}) handelt es sich um die VBScript-Engine.
Da hier üblicherweise nicht auf eine McAfee-DLL, sondern auf vbscript.dll verweisen werden sollte, haben wir den Key entsprechend gesichert und korrigiert.

Ursprünglich:
[HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
@=”C:\\Program Files\\McAfee\\Managed VirusScan\\VScan\\ScriptSn.20100412064520.dll

Ändern auf:
[HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
@=”C:\\Windows\\system32\\vbscript.dll

Im Anschluss trat das Problem nicht mehr auf.

Beim reverse Research habe ich im Internet verschiedene Seiten gefunden, die in unterschiedlichen Situationen ebenfalls über den Registry-Wert „gestolpert“ sind.

Den Hintergrund, warum dieser Wert verändert wurde, haben wir nicht weitergehend geprüft. Dies wurde weitergehend durch den McAfee-Support geprüft – wir haben jedoch vom Kunden keine Rückmeldung hierzu bekommen.
Die Funktionalität von VBS war gegeben – und der AV-Scanner hat ebenfalls weiterhin seinen Dienst verrichtet.

Grüße,
Matthias Meiling
Support Engineer – Platform Core

PS: Eventuell noch ein Verweis auf die WER-Einstellungen – Info u.a. wie der DUMP-Typ umgestellt werden kann – http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx