A.: AQtime and TestComplete are different products that are aimed at specific goals. AQtime is a performance profiler and a memory and resource usage debugger, that is, you can use it to time the execution of application functions, find memory and resource leaks, track exceptions, etc.

TestComplete is used for automated testing of applications. It allows you to record and play back user actions over your application, get access to internal application objects, methods and properties, simulate massive loads on a tested Web server, compare test results with previous results, etc.

However, both products include common facilities. For instance, TestComplete includes the DbgServices plug-in, which provides detailed information about exceptions that occur in your application during testing.

Both products are tightly integrated with each other. You can easily start and control AQtime profilers from your TestComplete projects.

A.: You cannot register the trial version of the product. To register AQtime, you should download the commercial version of the product from the client services portal and then register it. The client services portal and registration information were specified in the email message that you received from AutomatedQA. If you did not receive the message, please contact our Support department at support@automatedqa.com.

A.: AQtime includes two packages: AQtime x86 and AQtime x64. AQtime x86 is used to profile 32-bit Windows and .NET applications under 32-bit versions of the Windows operating system. AQtime x86 can also run on a 64-bit Windows OS, but in this case it is only able to profile 32-bit applications and the Performance and Function Trace profilers can only use the Elapsed Time counter.

AQtime x64 includes modules and components used to profile 32- and 64-bit Windows and .NET applications under 64-bit Windows operating systems. AQtime x64 can profile both 32-bit and 64-bit applications and it does not impose any limitation on counters.

A.: Yes. AQtime includes a special package that can run on 64-bit Windows operating systems. This package can profile both 32- and 64-bit Windows and .NET applications (EXE, DLLs, COM, DCOM and COM+ servers, services, IIS and ASP.NET applications and others).

A.: AQtime supports profiling of managed and unmanaged modules created with 32-bit or 64-bit compilers. Of course, profiling of mixed is supported. Profiling of mixed is transparent: you do not have to perform any specific actions - just profile your application as you normally would.

A.: AQtime supports .NET Framework ver. 1.0, 1.1, 2.0 and 3.0. Further versions will be supported as they are released by Microsoft.

A.: AQtime can profile Microsoft .NET Compact Framework applications if they are running under Microsoft .NET Framework. That is, the application should be run as a Win32 application rather than by a Windows CE device emulator. AQtime will profile it as an ordinary .NET application then.

A.: When AQtime is starting it attempts to connect to AutomatedQA’s Web site to check for updates. In order for this feature to function properly, you may need to modify your Windows Firewall settings:

A.: AQtime help contains detailed instructions about profiling ASP.NET applications. Just search for ASP.NET Applications in the index. To prevent you from having to switch to the help file, we included this description here.

Profiling ASP.NET applications requires Windows 2000, Windows XP, Windows XP Professional x64 Edition, Windows Server 2003 or Windows Server 2003 x64 Edition with Internet Information Services ver. 4.x, 5.x or 6.x.

In further explanations, we will assume that ASP.NET and IIS are running in the default configuration. If ASP.NET or IIS is running under a user account, you should specify certain permissions for this account:

Now we can prepare the ASP.NET application for profiling:

Open the sample project <AQtime>\Samples\Managed\VS.NET\ASP.NET\XMLTrace\VB\XMLTrace.sln in Visual Studio and compile it there.

A note for Visual Studio 2005 users: When you compile an ASP.NET application, Visual Studio organizes the application code into several temporary dynamic link libraries whose location and names are changed from one compilation to another. Since the names are changed, you have to include new modules to your AQtime project every time you compile your application and there is no guarantee that you can add all application modules, since their names and locations are defined by Visual Studio. To avoid these problems, you can publish your ASP.NET project before profiling it (you should publish your ASP.NET application every time you compile it). To publish it, select Build | Publish from the Visual Studio menu and uncheck the "Allow this precompiled site to be updatable" box in the ensuing Publish Web Site dialog. The folder that you specify for publishing will contain all DLLs generated for your ASP.NET application. It is recommended that you publish your project to the folder that is used as a virtual directory. If you publish it to another folder, you should specify that folder as a source folder for your virtual directory. If you do not publish the project, you still can profile all application modules. To do this, add any module to your AQtime project and check the Profile Entire .NET Code option in the Setup panel.

