Udostępnij za pośrednictwem

[Windbg Script] Connections from Pool

  • Artykuł

If you are like me, you may forget the classes and namespaces you need to find out some specific information. Or maybe you forget the field names you need to look for.

It happens to me when I need to take a peek at information from System.Data.SqlClient namespace, for example.

This script retrieves specific information from connections.

It’s also easy to extend it, so you can use the same approach to extract information from other namespaces and fields.

Personally, I prefer the approach based on DML (Debug Markup Language) because I can use hyperlinks and the default script call: $$><. The DML approach requires more work and more low-level programming, but offers better results as you can see in most the scripts I create.

You need to run it using $$< not $$><

 

Source code for CONNECTIONS_POOL.TXT:

$$

$$ =============================================================================

$$ Verify Connections from Pool.

$$

$$ Compatilibity: Win32, should work on Win64.

$$

$$ Attention! For .Net Framework 2.0, edit the script and remove the clr10\\ from it so it can use the

$$ sos.dll version 2.0

$$

$$ Usage: $$< to run the script. (note: Just $$< not $$><)

$$

$$ Requirements: Public symbols.

$$

$$ Roberto Alexis Farah

$$ Blog: https://blogs.msdn.com/debuggingtoolbox/

$$ All my scripts are provided "AS IS" with no warranties, and confer no rights.

$$ =============================================================================

$$

.shell -i - -ci ".foreach ( obj {!clr10\\sos.dumpheap -type System.Data.SqlClient.SqlInternalConnection -short} ) {!do ${obj} }" FIND "_fInPool"

.shell -i - -ci ".foreach ( obj {!clr10\\sos.dumpheap -type System.Data.SqlClient.SqlConnectionPoolControl -short} ) {!do ${obj} }" FIND "_fResetConnection"

.shell -i - -ci ".foreach ( obj {!clr10\\sos.dumpheap -type System.Data.SqlClient.SqlConnectionPoolControl -short} ) {!do ${obj} }" FIND "_maxPool"

$$

$$ Number of Connection Objects

$$ ============================

$$

!clr10\\sos.dumpheap -type System.Data.OleDb.OleDbConnection -stat

$$

$$ ===================================================================

 

Read me.

Comments

  • Anonymous
    April 02, 2007
    The comment has been removed

  • Anonymous
    April 02, 2007
    Hi, Let's try it first: 1- Make sure you are using our public symbols. Your Windbg Symbol path should be something like: SRVc:windowssymbolshttp://msdl.microsoft.com/download/symbols Reference: http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx 2- Before running the script, use this command: .reload /f It forces all symbols for the application to be loaded. 3- Use this command: !clr10sos.dumpheap -type System.Data.SqlClient.SqlConnectionPoolControl Or: .load sos !dumpheap -type System.Data.SqlClient.SqlConnectionPoolControl If your process is using it, then you should get something, otherwise nothing will be displayed. Anyway you shouldn't get an error message. 4- Run the script. If the process is using the SqlConnectionPoolControl then the script should show you the information.

  • Anonymous
    April 02, 2007
    Hi, For some reason, I am having problem executing the script. However, if I just executed the individual sos command (e.g.!dumpheap -type System.Data.SqlClient.SqlConnectionPoolControl), I have no problems. At any rate, it is OK since I still can get the connection pool info from the individual command. Thanks

  • Anonymous
    April 02, 2007
    Hum... are you using the SOS version that comes with Windbg? I guess I know what it is... the SOS version that comes with Windbg has some additional features. It accepts the -short argument, for example. Just to prove the point use the following command: !dumpheap -type System.Data.SqlClient.SqlConnectionPoolControl -short If you get a message like: "Unknown option: -short" it means you are using the version from Microsoft .NETFramework. Now use the CLR10sos and the same command. The script should use the CLR10 version, but just to make sure, unload the regular sos and let it uses the CLR10 version. Please, let me know if it works. I'm curious here :)

  • Anonymous
    April 02, 2007
    If I executed w/o clr10, it seems OK. But if I executed with clr10, it complained as shown below: :011> !dumpheap -type System.Data.SqlClient.SqlConnectionPoolControl -short 0:011> !clr10\sos.dumpheap -type System.Data.SqlClient.SqlConnectionPoolControl -short Cannot get the ThreadStore, do you have symbols for the mscorwks/mscorsvr files? Once the error occurs, I will get error even I executed w/o clr10. I am confused :-(( as shown below: 0:007> !dumpheap -type System.Data.SqlClient.SqlConnectionPoolControl -short Cannot get the ThreadStore, do you have symbols for the mscorwks/mscorsvr files? 0:007> !dumpheap -type System.Data.SqlClient.SqlInternalConnection Cannot get the ThreadStore, do you have symbols for the mscorwks/mscorsvr files? Thanks

  • Anonymous
    April 02, 2007
    Ok, it seems you are using .NET Framework 2.0 and the SOS for 2.0. (my mistake, I didn't consider it before) Just edit the script and remove the CLR10 from the source code. Please, let me know if it worked.

  • Anonymous
    April 03, 2007
    The comment has been removed

  • Anonymous
    April 03, 2007
    Hi, I use clr10\sos just to avoid using .load sos. The SOS version that comes with Windbg isn't working because it is for version 1.1 (http://blogs.msdn.com/aaronba/archive/2006/05/17/600589.aspx)  and you are using .NET Framework 2.0 You can use any extension command doing that: .load extension.dll !command or just: !extension.command That said, try it:

  • Remove clr10\sos from the source.
  • Load the dump file or process using Windbg.
  • Use .reload /f
  • Use .load SOS  
  • Run the script. Another approach:
  • Remove clr10\ from the source. Keep the !sos
  • Load the dump file or process using Windbg.
  • Use .reload /f
  • Run the script. For the next scripts I'll assume SOS v2.0 as the default SOS. Here I use PSSCOR/PSSCOR2 that are our internal SOS version then I change the calls to SOS and do a quick test using just public symbols before publishing the article. Thus, your feedbacks are very useful to adapt the scripts to SOS. I really appreciate them!
  • Anonymous
    May 14, 2008
    Hi, I am new at WinDbg and I edited your script as follow .shell -i - -ci".foreach ( obj {x module_name!key_to_search} ) {!do ${obj} }" FIND "filter_str" However when I run this, the command window opens and closes immediately so I couldn't see the output. And the  WinDbg commnad output only says ".shell: Process exited"
  1. How can I print the FIND output to WinDbg command window as shown above on the image?
  2. What is the !do command. I coudn't find in documantation. I am sorry if they are too simple questions, as I mentioned I am new at both windbg and scripting.