Windows 2000: Interactive search (COMAPI) always fails with 0x800706D3 while AU's own background search succeeds

[yumasansansan]

Environment

• OS: Windows 2000 Professional SP4 (5.00.2195), Japanese
• Host: Hyper-V on Windows 11 26H1
• Legacy Update: 1.13.2
• WUA client after self-update: build 7.2.6001.788

Summary

Every time I try to search for updates from the Legacy Update website (via "Install Updates" in Internet Explorer), it fails with error 800706D3. This happens 100% of the time, but Automatic Updates' own background/scheduled search succeeds and finds updates normally — only the interactive (COMAPI/ActiveX-driven) search path is affected.

I initially assumed this was related to Windows Installer 2.0 (since the log also shows "MSI DLL version is 2.0. Version 3.1 is required." around the same session), so I updated Windows Installer to 3.1. This had no effect on the 800706D3 error, so I don't believe it's related.

Steps to reproduce

1. On a fresh Windows 2000 Professional SP4 install, install Legacy Update 1.13.2.
2. Open the Legacy Update website in Internet Explorer and click "Install Updates" / trigger a search for updates.
3. The search fails almost immediately.

Expected behavior

The search completes and returns available updates, as it does when Automatic Updates runs its own background search.

Actual behavior

Every COMAPI-driven search fails with the same sequence in WindowsUpdate.log:

2026-08-24	11:29:23:062	 268	114	COMAPI	-------------
2026-08-24	11:29:23:062	 268	114	COMAPI	-- START --  COMAPI: Search [ClientId = Legacy Update]
2026-08-24	11:29:23:062	 268	114	COMAPI	---------
2026-08-24	11:29:23:062	 576	40c	Service	WARNING: GetUserTokenFromSessionId failed with error 800706d3 for session 0
2026-08-24	11:29:23:062	 268	114	COMAPI	WARNING: Unable to listen to self-update/shutdown event (hr=0X800706D3)
2026-08-24	11:29:23:062	 268	114	COMAPI	WARNING: Unable to establish connection to the service. (hr=800706D3)
2026-08-24	11:29:23:062	 268	114	COMAPI	  - WARNING: Exit code = 0x800706D3
2026-08-24	11:29:23:062	 268	114	COMAPI	---------
2026-08-24	11:29:23:062	 268	114	COMAPI	--  END  --  COMAPI: Search [ClientId = <NULL>]
2026-08-24	11:29:23:062	 268	114	COMAPI	-------------
2026-08-24	11:29:23:062	 268	114	COMAPI	FATAL: Unable to initiate asynchronous search, hr=800706D3

Meanwhile, Automatic Updates' own scheduled search (not going through COMAPI) completes successfully in the same log, e.g.:

AU <<## SUBMITTED ## AU: Search for updates [CallId = {1DA4B08C-...}]
...
AU >>## RESUMED ## AU: Search for updates [CallId = {1DA4B08C-...}]
AU # 92 updates detected