The XMLTrace application requires that the System.Web.dll library be in the application's folder. Copy this library from your .NET Framework folder (e.g. <Windows>\Microsoft.NET\Framework\<Framework Version>) to the <AQtime>\Samples\Managed\VS.NET\ASP.NET\XMLTrace\VB\bin folder.

Now we can profile our ASP.NET application with AQtime:

Select ASP.NET from the Profiling Mode dropdown list box on AQtime's Standard toolbar (AQtime toolbar in Visual Studio).

Select the desired profiler and press Run to start profiling. AQtime may ask for your permission to restart the IIS Admin service. Answer “Yes” to this question.

Launch Internet Explorer and open the Web page that loads your ASP.NET module. Then perform profiling as your needs dictate.

To avoid launching Internet Explorer manually, you can specify the desired Web page in the Start Page box of the Run Parameters Dialog (for ASP.NET Mode). In this case, AQtime will automatically open this page in Internet Explorer once you start profiling.

When you are profiling an ASP.NET application, the Event View panel displays both events that occur in the ASP.NET process and in the profiled application. One important note about this is that all displayed general events occurred in the ASP.NET process, all .NET specific events occurred in the profiled ASP.NET application.

A note for Windows x64 users: under 64bit versions of Windows, the ASP.NET process can operate in 64-bit mode (default) or 32-bit mode. The "bitness" (32-bit or 64-bit) of a process must match the "bitness" of the ASP.NET application, otherwise it will not run. AQtime checks the profiled ASP.NET application and automatically selects the proper mode of the ASP.NET process.

In the default configuration, IIS works as a service. It does not close when you close Internet Explorer, so AQtime does not generate profiling results. To obtain the results, select Run | Get Results from AQtime’s menu (Profile | Get Results from the main menu of Visual Studio). Another way to obtain the results is to create an action that will "tell" AQtime to generate the results.

To terminate the profiler run, select Run | Terminate from AQtime’s main menu or press Terminate on the Standard toolbar (select Profile | Terminate from the main menu of Visual Studio).

Your application may contain classes inherited from the System.Web.UI.Page or System.Web.HttpApplication class. If you include these inherited classes in profiling tasks and profile your .NET application with the Allocation profiler, you may note that AQtime will report that no instances of the inherited classes were created. This happens because the ASP.NET process does not create instances of your classes, which are inherited from System.Web.UI.Page or System.Web.HttpApplication. It creates instances of temporary classes that are inherited from your classes. Since your classes are not created, the profiling results are empty for them. However, the Allocation profiler automatically includes temporary classes in profiling tasks and traces the creation and deletion of their instances. By viewing profiling results for temporary classes, you can see how the application used your classes during the profiler run. The names of temporary classes inherited from System.Web.UI.Page have the following format: ASPXFileName_aspx, where ASPXFileName is the name of the .aspx file (excluding the file extension) that refers to your class. For instance, the XMLTrace sample application includes the XMLTrace.aspx file that refers to the XMLTraceForm class defined in XMLTrace.aspx.cs. The name of a temporary class inherited from the XMLTraceForm class will be XMLTrace_aspx. The names of temporary classes inherited from System.Web.HttpApplication have the ASAXFileName_asax format. For example, the XMLTrace application includes the Global.asax file that holds a reference to the Global class defined in Global.asax.cs. The name of a temporary class inherited from Global will be Global_asax.

A.: Profiling ASP.NET and IIS applications under Windows 2003 does not differ from profiling ASP.NET applications under Windows 2000 or Windows XP. AQtime supports profiling of both 32- and 64-bit ASP.NET and IIS applications.

A.: Yes, it is. You can profile them the same way you would profile native (non-.NET ) applications.

