KB960715 blocks msflxgrd.ocx in VBA

[kevin.meers@googlemail.com]

This update (KB960715) causes a problem with the msflxgrd.ocx control
when used in a Access 2003 application. The control gets blocked and
you have to uninstall the update. Would appricate a fix for this as I
am sure this is not what Microsoft intended to fix with this update.

[boncain]

It also causes a problem with msdatgrd.ocx when used in access 2003 application. We payd Microsoft (Italy) for the solution but i think they have not idea about the problem. The technicians of Microsodt Italy think i'm crazy

Ok friend we are in the shit. Microsoft Italy told me that these controls are not supported yet. You have to scrap your application or rewrite it without controls. I think that our microsoft support is ill informed but that's all at the moment.

I have got the same problem. I have emailed microsoft (uk) and will let you know if they come back with a fix

[chrisdev3@gmail.com]

I have the same problems also with MSFLXGRD.OCX. What are going to do
now since our programs that do not work ? We have to replace flexgrid
with different control ? Lot of clients will not accept uninstalling
update.

Apart from uninstalling update or executing the below, I was not able
to find another solution till now:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{6262d3a0-531b-11cf-91f6-c2863c385e30}]
"Compatibility Flags"=-

[PA Bear [MS MVP]]

If all of your MS and third-party applications are fully patched themselves,
installing KB960715 shouldn't be causing any problems.

There are only two (2) killbits set by KB960715, one for Akamai Download
Manager and one for Research in Motion (RIM) AxLoader. Both Akamai and RIM
have released security updates related to these killbits: Have you installed
the appropriate update(s) yet? See the FAQ section of
http://www.microsoft.com/technet/sec...ry/960715.mspx.

NB: KB960715 also includes the killbits in KB956391 (originally released 14
Oct-08); cf. http://www.microsoft.com/technet/sec...ry/956391.mspx.
Did you uninstall it, too?

[Robert_Kenworld]

I had similar issue since yesterday, and I tried re-registering the msflxgrd
serveral times but did not fix the errors. The only solution so far has been
to remove the KB960715. Thanks guys and let's keep posted on this issue.

http://www.microsoft.com/technet/sec...ry/960715.mspx
-> General Information -> Frequently Asked Questions ->
What does this update do?

See http://www.microsoft.com/technet/sec.../MS08-070.mspx for
further details though.

We simply created a .reg file changing the DWORD value for msflxgrd from COMPAT_EVIL_DONT_LOAD = 0x00000400 to COMPAT_SAFEFOR_LOADING = 0x00800000. Tested this solution in XP and in Vista and it seems to solve the problem without having to uninstall the 960715 update.

[mmorasan@bulkmatic.com]

This is exactly our problem, we have 200+ users who lost flexgrid
functionality with the auto application of kb960715. Only our
developer, who has VB6, was able to install the security roll up and
continue to use flexgrid pages on our custom intranet site. Thi site
was designed about 8 years ago and has never had an incompatibility
with any MS security updates until now. Any thoughts on replacing the
flexgrid component in our asp based app? Or how do we update the
client components on the pcs? thx

[Harry Johnston [MVP]]

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.

[Aquidneck]

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.

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 !

[Stephen Williamson]

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.

[Aquidneck]

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:

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.

[brian ellis]

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

This patch also causes an issue with MSMASK32.ocx

[Johann Schwarz]

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

Does anyone know of any otherHotfix that will cause this problem? I have had
KB960715 removed from my system and the network now no longer tries to
install it however I am having this problem with VBA flexigrids again, with
the error message 'Compile error in hidden module'. As this update no lnger
exists, it surely must be another one that has come through recently. Does
anyone have any ideas?

[MattNak]

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.

[PA Bear [MS MVP]]

To avoid confusion, please begin a new thread about your specific problems,
preferably in a VB-specific newsgroup. State your IE version and full
Windows version (e.g., WinXP SP3; Vista SP2) in your first post.

Did you read

Is your install VB version fully patched, too (e.g.,
http://support.microsoft.com/?kbid=957924)?

[Harry Johnston [MVP]]

ActiveX killbit update rollups are cumulative. So every killbit rollup since
960715 will have the same effect 960715 does.

Remember, by leaving the updates out you are leaving your machine vulnerable to
attack! The best solution is to update the ActiveX control to the corrected
version, not to block the killbit updates.