Comments have been closed on this page. Please use AppMon & UEM Open Q & A forum for questions about this plugin.

Work in progress!

This download provides a C++ wrapper library that allows instrumenting VB6 applications using the dynaTrace ADK.

Download Details


VB6 Instrumentation Wrapper



dynaTrace Version



Chuck Miller


dynaTrace BSD


Not Supported

Download Contents

  • - Standalone, instrumented vb6 test project written w/ Visual Basic 2010 Express
  • - dtAgentWrapper c++ written w/ Visual C++ 2010 Express – this very simply wraps all ADK calls with the necessary declaration type __stdcall so that the calls will work within VB6. This library is needed along with the ADK in order for the instrumentation to work (see Release subdirectory where the library is already compiled (dtAgentWrapper.dll)). This library is referenced in the VB6dTAgentTest project.
  • - instrumentor utility written in Java in Netbeans - the instrumentor utility is definitely not fool proof, but is a step in the right direction and can be a real time saver.
  • VBTestProfile.dts – dT Session with the profile and results of the stand-alone VB6 test.
    Assumptions/clarifications on the Instrumentor:
    The Instrumentor is likely to be imperfect and need manual follow-up.  The level of this effort depends upon conformity to the regex patterns.  Instrumentation of Functions and Subs is only done for those that have declared variables (Dims/ReDims).  The assumption is if there are no declared variables, the Function or Sub is insignificant. The Instrumentor does not provide any de-instrumentation or instrumentation refinement.  If needed, this will need to be done manually.# The Instrumentor only operates against .CLS or .BAS files.  Any other file types will need to be manually investigated/instrumented or added to the utility.
  1. Two hierarchical levels of instrumentation are provided … the Function or Sub Routine itself and any DB Connection Creations, SQL Executions, or Stored Procedure Executions within those.  If Functions or Sub Routines call each other, this hierarchy is maintained by default (observed PoC behavior).  If needed, other leveling will need to be done manually.
  2. The Instrumentor automatically inserts the following:
    1. Declarations for ADK wrapped calls
    2. Agent initialization inside Class_Initialize Sub
    3. Function and Sub instrumentation
    4. Parameter capture instrumentation for Public Functions and Subs
    5. Error capture instrumentation
    6. SQL Statement, Stored Procedure, and DB Connection instrumentation
    7. Purepath tagging plumbing
    8. The Instrumentor layers in code that expects the following environment variables to be declared:
      1. DT_VB6_AGENTNAME - Agent Name as declared to dynaTrace
      2. DT_VB6_AGENTLIB - dynaTrace library location – e.g. C:\Windows\SysWOW64\dtagent.dll
      3. DT_VB6_SERVER - dynaTrace Server IP Address or Name
      4. DT_VB6_DEBUGFLAGS - dynaTrace Agent debug flags – e.g. debugTaggingADKNative=true,debugPurePathADKNative=true
      5. DT_INSTRUMENTATION_LEVEL - instrumentation level 1, 2, or 3 where 3 is the deepest – e.g. 1
      6. DT_STRINGSIZE_LIMIT - string size capture limit for Function/Sub parameters – e.g. 100
      7. The Instrumentor adds instrumentation leveling.  At runtime, the value of the DT_INSTRUMENTATION_LEVEL environment variable is evaluated and instrumentation depth is controlled by it.  Here are the levels …
        1. DT_INSTRUMENTATION_LEVEL=1 – Functions, Subs, and Errors
        2. DT_INSTRUMENTATION_LEVEL=2 – Functions, Subs, Errors, DB Connections, SQL Statements, and Stored Procedures
        3. DT_INSTRUMENTATION_LEVEL=3 – Functions, Subs, Errors, DB Connections, SQL Statements, Stored Procedures, and Public Function/Sub Parameters
        4. Specific patterns are searched for SQL Statements, Stored Procedures, and DB Connections.  There are regex’s for these in the code and they can be changed, but it is unclear how common these patterns are.
        5. Parameter variables for SQL Executions and Stored Procedures are assumed to be strings.
        6. Non string or integer parameters are ignored in Public Function/Sub parameter capture instrumentation.
        7. Purepath tagging mechanism is not thread safe and assumes COM entry call threading constraints.

