diagnosing regsvr32 return code 0x8002801c (aka TYPE_E_REGISTRYACCESS)

[Michael Asherman]

I'm trying to install Visual Studio Professional 6.0, Service Pack 5 on an
XP SP3 machine, after having successfully performed a clean, full
installation of Visual Studio Professional 6.0. The SP5 upgrade seems to
just about make it to completion, but in the final "Setup is updating your
system..." phase, it encounters the error "htmed.dll was unable to register
itself in the system registry", and soon concludes with "Visual Studio 6.0
Service Pack 5 Setup was not completed successfully."

To diagnose the problem, I've tried launching a CMD window and executing the
following command line:

regsvr32 "C:\Program Files\Microsoft Visual
Studio\Common\IDE\IDE98\htmed.dll"

This produces the following RegSvr32 error message:

"DllRegisterServer in C:\Program Files\Microsoft Visual
Studio\Common\IDE\IDE98\htmed.dll failed.
Return code was: 0x8002801c"

I gather that this code goes by the name TYPE_E_REGISTRYACCESS, and is
symptomatic of not having access to some portion of the registry. According
to an often-cited reference, I should use a tool such as regmon to to look
for "OpenKey" failures listed as "ACCDENIED". (The reference is
http://www.cryer.co.uk/brian/windows/trbl_nt_rgsvrfld8002801c.htm.) Using
the newer procmon.exe utility, I captured a listing of registry events for
the Command Prompt (CMD) window, and I don't see any "ACCDENIED" results or
anything similar. The only RegOpenKey operations that yield a result other
than SUCCESS all indicate "NAME NOT FOUND". The following is a concise CSV
file listing of those RegOpenKey failure events:

"Path","Detail"
"HKCU\Software\Policies\Microsoft\Control Panel\Desktop","Desired Access:
Read"
"HKLM\System\WPA\TabletPC","Desired Access: Query Value, WOW64_64Key"
"HKCU\Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers","Desired Access: Read, WOW64_64Key"
"HKLM\Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Custom\regsvr32.exe","Desired Access: Read,
WOW64_64Key"
"HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags","Desired
Access: Read, WOW64_64Key"
"HKLM\System\CurrentControlSet\Control\SafeBoot\Option","Desired Access:
Query Value, Set Value"
"HKCU\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers","Desired
Access: Maximum Allowed"
"HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution
Options\regsvr32.exe","Desired Access: Read"
"HKCU\Software\Policies\Microsoft\Control Panel\Desktop","Desired Access:
Read"

Does this provide a clue where the problem lies? Any suggestions how to
proceed with my effort to get a clean installation of VS6SP5 would be much
appreciated.

 

[Andrew McLaren]

I'm trying to install Visual Studio Professional 6.0, Service Pack 5 on an
XP SP3 machine, after having successfully performed a clean, full
installation of Visual Studio Professional 6.0. The SP5 upgrade seems to

Hi Michael,

Short answer is: I dunno! But here are a couple of ideas ...

Are you perhaps installing VS6 onto 64-bit XP? (hence the WOW64_64Key in
ProcMon output). If so, you may need to explicitly run the 32-bit
regsvr32, instead of the default 64-bit regsvr32:

C:\>C:\Windows\WOW64\regsvr32 "C:\Program Files\Microsoft Visual
Studio\Common\IDE\IDE98\htmed.dll"

Yes,the 64-bit regsvr is also called "regsvr32.exe" and by default
will try to create entries in the 64 bit area of the registry. 32-bit
COM components obviously need to be registered under the WOW64 area of
the registry.

Secondly, I vaguely recall this being one of several similar problems
with installing SP5. Do you specifically need to run SP5? If not, try
again with SP6 which is the final SP for VS6 and contains many useful
bugfixes:

http://msdn.microsoft.com/en-au/vstudio/aa718364.aspx

Hope this helps a bit,

Andrew

 

[Jose]

I'm trying to install Visual Studio Professional 6.0, Service Pack 5 on an
XP SP3 machine, after having successfully performed a clean, full
installation of Visual Studio Professional 6.0.  The SP5 upgrade seems to
just about make it to completion, but in the final "Setup is updating your
system..." phase, it encounters the error "htmed.dll was unable to register
itself in the system registry", and soon concludes with "Visual Studio 6.0
Service Pack 5 Setup was not completed successfully."

Does this provide a clue where the problem lies?  Any suggestions how to
proceed with my effort to get a clean installation of VS6SP5 would be much
appreciated.

Suggested from a Google search results:

Diagnose with regmon: http://technet.microsoft.com/en-us/sysinternals/bb896652.aspx

The write permission of registry key HKCR\Interface
\{34A715A0-6587-11D0-924A-0020AFC7AC4D} had been blocked. When I allow
write (Full control) of this using regedt32 I could properly install
SP5.

 

[Michael Asherman]

Hi Andrew,

Thanks for replying. No, I'm running 32-bit Windows, so it's not a 64-bit
issue. As to SP6, unfortunately it does not include all of the SP5 stuff,
in particular the update for VFP. Thanks for the suggestion and reference
about SP6, though. I might pursue that after I get through SP5.

Aside from upgrading to VS6SP5, which is my primary objective, I am curious
to understand whether I'm missing something about the general problem of
using procmon to diagnose failures in regsvr32. According to the article I
cited (http://www.cryer.co.uk/brian/windows/trbl_nt_rgsvrfld8002801c.htm),
this return code should be associated with an ACCDENIED result, yet I saw no
such result - only instances of NAME NOT FOUND. It appears that this
article is not entirely correct, so I am still wondering how one uses
procmon to diagnose regsvr32 failures that return code 0x8002801c.

Mike

 

[Andrew McLaren]

Hi Michael,

Ahhh .. then I salute you as another Foxpro user (although, it is many
years since I did any xBase work).

In general terms, yes: I would expect that you'd see an "ACCESS DENIED"
in the Results column of ProcMon, if the process (eg regsvr32) did not
have permission to write to the Registry key. I'm not sure why you're
not seeing that in your Procmon output. Be careful with the filters, you
can exclude useful data if you set the filters too tight.

I looked for a copy of the old SP5 but can't find one; looks like MSFT
have removed it from the download site? There should be some kind of
logging option you can turn on, to get a detailed log of the SP setup
and some more diagnostic information about the htmed.dll error. For the
original VS 6.0 setup, you'd add "/gc" to the setup command. For MSI
based installs, you can run "msiexec /i foobar.msi /lvx* myfoo.log"

Also, I think htmed.dll is only required for the Interdev parts of VS 6,
not the Foxpro parts. So if there's any way you can deselect Interdev,
that might work around around it (just a guess).

if you want to be really forensic, you can load htmed.dll in the VS
Tools Object Browser, and see what COM Interfaces it uses. Then go and
inspect those interface GUIDs individually in Regedit, under
HKCR\Interface. As Jose suggested, DWebBrowserEvents2,
{34A715A0-6587-11D0-924A-0020AFC7AC4D}, would be a good one to start
with. Some installations of IE7 caused this reg key to be
write-protected, so that may be the culprit.

Good luck!

Andrew

 

[Michael Asherman]

Hi Jose,

I had already checked for this registry key, but failed to find it. Your
suggestion prompted me to check again, and lo and behold, there it was, with
permissions not set to give full access to Administrators. (I guess I must
have missed it, because I'd be surprised if the key got created during my
testing from a CDM window.) After setting permissions for Administrators to
Full control, I ran the VS6 SP5 update again, and this time it ran to
successful completion.

Thank you very much for the solution!

Mike

I'm trying to install Visual Studio Professional 6.0, Service Pack 5 on an
XP SP3 machine, after having successfully performed a clean, full
installation of Visual Studio Professional 6.0. The SP5 upgrade seems to
just about make it to completion, but in the final "Setup is updating your
system..." phase, it encounters the error "htmed.dll was unable to
register
itself in the system registry", and soon concludes with "Visual Studio 6.0
Service Pack 5 Setup was not completed successfully."

Does this provide a clue where the problem lies? Any suggestions how to
proceed with my effort to get a clean installation of VS6SP5 would be much
appreciated.

Suggested from a Google search results:

Diagnose with regmon:
http://technet.microsoft.com/en-us/sysinternals/bb896652.aspx

The write permission of registry key HKCR\Interface
\{34A715A0-6587-11D0-924A-0020AFC7AC4D} had been blocked. When I allow
write (Full control) of this using regedt32 I could properly install
SP5.

 

[Michael Asherman]

Andrew,

As you can see from my reply to Jose, the problem was solved by his
suggestion. In fact, the first reference I had found was this one (with
Jose's solution):
http://techrepublic.com.com/5208-7343-0.html?forumID=101&threadID=312476,
which led me to the Cryer article and my experiments with Process Monitor.

Before making the registry permissions fix, I thought it would be
instructive to do some further testing with procmon.exe. You hit the nail
on the head about that. I had naively set the filter to list only events
associated with the Command window (CMD.exe), not the process named
regsvr32.exe. Setting the filter to result = "ACCESS DENIED" does the
trick, confirming that the registry key in question is indeed
HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}.

I was curious whether any sort of installation log got generated -
apparently not, by default. Thank you for the additional information about
this, for future reference.

I suspected that htmed.dll was related to the highly dispensable Visual
Interdev. Reinstalling without this component was high on my list of things
to try next. Also I reviewed these relevant MS KB articles:

Explanation of Regsvr32 usage and error messages
http://support.microsoft.com/default.aspx?scid=249873

Possible Reasons for OLE Control Registration Failure
http://support.microsoft.com/default.aspx?scid=140346

I was not looking forward the the adventure of playing with the OLE Control
Test Container. I'm not sure how this relates to the VS Object Browser that
you mentioned, but I'm glad to have finally gotten around to learning how to
use ProcMon.

Thanks again for all of your help!

Mike

Hi Michael,

Ahhh .. then I salute you as another Foxpro user (although, it is many
years since I did any xBase work).

In general terms, yes: I would expect that you'd see an "ACCESS DENIED" in
the Results column of ProcMon, if the process (eg regsvr32) did not have
permission to write to the Registry key. I'm not sure why you're not
seeing that in your Procmon output. Be careful with the filters, you can
exclude useful data if you set the filters too tight.

I looked for a copy of the old SP5 but can't find one; looks like MSFT
have removed it from the download site? There should be some kind of
logging option you can turn on, to get a detailed log of the SP setup and
some more diagnostic information about the htmed.dll error. For the
original VS 6.0 setup, you'd add "/gc" to the setup command. For MSI based
installs, you can run "msiexec /i foobar.msi /lvx* myfoo.log"

Also, I think htmed.dll is only required for the Interdev parts of VS 6,
not the Foxpro parts. So if there's any way you can deselect Interdev,
that might work around around it (just a guess).

if you want to be really forensic, you can load htmed.dll in the VS Tools
Object Browser, and see what COM Interfaces it uses. Then go and inspect
those interface GUIDs individually in Regedit, under HKCR\Interface. As
Jose suggested, DWebBrowserEvents2,
{34A715A0-6587-11D0-924A-0020AFC7AC4D}, would be a good one to start with.
Some installations of IE7 caused this reg key to be write-protected, so
that may be the culprit.

Good luck!

Andrew

 

[Andrew McLaren]

Hmm, interesting. A valuable learning experience for all of us

Thanks for reporting back with results (and, thanks to Jose for posting
the correct answer!)