Article ID: 169275 - View products that this article applies to.
This article was previously published under Q169275
This article provides a collection of tips, tricks, and traps to you can use to avoid and solve common problems that you may encounter while using the Call Attribute Profiler (CAP) and Working Set Tuner (WST) utilities for Windows NT and Windows 2000. Note that these utilities are included with the Win32 Software Development Kit. You can use these powerful utilities to make your application run faster and use less RAM.
This article assumes that you have read the preliminary information on the use of these tools that is available in the Win32 SDK Tools documentation. The information in this article applies to the versions of CAP/WST utilities that are shipped on the January 97 Win32 SDK or later.
Preparing Your ApplicationWe recommend that you build applications that you want to tune with CAP or WST with slightly different switches than the documentation suggests. For the compiler, use /Zi or /Z7 (don't forget /Gh). For the linker, use /debug /debugtype:both and /pdb:<name>.pdb or /pdb:none.
One benefit of using these switches is that you can do full symbolic debugging under the Visual C++ or WinDbg debugger in case either the CAP or WST utility manages to flush out a problem in your code. This is more common than you may think. For example, /Gh causes the compiler to insert a call to a function called _penter() in front of each and every function in your code. This global increase in code size causes your functions to load into slightly different offsets in memory, which may cause a pointer bug or array-overrun bug in your code to now show itself. By using these switches, you can debug your application normally when it is compiled for CAP/WST.
TIP: We recommend that you do not use capsetup.exe to prepare your applications for tuning. Instead, building your applications with the proper switches works more reliably.
TRAP: Running "capsetup -a" and then building your application for tuning causes the CAP utility to not work. Just avoid Capsetup.exe if you can.
Tuning/Profiling DLLs and OCXsTuning DLLs and OCXs is fairly straightforward for both CAP and WST, once you know the details, though the procedure is slightly different for each.
When an executable compiled for WST is initialized, WST gets control and looks at all the DLLs loaded in that process's memory space. Only DLLs that are present and built for WST are tuned, which means that the DLLs must be statically linked. Dynamically-loaded DLLs (and OCXs) are not tuned even though they may be compiled for tuning.
TRICK: However, you can tune all static DLLs/OCXs. The trick is to build only the DLL/OCXs that you want to tune for tuning. Do not build the executable for tuning. Then do the following:
TRAP: You will get output files for static DLL/OCXs loaded after the desired module anyway. If present, the environment variables %_NT_SYMBOL_PATH% and %_NT_ALT_SYMBOL_PATH% might each contain only one path containing less than 256 characters.
For additional information, please see the following article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/148659/EN-US/ )How to Set Up Windows NT Debug Symbols
Fortunately, CAP supports dynamically loaded libraries without any special caveats. You just need to make sure that loadlibrary=on in the CAP.ini file. However, if you're not getting symbolic information for your DLLs, you can try something similar to the procedure for WST--except you must put the name of the .exe in the [exes] section, unlike for WST.
Known Problems, LimitationsThe following is a list of known problems and limitations with the CAP and WST utilities. It's best to contact Microsoft Professsional Support Services for help with any problems encountered with these utilities. A support professional may be able to provide a workaround or help with critical problems.
CAP Memory Usage InformationCAP memory usage can be a factor in the performance of your application. If CAP's memory usage becomes too great (usually due to a lot of chronological data), this will result in a lot of swapping, which in turn can affect the performance of your application.
CAP's memory usage can be divided into the following three groups (ordered from smallest to largest):
The calling tree structure is continuously built as the profiled application executes. Each node in this tree represents one caller-callee pair. For example, the first time function A calls function B, a new node is created. Each additional call from function A to function B changes the profiling values in node A-B, but does not increase the storage space. So the size of the calling tree is dependent on the number of caller-callee relations that are actually exercised by the application. Each node requires 80 bytes of memory.
The calling tree information is dumped to the log file and provides the input for Capview.exe. It contains information such as the number of times function A called function B, the shortest/longest/average time function B executed when called by function A, and how much of function B's time was due to calls that it made itself.
Chronological calling data is by far the largest user of CAP memory. Unlike the calling tree data, the chronological data contains a data cell for every function call that occurs. If function A calls function B 100 times, 100 cells are created. This allows for a very detailed log that shows the exact order that calls were made and how much time each call took. The size of the chronological data, then, depends on how many function calls are made by the application. Each data cell requires 40 bytes.
Preparing to Contact Professional Support ServicesWhen CAP or WST fails, the most common symptoms are failure to produce any output or an exception while your application executes (usually during initialization). To determine if the failure is due to a problem in CAP.dll or WST.dll, you will have to debug your application. When you hit a 2nd- chance exception in the debugger (ignore all 1st-chance exceptions - they are normal and are handled by an exception handler in CAP/WST), look at the top of the call stack to see if the exception occurred in CAP or WST. To do this, use LINK -dump -headers on CAP.dll or WST.dll (or you can do a "quick view" in Windows Explorer on the DLL) and note the image base address and the "size of image" value. If the address where the exception occurred is within image base + size of image, then you have most likely encountered a bug in CAP.dll or WST.dll.
Before contacting Microsoft Professional Support Services for help in diagnosing the problem, please debug your application and do the following (these instructions are for an x86 machine). Visual C instructions are for version 5.0 and later:
WinDbg: On the Options menu, click Exceptions, set "Access Violation" (0xc0000005) to "Notify", and then click Change.
Visual C debugger: On the Debug menu, click Exceptions and make sure that "access violation" is set to "stop if not handled".