Article ID: 2447913 - View products that this article applies to.
You are running an Active Directory Domain. Your administration of group policies is based on Group Policy Management Console (GPMC) running on Windows Server 2003 or Windows XP.
You are using the scripting interface, for example, to backup group policies (e.g. BackupAllGPOs.wsf) or retrieve resultant set of policies (RSOP). A list of example scripts can be found here: http://technet.microsoft.com/en-us/library/cc776655(WS.10).aspx
Now you are installing the .Net Runtime Updates or deploy the latest version of the runtime on the machines running GPMC. The first update that is changing the system behavior is:
976576 An update is available for the .NET Framework 3.5 Service Pack 1 and the .NET Framework 2.0 Service Pack 2 in Windows Server 2003 and in Windows XP
When the scripting support DLL GPMGMT.DLL unloads after executing the script, you get an error popup:
An event in the system log is also recorded:
The GPMC uses an approach to manage the object lifetime which is not compatible with the guidelines of the .Net runtime. The behavior was tolerated by the runtime until the update 976576, but caused the runtime to leak memory.
The side-effect of the change is that applications violating the rules will experience an access violation.
The version of GPMC that is included with Windows Server 2008 and later and that is also in the Remote Server Administration Tools (RSAT) are not causing this problem.
The error is shown and the event is logged by the Windows Hard Error Handler. You can modify the behavior of this handler:
124873 Disabling System Hard Error Message Dialog Boxes
The basic approach is to set ErrorMode to 2 and back to 0 in a separate script host executable, like this:
If the script working with the GPMC objects is embedded in a bigger script and you can't have an "outer" script, you can set ErrorMode=2 directly in the script when you are working with the GPMC objects, and have the operating system set ErrorMode=0 with an event triggered task which you can configure with this command:
If the script is not running at Administrator Level or LocalSystem, it cannot write to the registry key where ErrorMode is located. To solve this problem, you can write a custom event in the script, and create a second event trigger consume it to set ErrorMode=2.
Examples for eventlogging:
Note: To register the event source you need to run as administrator. Logging the event can be done as lower privilege account (e.g. Backup Operator).
Event triggers cannot be edited the same way as regular scheduled tasks. A limited set of options is available through the UI and SCHTASKS. When you do this, for some of the possible changes you lose the user the task is running under. You can reset the user the task is running under to LocalSystem using this script:
“§” would be any character not used in the job names.
(http://go.microsoft.com/fwlink/?LinkId=151500)for other considerations.