none
ADO.NET Tracing RRS feed

  • Question

  • Hi, I am attempting to configure tracing for my ADO.NET applicaiton. I am getting some errors with filling a DataSet and stepping through the code in Visual Studio has not helped in solving the issue. I am trying to take it to the next step and get a good trace of my DataSet Fill command. I have read several MSDN articles and an ADO.NET 2.0 book on tracing so I believe I have tracing configured sucessfully, but my logs files do not contain any good information.

    I am using the article http://msdn.microsoft.com/en-us/library/ms971550.aspx currently, because I tried using the Perfmon to run the trace, but I had no luck.

    My latest attempt using the above article's steps produced this summary.txt:

     Files Processed:
     Out.etl
    Total Buffers Processed 1
    Total Events  Processed 1
    Total Events  Lost      0
    Start Time              Wednesday, May 19, 2010
    End Time                Wednesday, May 19, 2010
    Elapsed Time            53 sec
    +-------------------------------------------------------------------------------------------------------------------------+
    |Event Count   Event Name           Task            Opcode          Version         Guid                                  |
    +-------------------------------------------------------------------------------------------------------------------------+
    |          1   EventTrace           0               Header          2               {68fdd900-4a3e-11d1-84f4-0000f80464e3}|
    +-------------------------------------------------------------------------------------------------------------------------+

    And dumpfile.xml looks like this:

     
    - <Events>
    - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    - <System>
      <Provider Guid="{9e814aad-3204-11d2-9a82-006008a86939}" />
      <EventID>0</EventID>
      <Version>2</Version>
      <Level>0</Level>
      <Task>0</Task>
      <Opcode>0</Opcode>
      <Keywords>0x0</Keywords>
      <TimeCreated SystemTime="2010-05-19T14:13:21.185392100Z" />
      <Correlation ActivityID="{00000000-0000-0000-0000-000000000000}" />
      <Execution ProcessID="1100" ThreadID="5612" ProcessorID="0" KernelTime="15" UserTime="0" />
      <Channel />
      <Computer />
      </System>
    - <EventData>
      <Data Name="BufferSize">8192</Data>
      <Data Name="Version">83951878</Data>
      <Data Name="ProviderVersion">7600</Data>
      <Data Name="NumberOfProcessors">2</Data>
      <Data Name="EndTime">129187702047940379</Data>
      <Data Name="TimerResolution">156001</Data>
      <Data Name="MaxFileSize">0</Data>
      <Data Name="LogFileMode">0x0</Data>
      <Data Name="BuffersWritten">1</Data>
      <Data Name="StartBuffers">1</Data>
      <Data Name="PointerSize">4</Data>
      <Data Name="EventsLost">0</Data>
      <Data Name="CPUSpeed">2194</Data>
      <Data Name="LoggerName">0x5</Data>
      <Data Name="LogFileName">0x5</Data>
      <Data Name="BootTime">129187645043751998</Data>
      <Data Name="PerfFreq">2143125</Data>
      <Data Name="StartTime">129187700011853921</Data>
      <Data Name="ReservedFlags">0x1</Data>
      <Data Name="BuffersLost">0</Data>
      <Data Name="SessionNameString">MyTrace</Data>
      <Data Name="LogFileNameString">C:\Users\Jordan\Desktop\ADOTracing\Setup\Out.etl</Data>
      </EventData>
    - <RenderingInfo Culture="en-US">
      <Opcode>Header</Opcode>
      <Provider>MSNT_SystemTrace</Provider>
      <EventName xmlns="http://schemas.microsoft.com/win/2004/08/events/trace">EventTrace</EventName>
      </RenderingInfo>
    - <ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/2004/08/events/trace">
      <EventGuid>{68fdd900-4a3e-11d1-84f4-0000f80464e3}</EventGuid>
      </ExtendedTracingInfo>
      </Event>
      </Events>

     

    My control file I used to trace originally looked like this:

    {7ACDCAC8-8947-F88A-E51A-24018F5129EF}  0x00000000  0   ADONETDIAG.ETW
    {914ABDE2-171E-C600-3348-C514171DE148}  0x00000000  0   System.Data.1
    {A68D8BB7-4F92-9A7A-D50B-CEC0F44C4808}  0xFFFFFFFF  0   System.Data.Entity.1
    {C9996FA5-C06F-F20C-8A20-69B3BA392315}  0xFFFFFFFF  0   System.Data.SNI.1
    {DCD90923-4953-20C2-8708-01976FB15287}  0x00000000  0   System.Data.OracleClient.1

    But I changed it, thinking this is how I can get more verbose logging with 0x2 switch

    {7ACDCAC8-8947-F88A-E51A-24018F5129EF}  0x2  0x0   ADONETDIAG.ETW
    {914ABDE2-171E-C600-3348-C514171DE148}  0x2  0x0   System.Data.1
    {A68D8BB7-4F92-9A7A-D50B-CEC0F44C4808}  0x2  0x0  System.Data.Entity.1
    {C9996FA5-C06F-F20C-8A20-69B3BA392315}  0x2  0x0   System.Data.SNI.1
    {DCD90923-4953-20C2-8708-01976FB15287}  0x2  0x0   System.Data.OracleClient.1


    AmI doing this wrong? Has anyone sucessfully gotten ADO.NET Tracing to work?

    Sorry, if this is in the wrong forum, is there another place where I can get help on this?

    • Edited by Jordan B Wednesday, May 19, 2010 8:52 PM grammar
    Wednesday, May 19, 2010 8:51 PM

