Using AQTime you can profile dynamic link libraries that are linked to your executable both at startup time (so called statically linked DLLs) and at run time (dynamically linked DLLs). Profiling a DLL is similar to profiling of any other standard application. In some cases it is even simpler, because the DLL may be compiled without debug information. This topic explains how you can profile dynamic link libraries with AQTime.

In further explanations we will call the executable that loads the profiled DLL in memory a host application. The manner in which you profile your DLL depends on whether you will start the DLL’s host application from AQTime or you will attach to it at run time.

If you can start the host application from AQTime, then you can profile your DLL in the following manner:

Compile your DLL. See How AQTime Profilers Use Metadata and Debug Information to decide if you need to include debug information.
Load the DLL in AQTime as a project (see Creating and Saving AQTime Projects).
Open the Run Parameters dialog and specify the host application for a dynamic link library. When you start profiling, AQTime launches the specified host application. The host application then calls the functions defined in the profiled dynamic link library. Note that AQTime does not profile the host application, so it can be compiled without the debug info.
Continue profiling as you normally would. AQTime profiles DLL functions only when they are included in one of custom areas or when All Project Modules is active.

Note:

In 64-bit versions of Windows, 32-bit modules can be loaded into 32-bit processes only and 64-bit modules can be loaded into 64-bit processes only. So, if the “bitness” of your dynamic link library does not match the “bitness” of the process, to which the library is loaded, AQTime will not start profiling.

AQTime normally generates results once the profiled application has ended its run. When profiling a dynamic link library, this means results are generated when the host application exits. If you need to obtain results without closing the host application, you can do this by using the Run > Get Results option from AQTime’s main menuyou can do this by selecting the AQTime > Get Results option from Visual Studio’s main menuyou can do this by selecting AQTime > Get Results from RAD Studio’s main menu or by creating an action that will command AQTime to generate results. For more information, see Getting Results During Profiling.

If the host application is already loaded into AQTime as a project, you can include your DLL into profiling tasks by adding it to that AQTime project. To do this, choose Add Module from the Setup toolbar or from the context menu of the Setup panel and select the desired DLL in the subsequent Open File dialog. Now, when you start profiling in AQTime, it will launch the host application, which, in turn, will load the DLL in memory and call its functions.

Note:

During the profiling, the host application may load a DLL that has the same file name as the DLL that is added to the project. In this case, AQTime will post a Module Loaded message to the Event Viewer panel that will say that the DLL is loaded and that it is not a project module.

Note that if you add a DLL to the host application’s project, AQTime can use both DLL’s debug information and table of exported functions to determine the routine’s location in code. That is, the added DLL may be compiled without debug information and may still be profiled by AQTime. This makes it possible to profile dynamic link libraries, which are used by your application and which do not have debug info (for example, system libraries. See Profiling System Calls). However, the absence of debug information imposes some limits on the profiling:

You can profile only those functions that are exported by the DLL. You cannot profile “internal” DLL functions and procedures.
You can profile DLL functions at routine level only.
The Allocation profiler will not trace memory allocations that are done directly within the DLL code.

For .NET modules AQTime offers one more way for profiling the dynamic link libraries: you may check the Entire .NET Code box in the Classes to Profile pane of the Setup panel. If this box is checked, AQTime will profile all managed routines and modules that are used by the profiled executable regardless of whether they are added to custom areas or not.

One more way to profile DLLs with AQTime is to attach to the process that uses this DLL:

Compile your DLL. See How AQTime Profilers Use Metadata and Debug Information to decide if you need to include debug information.
Load the DLL in AQTime as a project (see Creating and Saving AQTime Projects).
Select Run > Attach to Process or press Attach to Process button on the Standard toolbar.Select AQTime > Attach from Visual Studio’s main menu.Click the Attach to Process button in RAD Studio. This will call the Select Process to Attach dialog that lists all currently running processes. Note that the Attach to Process button does not reside on any RAD Studio’s toolbar by default. However, you can add the button to any toolbar via the Toolbar Customization dialog. In this dialog, switch to the Commands page, select the Run.AQtime category in the Categories list, drag the Attach to Process command from the Commands list and drop it on the needed toolbar.
In the dialog, select the process to which you would like to attach your module and press OK. If the desired process is not in the list, launch it outside of AQTime, and then return to the Attach to Process dialog and press Refresh to update the list.
Profile your applications you normally would.
To obtain the profiler results, select Run > Get Results from AQTime’s main menuselect AQTime > Get Results from Visual Studio’s menuselect AQTime > Get Results from RAD Studio’s main menu. Results are also generated when the process, to which you attached the DLL, finishes.

Profiling Dynamic Link Libraries

See Also