Using the Call-Attributed Profiler (CAP)

ID: Q118890

3.10 3.50 WINDOWS NT kbtool

The information in this article applies to:

SUMMARY

The call-attributed profiler (CAP) allows you to profile function calls within an application.

MORE INFORMATION

To profile an application using CAP, perform the following steps:

1. Replace the Windows NT system DLLs that your application uses with

   DLLs that contain debugging information. To find out which DLLs
   your application uses, run the APF32CVT.EXE utility provided with
   the Win32 SDK. The syntax to use is as follows:

      apf32cvt <application>

   This will list the DLLs to which your program is linked. The system
   DLLs that contain debugging information can be found in the
   \SUPPORT\DEBUGDLL\i386 of the Win32 SDK CD. Rename the DLLs in your
   WINNT\SYSTEM32 directory and copy the debugging DLLs to the
   WINNT\SYSTEM32 directory. You will need to reboot the machine to use
   the DLLs.

2. Recompile your application. If you are using the NTWIN32.MAK file
   in your makefile, all you need to do is to set the environment
   variable PROFILE=on. Otherwise, add /Gh and /Zd to the compiler
   options yourself and be sure that you are linking with the options
   "-debugtype:coff" and "-debug:partial,mapped".

3. Place a CAP.INI file in either the root directory of the drive, the
   application directory, the WINDOWS directory, or the root of the C
   drive. The CAP.INI file specifies the applications for which the
   profiler will gather information. At minimum, CAP.ini must contain
   the following:

      [EXES]
      <app>.exe
      [PATCH IMPORTS]
      <app>.exe
      [PATCH CALLERS]

   where <app> is the application to be profiled. The file CAP.TXT
   included in the \BIN directory of the SDK provides an excellent
   example.

4. Run the application. The profiling information is gathered
   and stored in a file with the same base name as the application
   and a .END extension. This information is in an ASCII format and
   can be viewed by any text editor. You can also use the CAPVIEW
   sample to view a graphical representation of the information.

Walter Oney points out in "Removing Bottlenecks from Your Program with Windows NT Performance-tuning Tools," from the April 1994 edition of "Microsoft Systems Journal," that the Visual C++ linker does not correctly generate debugging information that CAP can use. This is not correct. The problem is that the SDK 3.1 linker uses "-debug:mapped" by default, but the Visual C++ linker does not. Adding the switch to the link line (as in step 2, above) corrects this problem.

A common problem is for the profiling output to have "??? : ???" in place of the function names from your application. For example:

   1   ??? : ??? (Address=0x77889a1b)    1        4717        4717
             4717        4717        4717         n/a         n/a

This occurs if you use the wrong linker options. You should use "-debugtype:coff" and "-debug:partial,mapped".

Another common problem is to have function pointers instead of the Win32 API names. For example:

   1    0x77e9b10f                       1      1577         1577
             1577        1577        1577         n/a         n/a

This happens when you do not replace the system DLLs that your application calls with the DLLs that contain debugging information.

REFERENCES

The release notes for CAP.TXT can be found in the MSTOOLS\BIN directory.

The best source of information is "Optimizing Windows NT" by Russ Blake in the "Windows NT Resource Kit, Vol. 3".

Additional reference words: 3.10 3.50 KBCategory: kbtool KBSubcategory: TlsMisc Keywords : kbGrpDSTools

Last Reviewed: October 3, 1998