Have you been successfully compiling programs using Visual Basic 6 under Windows 7 in the past, only now to find that programs using Microsoft ActiveX Data Objects (ADO) / MDAC now crash with an automation error when running on Windows XP. Additionally the Package and Deployment Wizard hangs after you select a directory to save your package to.
Wondering what changed to break your previously working system? Well, if you had just recently installed Service Pack 1 for Windows 7, then you likely have run into the same issue I have. Read on for my own experiences and solution…
It seemed simple enough: I made a seemingly minor change to a program I’ve compiled dozens of times. This program uses Microsoft ActiveX Data Objects, but the change I made to the program touched nothing related to data access at all. As a matter of fact, I had taken a working code snippet from one project and applied it to another similar one. Nothing here was untested code. After what seemed like a normal compile, I attempted to deploy my updated program to a standard Windows XP system (running Service Pack 3) by copying the executable file over our network as I always do. When I launched the executable, however, I was graced with the following error:
‘Error 430 Class does not support automation or does not support expected interface’
Interestingly, I had been in the habit of placing line numbers in some sections of my source, in order to help with the trapping of just this kind of unexpected error. The line number is referenced pointed me to the following line of code:
Set ADOConn = New ADODB.Connection
Huh? This was a line of code I’d used in tons of different projects and never once had any trouble with. So, knowing that couldn’t really be the issue, I set off to try everything else I could think of to get this working. After removing and adding back all references and components in my project, I still had the same issue. I next reinstalled the MDAC 2.7 package on my target PC. Again, no change in the error at all. Finally, I attempted to run the Package and Deployment Wizard on my project, so that I could totally reinstall it on the target machine, in case a file or library there had become corrupted. After the first few screens, it just hung. Subsequent tries resulted in the same lock-up, happening right after I selected the folder to place the package in. My system seemed to be falling apart for no apparent reason!
At that point, I turned to Google for aid. From the results I found there, it seemed that a number of persons had begun experiencing the automation error issue after having installed Windows 7’s Service Pack 1. Apparently, that Service Pack changes the way the data access components are referenced in program, making them no longer compatible with the matching version level installed on an XP system. You’d never notice this, however, if you were testing the program on your Windows 7 system, as the errors only happen when you move it to an XP system. Thanks, Microsoft! :/
The main recommendation I found was to simply remove the Service Pack. As a virtualization user, however, I felt like I had a viable alternative: I had long ago installed Visual Studio 6 in Windows 7’s XP Mode. Since VB6 runs fairly well under XP, and since XP is not going to get many more major updates, I’d be insulated for the most part from the effects of any future, major Windows 7 updates. I also wouldn’t have to lose out on any benefits I had gained from the Service Pack, nor would I have to exert vigilance in order to keep Windows Update from giving it to me again. Upon compiling the project in XP Mode, I was able to copy the executable to the target machine and run it with no issues at all. So, from now on I’ll be running my VB6 exclusively under Windows 7’s XP Mode.
Please note that I never did find any other articles linking the issue I began experiencing with the Package and Deployment Wizard and the Service Pack. But, this was something I’d used often prior to the installation of the Service Pack. I have to believe that there is a correlation, at least as regards projects which use the MDAC. I haven’t tried it with non-MDAC-using projects, as at this point I really don’t care: if I’m going to use XP Mode for VB6, I may as well use it for the whole suite!
tl;dr edition
Windows 7’s SP1 breaks VB6’s ability to use ADO correctly on programs you try to run under Windows XP (or perhaps any other prior version of Windows). It may also break the Package and Deployment Wizard. So, either remove SP1 or run VB6 under XP Mode or an XP VM in any other virtualization program you like.
What follows is the discussion thread for this post from my old blog site, preserved here.
13 thoughts on “Fix: Problems with Visual Basic 6 / ADO / MDAC after installing Windows 7 Service Pack 1”
James Liddell November 3, 2011 at 10:14 am
Windows 7 32-bit needs to support Visual Basic 6.0 with v2 of SP6 Installed, MS has an “It just works” policy for this, if you take the time to read their support policy. The 64-bit version, well that’s unsupported and most likely will be ignored, so, with this in mind, MS will have to provide a solution for this, probably with the release of SP2. For now, I rolled back SP1 to fix this problem.
Luke G. November 5, 2011 at 8:48 am
@James
I agree that it would be very nice to see this issue cleared up in Windows 7’s Service Pack 2 (although I still really prefer the portability of running VB in a VM). As a matter of principle, I feel that Microsoft should definitely find a way to deal with this issue in as minimally intrusive of a manner as possible. I’d like to see them do one better than requiring us to manually install some hacked ADO package, alter the means of referencing the ADO interface in every program we make, or uninstall a Service Pack in order to fix an issue they knowingly caused.
According to some sites, it may be 8 months or more before we get SP2. So, let’s hope they take advantage of the time to give us a more reasonable and automated solution to this!
Ralph B January 24, 2012 at 3:34 pm
Nice post. We didn’t try the XP mode. We discovered this issue a while back as well. So no Win 7 SP1 on development computers. However, we are nearing the end of a 1 year process to convert all of our code to .Net. No biggie, just 2 million lines. Fortunately, we had started using .Net a while back for newer projects or it would have been even more.
MS really doesn’t support VB6 anymore, and .Net is so much better IMO. They don’t have any coversion utilities in VS 2010, and the one they had in prior versions was very poor. Out analysis of the commercial products was pretty dismal as well. Ultimately we came up with a system of pre-processing and post-processing around the VS 2008 VB6 conversion utility. This worked well because of our consistency (for the most part) in how the VB6 code was written. We’re working exclusively with Framework 4.0 in VS2010 now.
FYI: Another gotcha we found with SP1 is the BlackBerry JDE also breaks. Although getting it to work under Win 7 is a trick unto itself. Just another reason why BB is going downhill fast.
Jovanni Lo February 1, 2012 at 2:28 am
We actually have the same problem!!! nice
Matt Y February 6, 2012 at 5:34 pm
I ran into the same problem but got runtime error 13 – Type Mismatch when my VB6 program tried to connect to the DB. The virtual XP recompile fixed it for me too. Thanks!
Gertjan April 11, 2012 at 4:33 pm
There is know a fix from MS, finally! KB2640696
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28477
Luke G. April 12, 2012 at 8:22 am
It’s tempting to try, but I’m still in love with my virtualized development environment.
Thanks for posting the link! It’s good to see that Microsoft realizes that there is still a lot of code out there using ADO (in this case, VB6), and that they do still need to avoid breaking it.
Here’s a link to the kb article for the download: http://support.microsoft.com/kb/2640696
SandraLopez May 30, 2012 at 1:22 pm
Hola, estoy instalando Visual Basic 6, en windows 7 de 64 bits, pero como dicen en todos los post, al momento de correr actualizaciones despues de la instalacion, ya no me deja ver referencias y el ejecutabe que genero me marca error (430 Clase no admite automatizacion) al ejecutarlo en una maquina con xp.
que es lo que tengo que hacer para que no me muestre ese error..
quitar el service pack de windows 7 o que..
muchas gracias de antemano
Luke G. August 13, 2012 at 8:02 am
If you must stay on Windows 7 you have two options: you can try installing Microsoft’s ADO update, or you can remove service pack 1.
My personal preference is to install Visual Basic in XP Mode and use it from there. That, in my opinion, eliminates the danger of any future Windows 7 updates breaking compatibility again.
Removing Windows 7’s service pack 1 will immediately fix your issue. Setting up XP Mode would take considerably longer. So, now you have a short-term and long-term fix!
Revy D. August 12, 2012 at 6:12 am
Curse Microsoft! XD we have similar problems… i had a working program(in windows 7) not work on an XP machine because of a faulty package and deployment wizard… grr grrr windows 7….
Good think no one has tried my program in XP yet…
You’re a good soul! Thanks for this information.
Ahmed El Sayed October 8, 2012 at 10:07 am
I faced the same problem, but this hotfix fixes my problem.
after installing, my vb6 compiled apps on win 7 sp1 now running on xpsaumiya somanathan July 14, 2013 at 4:43 am
When I try to install visual basic6.0 in my windows xp,this is the error I encounter
setup was unable to create a DCOM user account in order to register “G;PROGRAM FILESMICROSOFT VISUAL STUDIOCOMMONTOOLSVS-Ent98Vanalyzrvalec.exe”
Bernard March 14, 2014 at 3:17 am
I have the same problem, but not with Windows 7 SP1, but XP SP3.
It works fine on my computer but hangs on another one. Both are XP SP3 machines. Both having MDAC 2.81 installed.
Error 430 Class does not support automation or does not support expected interface’
at
Set cnMyConn = New ADODB.Connection.