locked
ADO, adAsyncExecute and Windows 7 SP1 handles leaking RRS feed

  • Question

  • Is anyone here accessing a database using the ADO ActiveX with the
    adAsyncExecute option for the Execute method so the call is non blocking
    with the ExecuteComplete called upon completion?

    Since installing Windows 7 SP1, I've discovered a massive handle and
    memory leak in a database application using this option, each execute call
    leaks three handles and about 20K of memory.  This happens on both 32-bit
    and 64-bit Windows 7 SP1, and Windows 2008 R2 SP1.  The same application
    runs without any leaks on Windows 7 and 2008 R2 without SP1. Closing the
    database connection releases all the handles, but this took 10 minutes
    with 180,000 handles from 60,000 writes.

    Internally, msado15.dll starts two threads so the Execute method can
    return immediately, and it seems the thread and event handles, and some
    memory are not being released.  msado15.dll is 6.1.7601.17514.

    Goggling does not show any other reports of such leaks, but does bring up
    KB983246 from May 2010 in which Microsoft has changed some ADO interfaces
    for 64-bit Windows platforms, and SP1 is probably the first wide release
    of this hotfix.  The hotfix is available for all platforms, so assuming
    the leak was introduced as the same time, it may potentially effect
    Windows XP or later. 
     
    Angus

     

    Monday, March 7, 2011 10:33 AM

Answers

  • We have just identified the root cause of the regression. It is a reference count leak within the ADO, whenever the application is using ADO Event and asynchronous execution. The reference count leak eventually results in leaking of a thread handle, etc.

    This issue will be fixed in one of the future releases of windows. But in case if this issue blocks your business significantly, please contact Microsoft CSS. We will then decide whether we can release a QFE based on customer's impact, how risky to fix, etc.

    For KB955843, this is a deadlock issue with ADO Async. The issue has been fixed via a QFE on Srv03 SP1 and SP2, and XP SP2 and SP3. Also, the issue has been fixed in Vista RTM and all subsequent releases. However, since there can be many reasons to result in deadlock, it is difficult to say whether your issue is related to the KB955843. If you are in doubt, you can try to install the KB on your Srv03 and see whether the issue can be repro or not, or contact Microsoft CSS for more information. You might need to prepare a dump (hanged dump) to CSS so that they can quickly determine whether they are of the same issue.

    btw, if you are using Srv03 SP1 or Srv03 SP2, the MDAC component is already in-band (shipped with windows directly - installing SQL 2K5 will not update the MDAC component). You can get more detail information from our roadmap at: http://msdn.microsoft.com/en-us/library/ms810810.aspx.

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Monday, March 14, 2011 6:50 AM
    Answerer
  • After 11 months, there is finally a working hotfix for the handle and memory leaks in the msado15.dll introduced with Windows 7 SP1 at  KB2640696:

    http://support.microsoft.com/kb/2640696

    The article does not mention any memory leaks, only the other issue that prevented some programs developed under SP1 running under old versions of Windows.  But I have tested both the 32-bit and 64-bit hotfixes with the ADO test program I wrote 10 months ago, and memory is no longer leaked. 

    Thank you Ming, I guess you had a long internal battle to get the hotfix released.

    Angus


    Angus Robertson - Magenta Systems Ltd

    • Marked as answer by Angus Robertson Wednesday, February 15, 2012 11:55 AM
    Wednesday, February 15, 2012 11:54 AM

