Using Memory Validator with a server application

This tutorial assumes that you have read the tutorial on collecting memory leaks and that you have built the sample application. If you have no done this, please do do before continuing with this tutorial. The memory leak tutorial is here.

This tutorial demonstrates how to associate information collected by Memory Validator with actions in an application. The application can be an application or a server, although typically the techniques described here are used more with server applications and applications that run for extended periods of time.

For the scenario where you are trying to identify which data items collected by Memory Validator correspond to actions you have in your application logfile, we assume that your logfile logs the time of any given activity.


Each data item collected by Memory Validator has a timestamp. The timestamp is expressed in milliseconds from the time the application started executing (to be correct: actually from the time Memory Validator’s DLL attached to the application).

The timestamp can be displayed as milliseconds or as a local time.

For example: 3897mS or 11/21 13:46:21 897mS where the 11/21 means November 21st.

To change the way timestamps are displayed, modify the controls on the Callstack tab of the settings dialog.

Setting watermarks using Memory Validator’s API

If timestamps are not quite what you want, or you want additional information, you can use watermarks. Watermarks can be added by manual intervention using the user interface, or by using the Memory Validator linkable API, or by calling GetProcAddress to dynamically identify the Memory Validator API.

For server applications and many interactive applications, manual addition of watermarks is not appropriate. Additionally, you may not want to link to Memory Validator’s linkable API. This leaves one last technique which is dynamically linking to the appropriate API function.

The benefit of the last technique is that you can leave your calls to the API in your application, even in release mode. The reason for this is that your customers will not be running your application with Memory Validator, hence the call to GetModuleHandle() will return NULL and the code will be skipped.

Consider the code shown below.

	// Function definition for the dynamic function we are going to call.
	// The available functions are in stublib.h, although the names in stublib.h
	// start with mv, rather than api

	typedef void (*apiSetWatermark_func)(char	*name);


	// Code at a point where user wants to set a watermark.
	// Note, get module handle (NOT LoadLibrary() call!).
	// If Memory Validator is working with your application this call will
	// return the module handle. If Memory Validator is not working with your
	// application this will return NULL.


	hMod = GetModuleHandle(_T("svlMemoryValidatorStub.dll"));
	if (hMod != NULL)
		// Memory Validator is loaded, now get the function we need
		// The linkable API call is void mvSetWatermark(char	*name); 
		// defined in stublib.h
		// The dynamic API call is the same name but with the mv replaced with api
		// giving void apiSetWatermark(char	*name). The decorated form of this name is
		// ?apiSetWatermark@@YAXPAD@Z. 
		// Finding the decorated name is easy: 
		//	Load svlMemoryValidatorStub.dll into depends.exe
		//	and look into the export address table for the function name.

		apiSetWatermark_func	aswf = (apiSetWatermark_func)GetProcAddress(hMod, &text[0]);
		if (aswf != NULL)
			//apiSetWatermark("Example dynamic watermark");
			(*aswf)("Example dynamic watermark");
			// something went wrong - function doesn't exist or function name was spelt incorrectly

Using the technique above you can rely on having watermarks in all the appropriate places in your application without linking to Memory Validator, or requiring a special build to remove the linked code from customer applications. You can use the techniques decribed in the watermarks tutorial to get information using this watermarks.

Fully functional, free for 30 days