Remote Application Verifier: This tool is part of the Windows CE test kit, that monitors :
- Heap allocations
- Handle allocations
- GDI Resources
- More… (If you knew how to write a shim)
The output is a log file that is placed on the device, pointing to various leaks (potential or otherwise) Here's a li'l example to settle the initial dust. Consider I have written this harmless code in an application:
#include "stdafx.h"
void ThreadRoutine(void);
int _tmain(int argc, TCHAR *argv[], TCHAR *envp[])
{
// Create the thread
CreateThread(NULL,NULL, (LPTHREAD_START_ROUTINE)ThreadRoutine,NULL, NULL, NULL);
return 0;
}
void ThreadRoutine(void)
{
MessageBox(NULL, TEXT("The thread was created!!"),NULL,MB_OK);
return;
}
Run the App verifier tool on this code (I'll leave the "how to" as an exercise), ad export the log.
The log shows a potential leak at 30h.
We need to generate the code file now, in order to know where our code is leaking.
Right click on the subproject name and choose Properties, click on the General tab and locate the setting next to Generate Code File. Select Yes from the drop down box. Click OK and Rebuild the subproject.
When PB is finished rebuilding the project right click on the project’s name again and select Explore. Navigate to the \obj\ARMV4I\debug and locate the LeakingMemory.cod file.
Click and drag that file from the explorer window to VS document editor. Navigate to the line that starts with 00030. It looks like the problem occurs in the CreateThread method.
See the code now: Looks like the handle created by the CreateThread function in the heap is never released, essentially resulting in a Heap memory leak!!
The good approach to code would have been:
#include "stdafx.h"
void ThreadRoutine(void);
int _tmain(int argc, TCHAR *argv[], TCHAR *envp[])
{
DWORD Base_Address;
DWORD Page_Size=1024;
HANDLE HDl;
HDl = CreateThread(NULL,NULL, (LPTHREAD_START_ROUTINE)ThreadRoutine, NULL, NULL, NULL);
// Close the Handle before exiting
CloseHandle(HDl);
return 0;
}
void ThreadRoutine(void)
{
MessageBox(NULL, TEXT("The thread was created!!"),NULL,MB_OK);
return;
}
The above example shows the capabilities of App Verifier with a simple application. Such callous mistakes are abundant in a large, multithreaded environment, leading to a unexpected system failure. The App Verifier may be used in 3 ways:
- From the PC : Easier to control from PC, Automatically brings data to PC, however needs Activesync or ethernet connection
- On the device : No need for a connection with a PC, however Requires a device U/I, Dialog needs a 800x600 screen
- Using Shell: No device U/I required, Can run from Device,PC using Platform Builder, PC using a serial port, however this is not as polished as other options.
The App verifier is not foolproff, nor is it exhaustive... in fact, it can become quite daunting. Another downside is somewhat flaky connectivity at times.
All said and done, the App verifier is a powerful tool to use for detecting per process level leaks.