All replies

  • Hi Angus,

    Could you please post some code snippets in the thread?

    Since the issue occurs after installing Windows 7 SP1, it might be a product issue.   I would suggest you also open a case with Microsoft CSS for this issue.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, March 8, 2011 3:11 AM
  • Thanks for telling us about the issue. This does sound like a regression in Win7 SP1 from Win7 RTM.
    As mentioned by Jian, please post the code snippets here so that we can start the investigation.

    In case if this issue is significant to your business, please open a CSS case as well.

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Tuesday, March 8, 2011 6:03 AM
    Answerer
  • The handle and memory leak issue occurs in our ComCap application, which
    is a general purpose data capture tool, writing data to files and SQL,
    http://www.magsys.co.uk/comcap/

    No users have reported the leak yet, but our users tend to be very
    conservative with upgrades for business critical systems, ComCap just
    sits quietly for years collecting telephone CDRs, instrument data, syslogs,
    etc.

    ComCap is a Delphi 2007 application, so I'm not sure how much use our Pascal
    source code will be, ADO is wrapped in a Delphi ADO database class component,
    with the type library converted to Pascal, an old version:

    LCID: {00000200-0000-0010-8000-00AA006D2EA4}
    Microsoft ActiveX Data Objects 2.1 Library

    The code optionally calls the sync or async ADO Execute methods, the former
    works fine without any leaks, the latter leaks the thread and event handles.

    if NOT ChDbUseAsync then
        ChDbAdoConn.Execute (ChDbLastCmdLine)  // sync
    else
        ChDbAdoConn.Execute (ChDbLastCmdLine, cmdText, [eoAsyncExecute, eoAsyncFetchNonBlocking]) ;  // async
       
    The database class translates these arguments into ADO literals:

    ConnectionObject.Execute(CommandText, VarRecsAffected, adCmdText+ExecuteOptionsToOrd(ExecuteOptions));

    The application does not currently use any threads for database access,
    although I'll have to replace the async method with its own thread and the
    sync method if this leak is not fixed real soon. 

    The application can use the sync method now, but the same thread may be
    capturing TCP data from 20 sources and writing 20 databases, so clearly
    async non-blocking is preferable. 

    I hope this is sufficient to get this issue investigated.  I note it's not
    the first problem with this option, see KB955843 about a thread deadlock.

    Angus


    Angus Robertson - Magenta Systems Ltd
    Tuesday, March 8, 2011 10:53 AM
  • Although it seems that the application can be downloaded freely, I don't know how I can reproduce the issue with ComCap.

    Therefore, could you give us a simplified repro code snippets? Preferably, it only contains ADO code. This can help our investigation much.

    The other way is to use the UMDH to give us a call stack about the leak. UMDH can be obtained at: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx. See "umdh /?" about how to use the tools. You also need to use tools "gflags" to enable the "user-mode stack trace database". And you need to setup the symbol server pointing to the Microsoft public symbol server. 

    However, in case if it is too difficult for you to distill a simplified repro, you might contact our CSS representative who will be happy to help you on the repro issue.

    Thanks,
    Ming.

     


    Pak-Ming Cheung - MSFT
    Tuesday, March 8, 2011 3:05 PM
    Answerer
  • The ComCap demo package has everything you need, but will take 30 minutes or so to set-up.  There is a ComGen tool that generates test lines of data over serial, TCP or UDP ports, SQL scripts to create test tables and stored procedures, and then ComCap itself to capture UDP packets from ComGen and write then to your new database.  One packet per second will leak three handles per second. 

    I suspect the Microsoft debuggers will not be interested in working with Delphi applications.  I do has System Internals Handles and Process Monitor logs, but these simply show lots of thread and event handles leaking.

    I guess I could write a simple Delphi application reading rows from AdventureWorks, which should be sufficient to reproduce the leak. 

    Are you aware of a Windows API that reports handles used by a process?  Memory leaks I can report with GetProcessMemoryInfo. but not found anything for handles.

    Angus

     

     


    Angus Robertson - Magenta Systems Ltd
    Tuesday, March 8, 2011 4:25 PM
  • Sorry, I couldn't repro the issue with the tools you mentioned. What I have tried to do are:

    - Install the ComGen at: http://www.magsys.co.uk/download/software/comcap.zip

    - Launch ComGen Data Stream Generator:
      * Network tab:
             Protocol = UDP Client
             Enabled = TRUE
             Local: IP Address = <my local IP>
             IP Port (local) = 0
             Remote: IP Address = <my local IP> (same as the above)
             IP Port (remote) = 10000
             Data Type = Fixed Line
             Other settings left as default
      * Click the button "Start" at the main interface

    - Launch the ComCap program:
      * Settings -> Common Settings -> Network tab:
               Capture Name = "UDP"
               Enabled = TRUE
               IP Protocol = UDP Server
               Service = "" (<leave as blank>)
               Local IP Address = <my local IP> (same as the above)
               IP Port (local) = 10000
               Remote IP Address = <my local IP> (same as the above)
               IP Port (remote) = 0
               Other settings left as default
       * Settings -> Common Settings -> Log Files tab:
               Main Directory: <one of my local directory>
       * Click the button "Start" at the main interface

    I do see that some lines such as:
               "ComGen TEST-20112450445 2011-03-09T09:36:02 00000006 ...."
    got displayed on the main interface of ComCap. And there are two files generated in my local log directory.

    However, there is no memory leak or thread leak. I run the above on Win7 SP1.

    I tried to use perfmon.exe to monitor the three counters "Process-> Private Bytes", "Process -> Thread Count" and "Process -> Handle Count" for the two processes "comcap4" and "comgen". However, it does not show any increment after the warmup time. All these counters stay flat after startup.

    Therefore, I am not sure how to reproduce the issue. Could you give me a step-by-step guidance (just like what i have written) to repro the issue? Or could you give me a code snippets in Delphi (preferably, if you can write it in Visual Studio, since i have no Delphi installed in my office).

    btw, the debugger tools (umdh) can work well for all native applications. Therefore, it should be able to capture the memory leak even if your application is written in Delphi.

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Wednesday, March 9, 2011 2:01 AM
    Answerer
  • Many thanks for trying to reproduce the handle leak, you just have one major
    step left, which is actually to write to a database <g>

    You need to create the sample comcap database in SQL Server, with the scripts
    described at (or in the help):

    http://www.magsys.co.uk/comcap/onlinehelp/index.html?db_sample_databases.htm

    For this test, you really only need the simple capture_whole table.  
    In Settings, General, tick Save to Database, then on the Database tab set-up
    the connection per:

    http://www.magsys.co.uk/comcap/onlinehelp/index.html?db_microsoft_sql_server.htm

    Then select Add Records, Stored Procedure, select the capture_whole_put SP,
    tick both 'Extra Columns'.  The Data Format tab will now list the database
    column names, for the info column set record starting position 1 and the
    whole of each captured line will be written to that column. 

    Restart capture, and the info log window should show a SQL connection being
    opened OK, and the status bar showing how many rows have been written.  Task
    Manager should then show handle count increasing three for each row written.

    BTW, I've only tested against SQL Server 2008 R2, since I assume this is a
    client issue. 

    I will write a simple test application this morning to try and reproduce the
    handle leak in a much easier way, partly to prove I'm not deluding myself.

    Angus

    Angus Robertson - Magenta Systems Ltd
    Wednesday, March 9, 2011 10:10 AM
  • As requested, I've written a small ADO application demonstrating async
    execute requests, and reporting working memory and handle usage.  It
    can be downloaded from:

    http://www.magsys.co.uk/download/software/testadoexec.zip

    The zip includes an EXE and Delphi 2007 source code.  Hopefully it's
    usage is self explanatory. 

    Angus

    Angus Robertson - Magenta Systems Ltd
    Wednesday, March 9, 2011 3:32 PM
  • Thanks for telling me how to repro the issue. I can now repro the issue with ComCap. I do see thread handles and event handles leak in the program. However, I am still studying the root cause of the issue.

    btw, I cannot access: http://www.magsys.co.uk/download/software/testadoexec.zip
    It returns me "404: The Web site cannot be found".

    Although I can repro the issue and I am not investigating the issue from ComCap, could you please still make the above link available so that I can investigate the issue faster. btw, are there any source code inside the zip?

    Thanks,
    Ming.
    WDAC Team.

     


    Pak-Ming Cheung - MSFT
    Thursday, March 10, 2011 10:31 AM
    Answerer
  • I'm relieved you managed to reproduce the handle leak in ComCap, thank you for perservering. 

    The testadoexec.zip file is now available, sorry forgot to upload it yesterday.

    Assuming this is a lurking ADO bug, will there be a hotfix for it in a few weeks?

    I'm also interested in the history of KB955843, relating to ADO thread deadlocks.  I do get rare
    reports of ComCap locking up while updating SQL, which could be explained by KB955843.
    The question is has this been released through Windows Update for XP, 2003 and Vista.
    My own 2003 has a later version of ADO, but this probably came from a SQL Server 2005 update.

    Angus

     

     


    Angus Robertson - Magenta Systems Ltd
    Thursday, March 10, 2011 10:49 AM
  • We have just identified the root cause of the regression. It is a reference count leak within the ADO, whenever the application is using ADO Event and asynchronous execution. The reference count leak eventually results in leaking of a thread handle, etc.

    This issue will be fixed in one of the future releases of windows. But in case if this issue blocks your business significantly, please contact Microsoft CSS. We will then decide whether we can release a QFE based on customer's impact, how risky to fix, etc.

    For KB955843, this is a deadlock issue with ADO Async. The issue has been fixed via a QFE on Srv03 SP1 and SP2, and XP SP2 and SP3. Also, the issue has been fixed in Vista RTM and all subsequent releases. However, since there can be many reasons to result in deadlock, it is difficult to say whether your issue is related to the KB955843. If you are in doubt, you can try to install the KB on your Srv03 and see whether the issue can be repro or not, or contact Microsoft CSS for more information. You might need to prepare a dump (hanged dump) to CSS so that they can quickly determine whether they are of the same issue.

    btw, if you are using Srv03 SP1 or Srv03 SP2, the MDAC component is already in-band (shipped with windows directly - installing SQL 2K5 will not update the MDAC component). You can get more detail information from our roadmap at: http://msdn.microsoft.com/en-us/library/ms810810.aspx.

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Monday, March 14, 2011 6:50 AM
    Answerer
  • This is serious, it's unclear when leak was introduced, and which platforms it could be deployed to.  Why is it only showing up now under (7 and 2008) SP1?  Could it happen on other platforms, if so how and which delivery mechanism (MDAC, OS Service Pack, etc).

     

    Monday, March 14, 2011 4:10 PM
  • I've only reproduced the leak in Windows 7/2008 R2 SP1, but I suspect it was introduced with KB983246 from May 2010, which is a hotfix available for Windows XP and later, mainly for Office 2010 64-bit compatibility (according to my reading).

    Perhaps the WDAC team can confirm if the leak was in the hotfix, or only a later change for SP1 (which is a different build).

    I have opened a CSS case, although unfortunately it seems to be 'Severity C (Minimum business impact)' when I'd have thought that crashing a server due to memory exhaustion would have some business impact <g>

    I'd guess there are no more service packs for XP, 2003 or Vista/2008, so the hotfix is unlikely to be distributed automatically to older platforms.

    Angus

     


    Angus Robertson - Magenta Systems Ltd
    Monday, March 14, 2011 4:28 PM
  • Yes, Angus is right here. This regression was introduced in KB983246.

    Therefore, Win7 SP1 is suffered. And all machines installed the KB983246 will be suffered.

    But, fortunately, if someone (say, Angus or Ted) was severely impacted, we should have some way to fix it (QFE is one of the ways).

    Angus, it is good to start engaging the CSS team. I believe they will contact you very soon, even though they assigned an initial rating of "severity C".

    Ted, if this is really a serious issue to you, please also open a CSS case. This allows us to officially keep track how many customers were impacted.

    But I would like to clarify a little bit - the regression can be hit whenever the ADO application is using both event and asynchronous execution. I forgot to mention "async" in my previous post.

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Tuesday, March 15, 2011 12:17 AM
    Answerer
  • Any one find a solution yet to this problem? Microsoft going to release any official finding about this issue?  Is it possible to rollback SP1? Or uninstalling KB983246 update fix the problem?

    I am not sure what is causing my Windows 7 SP1 machine to keep running out memory.  I currently do have SQL 2008R2 and SQL Express 2005 SP2 installed on my machine.  Also Visual Studio 2008 and Office 2010.  I have eliminated many of the services at startup to see if that helps.  Message that keeps popping up is microsoft windows dialog box keeps saying 'Close programs to prevent information loss' - 'Your computer is low on memory. Save your files and close these programs.'  It always has Microsoft Outlook and Internet Explorer listed as the programs to close.  Not sure if that means these are the culprits programs causing the memory leak.

     

    Thanks,

    Matt


    Matt Shah
    Thursday, March 17, 2011 1:17 PM
  • Uninstalling SP1 or uninstalling the KB983246 should help this issue.

    However, before doing so, please identify whether you are suffered from the same issue first. Since you only mentioned that you can get "out-of-memory" problem easily, have you identified which program or which component caused that leak?

    To identify the program that has memory leak, you can try to use perfmon.exe to monitor the memory usage. The usual counter that I am using is "Process -> Private Bytes". Since the issue can result in "low memory" in your system, the problematic program should be an outlier among all of your other processes. In other words, you can identify the problematic process easily.

    After identified the problematic process, you can then try to use "UMDH" (downloaded from http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx) to detect which component leaks that memory. See "umdh /?" about how to use the tools. You also need to use tools "gflags" to enable the "user-mode stack trace database". And you need to setup the symbol server pointing to the Microsoft public symbol server.

    If you can confirm that this is an issue from a Microsoft component and if it impacts your usage (e.g. low memory on the system), then please contact Microsoft CSS for further help.

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Wednesday, March 23, 2011 10:27 AM
    Answerer
  • You need to identify the application using a lot of working memory, using Task Manager or a similar tool.  If that application is also using 50,000 or more windows handles, it is probably this ADO handle leak bug. 

    This bug only happens if an application is making many thousands of  ADO database requests, probably hundreds of thousands before a problem is noticed.  It will only happen with client database applications, not the server. 

    And that application must be making asynchronous non-blocking execute database requests, whereas many applications (including most of mine) will be making synchronous blocking requests (because they are easier to program) and will not exhibit the handle leak bug. 

    The only workaround at the moment is to avoid making asynchronous requests, so I have rewritten my ComCap application to use a separate thread to make synchronous requests instead.  It will actually be more efficiemt. since the ADO async method starts and stops two threads for each execute request, and I now have one thread running continually instead of up to 100 threads starting and stopping each second.  Maybe everyone else does this already, which is why few people have reported this handle leak error <g>

    Angus

     


    Angus Robertson - Magenta Systems Ltd
    Wednesday, March 23, 2011 10:33 AM
  • Thank you for the detailed writeup in this post. We are experiencing the same problem. We have a VB6 application making async ADO calls to write to a database approximately 4000 writes per hour. With Windows 7 SP1 installed, we see the process Private Bytes counter rise linearly until eventually we get an out of memory error.  We do not see the handle counter increase.  The problem goes away when SP1 is uninstalled. We registered a support issue with Microsoft and linked to this post. They replied they are working on a fix for the problem. No information when it will be released. We also experienced the problem mentioned elsewhere where if we compile on a PC with Windows 7 SP1 installed, the application won't connect to the database on lesser versions of Windows because the ADO interface was changed.

    Our short-term solution is to not install SP1 anywhere. We are evaluating what to do for the long-term.

     

    Elena Lawrence

    Solid State Equipment Corp.

    Tuesday, May 3, 2011 3:02 PM
  • We have the same problem. Is already a hotfix available?
    Friday, May 27, 2011 3:49 PM
  • Sorry, I've not heard of a hotfix, nor any acknowledgement from Microsoft (such as knowledgebase article) that this ADO problem exists, outside this MSDN thread.

    I've rewritten my own ComCap application to use a single thread for database access, instead of letting ADO create a tthread for each command, which is probably rather more efficient, avoids this problem, and a previous thread deadlock issue that I suspect my users have encountered.

    Angus


    Angus Robertson - Magenta Systems Ltd
    Friday, May 27, 2011 4:11 PM
  • We are seeing the same issue.   I'm trying to figure out if Angus' solution would be viable in our case.

    Aaron

    Quomation


    Thursday, June 9, 2011 7:17 PM
  • KB Article Number(s): 978042

    I was able to apply the following hot fix:
    http://support.microsoft.com/kb/978042

    It worked incredibly (after rebooting).

    It went from a linear increase up to about 2 gigs of memory in task manager and then getting a "System resources exceeded" error to after applying the hotfix - the program stopping at 90 Megs or so of memory in task manager and remaining constant as well as the private bytes in perfmon are now also constant.

    Aaron

    Quomation

    Friday, June 10, 2011 7:51 PM
  • KB78042 dates back to December 2009 and relates to a memory leak caused by persist secruity info=false. 

    Windows 7 SP1 msado15.dll is 6.1.7601.17514, but the version in the patch is older 6.1.7600.20569.  There have been at least more releases since then, the latest I found with a security bulletin 6.1.7600.20818.

    While installing an older version of the DLL may fix the memory leak discussed in this thread, Windows Update may decide you have an old version of the the DLL, and download the security fix or SP1 and update it. 

    I have overcome the memory leak by rewriting my application to avoid the bug, and my customers report the application is now much more reliable and no longer periodically locks up, which probably means they were experiencing previous deadlock issues.

    Angus

     


    Angus Robertson - Magenta Systems Ltd
    Saturday, June 11, 2011 5:41 PM
  • I am experiencing this issue; I debugged the disassembly quite thoroughly to pinpoint the issue and created a connect item at http://connect.microsoft.com/VisualStudio/feedback/details/682540/significant-ado-memory-leak-when-using-asynchronous-operations-with-events -- I also created a professional support incident with Microsoft.

    And now I find this thread, after fruitless searching for others experiencing this issue. We opened a professional support incident with Microsoft recently, but I am surprised this issue has been identified for nearly 5 months now without even a KB article, let alone a hotfix.

    Adzm
    Friday, August 5, 2011 1:25 PM
  • Cogratulations on your hard work detailed in the other thread explaining exactly how memory and handles are leaking.

    But as you say, the WDAC Team from Microsoft identified (and probably fixed) the problem back in March, and it's sad that developers such as yourself are wasting valuable time repeating this testing, when Microsoft could have at least issued a KB, if not a hotfix. 

    Can I suggest you post a link to this thread back in Connect, so anyone finding it sees the full story.

    At least the more reports, the more likely Microsoft will issue the fix.

    Angus


    Angus Robertson - Magenta Systems Ltd
    Friday, August 5, 2011 1:43 PM
  • Hi.

    I'm experiencing the same issue as you already have found. My enviroment is W2k8r2SP1 with msado15.dll 6.1.7601.17514.

    I have installed 4 server's (W2k8r2SP1) at different customers and they all are experiencing memory leaks.
    On a W2k3r2SP2 server it's works OK.

    Is there any planning of an update for this problem?

    Bjørn.

    Tuesday, August 9, 2011 2:21 PM
  • Any applications running on a machine with the update applied will experience the leaks, assuming you are using asynchronous operations and handling events. Unfortunately I have heard nothing further from Microsoft regarding the issue, but I'm sure we'll be kept up to date. It may be helpful to visit the connect item here http://connect.microsoft.com/VisualStudio/feedback/details/682540/significant-ado-memory-leak-when-using-asynchronous-operations-with-events and add your vote and feedback to help highlight the prevalence of those affected by this problem.
    Adzm
    Tuesday, August 9, 2011 2:33 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 this forum thread)

    - 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 the forum thread: http://social.msdn.microsoft.com/Forums/en-NZ/windowsgeneraldevelopmentissues/thread/0a0fa3b8-9334-45a3-8405-44e6f969c46f)

    - 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:09 AM
    Answerer
  • I have spot the same issue in my app recently. What it does is communicate with up to 800 clients using TCP/IP and storing data into MSSQL DB.

    When there are no clients connected, the working set of my app is not increasing. As soon as some clients connect, it starts increasing. I noticed (using Process Explorer) when this happens, there is a thread using msado15.dll starting and stopping constantly.

    I also made 2 log files with umdh.exe and in their compare there is a following stack situation:

    + 5302696 ( 7077376 - 1774680)  38464 allocs    BackTrace2F7C690
    +   28819 (  38464 -   9645)    BackTrace2F7C690    allocations

        ntdll!EtwSetMark+00002405
        MSDART!MpHeapAlloc+0000002D
        msado15!DllGetClassObject+00009EC5
        msado15!DllGetClassObject+0003BCCC
        msado15!DllGetClassObject+00022747
        msado15!DllGetClassObject+000069E7
        kernel32!BaseThreadInitThunk+00000012
        ntdll!RtlInitializeExceptionChain+000000EF
        ntdll!RtlInitializeExceptionChain+000000C2

    My msado15.dll version is also 6.1.7601.17514 as Angus is using. I'm experiencing this issue on Windows 7 SP1 and also on Server 2008 R2 SP1.

    Hope we will get some fix soon.

    Thanks,

    Iztok Jakac


    • Edited by Iztok Jakac Thursday, December 8, 2011 7:25 AM
    Wednesday, December 7, 2011 2:11 PM
  • Just an update.

    I changed my msado15.dll in C:\Program Files\Common Files\System\ado (version 6.1.7601.17514) with the one from Server 2003 OS (version 6.0.6002.18362). Now there is no memory leak due to msado15.dll. It was tested in Windows 7 x86 and Server 2008 R2 and in both cases the leak is gone!

    Now I'm only worried about next windows update - will it override the working dll file or will it not - this is the question.

    Update:

    I changed my app to use synchronous execution instead of synchronous and the memory leak is gone. Even with the original msado15.dll file.

    Cheers,

    Iztok




    • Edited by Iztok Jakac Thursday, December 22, 2011 12:37 PM
    Monday, December 12, 2011 1:10 PM
  • After 11 months, there is finally a working hotfix for the handle and memory leaks in the msado15.dll introduced with Windows 7 SP1 at  KB2640696:

    http://support.microsoft.com/kb/2640696

    The article does not mention any memory leaks, only the other issue that prevented some programs developed under SP1 running under old versions of Windows.  But I have tested both the 32-bit and 64-bit hotfixes with the ADO test program I wrote 10 months ago, and memory is no longer leaked. 

    Thank you Ming, I guess you had a long internal battle to get the hotfix released.

    Angus


    Angus Robertson - Magenta Systems Ltd

    • Marked as answer by Angus Robertson Wednesday, February 15, 2012 11:55 AM
    Wednesday, February 15, 2012 11:54 AM