diagnosing regsvr32 return code 0x8002801c (aka TYPE_E_REGISTRYACCESS)
in [Windows XP]
|
From: Michael Asherman on 15 Oct 2009 12:07 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" <jose_ease(a)yahoo.com> wrote in message news:ecb23eb8-9c29-43eb-b495-2bc640ef9ffe(a)a32g2000yqm.googlegroups.com... On Oct 14, 12:37 am, "Michael Asherman" <m...(a)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/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.
From: Michael Asherman on 15 Oct 2009 12:58 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 "Andrew McLaren" <me(a)somewhere.com> wrote in message news:uR8yFaWTKHA.4020(a)TK2MSFTNGP05.phx.gbl... > 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/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" <me(a)somewhere.com> wrote in message >> news:uBTDyAJTKHA.5052(a)TK2MSFTNGP06.phx.gbl... >>> 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 >>
From: Andrew McLaren on 16 Oct 2009 06:49
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-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 > > "Andrew McLaren" <me(a)somewhere.com> wrote in message > news:uR8yFaWTKHA.4020(a)TK2MSFTNGP05.phx.gbl... >> 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/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" <me(a)somewhere.com> wrote in message >>> news:uBTDyAJTKHA.5052(a)TK2MSFTNGP06.phx.gbl... >>>> 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 > |