A.: An AQtime license is considered to be used when AQtime's modules are loaded into memory. This happens when you launch AQtime. If you use AQtime integrated into Microsoft Visual Studio, Borland Developer Studio, or CodeGear Delphi then AQtime modules are loaded into memory in the following cases:

• When you are using Visual Studio's / Developer Studio's / CodeGear Delphi's menu or toolbar item that triggers AQtime functionality.
• When you are creating a new or loading an existing AQtime project into Microsoft Visual Studio / Borland Developer Studio / Borland CodeGear Delphi.
• If a Visual Studio solution or a Developer Studio / CodeGear Delphi project that contains an AQtime project is open.
• When any of the AQtime panels are visible in Visual Studio's / Developer Studio's / CodeGear Delphi's IDE.

If AQtime modules are not loaded into memory, the license is considered as not being used.

A.: No, it is not nesessary. The software maintains the licenses itself.

A.: AQtime includes two features for profiling COM servers:

COM Server mode

AQtime can profile COM servers in Normal and COM Server mode. If you use the Normal mode, you profile your COM server as an ordinary application. That is, AQtime launches the application or attaches to it at run time, then instruments the application code and profiles it. However, in Normal mode AQtime cannot profile code that is executed when your COM server is being launched by the operating system, not by AQtime. For instance, DCOM servers are launched by a request from a remote computer. In this case, AQtime cannot profile the initialization code of the COM server, because the COM server process is not started via AQtime, and AQtime is not attached to the process. To profile this code, you need to use the COM Server mode. When you start profiling in this mode, AQtime performs specific actions that allow it to detect requests to the operating system and start profiling your COM server.

Profile COM logical threads (Thread model) option

A COM server may receive several requests from client applications simultaneously. Suppose, you are profiling a COM server with two client applications (see the figure below):

Client A calls the server function F1. Suppose, this function executes for a long time (As shown on the figure above, the function is displaying a message box. It will execute until the user closes this message box). Now, imagine that another client application, Client B, calls the server function F2, which finishes before F1 (because the message box has not been closed).

Both functions can be executed in the same Windows thread. The problem is that since F2 starts and finishes during the F1 execution and both functions are ran within the same thread, AQtime "thinks" that F2 is a child function of F1. This causes inaccurate profiling results.

The Profile COM logical threads (Thread model) option solves the problem. If it is enabled (set to COM Threads), AQtime performs an additional check to determine the "relationship" of the COM server functions. That is, this option helps you avoid getting inaccurate profiler results.

A.: The "Attach to Process" facility dramatically extends the sphere of applications available for profiling. This feature lets you profile applications that were not started by AQtime. That is, you can start your application outside of AQtime, then attach the selected AQtime profiler to the application and start profiling it. Using this feature will make it a lot easier for you, for instance, to profile IIS, ASP and ASP.NET applications in AQtime 3 (these applications are typically DLLs that are used by the IIS process). Without using the "Attach to Process" facility, you would have to start IIS under a debugger (for instance, to do this, you may need to switch IIS to debug mode). Another example that resembles profiling of IIS, ASP and ASP.NET applications is the profiling of services that are started by the operating system. If you don’t use "Attach to Process", you will have to start your service under the debugger or use the Service profiling mode.

The "Attach to process" facility can also be used to find errors that are hard to reproduce. Suppose you are testing your application and notice that the application behavior is strange (for instance, the application starts consuming too much memory without reason). If you close the application, load it in AQtime and attempt to reproduce the problem, you may no longer be able to reproduce the problem. The solution here is to use the "Attach to process" facility: Once you notice the application behaves oddly, you can attach to it and figure out what is going wrong.

A.: Currently, detaching is not supported. When attaching, AQtime instruments the process's binary code and these changes cannot be undone.

A.: To profile a WebSnap application in AQtime, do the following:

A.: Yes, AQtime can do this, but only if the version of EurekaLog you use is 4.5.5 or later. However, normally AQtime cannot profile applications that use exception catchers like EurekaLog (including earlier versions of EurekaLog). To profile these applications in AQtime, you need to disable the corresponding catcher. As for the EurekaLog versions earlier than 4.5.5, you should select EurekaLog Options from Delphi’s or C++Builder’s Project menu and disable the Activate EurekaLog checkbox in the resulting dialog.