This suggests the underlying detection/download machinery works fine, but something about the interactive session-token lookup (GetUserTokenFromSessionId) that COMAPI relies on to talk back to the website's ActiveX control is failing at the RPC interface level (0x800706D3 = RPC_S_UNKNOWN_IF, "the interface is unknown") rather than a simple permission/timeout error. My guess is this call depends on session infrastructure that doesn't exist in the same form on Windows 2000 (predates XP's Fast User Switching / Terminal Services session model), but I don't have enough visibility into the WUA client internals to confirm.

Additional notes

• Updating Windows Installer from 2.0 to 3.1 did not change this behavior.
• Full WindowsUpdate.log attached.
  WindowsUpdate.log

[kirb]

Are you using it as a non-admin user? The logic to detect an admin user did change recently, and it’s possible it’s broken on 2000. Running as non-admin is supposed to display a logon prompt to run as an administrator, or an error page if you go directly to the website. Without those checks on our side, it’s possible this is what you get.

Are there possibly some custom ACLs configured that could be denying some privileges to your user? (If you don’t know, it’s most likely not that.)

Is this a plain Windows 2000 SP4 install from an original CD image, or is it possibly modified in some way?

Not exactly the same error, but I noticed this which claims a known bug with 7.2.6001.xxx versions of WUA returning 800703F0 (“An attempt was made to reference a token that does not exist.” - your error is “The authentication service is unknown.”) on Server 2008 when no users are logged on. It could be related, but I’m still surprised because this has never come up before.

[yumasansansan]

Thank you for looking into this.

• I'm a member of the Administrators group, but not the built-in Administrator account itself.
• I haven't modified any ACLs as far as I'm aware.
• This should be a plain SP4 install from an original CD image, though I can't be 100% certain of its provenance.

Regarding theether.net/kb/100122: the log signature there is a near-exact match to mine (same sequence of GetUserTokenFromSessionId -> "Unable to listen to self-update/shutdown event" -> "Unable to establish connection to the service" -> FATAL), and it's the same exact WUA build, 7.2.6001.788, that I originally had installed via Legacy Update's self-update.

There are two differences worth noting though:

1. Their error is 800703F0 ("a token that does not exist"), mine is 800706D3 (RPC_S_UNKNOWN_IF, "the interface is unknown").
2. Their case is triggered by no user being logged on (a script running via cscript with no interactive session). I was logged on interactively at the time (via Hyper-V's Basic Session / VMConnect, not Enhanced Session).

To dig further, I manually installed WUA 7.4.7600.226 directly from Microsoft's download servers, to see if this was specific to the 7.2.6001.784/.788 builds mentioned in that KB. The exact same failure signature persists on 7.4.7600.226 - a different WUA generation that isn't one of the affected builds listed there:

Service   WARNING: GetUserTokenFromSessionId failed with error 800706d3 for session 0
COMAPI    WARNING: Unable to listen to self-update/shutdown event (hr=0X800706D3)
COMAPI    WARNING: Unable to establish connection to the service. (hr=800706D3)
COMAPI    FATAL: Unable to initiate asynchronous search, hr=800706D3

Across both WUA versions I count 8 COMAPI search attempts in my logs, and all 8 fail identically. So this doesn't look like the theether.net bug specifically - it looks more like Windows 2000 is missing the underlying session/token RPC interface entirely (rather than having the interface but failing to find a valid token), independent of which WUA client version is installed. That would explain "unknown interface" rather than "token doesn't exist," and why it reproduces across different WUA generations.

On the bright side, downloads and installs are happening successfully in the background without going through the broken COMAPI search path - the pending update count dropped from 93 to 91 over the course of a day, with successful install events in between. I should correct myself on one point though: the reboots weren't happening autonomously on the 3:00 schedule - the VM wasn't actually running at that time. Rather, I noticed the website itself reported that a reboot was needed, and I triggered the reboot manually in response to that.

That's actually an interesting data point on its own: if the interactive COMAPI search is failing 100% of the time, I'm not sure how the site was able to determine a reboot was pending and display that to me. It's possible that check uses a different code path than the search that's failing, but I don't have enough insight into the site/control internals to say for sure.

So the underlying update mechanism (search/download/install triggered by AU itself, not by the site) isn't broken - just the interactive "check for updates now" flow, and possibly whatever the site uses to determine/report reboot status also has to go through some working path.

Happy to test anything specific if it'd help narrow this down. I'll attach the full WindowsUpdate.log covering both WUA versions.
WindowsUpdate.log

[JehadurRE]

Error 0x800706D3 is RPC_S_UNKNOWN_IF which means the COMAPI cannot talk to the Windows Update service via the expected RPC interface. Your analysis is correct -- this is a session infrastructure issue.

On Windows 2000, the WUA COMAPI path expects a session model that was introduced with XP Terminal Services. The GetUserTokenFromSessionId call fails because Windows 2000 session 0 does not have the same token lookup infrastructure.

The reason AU background search works is that it runs in-process with the service and does not need the COMAPI session token lookup. Only the interactive ActiveX-driven path hits this.

Practical workarounds:

1. Use the AU (Automatic Updates) path instead of the website-driven COMAPI path. Configure AU to check daily and install updates automatically.
2. If you need interactive control, use the wuauclt command line tool directly -- it talks to AU rather than going through COMAPI.
3. This is likely a fundamental incompatibility that cannot be fixed in LegacyUpdate without reimplementing the COMAPI session layer. It may be worth documenting as a known limitation for Windows 2000 specifically.

The Windows Installer version is indeed unrelated -- your testing confirmed that.

[kirb]

Appreciate you trying to help, but this AI response is restating what we already know and is not useful. The conclusion that Legacy Update is incompatible with Windows 2000 is incorrect, because this is the only known instance of this error on Windows 2000.