KB960715 blocks msflxgrd.ocx in VBA

Discussion in 'Windows Update' started by kevin.meers, Feb 12, 2009.

  1. I think you were missing my point - if it so happens that a base install of
    Office includes msflxgrd.ocx, and there is no corresponding update, then
    Microsoft will consider that a bug and will fix it if we bring it to their
    attention. If msflxgrd.ocx was distributed with a third-party application, then
    the application developer is expected to have distributed a patch, and Microsoft
    won't consider it to be a (Microsoft) bug.

    Now, whether Microsoft *should* support Visual Studio OCX controls directly
    rather than through the developers is another issue entirely, but it's pretty
    much pointless to debate it; they don't, and I very much doubt they're going to
    be convinced to change their mind. My only comment on the subject is that the
    relevant security bulletin *was* released two months ago, so it isn't as if
    developers haven't had time to provide an update.

    Harry.
     
    Harry Johnston [MVP], Feb 16, 2009
    #21
    1. Advertisements

  2. PA Bear [MS MVP], Feb 16, 2009
    #22
    1. Advertisements

  3. kevin.meers

    Aquidneck Guest

    Both links won't resolve the issue of ActiveX controls in an MSO application.
    My problem surfaced in MS Access with two separate clients. One link you
    gave does list the affected controls, so my quick solution was to create an
    empty VB6 project with the affected tools selected. Compile and package it
    up and do an install on the affected workstation, and the problem is solved.

    I still maintain it would have been a lot less painful if MS had just rolled
    those updated OCX files into KB960715 in the first place.
     
    Aquidneck, Feb 17, 2009
    #24
  4. We distribute a couple of these controls with our application - an
    application that hosts VBA. We ship a number of VBA modules with each
    installation that have dependency on the offending ocxs (hence the
    distribution). So, fair enough, the dlls are security flawed and must be
    upgraded. We can patch our install database (msi) with the latest dll by
    extracting it from the VB6 distro, as described above. However, once
    installed these safe versions still fail at vba compile time with "hidden
    module not found" error - my guess is that there is a licensing issue. My
    question is where to source a non-developer, non-deisgn-time licensed version
    that is freely distributable? Do we need to establish a new licensing
    agreement with MS? The control we distribute currently comes from an ancient
    msm file, the source of which has been lost in the sands of time!

    Of course, we have other options - drop the dependency on the controls or
    migrate to VSTA, neither are short-term solutions. Ideas greatly appreciated.
     
    Stephen Williamson, Feb 19, 2009
    #25
  5. kevin.meers

    Aquidneck Guest

    The only suggestion I can offer is what worked for me, which is create an
    empty VB6 project using the controls from the following link:

    http://accessblog.net/2009/02/kb960715-ie7-is-breaking-access-apps.html

    I'd go back to your original distro, do an install of the 'empty' VB6
    project, and test the results. I doubt it's a license issue. VBA doesn't,
    to my knowledge, check versions.

    All I did for my fix (that MS should have provided) is create a VB6 project,
    select those particular components identified in the link above, and compile
    the result, using the MS installer to create an installable. That solved my
    issue with MSO, without having to touch the VBA code. If your 'ancient'
    control isn't included in that list, go ahead and include it in the 'empty'
    project after running the VB6 rollup.

    You didn't indicate the source language for your app, but I would expect the
    same principle to apply in your case - once the affected controls are safely
    ensconsed in windowsl\system32 and the registry, I would be surprised if you
    continue to have an issue.

    Good luck...
     
    Aquidneck, Feb 21, 2009
    #26
  6. kevin.meers

    Jean-Paul J Guest

     
    Jean-Paul J, Feb 22, 2009
    #27
  7. kevin.meers

    Jean-Paul J Guest

    I've made this update of OCX and reinstall the KB960715. After restart the
    computer, the DWORD in register is set to 400 hexa. The only way I found is
    writing a function with API advapi32.dll to rewrite the correct entry form my
    program !
     
    Jean-Paul J, Feb 22, 2009
    #28
  8. kevin.meers

    brian ellis Guest

    Also we've experienced problems with the mask control MSMASK32.ocx, which is
    fixed by changing the registry key below:-

    Windows Registry Editor Version 5.00
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
    Compatibility\{C932BA85-4374-101B-A56C-00AA003668DC}]

    Compatibility Flags value changed from 400 to 0
     
    brian ellis, Feb 26, 2009
    #29
  9. And Windows make use of a known to vulnerable version of that ActiveX
    control then. Not the right choice, if you'ld ask me.

    Bye,
    Freudi
     
    Ottmar Freudenberger, Feb 27, 2009
    #30
  10. kevin.meers

    brian ellis Guest

    This patch also causes an issue with MSMASK32.ocx

    Can be fixed by amending the registry key below:-

    Windows Registry Editor Version 5.00
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
    Compatibility\{C932BA85-4374-101B-A56C-00AA003668DC}]

    Compatibility Flags value changed from 400 to 0
     
    brian ellis, Feb 27, 2009
    #31
  11. This is not a good solution because it reintroduces the security vulnerability.

    Harry.
     
    Harry Johnston [MVP], Mar 2, 2009
    #32
  12. Yes I downloaded and installed it on my machine where I have my Visual Studio
    running and my developertools. There I had no problem since there is XP and
    VB6.0 already installed. There is KB960715 installed and the Flexgrid works
    now even in my MSAccess solution where it was used together with VBA code.


    But on machines where I have Vista and no VB6.0 IDE I couldn't install the
    VB6.0 SP6 Rollup packacke because this only installs if you have the IDE
    installed too.
    So I copied the ocx files to the other machines and registered them using
    regsvr32 as an admin. Now the applications also work there. But I really
    would have prefered they would release a runtim package for VB6SP6 rollup
     
    Johann Schwarz, Mar 11, 2009
    #33
  13. kevin.meers

    MattNak Guest

     
    MattNak, May 21, 2009
    #34
  14. kevin.meers

    MattNak Guest

    I made my Access 2007 work with this with the new controls on PCs without VB6.
    I would imagine it should work for Access 2003 as well.

    Steps to take:
    1. Install the May 2009 VB Controls Update on PC with VB6
    2. The two files in C:\windows\system32 you want is
    MSFlxGrd.ocx and the comcat.dll (its dependent file)
    3. Unregister these two files from your target machine without VB installed
    a) Run cmd for dos box, then type regsvr32 -u
    c:\windows\system32\msflxgrd.ocx
    b) regsvr32 -u c:\windows\system32\comcat.dll
    4. Replace target PC files with the two new files you extracted in step 2
    5. Register the two new replacement files with the dependent file first:
    a) Open the cmd box
    b) regsvr32 c:\windows\system32\comcat.dll
    c) regsvr32 c:\windows\system32\msflxgrd.ocx
    6. Run your Access App and check to see your Flexgrid is just doing fine! ;-)

    For handful of PCs, you can do this manually.
    For lots of PCs or for client site, you can just script this process in cmd
    script and run it on each PC or push it out automatically and have it run the
    script.
     
    MattNak, May 21, 2009
    #35
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.