none
Has Windows 7 Service Pack 1 broken ADO based COM+ Applications

    Question

  • This is a repost of a response in the "Breaking change in MDAC ADODB components in Windows 7 Service pack 1" thread. (Some respondents felt it should be in a different thread)

    COM+ Problem!

    I'm not sure whether this belongs here or in a new thread, but I am sure the problem is related. We have a number of old VB6 COM+ based applications which were originally written as NT applications but have served well in an XP client / Win2003 server environment with the odd tweak here and there. We are intending to change our client environment soon and I had done some initial testing of some of these apps (using the same executables) with a Windows 7 32-bit RTM client (with the same Win2003 backend) late last year. All appeared to be fine.

    This week (thinking it would be a sure thing) I started testing one of these using Windows 7 SP1. To my surprise the app had barely started and I got an 'automation error - element not found'. I checked that I had not made any installation mistakes. I rechecked that the same procedure worked on both XP and Windows 7 RTM, which it did. I tracked down the line in the code that generated the SP1 error to where an object in COM+ application was being created. Strangely however another COM+ object (in a different application) had already been created successfully during the initialisation. A difference between these two objects was that the latter referenced the Microsoft ActiveX Data Objects Recordset 2.8 Library.

    In order to confirm that this was the problem I have created a minimal test COM+ library and client program in VB6 on an XP machine. This references the same library but only uses it to allow a recordset to be passed between the client and server (it is never actually used). Sure enough this combination works fine in XP , Windows 7 RTM but NOT Windows 7 SP1. As I mentioned we have several significant applications built on this architecture so this could causes us very major problems. The test library consists of just the following code

    '---------------------------------------------

    Public Sub testString(ByRef referenceText As String)

       referenceText = "Updated via COM+"

    End Sub

    Public Function testRecordset(ByRef myRecords As Recordset) As Boolean

       testRecordset = True

    End Function

    '-------------------------------------------

    This is in a class file called clsW7SP1ADOProblem which has instancing set to MultiUse and TransactionMode set to UsesTransactions. The class is compiled in an ActiveX DLL called W7SP1ProblemDemoLib. The compiled DLL was then added as a new component to a new COM+ application on a Windows 2003 server and the proxy then exported. The client application is just a form with two buttons that contains the following code:

    '------------------------------------------------

    Private Sub Command1_Click()

      Dim testlib As W7SP1ProblemDemoLib.clsW7SP1ADOProblem

      Dim paramtext As String

      Set testlib = New W7SP1ProblemDemoLib.clsW7SP1ADOProblem

      testlib.testString paramtext

      MsgBox paramtext, vbOKCancel, "Reference Text"

      Set testlib = Nothing

    End Sub

    Private Sub Command2_Click()

      Dim testlib As W7SP1ProblemDemoLib.clsW7SP1ADOProblem

      Dim records As Recordset

      Dim result As Boolean

      Set testlib = New W7SP1ProblemDemoLib.clsW7SP1ADOProblem

      result = testlib.testRecordset(records)

      MsgBox result, vbOKCancel, "Reference Text"

      Set testlib = Nothing

    End Sub

    '--------------------------------------------

    The client app references the test library and also references the Microsoft ActiveX Data Objects Recordset 2.8 Library in order to handle the recordset parameter. The compiled client and the COM+ proxy were installed manually on all three clients (XP, Windows 7 RTM, and Windows 7 SP1). In the first two cases clicking either button displays the expected dialog. On SP1 the 'automation error - element not found' message appears in either case. The first call does not even involve an ADO parameter but from earlier posts I am guessing that the mere presence of the ADO library reference is causing the problem.

    Please can anyone explain what is going on here, whether this is related to the other incidents described in earlier posts, and, hopefully, what we can do to workaround the issue.

    Thanks.

    (NOTE - all code was compiled in Visual Studio 6 on Windows XP)

    Monday, April 18, 2011 9:55 AM