Answers

  • Hello Jordan,

     

    Welcome to ADO.NET DataSet forum!

     

    Yes, I think the ADO.NET Tracing is working fine at my lab.   I followed the steps in this article to trace in SQL Server 2008, http://msdn.microsoft.com/en-us/library/cc765421.aspx.   Based on my test, the step to set up the trace is very important.   I am using VS2010 and SQL Server 2008.  The dataset app is targeted to .NET 4.0, so the “:Path” value under the HKEY_LOCAL_MACHINE\Software\Microsoft\BidInterface\Loader\ is “%SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\AdoNetDiag.dll”.    

     

    Besides, if it is a x64 OS and the “:Path” value should be “%SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319\AdoNetDiag.dll”, since it is the x64 version .dll is used here.   Also, the app should be built as “Any CPU” or “x64”.   If it is built as “x86”, we will see the situation as yours.  The trace log is very small without important information.    

     

    Note: if the your app should be built as “x86” on x64 system, please set the HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\BidInterface\Loader\ instead, since the app is running on Wow64 mode.   

     

    Hope it is helpful to you!

     

    Have a great day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    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.
    Thursday, May 20, 2010 6:38 AM
    Moderator
  • Hi Lingzhi,

    Thanks for the reply. Well, I think I have all of the pieces in place.

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BidInterface]

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BidInterface\Loader]
    ":Path"="%SYSTEMROOT%\\Microsoft.NET\\Framework\\v2.0.50727\\ADONETDiag.dll"

    My ADO.NET projects' target framework version is ".NET Framework 2.0".

    If I run from a command prompt "logman query providers > temp.txt" and check my providers, I see that I do have following providers enabled (in addition a few hundred others):

    ADONETDIAG.ETW                           {7ACDCAC8-8947-F88A-E51A-24018F5129EF}
    System.Data.1                            {914ABDE2-171E-C600-3348-C514171DE148}
    System.Data.SNI.1                        {C9996FA5-C06F-F20C-8A20-69B3BA392315}
    SQLNCLI.1                                {BA798F36-2325-EC5B-ECF8-76958A2AF9B5}

    So I think my MOF files compiled with no issues.

    I start my trace using the "_startTrace.cmd" provided with the samples.
    Then, I run the sample application against AdventureWorks to return my DataSet, then I "Exit" the application.
    I run the "_stopTrace.cmd".
    Then run the "_report.cmd" to convert the "out.etl" to "summary.txt" and "dumpfile.xml"

    Then I review the summary.txt and all it shows is:

    Files Processed:
     Out.etl
    Total Buffers Processed 1
    Total Events  Processed 1
    Total Events  Lost      0
    Start Time              Thursday, May 20, 2010
    End Time                Thursday, May 20, 2010
    Elapsed Time            21 sec
    +-------------------------------------------------------------------------------------------------------------------------+
    |Event Count   Event Name           Task            Opcode          Version         Guid                                  |
    +-------------------------------------------------------------------------------------------------------------------------+
    |          1   EventTrace           0               Header          2               {68fdd900-4a3e-11d1-84f4-0000f80464e3}|
    +-------------------------------------------------------------------------------------------------------------------------+

    What's strange is that the event GUIDs specified in the Ctrl file used by the "_startTrace.cmd" do not show up in the summary.txt. I would have expected a summary.txt that looked something like this:

    Files Processed:
    MyTraceLog.etl
    Total Buffers Processed 29
    Total Events Processed 709
    Total Events Lost 0
    Start Time 4 Dec 2007 10:27:42.592
    End Time 4 Dec 2007 10:31:52.231
    Elapsed Time 249 sec
    +------------------------------------------------------------+
    |Event Count Event Name Event Type Guid |
    +------------------------------------------------------------+
    | 1 EventTrace Header {68fdd900-4a3e-11d1-84f4-0000f80464e3}|
    | 6 AdoNetDiag TextW {7acdcac9-8947-f88a-e51a-24018f5129ef}|
    | 702 System.Data TextW {914abde3-171e-c600-3348-c514171de148}|
    +------------------------------------------------------------+

    This indicates to me that the trace is not capturing ADO.NET events, or that I still do not have the correct Ctrl file for capturing ADO.NET events.

    The different control files I have used thus far:

    Ctrl file 1

    "ADONETDIAG.ETW"  0x4  0x0   ADONETDIAG.ETW
    {914ABDE2-171E-C600-3348-C514171DE148}  0x8  0x0   System.Data.1
    "System.Data.SNI.1"  0x2  0x0   System.Data.SNI.1
    "SQLNCLI.1"  0x2  0x0   SQLNCLI.1

    Ctrl file 2

    {7ACDCAC8-8947-F88A-E51A-24018F5129EF}  0x00000000  0   ADONETDIAG.ETW
    {914ABDE2-171E-C600-3348-C514171DE148}  0x00000000  0   System.Data.1
    {C9996FA5-C06F-F20C-8A20-69B3BA392315}  0xFFFFFFFF  0   System.Data.SNI.1

    Ctrl file 3

    {7ACDCAC8-8947-F88A-E51A-24018F5129EF}  0x2  0x0   ADONETDIAG.ETW
    {914ABDE2-171E-C600-3348-C514171DE148}  0x2  0x0   System.Data.1
    {C9996FA5-C06F-F20C-8A20-69B3BA392315}  0x2  0x0   System.Data.SNI.1

    This morning, I had one of our senior support engineers review the article independently and try to enable tracing as well and they got the same results, so I'm not sure what to do next.

    I also attempted to enable tracing using this developer.com article in addition to the article you specified in your reply:

    http://www.developer.com/net/csharp/article.php/10918_3723011_3/ADONET-Trace-Logging.htm

    Is there a forum that is specific to Event Tracing/ETW/WMI issues?

    I guess one thing I need to keep in mind is that this isn't really the actual issue, I'm just trying to get more information about another error I'm experiencing with filling an ADO.NET Dataset, so maybe I just need to talk about that instead :)

    Thanks for your input - It makes sense that I would need to adjust my path based on my application's target framework and the operating system, I hadn't thought of checking that out.

    Thanks,

    Jordan

     

    Thursday, May 20, 2010 6:56 PM

