A Better solution for the Windows 7 SP1 ADO GUID changes

UPDATE:  This fix was published in mid-February as http://support.microsoft.com/kb/2640696.  We are still working on fine-tuning all of the documentation so that everything points to the appropriate places, but the binaries are already available.  The fixes for Windows 7 and Windows 2008 R2 and publically available.  Fixes for other OSes are also available, but you will need to open up a support case to request them.

If you are still using ADO in some of your code and tried to upgrade your build machine to Windows 7 SP1, you probably ran into the fact that you cannot run code recompiled on Windows 7 SP1 on downlevel OSes unless you modify your references to point to the backward compatible type libraries from http://support.microsoft.com/kb/2517589. Unfortunately, the solution does not work in several scenarios of which the biggest is Visual Basic for Applications (VBA).

The GUID change itself was not really the big problem – in fact, if you have been developing against MDAC/WDAC for a while you probably remember the days when applications would only run on the MDAC version that it was compiled on or higher. When we stopped revisioning MDAC around the Windows 2003 SP2 days, the problem pretty much went away. Until recently…

What happened is that we realized that some of our ADO APIs used platform dependent data types. This caused problems when 64-bit applications tried to consume these platform dependent data types and the caller’s data type did not match that of the callee. http://support.microsoft.com/kb/983246 discusses a scenario where a VBA macro runs into this exact problem. Unfortunately, we drastically underestimated the number of customers who were recompiling ADO applications on Windows 7 SP1. Even worse, when I say drastically, I really mean DRASTICALLY.

As soon as we realized the magnitude of the problem, we started scrambling to come up with a better solution. At this point, though, our significantly less than ideal first attempt had compounded the problem because it had the potential to spread the changed GUIDs to downlevel OSes. At this point, we made the painful decision to pull http://support.microsoft.com/kb/983246. Yes – we recognized that it would leave some scenarios like VBA without a workable solution, but we deemed that a better option than continuing to spread the modified GUIDs. Although not ideal, our standing recommendations were to use either the backward compatible libraries from http://support.microsoft.com/kb/2517589 or to compile on Windows 7 RTM. While not covering every scenario, it covered the bulk of them and was the best option we could provide without massive re-architecting.

Now, I am happy to announce that we are coming out with a much better solution. We are going to do the following:

  1. Ship the 6.0 type library from Windows 7 RTM via the new type library file msado60.tlb.  This will ship for multiple platforms.
  2. Ship a new 6.1 type library (which contains both new and deprecated interfaces) and embed it inside the msado15.dll
  3. Revert back all 2.x type libraries to what they looked like in Windows 7 RTM.

Therefore, the 2.x and 6.0 type libraries can be used for backward compatible purposes, and the 6.1 type library can be used for 64-bit VBA solutions. If you find yourself in the enviable place of not having to do any downlevel OS support, you can migrate entirely to the 6.1 type library even for your non-VBA applications.

Although you can see this fix in action in the Windows 8 Preview we shipped in September, we won’t be able to deliver the Windows 7 SP1 fix until early next year. As you can imagine, we are checking and re-checking everything because we completely understand that the only thing worse than no fix at this point would be another incomplete fix that requires yet another direction shift and another significant delay. Also, we are hard at working making sure some other known issues with the Windows 7 SP1 WDAC build get addressed with this fix as well. These are as follows:

We are still working hard to try to deliver this fix even sooner than early next year, but at this point I am not making any promises for an earlier delivery.

Comments (14)
  1. Papy Normand says:

    Thanks for this article which explains clearly the problem appearing in your link towards the SQL Server Data Access Forum. ADO and ADODB have disappeared in my own use since the release of VS 2003 , but i have kept the link about your "paper" just in case that i see a new thread about this problem in one of my best-prefered forums

  2. Fred Gazinta says:

    Sadly unless the 6.1 typelib is somehow marked to prevent its use in 32-bit development this problem will re-occur over and over again.  Developer forums are chock full of Kasual Koders asking about this compatibility break over and over and over again.  Since they seldom read any docs and don't keep up on changes they are likely to see 6.1 and say "how spiffy and new" and select it.  Boom.

  3. ms@colinpritchard.com says:

    Just got pointed at this post from the ongoing forum thread [ social.msdn.microsoft.com/…/280de88a-77dd-455e-9797-b28928206e38 ].

    It's great to see someone not only acknowledging the problem but also emphasising the impact it had on customers.

    Look forward to having a chance to test the fix (and to being able to finally update our dev machines to SP1) soon.

    Thank you 🙂

  4. Dean Wiles says:

    Thank you for acknowledging, discussing and working on a resolution to this major and costly bug. The KB2517589 workaround helped with our VB6-to-VB6 COM components, however it does not work for C++ components that use ADODB Recordsets as in/out parameters. Can you update us with a target delivery date for a fix for Windows 7 SP1 / Server 2008 R2 SP1? The Windows 8 Preview is not a viable option for our development environment at this time.

  5. Thank you says:

    Thank you for admitting there is a huge problem, and working on a fix.  Please notify me when the fix is available.



  6. Perry says:

    For god sake, I didn't expect this will suddenly end with this scenario. I updated my old laptop because of some hardware problem. then now, all the latest laptops available don't have a Win XP anymore. how come microsoft cannot solve this problem? Please bring back the Win XP, so said Win 7 is based on XP? and why cannot do a backward compatibility?

  7. Ben A says:

    It's mid-"next year" now… so… we can find these wonderful, new, fix-all DLLs… where exactly?

  8. William says:

    Is this resolved yet?  If so, where?  Thanks.

  9. Wayne says:

    Next year = whatever this year is + 1, I guess.

  10. Simon says:

    Any ideas why a W7SP1-compiled project with 6.0 doesn't work/isn't available (object not found) on XP SP3 machines, but 2.8 does? I thought 6.0 was supposed to be backward compatible…

  11. Lee Hawthorn says:

    Has this fix to Win7 SP1 been released?

  12. @Lee says:

    look at the top of the page and you get a link to an update 😉


  13. aalia lyon says:

    It’s  superb blog please  go through this url and solve your query . We provide Best online Services.check this site .

    <a href=windows7support.blogspot.in/…/fix-windows-7-error-1068.html> Fix Windows 7 Error 1068</a>

    Thank you

    Aalia lyon

  14. Alexandre TELLIER says:

    Hello, the hot fix does not apply to Win Server 2008…

Comments are closed.

Skip to main content