All replies

  • Does anyone out there share this problem? I note that my post has been read by around a hundred people but there have been no replies on this thread and only an enquiry about where the code was compiled on the original thread. Does anybody else still have VB6 systems based around COM+ applications that use ADO? I guess a lot of those who do are not looking to move to Windows 7 at the moment. However, if they ever intend to, it would appear that this could bite them.

    Just to be absolutely clear on the compile and runtime environments:

    • All code was compiled using Visual Basic 6.0 on Windows XP Service Pack 2.
    • The Com+ application is created in component service on Windows 2003 Server Service Pack 1 and an application proxy is generated from that server
    • The client runs without problem when installed (with the COM+ application proxy) on Windows XP Service Pack 3 and Windows 7 RTM
    • The client errors when either it is installed directly in, or the machine is upgraded to, Windows 7 SP1.

    I would be very grateful for any response (if only to assure myself I am not going mad).

    Thanks.

    Thursday, April 21, 2011 10:22 AM
  • Yes we have the same problem and are anxiously awaiting Microsoft's response.

    • Our product is based on code compiled using Visual Basic 6.0 on XP Service Pack 2. Both client and server objects are built this way.
    • Our client machines register server based VBR files in order to access the Com+ components that are installed into Com Packages on Windows 2003 servers and 2008 servers.
    • We have installations all over the US, Mexico and Canada.
    • We have had unbroken success until Windows 7 SP1.

    Your pursuit of this issue is much appreciated. Keep pushing. If you are on other forums with this, let this site know of it please.

    Thank you.

    Monday, April 25, 2011 2:02 PM
  • Same here.

    • VB6 code compiled in XP SP3.
    • Application Proxy (Com+)

    I can query the Application proxy via VBS, and it's OK, but when I launch the client application, it reports no connection with the server.

    My findings so far:

    • Fresh install of W7 SP1: no way.
    • Fresh install of W7: all OK.
    • Install SP1 over the last point: no way.

     

    • Proposed as answer by vishnu-yada Friday, August 17, 2012 8:25 PM
    Wednesday, April 27, 2011 12:03 PM
  • Thanks for the responses. Yes, as noted on the original thread ('Breaking change in MDAC ADODB COM components in Windows 7 Service Pack 1 (repost with MSDN liveID)') there is no problem with late binding, which is why I believe this is same core issue showing itself in a different. Also, I have now tested with the 64-bit client OS (obviously the code is still 32-bit), and not surprisingly the results are the same (works in RTM, errors in SP1). Anyone at Microsoft looking into this ????
    Wednesday, April 27, 2011 2:41 PM
  • Wolfling67 has posted an interesting piece of information in the 'original' thread:

    "The BackCompat library lists the Recordset.RecordCount property as restricted for VB6.  This is a change from the original .TLB, and effectively renders the BackCompat library incompatible."

    Could anyone test if this also applies to W7SP1 .TLB?

    Thursday, April 28, 2011 7:35 AM
  • I am sorry for late reply, and thanks for reporting this issue.
     
    I tried to reproduce the issue, but I can't (my Win7 SP1 can successfully call into the server). I will list all my detail steps I have taken below. Please take a look and confirm whether I have missed anything. If there are anything differences from your steps, please point it out. Thanks :-)
     
    1. Prepare four machines - (1) Windows XP SP3; (2) Server 2003 SP2 32-bit; (3): Windows 7 SP1 64-bit; (4): Windows 7 RTM 64-bit
          A) My "C:\Program Files\Common Files\System\Ado\msado15.dll" is of version "2.81.3012.0" on WinXP and "2.82.4795.0" on Server 2K3
          B) I turned off the firewall on these machines
     
    2. On Windows XP, create the server component:
          A) Install VB6 SP5 and create a new Vb6 project of type "ActiveX DLL"
          B) VB6 will create a project named as "Project1" and create a class module named as "Class1"
          C) In the project explorer, select the "Project1 (Project1)". In the property windows, change its name into "W7SP1ProblemDemoLib"
          D) In the project explorer, select the "Class1 (Class1)". In the property windows, change its name into "clsW7SP1ADOProblem"
          E) In the property windows of "clsW7SP1ADOProblem", make sure the "Instancing" was set to "5 - MultiUse" and set the MTSTransactionMode to "3 - UsesTransaction"
          F) Copy the following code into the Code Windows:
     
            '/////////////////////////////////////////////////////////////////////////////////////////////////
             ' VB6 code
                     Public Sub testString(ByRef referenceText As String)
     
                        referenceText = "Updated via COM+"
     
                     End Sub

                     Public Sub testRecordset(ByRef myRecords As Recordset, ByRef referenceText As String)
     
                        referenceText = myRecords.State
        
                     End Sub 
             '/////////////////////////////////////////////////////////////////////////////////////////////////
           
          G) Project -> Reference... Menu: Check "Microsoft ActiveX Data Objects 2.8 Library"
          H) File -> Make "W7SP1ProblemDemoLib.dll" and save it to a local folder c:\temp\com+\server\
          I) Close VB6 and saves all necessary files. Make sure the following files exist in the folder: "clsW7SP1ADOProblem.cls", "W7SP1ProblemDemoLib.dll", "W7SP1ProblemDemoLib.exp", "W7SP1ProblemDemoLib.lib", "W7SP1ProblemDemoLib.vbp" and "W7SP1ProblemDemoLib.vbw"

    3. On Windows XP, create the client component
          A) Launch VB6 SP5 and create a new Vb6 project of type "Standard EXE"
          B) VB6 will create a project named as "Project1" and create a Form named as "Form1"
          C) Drag two buttons in the form. Rename one of them as "Test String" and the other as "Test Recordset"
          D) Double-click on "Test String" and copy the following code into the Code Windows:
     
            '/////////////////////////////////////////////////////////////////////////////////////////////////
             ' VB6 code
                     Private Sub Command1_Click()
      
                      Dim testlib As W7SP1ProblemDemoLib.clsW7SP1ADOProblem
                       Dim paramtext As String
     
                       Set testlib = New W7SP1ProblemDemoLib.clsW7SP1ADOProblem
                       testlib.testString paramtext
     
                       MsgBox paramtext, vbOKCancel, "Reference Text"
                       Set testlib = Nothing
     
                    End Sub
             '/////////////////////////////////////////////////////////////////////////////////////////////////
     
         E) Double-click on "Test Recordset" and copy the following code into the Code Windows:
     
            '/////////////////////////////////////////////////////////////////////////////////////////////////
             ' VB6 code
                     Private Sub Command2_Click()
      
                       Dim testlib As W7SP1ProblemDemoLib.clsW7SP1ADOProblem
                       Set testlib = New W7SP1ProblemDemoLib.clsW7SP1ADOProblem

                       Dim records As New Recordset
                       Dim paramtext As String
                       testlib.testRecordset records, paramtext

                       MsgBox paramtext, vbOKCancel, "Reference Text"
                       Set testlib = Nothing
     
                    End Sub
             '/////////////////////////////////////////////////////////////////////////////////////////////////
     
          F) Project -> Reference... Menu: Check "Microsoft ActiveX Data Objects 2.8 Library" and "W7SP1ProblemDemoLib". Please note that "W7SP1ProblemDemoLib" is pointing to the local instance: c:\temp\com+\server\W7SP1ProblemDemoLib.dll
          G) Run the program (for testing). Verify that clicking on "Test String" button produces a message box of "Updated via COM+" and clicking on "Test Recordset" button produces a message box of "0"
          H) File -> Make "Project1.exe" and save it to a local folder c:\temp\com+\Client
          I) Close VB6 and saves all necessary files. Make sure the following files exist in the folder: "Form1.frm", "Project1.exe", "Project1.vbp" and "Project1.vbw"
     
    4. On the Server 2K3, launch "Add or Remvoe Programs" from "Control Panel"
          A) In the "Add or Remvoe Programs" dialog, click "Add/Remove Windows Components" from the left-pane
          B) Select "Application Server", and click the button "(Detail)"
          C) Check "Enable network COM+ access" and "Enable network DTC access". Click "OK" to install these two components
          D) Restart the Server 2003

    5. On the Server 2K3, launch "Component Service" (Start Menu -> Administrative Tools -> Component Service)
          A) Copy "W7SP1ProblemDemoLib.dll" compiled in WinXP (step 2) into a local folder of Srv03 (e.g. c:\temp\com+\server\)
          B) Navigate to "Console Root -> Component Service -> Computers -> My Computer -> COM+ Application"
          C) Right-click "CoM+ Application", and Click "New -> Application"
          D) Click "Next" in the Welcome page
          E) Click "Create an empty application"
          F) Type the name for the new application as "W7SP1ProblemDemoLib"
          G) Select "Server application" and click "Next"
          H) In the "Set Application Identity" page, selects "This user" radio button and enters my credential (Note, I am from Admin group). Then, click "Next"
          I) Click "Next" until the last page, and then click "Finish" on the last page
          J) Verify that there is a new item "W7SP1ProblemDemoLib" created under the node "COM+ Application"
          K) Right-click "COM+ Applications -> W7SP1ProblemDemoLib -> Components", and Click "New -> Component"
          L) Click "Next" in the welcome page, and click "Install new component(s)"
          M) Select "c:\temp\com+\server\W7SP1ProblemDemoLib.dll"
          N) Click "Next" until the last page, and then click "Finish" on the last page
          O) Navigate to "COM+ Applications -> W7SP1ProblemDemoLib" node
          P) Right-click "W7SP1ProblemDemoLib" and click "Export..."
          Q) Click "Next" on the welcome page
          R) Input the path: "c:\temp\com+\Proxy\Proxy.MSI" in the text box
          S) Select "Application proxy - Install on other machines to enable access to this machine"
          T) Click "Next" and click "Finish" on the last page
          U) Verify that "c:\temp\com+\Proxy\Proxy.msi" and "c:\temp\com+\Proxy\Proxy.msi.cab" were created
     
    6. On Win7 SP1,
          A) Copy the entire folder "c:\temp\com+\Proxy" from Server 2K3 into Win7 SP1 (created in step 5)
          B) Run the program "c:\temp\com+\Proxy\Proxy.msi" on Win7 SP1 to install the COM+ proxy
          C) Verify that "W7SP1ProblemDemoLib" was installed into the Win7 SP1 from the "Component Service"
          D) Copy the file "c:\temp\com+\client\Project1.exe" from Windows XP into Win7 SP1 (created in step 3)
          D) Run "c:\temp\com+\client\Project1.exe"
          E) Verify that clicking on "Test String" button produces a message box of "Updated via COM+" and clicking on "Test Recordset" button produces a message box of "0"
     
    7. On Win7 RTM,
          A) repeat all steps done in Win7 SP1
     
     However, I can successfully get "0" by clicking "Test Recordset" on Win7 SP1. Also, it succeeded in Win7 RTM and Server 2K3 as well.
     
     So, I am not sure which step i got wrong and that may make me not be able to repro the issue. Could you kindly point it out?
     
     Thanks,
     Ming.
     WDAC Team, Microsoft. 



    Friday, April 29, 2011 4:14 PM
  • Furzehill / DonP_gett,

    Please help to verify the above repro steps. If there are anything different from your scenario, please point it out and give me the detail steps. This is an important piece of information to prepare the new fix.

     

    Beriaru,

    If you encountered "no connection" or "failed to connect", it may be other issues unrelated to this one. Please try to study the firewall setting / log files, and make sure the remote computer received your client requests.

     

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Monday, May 02, 2011 4:29 AM
  • Hi Ming

    Thanks for your response and sorry for the delay in replying (holiday weekend).

    Your setup does not match the environment I described in my earlier posts but I am surprised at the effect of the differences.

    Firstly, and most seriously, all my code was compiled on an XP machine (not Server 2K3). Specifically, for the posted example (and for most of our codebase), all code (both client app and library) was compiled using Visual Basic 6 SP5 on a XP SP2 machine. The referenced version of the "C:\Program Files\Common Files\System\Ado\msado15.dll" on this machine is 2.81.1117.0.

    Secondly (and also mentioned previously) the server on which the COM+ application was created, and to which the compiled dll was copied, is running Windows Server 2003 Service Pack 1. (The version of "C:\Program Files\Common Files\System\Ado\msado15.dll" on this machine is 2.82.1830.0).

    The application server settings on the W2K3 server are as you describe in your point 2.

    The actual ActiveX DLL creation process was as you describe in 3A - 3H except that this was on the XP machine, so rather than your point 3I the following files were copied from a location from the development machine to a location on the server:

    • W7SP1ProblemDemoLib.dll
    • W7SP1ProblemDemoLib.exp
    • W7SP1ProblemDemoLib.lib
    • W7SP1ProblemDemoLib.TLB
    • W7SP1ProblemDemoLib.VBR

    The COM+ application creation process was as you describe in your point 4 referencing the dll from the location to which it was copied on the server.

    The client creation is similar to your (first) point 5 except again this was done on the XP machine with the reference to the W7SP1ProblemDemoLib being to the local copy.

    Installation on the client OS machines was as you describe.

    I would be interested in your comments on my development environment, but whether or not it is ideal, I do not Know why the resulting executables work fine on XP and Windows 7 RTM, but not on Windows SP1 (whether 32 or 64 bit).

    If you need any further detail please let me know.

    Tuesday, May 03, 2011 9:51 AM
  • I have here a handicap: I'm not a developer (nor english is my first language, so sorry for any slip), I'm just the tech support guy. But the 'broken' application here is the ERP, so that's very bad news.

    I just tried an specific approach to pinpoint the problem:

    Fresh install of 7 sans SP. Installed "the program". It works.

    Install SP1. The program no longer works.

     

    Now, I go to a W7 sans SP and I copy the "C:\Program Files (x86)\Common Files\System\ado" folder, and Replace the folder in the W7 SP1 with the pre-SP1 copy (and regsvr32 the dll's). Lo and Behold: the program works.

     

    Sadly I can't be more specific why it breaks with SP1. I'll try to kidnap the developer for the next series of tests...



    EDIT:

    Ok, the offending lib is MSADOR15.DLL

    After replacing for a pre-SP1 one it works.

    Is there a problem with recordsets and VB6??

    Tuesday, May 03, 2011 2:09 PM
  • Beriaru,

    This is a known issue and we are addressing the issue. There are two "supported" workarounds:

    - Stay on Win7 RTM, or uninstall SP1 until we can address the issue

    - Install the backcompat tlb on your machine as described in the KB #2517589 (http://support.microsoft.com/kb/2517589)

     

    Note: Please don't download the QFE from the KB: 983246 for the moment.

     

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Wednesday, May 04, 2011 12:50 AM
  • Sorry if I'm a bit lost, Ming, but the issue KB #2517589 addresses is a application compiled in W7 SP1 which stops working in down-level OS.

    The situation I describe is an application which is working fine in XP & W7RTM but not in W7SP1. That application, by the way, is compiled in a XP SP3.

    Wednesday, May 04, 2011 6:48 AM
  • A little more info for anyone following my posts (particularly Ming).

    I have now recompiled my code using Visual Basic 6 Service Pack 6 on Windows XP Service Pack 3 (where as previously to emulate our live code I has used VB6 SP5 on XP SP2). As one might expect from Beriaru's post the results are the same (same error on Windows 7 SP1, works on XP and Windows 7 RTM).

    Given Mings earlier success this seems to point at two possible 'causes':

    1. Compilation on XP (whatever service pack) rather than Windows Server 2003 .
    2. OR running the server components on Windows Server 2003 Service Pack 1 rather than Service Pack 2.

    Why either of these things should suddenly cause an issue with a Windows 7 SP1 client remains a mystery to me (maybe something to do wiith versions of ADO ???).

    [A minor clarification - I was previously running the COM+ application with the 'Enforce access checks' option turned off. I have since tested with it on (i.e. exactly as Mings procedure above) and it makes no difference.]

     

    Wednesday, May 04, 2011 9:27 AM
  • One further test was to run the server components on Windows 2008 R2 (as this may be our future), generating new proxies, and installing on the clients. Using the same dll and client executables (both those created on XP SP2 and XP SP3) I get the same result - errors on Windows 7 SP1, but works on XP, Windows 7 RTM.

    This is what I would have expected given that I think the problem is with the reference to the Microsoft ActiveX Data Objects Recordset 2.8 Library (msado15.dll) in the compiled code. Why Ming's later version of this when compiled on Windows 2003 server SP2 should work I don't know.

     

    Wednesday, May 04, 2011 12:33 PM
  • Have you tried to replace in a a W7-SP1 the msador15.dll file in C:\Program Files (x86)\Common Files\System\ado with a W7-RTM one (and register it) and try to run your program?

    That's all our program needed to start work in a W7 SP1.

     

    Of course that's not a solution in the long term, but at least we could know where the problem resides.

    Also I'd like to know what 'problems' could arise from using that workaround.

    Wednesday, May 04, 2011 3:10 PM
  • Just to confirm Beriaru's post, changing the msador15.dll (not msado15.dll) back to the pre SP1 version does indeed fix the immediate error.

    As Beriaru says this localises the problem but doesn't really provide a solution. Even if the file was replaced on client machines I have no idea what kind of other problems may be caused by using an inconsistent set of ADO files.

    Anybody from Microsoft care to comment? (Ming?)

     

    Friday, May 06, 2011 10:25 AM
  • Sorry for late reply. I have tried to use WinXP SP3 to compile both the client and server. However, the behavior is still the same as previously. Although I am using Windows Server 2003 SP2, but I don't believe there are any difference between SP1 and SP2.

    So, Furzehill, could you double-check the repro steps above to see whether there are any possible tricky things that we have not noted before? (btw, I have updated the steps above inline). So, please double-check the new repro steps.

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     

     


    Pak-Ming Cheung - MSFT
    Monday, May 09, 2011 5:01 PM
  • Sorry if I'm a bit lost, Ming, but the issue KB #2517589 addresses is a application compiled in W7 SP1 which stops working in down-level OS.

    The situation I describe is an application which is working fine in XP & W7RTM but not in W7SP1. That application, by the way, is compiled in a XP SP3.


    Beriaru,

    Oh, if the program was compiled on XP, then it is not expected not to work on Win7 SP1.

    Could you please post some more detail repro steps (e.g. code snipplet, which platform did you compile, which platform did you run?) Preferably, please include detail repro steps in your description.

    The suggested workaround for VB6 developers is to either: (1) stay on Win7 RTM; (2) Download/use the backward compat typelib. Please note that replacing a SP1 file with a RTM file (as what you have described before) can render into an unsupported scenario.

    Thanks,
    Ming.
    WDAC Team, Microsoft.


    Pak-Ming Cheung - MSFT
    Monday, May 09, 2011 5:14 PM
  • I have updated my repro steps to use the "local copy" of the server component, when I was compiling the client component on WinXP.

    But it still can't repro the issue.

     

    So, the only differences between our settings is about Srv03 SP1 or Srv03 SP2. We don't have SP1 in our lab. And I don't believe there are any differences between SP1 and SP2.

     

    Furzehill, could you follow my steps one by one (instead of just reviewing it) and see whether you can repro the issue on SP1? I am afraid there are some tricky parts that we have missed.

     

    Thanks,
    Ming.
    WDAC Team, Microsoft.


    Pak-Ming Cheung - MSFT
    Tuesday, May 10, 2011 2:50 AM
  • Also, I have tried to use the Recordset object passed into the server component. And there is completely no issue in that scenario as well.

     

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Tuesday, May 10, 2011 3:37 AM
  • Hi Ming,

    I think I have spotted the problem in your repro steps.

    You are referencing "Microsoft ActiveX Data Objects 2.8 Library" (ie. MSADO15.dll), where as I am referencing "Microsoft ActiveX Data Objects Recordset 2.8 Library" (i.e. MSADOR15.dll). We established a few posts back that this was the source of the problem.

    i suggest you change the reference and try again.

    I will also check this at my end.

    Tuesday, May 10, 2011 10:40 AM
  • Just as final confirmation of this problem I have rebuilt the test code following Ming's detailed procedure, using a completely clean build machine.

    If, as my original post specified, I reference "Microsoft ActiveX Data Objects Recordset 2.8 Library" (i.e. MSADOR15.dll) the code runs on Windows 7 RTM but errors on Windows 7 SP1.

    If, as Ming did, I reference "Microsoft ActiveX Data Objects 2.8 Library" (i.e. MSADO15.dll) the code runs on both.

    So to answer the original question of this thread, yes, Windows 7 SP1 does break ADO based COM+ applications if they use the recordset library. We have applications that do, Beriaru has applications that do, and I am guessing there are probably a lot more people out there who have yet to hit the problem.

    Tuesday, May 10, 2011 12:14 PM
  • Thanks Furzehill for pointing out the difference of the setting.

    I can now repro the issue. Basically, clicking on either"Test String" or "Test Recordset" will result in the following error message on Win7 SP1, but not Win7 RTM:

                 ---------------------------
                 Project1
                 ---------------------------
                 Run-time error '-2147319765 (8002802b)':

                 Automation error
                 Element not found. 
                 ---------------------------
                 OK   
                 ---------------------------

    I will have more in-depth investigation on the issue.

     

    Going forward, please note that ADOR is only shipped for legacy purpose. And you may want to use ADO15 typelib in your future projects. See: http://support.microsoft.com/kb/216389

     

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     

     


    Pak-Ming Cheung - MSFT

    Wednesday, May 11, 2011 9:00 AM
  • Thanks, this is a duplicated, recently-found issue that ADOR15 typelib does not include the deprecated interfaces. Therefore, your applications cannot load the deprecated interfaces in SP1.

    Thanks for reporting this issue to us.

     

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     

     


    Pak-Ming Cheung - MSFT
    Wednesday, May 11, 2011 9:33 AM
  • Hi,

    I am having the same issue in W7 SP1.  If you create a empty VB 6.0 project and reference to Microsoft ADO 2.0 and compile it. The application compiles and runs on W7 SP1 but not on WXP or even W7. It results in to run-time error 'Automation Class ...'

    If I compile it using Windows XP Mode in Windows 7 SP1, it works fine. Please do help me.

    Thanks in advance,

    Rahul A H

    Sunday, May 15, 2011 9:30 AM
  • Some people really need to read the forum before adding a casual 'me too' post.

     

    I swear these 3 w7 ado posts show us exactly what a sign wave a forum post is

    ... problem --- solution ... talk about solution ... problem --- repaste solution ... talk about solution ...

     

    :)

     

    Sunday, May 15, 2011 5:36 PM
  • Ohhh !!! You saved my life, really saved my life, have to figure it out for 4-5 hours though, but this saved me.

     

    First my Laptop updated to SP1 on Win 7 & my compiled exes in VB6 stop working on client end, and this morning it happened with my Work Computer...

     

    I was thinking of going back to Win XP, If I didn't find the solution today.

     

    Thank You !!! :)

    Monday, May 16, 2011 2:15 PM
  • Hi again,

    Thanks to Ming for his response that this is replicated error. However, I assumed that that response would be followed by some indication of how this problem can be fixed. At present we have applications which use the MSADOR15 library and which will not work in Windows 7 SP1. The only workarounds that have been discussed are:

    1) Stay on Windows 7 RTM or earlier versions of Windows.

    2) Recompile using the MSADO15 library and redistribute to all clients.

    Neither of these is practical solution for anything but very short term for most people. In our case it just might be possible to adopt the second approach but only with a large amount of (what should have been unnecessary) effort.

    The question that needs an early answer is:

    Is Microsoft going to provide a full solution to this problem of its own making?

    It has been three weeks now since it was agreed that this was a problem and while I appreciate the solution may be wrapped up with resolving other SP1 ADO issues, it would be helpful to know if something was on the way.

    Thanks in advance for any info you can provide.

    Wednesday, June 01, 2011 8:53 AM
  • Yes, this is a runtime regression.

    We are looking at the possibility of releasing a hotfix for SP1.

     

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Wednesday, June 01, 2011 9:38 AM
  • Hi there,


    Are there any updates on this -- is a hotfix going to be released? If not, what guidance do Microsoft have to resolve this issue? Are we able to track this on Microsoft Connect?

    Cheers,

    Chris

    Monday, July 18, 2011 1:23 PM
  • Ming,

    Is there an update on the hotfix for SP1.

    We are close to losing a large customer if we do not come up with a solution.

    My problem is the same mentioned earlier in this  thread. I have VB6 XP compiled objects  (Server/Client) that will not communicate from client to server when running Win7 SP1.

    Our company has many of these applications in the field. We are now suffering for this flaw in Win7 SP1.

    Can you advise ?

     

    Don

    Friday, August 05, 2011 2:41 PM
  • Don,

    As mentioned earlier, if you have a business impact and the issue cannot be worked around, please open a case with our Customer Support Team. Please mention your business impact in your request.

    This allows us to triage / prioritize the hotfix schedule.

    But for this particular issue, I think that it can be worked around by referencing the ADO typelib, rather than the ADOR typelib. However, since there is another issue in the ADO typelib in Win7 SP1, please compile your VB6 app on Win7 RTM or below. Does this workaround works for you?

     

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     

     


    Pak-Ming Cheung - MSFT
    Saturday, August 06, 2011 3:34 AM
  • All, you may want to try to compile against ADO 2.7 in stead of 2.8 as a temporary work around.

    I have an executable and COM dll's that refer to ADO 2.7, in an application that I compile with VB 6 SP6 on Windows 7 64 bits. This application works without problems on any target Windows operating environment, including Windows 7 64 bits with SP1.

     

    Saturday, August 06, 2011 10:07 AM
  • Ming,

    I am slightly worried by your answer here. It sounds like you don't think this is a significant issue given the 'workaround'. However, unlike the issue in the "Breaking change in MDAC ADODB components in Windows 7 Service pack 1" thread, this issue's effects are felt by existing applications. If clients upgrade to SP1 the current versions of applications stop working. Surely, if anything, this is more signficant than the case where newly compiled applications don't work on an older OS.

    I have been waiting for the promised fix since your June 1st reply. As previously mentioned in our case it would be a very significant but not impossible task to amend the applications and distribute them to our users. However I can imagine this will be much more difficult for others.

    If you are implying that this issue is not being given the highest priority please say so. At least then everyone can start resourcing alternative arrangements.

    Monday, August 08, 2011 8:42 AM
  • Furzehill,

     

    I am sorry if I gave you a wrong impression. I do agree that this is a bad bug and it should be fixed.

    However, it is TRUE that there is a workaround. But we also understand that it is usually difficult to change the code of an existing product from customers, while it may be easier to work around the issue for a new product release.

    Anyway, if this issue really blocked your business, please feel free to open a case with our CSS team as what I have mentioned above. They will certainly review your business impact and give a correct prioritization to the issue.

    I hope that all the above statements are fair to every one.

    btw, please forgive me that I cannot tell you too much about our progress on the fix of the issue because of the forum policy........

     

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Monday, August 08, 2011 3:47 PM
  • Bill,

    We too are waiting for this answer. One large client is very anxious to see if our application will remaiin viable. Their roll out of SP1 had to be recalled and cost them warehouse down time.

    "Resourcing alternative arrangements" is, for us, incredibly challenging. Especially since this should not be a problem in the first place.

    Thanks for remaining active in this forum. I wish we had enough clout to force a quicker solution.


    Donald R. Padgett
    Wednesday, August 10, 2011 2:37 PM
  • Bill ,DonP_gett and others interested people.

    I have the same issue with windows 7 SP1 and I've solved temporary installing Windows XP in a freeware virtual environment (VirtualBox) , installing at it Visual Basic 6 and compiling with It. I've mapped letters from virtual environment to my local drives for using directly the sources and not syncronizyng later the sources at virtual environment with local source.

    The bad part of it is that you need a lot of memory (2 GB at least) , better with 4 GB.

    I've a Core 2 Duo at 2.26 Ghz with  4 GB Installed,, windows 7 only using 2.90 GB , and in the virtual environment configured with 512 MB of RAM. It works OK.

    Thursday, August 11, 2011 6:29 AM
  • Also waiting for the Hotfix or practical instructions. In my notebook going back to Win7 RVP, but my new desktop Win7 came with SP1 and I do not know how to go to 7 whithout it.

     

    Here in Brazil we have thousands of developers and companies using VB6 yet. Most of the customers using XP SP3. We need some help.

     

    Thanks in advance,

     

    Luiz Alfredo Guimarães Menezes

     


    L.A.G.M.
    Tuesday, August 16, 2011 7:20 PM
  • Luiz,

     

    I think that it is impossible to go back to Win7 RTM, if your new desktop was preinstalled with Win7 SP1. To workaround the issue, you may try to install the "XP Mode" which basically installs a WinXP Virtual machine on your Win7. I agree that this may sound like to be ugly, but this should be one of the possible ways to workaround the issue. "XP Mode" can be freely downloaded from: http://www.microsoft.com/windows/virtual-pc/download.aspx

     

    Again, if this issue blocks your business significantly, please open a formal case with our Customer Support team. They will evaluate your business impact and see whether they can release a hotfix to you sooner.

     

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Wednesday, August 17, 2011 2:42 AM
  • Hi,

    We are experience exatly this problem. We are now holding the installation of WIN 7, SP 1.
    Problem is that we must install some new computers that are bundled with SP1 and therefore cannot be used with the VB6 applications.

    When can we expect a fix for this issue?

    Best Regards
    Thomas Eriksson
    Consultant
    Returpack AB, Sweden

     

    Monday, September 05, 2011 6:17 AM
  • Thanks David,

    I am succesfully using the XP virtual solution in house, however, none of our customers are willing to go that route. They are waiting for a fix.

    My prayer is that MS come through on this one.

     

    Don


    Donald R. Padgett
    Wednesday, September 07, 2011 3:59 PM
  • The Windows 8 Preview build contains the complete fix of this issue. Please download the Preview build freely at:http://msdn.microsoft.com/en-us/windows/apps/br229516. (However,please note that there is no customer support if you got any problem with the Windows 8 Preview build - so please only install the build on your test machines, but not your business-important machines).

    In the preview build, what we have done are:

    - Pull out the 6.0 typelib from Win7 RTM and ship it via the new typelib file: msado60.tlb. Ship a new 6.1 typelib (which contains both new and deprecated interfaces) and embed it inside the msado15.dll. Revert back all 2.x typelibs to what they looked like as in Win7 RTM. Therefore, the 2.x and 6.0 typelib are used for backward compatible purpose, and the 6.1 typelib is used for 64-bit VBA solutions. You are advised to migrate to the 6.1 typelib whenever there is no more downlevel support concern for your applications. This fixes the recompilation issue (as reported in the forum thread: http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13?prof=required).

    - We also fixed the thread handle leak issue in ADO Async execution mode (as reported in the forum thread:http://social.msdn.microsoft.com/Forums/en/sqldataaccess/thread/68e23681-f6b5-4ed5-b963-e63e34eeac2f)

    - msadoR15.dll has been reverted back to what it looks like in Win7 RTM. Since this binary is deprecated, there is no new interfaces introduced for ADOR. btw, customers are advised to migrate to ADO interfaces. (Actually, ADOR is simply a subset of ADO)

    - COM+ marshalling scenario (as reported in this forum thread)

    - Some other internally reported issues.

     

    With the newly-implemented solution, if customers require downlevel support, they should compile their applications with the 6.0 typelib (or 2.x typelib). [btw, 2.x typelibs are deprecated, so we advise our customers to use the 6.0 typelib]. Whenever the downlevel support requirement are gone in the future (say, those downlevel platforms are not relevant anymore as times goes on), customers should seriously consider to migrate to the 6.1 typelib, which is the only supported typelib in the future.

     

    If your applications (VBA, VB6, .NET) are referencing the 6.0 (or below) typelib, you can simply recompile your application on the Windows 8 Preview build and then your application should now work on downlevel platforms as well. If you are using C++ and using "import msado15.dll", you have to change the reference to "msado60.tlb" in your code and recompile to get downlevel platform compatibility. If you are using C++ and using "include header method", you have to use the latest Win8 SDK and target your applications to downlevel, in order to obtain the backward compatibility behavior (see the Visual Studio setting for more detail on how to target downlevel platforms) [Please note that VB6 and .NET ADO interop are not supported anymore. This forum post does not imply any future support of these out-of-support technologies.]

     

    So, I hope everyone who has impacted by this issue to try out the Windows 8 Preview build as soon as possible. Report any new (un-addressed) issues to us, so that we can address them in the Windows 8 RTM build. Your feedback is very important to the success of the Windows 8.

    [Important Note: We would like to centralize all future communication. Therefore, I have opened a new forum thread at:http://social.msdn.microsoft.com/Forums/en-NZ/windowsgeneraldevelopmentissues/thread/280de88a-77dd-455e-9797-b28928206e38. Please reply or discuss on the new forum thread instead of this one. This can save everyone time and effort to find your new findings and discussions. We will not monitor this forum thread anymore, but monitor the new forum thread].

    =========

    We are still actively looking at whether / how to ship the fixes on Windows 7 SP1 (and other downlevel platforms). Therefore, please stay tuned. We will announce once we got more information on the downlevel fixes. In the mean time, please try the Windows 8 Preview build first.

     

    Sorry for any inconvenience caused by this issue and hopefully the Windows 8 fix can address your problem.

     

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     

     


    Pak-Ming Cheung - MSFT
    Monday, September 19, 2011 3:06 AM
  • I have posted a fuller response on the new thread, but the idea of closing this thread just because a Windows 8 preview does not have this problem is crazy. Come on Microsoft let's solve this problem rather than just abandon everybody until Windows 8.

    Monday, September 19, 2011 9:06 AM
  • I was able to change the ADO from 2.8 to 2.7 then transfer the project to an XP to be compiled.  This took care of the problem and was a good easy solution.  I hope someone benefits from this as it seems that MS is not going to do much about this problem soon enough.

    Tuesday, December 13, 2011 3:45 AM
  • @Ming:

    1) I complied my vb6 app (.exe) on a x64 W7SP1 machine with both backcompat.tlb (32 and 64) installed. Everything compiled and I deployed it to a Win7SP1 PC where it works without installing the backcompat.tlb.

    2) I also compiled my vb6 com dll on the same machine and deployed it to a W2008R2 SP1 Server where it failed with an error loading dll. When I installed the backcompat.tlb on the server it worked.

    Is this behaviour correct which means in one case I don't need to deploy the tlb (W7SP1) and in the other case it is necessary (W2008R2SP1) ?

    Pleas advise
    Thanks
    Wolfgang

    Monday, February 13, 2012 10:23 AM
  • Wolfgang,

    This is not expected. As far as know, VB6 will normally not load the typelib at runtime. Therefore, it is not expected to install the backcompat tlb on the W2008 R2 server. Please tell us what have you done (step-by-step detail with code snipplet) in the COM DLL built from VB6.

    Thanks,
    Ming.
    WDAC Team, Microsoft.


    Pak-Ming Cheung - MSFT

    Tuesday, February 14, 2012 7:25 AM
  • Announcement:

    We have just published the fix for Win7 SP1 and Win Server 2008 R2 SP1. Please download and install the KB from http://support.microsoft.com/kb/2640696 (also, please read the section "Update Information" carefully). This fix is very similar to the Win8's fix; so if you can work well with the Win8 fix, it is very likely that the new fix can work for you as well.

    In case if you encounter any issues with the new fix, please post the detail steps to reproduce the issue in the forum: http://social.msdn.microsoft.com/Forums/en-NZ/windowsgeneraldevelopmentissues/thread/280de88a-77dd-455e-9797-b28928206e38. Or if it is an urgent issue blocking your business, please file a new request to our customer support team.


    Thanks,
    Ming.
    WDAC Team, Microsoft.

     

    Wednesday, February 15, 2012 5:14 AM
  • Ming,
    thanks for your reply.
    It is difficult to explain everything what is inside the dll, but from my point of view I cannot see what is so special in it. It is installed as a library component of another COM dll which has not changed for a long time, so this one is installed as a server component without being recompiled.
    However what happend now after installing the update is quite strange: When I delete the BackCompat reference and replace it with the new ActiveX 6.1 Library I receive a compiler error that says it is not compatible anymore to both the old (before BackCompat) and new dll.
    So there seems to be no way to proceed with the new reference without breaking old references.
    This situation also happend with other dlls which are installed on the client. There I have a reference to a typelib which I created and it is implemented as follows:
    Private WithEvents cExecutant       As IDocExecutant

    Private Sub cExecutant_OnConflict(ByVal rsConflict As ADODB.Recordset)

    End Sub
    The COM events are done with the feature described by Matt Curland.

    I know this is not a very detailed information, so how should we proceed ?
    Thanks
    Wolfgang

    Thursday, February 16, 2012 7:58 PM
  • Well..... the information isn't enough for me to understand the problem. It would be better to give us the detail:

    - How many DLL / EXE are involved?

    - What're their relationship to each other?

    - What're their platform (x86 or x64)? Since you are using VB6, I suspect that all your binaries are x86, but please confirm.

    - How are they compiled (which typelib are they referencing in compilation)?

    - Are they exposing COM interfaces such that another DLL / EXE are relying?

    - Are all of your binaries (DLL / EXE) run on the same machines? Are there any remoting scenario?

    - You have mentioned something like "failed to load DLL". So, which DLL is being loading from which binary (EXE / DLL)?


    Since we have just shipped KB #2640696, please ignore the backcompat typelib from now on (This can simplify the problem a little bit). Since you are using VB6, I think that you can reference the "ADO 6.0" typelib (but if your application is targetting Win XP / Win Server 2003, you need to use "ADO 2.8" typelib). Please see the KB on detail how to browse to that file in VB6.

    Make sure *all* of your binaries (DLL / EXE) are recompiled with referencing the "ADO 6.0" typelib.

    If your application was working when you compiled on Windows 7 RTM, you should get it working again when you recompiled on Windows 7 SP1 (after installing KB #2640696 and doing the above steps).

     

    Again, if this is urgent in your business, please open a case to our customer support team.


    Thanks,
    Ming.
    WDAC Team, Microsoft.


     


    Pak-Ming Cheung - MSFT

    Friday, February 17, 2012 1:47 AM
  • Ming,
    thanks for your reply.
    This line solved my problem:
    >> but if your application is targetting Win XP / Win Server 2003, you need to use "ADO 2.8" typelib
    When I changed the reference from ActiveX6.1 to ADO 2.8 everything compiled perfectly.
    So even if all my customers have changed to W7 I will stay on this typelib, until the whole project is moved to .NET :)

    Thanks
    Wolfgang

    Friday, February 17, 2012 8:18 AM