RE: FIX: EventSystem 4609 errors after installing XP SP2

From: Christopher Hill (Hill_at_discussions.microsoft.com)
Date: 06/17/05 

Date: Fri, 17 Jun 2005 04:00:01 -0700

As a followup to my own post, if the suggestion I made below doesn't help,
you can also try the workaround posted at TechRepublic here:

http://techrepublic.com.com/5138-10877_11-5657162.html

When is this problem going to be at least acknowledged on the Knowledge
Base, and a fix provided?!?

"Christopher Hill" wrote:

> Hi,
>
> I've been seeing a particular problem on certain Windows XP computers when
> they are updated to Service Pack 2, and judging from posts in these
> newsgroups and also on other Internet message boards, it's quite a common
> problem. The symptoms are that after SP2 has been installed, and the machine
> has been rebooted a few times, the following error message occurs in the
> Application Event Log:
>
> Event Type: Error
> Event Source: EventSystem
> Event Category: (50)
> Event ID: 4609
> Date: 10/06/2005
> Time: 10:40:23
> User: N/A
> Computer: HISAD
> Description:
> The COM+ Event System detected a bad return code during its internal
> processing. HRESULT was 80070005 from line 44 of
> d:\qxp_slp\com\com1x\src\events\tier1\eventsystemobj.cpp. Please contact
> Microsoft Product Support Services to report this error.
>
> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.
>
> Some errors may be slightly different:
>
> Event Type: Error
> Event Source: EventSystem
> Event Category: (50)
> Event ID: 4609
> Date: 10/06/2005
> Time: 09:30:35
> User: N/A
> Computer: HISAD
> Description:
> The COM+ Event System detected a bad return code during its internal
> processing. HRESULT was 80080005 from line 44 of
> d:\qxp_slp\com\com1x\src\events\tier1\eventsystemobj.cpp. Please contact
> Microsoft Product Support Services to report this error.
>
> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.
>
> and at the same time errors similar to the following (sometimes with a
> different GUID number) may occur in the System event log:
>
> Event Type: Error
> Event Source: DCOM
> Event Category: None
> Event ID: 10010
> Date: 10/06/2005
> Time: 09:53:34
> User: NT AUTHORITY\SYSTEM
> Computer: HISAD
> Description:
> The server {8BC3F05E-D86B-11D0-A075-00C04FB68820} did not register with DCOM
> within the required timeout.
>
> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.
>
> I ummed and ahhed over this problem for a while, and eventually found the
> following two articles relating to Windows 2000 Service Pack 4:
>
> Overview of the "Impersonate a Client After Authentication" and the "Create
> Global Objects" Security Settings (821546.KB.EN-US.2.2)
> http://support.microsoft.com/?kbid=821546
>
> Local Security Policy Values May Revert to the Values That Are Stored in
> SecEdit.sdb After You Install Windows 2000 Service Pack 4
> http://support.microsoft.com/?kbid=827664
>
> It turns out that in Windows 2000 Service Pack 4 two new user rights were
> added, "Impersonate a client after authentication" (SeImpersonatePrivilege)
> and "Create Global Objects" (SeCreateGlobalPrivilege).
>
> Even though the articles don't say so, it seems that they were also added in
> Windows XP Service Pack 2.
>
> However, it seems that *sometimes* something goes wrong in the XP SP2
> installer when it sets up these two new user rights. I think this is why some
> computers get the above error messages. It doesn't happen all the time, and I
> can't see any rhyme or reason to which computers get messed up and which ones
> don't. I reckon it's a race condition or some other similar bug in the
> installer.
>
> The reason that the problem doesn't always manifest itself straight away is
> probably because by default Windows only 'refreshes' its security settings
> every 16 hours, and if that refresh is a while away you might not see the
> problem for a while. Some networks may also have turned up this refresh time,
> so the problem is even worse.
>
> Some sites may also have these settings set (possibly incorrectly) in their
> Default Domain Policy group policy, which could also mess things up. However,
> at my site we don't have these settings set on the domain anywhere, only in
> the Local Security Settings, and yet we still have the problem.
>
> Anyway, if the security settings upgrade goes wrong, you end up with the
> error. Fortunately, it seems to be quite easy to fix:
>
> On the affected workstation:
> 1) Go to Start/Settings/Control Panel/Administrative Tools
> 2) Run 'Local Security Policy'
> 3) Go to Security Settings/Local Policies/User Rights Assignments
> 4) Double click on 'Create global objects'.
> The correct default settings are 'Administrators', 'INTERACTIVE' and
> 'SERVICE'.
> 5) Double click on 'Impersonate a client after authentication'.
> The correct default settings are 'Administrators', 'ASPNET' (if you have
> the .NET framework installed) and 'SERVICE'
>
> Even if the settings are set correctly, you may need to 'refresh' them to
> fix the problem.
> To do this, on each policy, remove one of the entries ('SERVICE' is probably
> the best to remove), then press OK to save the changes, and then go back in
> and add it back in again (click 'Add User or Group...', type 'SERVICE' into
> the white box, and press OK).
>
> Then close the Local Security Settings box and reboot. If you are running in
> a domain with Group Policy you might want to force a group policy refresh
> before you reboot by running 'gpupdate /force'.
>
> I hope this helps some people!
>
> Regards,
>
> Chris
>

Relevant Pages

  • RE: FIX: EventSystem 4609 errors after installing XP SP2
    ... >> Microsoft Product Support Services to report this error. ... >> probably because by default Windows only 'refreshes' its security settings ... Some networks may also have turned up this refresh time, ... >> Default Domain Policy group policy, which could also mess things up. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Enforce update on a remote computer?
    ... Psexec can use a text file to run the ... do not refresh exactly on the same time. ... all security settings every 16 hours. ... There are however some Group Policy ...
    (microsoft.public.windows.group_policy)
  • Re: Security settings on the Terminal Server prevent automatic logon
    ... You may also want to post in a Terminal Services newsgroup. ... check the Group Policy security settings applied to the TS which could be ... > Security settings on the Terminal Server prevent automatic logon from ...
    (microsoft.public.security)
  • Re: Pushing out Registry Permissions
    ... Computer Configuration - Windows Settings - Security Settings - Registry ... Regards ... > I think this should be doable with AD and group policy, ...
    (microsoft.public.windows.server.active_directory)
  • RE: Local Security Policy
    ... process of updating group policy, the condition is normal in this scenario. ... Got to run and pick my daughter up! ... All local security settings will be displayed, ...
    (microsoft.public.windows.server.general)