A.: When profiling an Apache DSO module, you may come across a problem: AQtime displays the results for unit initialization and finalization code only or it does not display any results at all. The point is that the Apache process that is profiled by AQtime creates a child process, which loads your module. Therefore, all of the profiling is performed in this child process that AQtime does not know about. To eliminate the problem, we recommend that you run Apache from AQtime using the –X command-line argument (flag):

The –X command-line argument forces Apache to not create a child process, so your module will run within the profiled Apache process.

To obtain the profiling results, select Run | Get Results from the main menu of AQtime (Profile | Get Results if AQtime 4 is integrated into Visual Studio) before closing the Apache process.

A.: AQtime can read debug information of Window CE applications created with Visual Studio 2005 or Embedded Visual C++ 4.0. You can analyze your application with Static Analysis profilers and with the Disassembly panel.

A.: Normally, macros are used to automate user actions, such as typing a series of keys or running certain procedures, in Visual Studio .NET 2002, Visual Studio .NET 2003 and Visual Studio 2005. By default, macro projects are stored in the .Vsmacros files of the <Visual Studio>\Common7\IDE\MacroProjects folder. In fact, each Macro Project is a module with several procedures written in VBScript.NET.

To profile your macros with AQtime, compile them in a specific way to obtain a standalone .NET application. For this purpose, use the vbc.exe compiler located in the <Windows>\Microsoft.NET\Framework\<Framework version> folder.

The compiler must be run with the following command-line arguments:

vbc.exe MacroFileName /debug:full
/reference:assembly1[,assembly2, ...]

To perform the compilation quickly, you can create a .bat file that will run vbc.exe with necessary command-line arguments.

Note that it may be necessary to add the Main procedure to the module (if it does not exist). Else, a compilation error will occur.

Once the macro module is compiled as an application, you can profile it as an ordinary application in AQtime 4.

A.: Yes, you can easily do this with AQtime:

A.: One instance of AQtime can profile one process. For instance, if you profile an application that starts a new application, AQtime will not profile the new application. To profile several processes, you have to run several AQtime instances or, in other words, one instance per process.

In general, profiling multiple processes only differs slightly from profiling a single process. For each process you create a project, add the desired module(s) to it, specify the profiling areas, triggers, actions and other settings and then start the process from AQtime or attach to the process using the Attach-to-Process feature. Note, however, that attaching to the process requires time, so you will not be able to profile the startup code of the started process.

To solve this problem, you can modify the registry settings so that when the operating system gets a command to start a process, it automatically launches an AQtime instance, which you can then use to profile your application. To modify the registry settings:

• Launch the Registry Editor (regedit).
• Open the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options node.
• Add a key for your application to this node:
  • Right-click the node and choose New | Key from the context menu. This will create a new key node under the Image File Execution Options node.
  • Right-click the new node and select Rename from the context menu.
  • Change the key name to the name of your executable (for instance, MyApplication.exe). Only specify the file name and extension. The path is not needed.
• Specify AQtime as a debugger for the application. To do this:
  • Right-click the new key node and select New | String Value from the context menu. This will append a new string value to the created key.
  • Switch to the right panel of the Registry Editor, right-click the string value's node and choose Rename from the context menu.
  • In the ensuing in-place editor, change the value name to debugger.
  • Right-click the value node again and select Modify from the context menu. This will call the Edit String dialog.
  • In the Value data box of the dialog, enter the fully qualified name of AQtime.exe, for instance, C:\Program Files\Automated QA\AQtime 5\Bin\AQtime.exe.
  • Click OK to save the changes and to close the dialog.

Now the operating system will launch AQtime every time your application starts.

Do not forget to remove the registry key when you no longer need to automatically start AQtime.

If you need to enable or disable the automatic launch frequently, you can create two .reg files:

