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...ld8002801c.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.

Michael Asherman wrote:
> 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

--
amclar at optusnet dot com dot au

On Oct 14, 12:37*am, "Michael Asherman" <m...@nospam.com> wrote:
> 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/s.../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.

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...ld8002801c.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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Michael Asherman wrote:
>> 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
>
> --
> amclar at optusnet dot com dot au

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 wrote:
> 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...ld8002801c.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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Michael Asherman wrote:
>>> 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
>>
>> --
>> amclar at optusnet dot com dot au
>
>

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

"Jose" <(E-Mail Removed)> wrote in message
news:ecb23eb8-9c29-43eb-b495-(E-Mail Removed)...
On Oct 14, 12:37 am, "Michael Asherman" <m...@nospam.com> wrote:
> 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/s.../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.

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-734...hreadID=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

"Andrew McLaren" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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 wrote:
>> 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...ld8002801c.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" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> Michael Asherman wrote:
>>>> 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
>>>
>>> --
>>> amclar at optusnet dot com dot au
>>

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!)


Michael Asherman wrote:
> 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-734...hreadID=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
>
> "Andrew McLaren" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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 wrote:
>>> 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...ld8002801c.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" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> Michael Asherman wrote:
>>>>> 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
>>>>
>>>> --
>>>> amclar at optusnet dot com dot au
>