Strange SCOM CScript.exe Errors On Domain Controllers

I recently encountered a domain controller running Windows Server 2008 R2 in our Active Directory domain that was recording a strange event in the Application event log every five minutes. The event information was:

Log Name:      Application
Source:        Application Error
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Description:
Faulting application name: cscript.exe, version: 5.8.7600.16385, time stamp: 0x4a5bca2a
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec4aa8e
Exception code: 0xc00000fd
Fault offset: 0x0000000000053560
Faulting process id: 0x25ac
Faulting application start time: 0x01cdffe08a2d9a20
Faulting application path: C:\Windows\system32\cscript.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: c8dd9c2a-6bd3-11e2-89a7-2c768a515630

After doing a little research online I discovered that there was a problem with one of the AD monitoring scripts in System Center Operations Manager 2007 R2. In my case, it was the AD_General_Response.vbs script. It appeared to be related to information this script reads and writes to/from the registry. The registry path in question can be found at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Modules\{D0C83F7B-F7B6-91F9-47DE-B63140166447}\S-1-5-18\Script\AD Management Pack\AD General Response

(Note that the unique identifiers may vary on your system.) In this path there are two keys, ErrorCount and ErrorDescription, that contained data. ErrorCount contained a number, and ErrorDescriptions contained a long string of data that was too big to see. It is this long ErrorDescriptions key that I believe contained faulty data and needed to be cleared to prevent these errors from being logged. After backing up the registry (always back up your registry before making registry changes!) I deleted the values in both of these keys. I noticed after doing this that within 5 minutes, the ErrorCount key was repopulated with the value “0”.

Note that the ErrorDescriptions key, when I opened it, didn’t contain any text in the box, but if I held down the delete key for several seconds and then hit OK, it cleared the data from the value. Again, something was definitely unusual about this key.