If you have any questions, please don't hesitate to ask in our Plugins and Extension Forum.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels


  1. Hi,

    I don't see any download link, tried with different browsers.


    1. use tools / attachments on top right

  2. I've added links to the downloads in the text. Now you can click on the names of the files listed in the Download Contents section

  3. Hi Chuck, Thanks for sharing the VB code instrumentor with us. I have a situation in my project where I need to analyze the instrumentaiton of COM dlls referenced inside a .NET website. although the code is available to me I would really appreciate if you can either provide or direct me to the documentation on how we can integrate this wrapper with DynaTrace and run the tests to get the DT data for processes inside the COM dlls.


  4. This is awesome stuff Chuck! Thank you!

  5. FYI in case others have the same questions ...

    You need multiple dll’s to make this work …

    1. dtAgentWrapper.dll
    2. dtAdk.dll
    3. dtAgent.dll

    All need to be somewhere in the %PATH% so they are found when the VB6 code tries to load them. You would need in this case to install the dT ADK which includes dtAdk.dll and dtAgent.dll and then get dtAgentWrapper.dll from the VB6 Community page. None of them require registration.

    You also need the VB6 code to be instrumented so that the purepaths show up. The utility is there to instrument the VB6 code so that you are not doing that manually and then of course, it would need to be recompiled.

    Lastly, the tagging is not done automatically in this case either. The instrumentor utility sets up for tagging, but the tag has to be set and sent over to the VB6 side in order for that to work.

  6. FYI, the same approach works for Power Builder (Sybase), although, of course the instrumentor would not work for PB (smile)

    PowerBuilder supports calls to external DLL functions if they are following the Win32 API convention (_stdcall), hence the need for a wrapper as for VB6. The use cases are pretty similar as PowerBuilder has been a long time competitive platform to VB. Also, PowerBuilder has now been ported to .NET so PB DataWindow GUI component can be compiled to a .NET WPF and some components have been re-written in C#.

    But for the good old legacy Power Builder code, the wrapped ADK approach works as for VB6.

  7. Hi,

    I'm using the wrapper to instrument a VB6 COM+ Component and I managed to use the most functions as well.

    However, when I try to use dTExceptionThrow method, i get the following error: The remote procedure call failed. (Exception from HRESULT: 0x800706BE)

    rv3 = VB_dTExceptionThrow(dt_method_id2, "ErrorTest ", "ErrorXPTO")

    Has anyone experienced this issue?



  8. Hi All,

    We are using the VB Wrapper and .NET ADK to instrument a VB6 Component that is called from an ASP.NET Application.

    In our tests, we have noticed that the VB6 Call was not correctly located on the purepath timeline, unless I create a custom sensor on .NET caller method.

    It seems that the Autosensor does not recognize that there is a ADK call.

    Is it normal? I need create a custom sensor for each ADK call to have the purepath in the correct call order?

    Thank you,


    1. It would be helpful if you have a screenshot or export a purepath

  9. Hi Andi,

    Below the screenshots. Without creating a .NET custom sensor, the ADK call appears before the caller method on stack. Creating a custom sensor the sequence and link appears correclty.

    Thank you,

    With custom .NET Sensor

    Caller Method (.NET): AutenticarUsuario

    Without custom Sensor:

    1. Thanks. This makes it clearer now. ADK calls are linked to the last instrumented node. The Auto Sensors are "not yet" smart enough to know what the last call was before calling the ADK. Thats the explanation for it. I will forward this to engineering and see if there is anything we can do in the future to make these Auto Sensors smarter for that particular special scenario. In the meantime I suggest you simply create a custom sensor for the methods you know will call into the VB6 code

      1. Thanks. That makes sense.

        Luis Redda

        1. There is a little more information about this in the "important" note on the Tagging ADK for .NET

  10. Hi All,

    I am on a customer that instrumented a lot of VB COM+ Methods using the VB Wrapper. They are using object pooling on
    COM+ and the pool size is 20 for each web server.

    Because this, each COM+ component starts about 20 ADK instances simultaneously and the customer is running out of licences (They have only 12).

    Due the default behavior of COM+ applications (Just In Time Activation), the ADK agent is started on beginning of transaction and the agent stops at the end of transaction. This is confusing for dynaTrace, because most time has some agent offline, and the agent names being duplicated.

    Now they instrumented more methods and are facing a problem: In the most cases the purepath exceeds the timeout for a specific VB transaction (gfSalvar). The transaction is running succesfully without timeout or delay.

    Any idea what might be causing the ADK timeout ?

    I'm attaching the purepaths with this problem (TimeoutPPs.dts)



    1. Just to expand a little on what Redda said, there is a ticket opened for this case:

      We think it might have to do with the ADK receiving a new tag before closing the old one, and then somehow "forgeting" about the old tag. This seems to happen because the VB portion handles new requests on the same thread that started the old request, and the ADK gets confused because it correlates the different PPs by the thread it uses.