none
Adding Web Browser Control to Excel 2013 RRS feed

  • Question

  • I have a web browser control in a spreadsheet created in Excel 2010.  I can't view it in 2013 for some reason. When I try in a blank 2013 worksheet I get the same error: "Can't insert object"

    Any help is appreciated.

    Wesley

    Tuesday, November 13, 2012 2:50 AM

Answers

  • Thanks again for the reply. I'm not sure about the killbit but I'm not trying to block the webbrowser control.  This is what I received from Microsoft TechNet Support on this issue which is what lead me to killbit.  If I understand this correctly there is no alternative CLSID for the web browser control and she says in another email that 2007 and 2010 will soon be updated to have the same issue as 2013.

    Amber Mertes (ammert@microsoft.com)
    Attachment
    11:28 AM
    To: Wesley Holt
    Cc: MSSolve Case Email
    In summary Wesley, the Web Browser control has been killbitted. There is not an alternative CLSID to use in its place. I was able to use it with a VBA UserForm. So that’s one option to you. In the reg
    Picture of Amber Mertes
    From: Amber Mertes (ammert@microsoft.com)
    Sent: Wed 11/14/12 11:28 AM
    To: Wesley Holt (doctorcpu@hotmail.com)
    Cc: MSSolve Case Email (casemail@microsoft.com)
    In summary Wesley, the Web Browser control has been killbitted. There is not an alternative CLSID to use in its place. I was able to use it with a VBA UserForm. So that’s one option to you.
     
    In the registry, do a search for “COM Compatibility” as depending on whether your OS is 64 or 32-bit and whether your install of Office is a Click-to-Run or MSI install…. The path may be different.
     
    For example, on my 64-bit OS with 32-bit Office Click-to-Run install…. My location for that is: 
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\15.0\Common\COM Compatibility\
     
    In testing the “400” to “0” workaround, it does resolve the issue in my testing. However, as you are turning off the killbit with this, it would not be my recommendation, nor would it be supported, as it was disabled for security reasons.
     
    Please let me know when you have some time to discuss any questions you have on this. Thanks!
     

    Wesley

    • Marked as answer by doctorcpu Friday, January 3, 2014 12:13 AM
    Thursday, November 15, 2012 4:04 AM

All replies

  • Hi,

    Go to the following registry:

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\15.0\Common\COM Compatibility\{8856F961-340A-11D0-A96B-00C04FD705A2}

    Then set the value data from 400 to 0.


    Jaynet Zhang

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.


    Wednesday, November 14, 2012 6:14 AM
    Moderator
  • Thanks for the reply,

    This key does not exist.

    COM Compatibility\{8856F961-340A-11D0-A96B-00C04FD705A2}

    Not sure how to add it.


    Wesley

    Wednesday, November 14, 2012 4:31 PM
  • I am using Windows 8 if that makes a difference.

    Thanks,


    Wesley

    Wednesday, November 14, 2012 4:35 PM
  • Thanks,  I found the key and this works however I'm told this also disables KillBit which is not supported or recommended.  Is there a hotfix or workaround that does not affect KillBits?

    Thans again.


    Wesley

    Wednesday, November 14, 2012 6:15 PM
  • The location for setting the Office COM kill bit in the registry is as follows:

    HKEY_LOCAL_MACHINE/Software/Microsoft/Office/Common/COM Compatibility/{CLSID}

    In this case, <var>CLSID </var>is the class identifier of the COM object. To enable the Office COM kill bit, you have to add the registry subkey together with the CLSID of the ActiveX control or OLE object that you want to block from loading. Also, you have to set the Compatibility Flag's REG_DWORD value to 0x00000400.

    For example, to set the Office COM kill bit for an object that has CLSID {77061A9C-2F18-4f38-B294-F6BCC8443D24}, locate the following subkey, and add REG_SZ {77061A9C-2F18-4f38-B294-F6BCC8443D24} to the subkey:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Common\COM Compatibility

    In this case, the path is as follows:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Common\COM Compatibility\{77061A9C-2F18-4f38-B294-F6BCC8443D24}

    When you add a subkey that contains the value of 0x00000400 to the {CLSID} key, the Office COM kill bit is set. The 64-bit and 32-bit objects and their kill bits are located in different registry locations.

    Quote from:

    http://support.microsoft.com/kb/2252664?wa=wsignin1.0

    The link applies to Excel 2007, but we can refer to it.


    Jaynet Zhang

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.


    Thursday, November 15, 2012 2:42 AM
    Moderator
  • Thanks again for the reply. I'm not sure about the killbit but I'm not trying to block the webbrowser control.  This is what I received from Microsoft TechNet Support on this issue which is what lead me to killbit.  If I understand this correctly there is no alternative CLSID for the web browser control and she says in another email that 2007 and 2010 will soon be updated to have the same issue as 2013.

    Amber Mertes (ammert@microsoft.com)
    Attachment
    11:28 AM
    To: Wesley Holt
    Cc: MSSolve Case Email
    In summary Wesley, the Web Browser control has been killbitted. There is not an alternative CLSID to use in its place. I was able to use it with a VBA UserForm. So that’s one option to you. In the reg
    Picture of Amber Mertes
    From: Amber Mertes (ammert@microsoft.com)
    Sent: Wed 11/14/12 11:28 AM
    To: Wesley Holt (doctorcpu@hotmail.com)
    Cc: MSSolve Case Email (casemail@microsoft.com)
    In summary Wesley, the Web Browser control has been killbitted. There is not an alternative CLSID to use in its place. I was able to use it with a VBA UserForm. So that’s one option to you.
     
    In the registry, do a search for “COM Compatibility” as depending on whether your OS is 64 or 32-bit and whether your install of Office is a Click-to-Run or MSI install…. The path may be different.
     
    For example, on my 64-bit OS with 32-bit Office Click-to-Run install…. My location for that is: 
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\15.0\Common\COM Compatibility\
     
    In testing the “400” to “0” workaround, it does resolve the issue in my testing. However, as you are turning off the killbit with this, it would not be my recommendation, nor would it be supported, as it was disabled for security reasons.
     
    Please let me know when you have some time to discuss any questions you have on this. Thanks!
     

    Wesley

    • Marked as answer by doctorcpu Friday, January 3, 2014 12:13 AM
    Thursday, November 15, 2012 4:04 AM
  • Hi,

    Correct reg path is [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\15.0\Common\COM Compatibility\{8856F961-340A-11D0-A96B-00C04FD705A2}]

    Change the value from 400 to 0

    Note - I have tested above on 64 bit Windows 7 with 64 bit Office 2013


    Regards,
    Ojas Maru ( My blog )


    • Proposed as answer by Ojas Maru Thursday, January 2, 2014 11:36 PM
    • Edited by Ojas Maru Thursday, January 2, 2014 11:37 PM
    Thursday, January 2, 2014 11:35 PM
  • Thank you, this fixed my issue.
    Friday, February 12, 2016 5:51 AM