• One of the files will include the Registry key and the debugger value with the path to AQtime:

  

  To create this file:

  • Modify the registry as it was described above.
  • Select the key in in the tree view on the left of the Registry Editor.
  • Choose File | Export from the editor's main menu and specify the file name in the ensuing Export Registry File dialog.
• Another file will store the Registry key and the debugger value, but it will not store the path to AQtime:

  

  To create this file:

  • Modify the registry as it was described above.
  • Clear the data of the debugger value.
  • Export the key to a file by choosing File | Export from the main menu of the Registry Editor.

Now, when you need to enable or disable the automatic launch of AQtime for your application, you can execute one of the .reg files.

A.: In AQtime, the timing results depend on the counter, which you used for profiling. If you used the Elapsed Time counter, the time spent on executing the method includes the waiting time; if you used the User Time or User+Kernel Time counters, the resultant time does not include the waiting time.

If you profile your application with AQtime 3, the waiting time will be included in routine results.

A.: Interface methods and properties are abstract methods. Compilers do not generate debug information for abstract methods, so AQtime “does not know” about these methods when analyzing your application.

A.: There are some possible situations:

A.: The Editor panel is updated when you select a routine in one of AQtime's panels. To view the source code for a leak, choose that leak in the Report panel and then switch to the Details panel, which will display the call stack data. The topmost routine in the stack is the routine that allocated the memory block (or resource). To view the routine's source code, click the routine in the Details panel and then switch to the Editor.

A.: You most likely have an active filter applied to the results. Make sure that you do not have filters that hide the objects from the report:

• Press the Filter button on the Report panel's toolbar and disable the filter in the ensuing Filter dialog.
• Try disabling the Filter leaks setting on the Report panel's toolbar.

Another reason for hiding leaks is that you profiled your application with the active Show leaks for Setup modules setting (you can enable or disable this setting on the Report panel's toolbar). If the setting is enabled, AQtime only displays profiling results for those modules that are added to the Setup panel. If the setting is disabled, AQtime shows the results for all modules used by the profiled application. So, if the setting is active and the leak occurred in the module that is not added to your AQtime project, AQtime will display no information about the leak. Note that this setting only effects the Objects category of the profiling results and is ignored when the Classes category is selected.

A.: AQtime shows both handled and unhandled exceptions that occur in the profiled process. If your application is functioning as expected, then the exceptions you see are likely to be first-chance exceptions that are handled in the application's code. They do not mean that there is a problem in your code.

For more information about these exceptions, see the following articles:

• http://blogs.msdn.com/davidklinems/archive/2005/07/12/438061.aspx
• http://support.microsoft.com/kb/105675

A.: Currently, AQtime does not have a sampling profiler. But you can still profile an application under stress with AQtime. You can use the Performance profiler in combination with Profiling Areas that limit the monitored code thus reducing the profiling time.

A.: The results of this type are only generated if the Check System Memory Allocations option of the Allocation profiler is enabled. Once this option is enabled, AQtime traces calls to system memory management functions.

The "Reserved Virtual Memory" items are produced by the VirtualAlloc function. It can reserve a range of the process’s virtual address space without allocating any actual physical storage in memory. Thus the reported items are not genuine memory leaks, so there is no need to eliminate them.

A.: The resulting "C++ native memory" value is posted for memory blocks that were allocated by memory management routines and statements. The same value is posted if the creation and deletion of C++ classes were traced as the creation and deletion of memory blocks. This occurs for the applications created with the Intel C++, Borland C++ and GNU CC compilers, or if the classes of the C++ Builder / Visual C++ applications do not have an explicit constructor.

Therefore, the actual class name is only displayed if the following conditions are met:

1. The application was compiled in Borland C++ Builder or in Microsoft Visual C++.
2. The class has a constructor written in code or generated by the C++ compiler.

Even if the class name is not displayed, you can still locate the code line that produced the corresponding memory allocation. To do this switch to the Objects category, select a record in the Report panel, open the Details panel and switch to the Call stack panel. It displays the stack of function calls that led to the object’s creation. When you double-click a specific item in the call stack, the source code for this record (if available) is displayed in the Editor panel, so, you can find the exact line in where the allocation was made.