All replies

  • Hello Jordan,

     

    Welcome to ADO.NET DataSet forum!

     

    Yes, I think the ADO.NET Tracing is working fine at my lab.   I followed the steps in this article to trace in SQL Server 2008, http://msdn.microsoft.com/en-us/library/cc765421.aspx.   Based on my test, the step to set up the trace is very important.   I am using VS2010 and SQL Server 2008.  The dataset app is targeted to .NET 4.0, so the “:Path” value under the HKEY_LOCAL_MACHINE\Software\Microsoft\BidInterface\Loader\ is “%SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\AdoNetDiag.dll”.    

     

    Besides, if it is a x64 OS and the “:Path” value should be “%SYSTEMROOT%\Microsoft.NET\Framework64\v4.0.30319\AdoNetDiag.dll”, since it is the x64 version .dll is used here.   Also, the app should be built as “Any CPU” or “x64”.   If it is built as “x86”, we will see the situation as yours.  The trace log is very small without important information.    

     

    Note: if the your app should be built as “x86” on x64 system, please set the HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\BidInterface\Loader\ instead, since the app is running on Wow64 mode.   

     

    Hope it is helpful to you!

     

    Have a great day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    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.
    Thursday, May 20, 2010 6:38 AM
    Moderator
  • Hi Lingzhi,

    Thanks for the reply. Well, I think I have all of the pieces in place.

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BidInterface]

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BidInterface\Loader]
    ":Path"="%SYSTEMROOT%\\Microsoft.NET\\Framework\\v2.0.50727\\ADONETDiag.dll"

    My ADO.NET projects' target framework version is ".NET Framework 2.0".

    If I run from a command prompt "logman query providers > temp.txt" and check my providers, I see that I do have following providers enabled (in addition a few hundred others):

    ADONETDIAG.ETW                           {7ACDCAC8-8947-F88A-E51A-24018F5129EF}
    System.Data.1                            {914ABDE2-171E-C600-3348-C514171DE148}
    System.Data.SNI.1                        {C9996FA5-C06F-F20C-8A20-69B3BA392315}
    SQLNCLI.1                                {BA798F36-2325-EC5B-ECF8-76958A2AF9B5}

    So I think my MOF files compiled with no issues.

    I start my trace using the "_startTrace.cmd" provided with the samples.
    Then, I run the sample application against AdventureWorks to return my DataSet, then I "Exit" the application.
    I run the "_stopTrace.cmd".
    Then run the "_report.cmd" to convert the "out.etl" to "summary.txt" and "dumpfile.xml"

    Then I review the summary.txt and all it shows is:

    Files Processed:
     Out.etl
    Total Buffers Processed 1
    Total Events  Processed 1
    Total Events  Lost      0
    Start Time              Thursday, May 20, 2010
    End Time                Thursday, May 20, 2010
    Elapsed Time            21 sec
    +-------------------------------------------------------------------------------------------------------------------------+
    |Event Count   Event Name           Task            Opcode          Version         Guid                                  |
    +-------------------------------------------------------------------------------------------------------------------------+
    |          1   EventTrace           0               Header          2               {68fdd900-4a3e-11d1-84f4-0000f80464e3}|
    +-------------------------------------------------------------------------------------------------------------------------+

    What's strange is that the event GUIDs specified in the Ctrl file used by the "_startTrace.cmd" do not show up in the summary.txt. I would have expected a summary.txt that looked something like this:

    Files Processed:
    MyTraceLog.etl
    Total Buffers Processed 29
    Total Events Processed 709
    Total Events Lost 0
    Start Time 4 Dec 2007 10:27:42.592
    End Time 4 Dec 2007 10:31:52.231
    Elapsed Time 249 sec
    +------------------------------------------------------------+
    |Event Count Event Name Event Type Guid |
    +------------------------------------------------------------+
    | 1 EventTrace Header {68fdd900-4a3e-11d1-84f4-0000f80464e3}|
    | 6 AdoNetDiag TextW {7acdcac9-8947-f88a-e51a-24018f5129ef}|
    | 702 System.Data TextW {914abde3-171e-c600-3348-c514171de148}|
    +------------------------------------------------------------+

    This indicates to me that the trace is not capturing ADO.NET events, or that I still do not have the correct Ctrl file for capturing ADO.NET events.

    The different control files I have used thus far:

    Ctrl file 1

    "ADONETDIAG.ETW"  0x4  0x0   ADONETDIAG.ETW
    {914ABDE2-171E-C600-3348-C514171DE148}  0x8  0x0   System.Data.1
    "System.Data.SNI.1"  0x2  0x0   System.Data.SNI.1
    "SQLNCLI.1"  0x2  0x0   SQLNCLI.1

    Ctrl file 2

    {7ACDCAC8-8947-F88A-E51A-24018F5129EF}  0x00000000  0   ADONETDIAG.ETW
    {914ABDE2-171E-C600-3348-C514171DE148}  0x00000000  0   System.Data.1
    {C9996FA5-C06F-F20C-8A20-69B3BA392315}  0xFFFFFFFF  0   System.Data.SNI.1

    Ctrl file 3

    {7ACDCAC8-8947-F88A-E51A-24018F5129EF}  0x2  0x0   ADONETDIAG.ETW
    {914ABDE2-171E-C600-3348-C514171DE148}  0x2  0x0   System.Data.1
    {C9996FA5-C06F-F20C-8A20-69B3BA392315}  0x2  0x0   System.Data.SNI.1

    This morning, I had one of our senior support engineers review the article independently and try to enable tracing as well and they got the same results, so I'm not sure what to do next.

    I also attempted to enable tracing using this developer.com article in addition to the article you specified in your reply:

    http://www.developer.com/net/csharp/article.php/10918_3723011_3/ADONET-Trace-Logging.htm

    Is there a forum that is specific to Event Tracing/ETW/WMI issues?

    I guess one thing I need to keep in mind is that this isn't really the actual issue, I'm just trying to get more information about another error I'm experiencing with filling an ADO.NET Dataset, so maybe I just need to talk about that instead :)

    Thanks for your input - It makes sense that I would need to adjust my path based on my application's target framework and the operating system, I hadn't thought of checking that out.

    Thanks,

    Jordan

     

    Thursday, May 20, 2010 6:56 PM
  • Hello Jordan,

     

    :-)   Yes, I forgot it in my last post.  Could you provide us with more detailed information about the dataset issue you encountered?   I will do my best to help you!    But I think it is better to open a new thread so that more community members can benefit from the issue.  

     

    Please tell me the thread link if you open a new thread. 

     

     

    Have a nice weekend!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    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.
    Friday, May 21, 2010 3:02 AM
    Moderator
  • Did any of your guys find a solution to the logging issue. Even I am facing a similar issue, I tried all the steps as mentioned in this article

    http://msdn.microsoft.com/en-us/library/aa964124(SQL.90).aspx

    But looks like the etl file is not updated which implies that the logs are not being generated. I desperately want to enable dll logging for sqljdbc_xa.dll since we are facing a DTC issue. 

     

    Any help is really appreciated.

    Tuesday, November 2, 2010 7:28 AM
  • Hello All,

                 You can use this thread for the answer, worked for me.

    http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/b7934692-15a4-4bbd-a2b5-6924942e0e5f

     

    Thanks,

    Basu.

    • Proposed as answer by Basuk Monday, November 8, 2010 6:32 AM
    Monday, November 8, 2010 6:32 AM
  • I know this is old but I had the same issue as Jordan and just resolved it.

    For me, using the recommended :Path "%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\ADONETDiag.dll" did not work. I had to expand the placeholder and use "C:\Windows\Microsoft.NET\Framework\v2.0.50727\AdoNetDiag.dll" in the registry.

    Wednesday, November 16, 2016 7:52 PM