Loading Validator into a process
Everything written here applies to all Validators: Bug, Coverage, Memory, Performance and Thread.
There are many ways to start collecting data with a Validator: Launch, Inject, Wait, Service, IIS, WDS.
But sometimes the methods we’ve provided won’t work because the scenario you’re trying to track is too complex for the GUI driven options we’ve provided.
So, in that scenario how do you detect memory leaks, or collect code coverage, etc?
API
This is where the API comes in handy, and in particular a convenience function we’ve written to make life easy.
If you look in the API subdirectory in your Validator’s install directory you find two files:
loadValidatorIntoAnApplication.c
loadValidatorIntoAnApplication.h
Building a .exe
- Add both files to the project that builds the .exe you want to monitor.
- For loadValidatorIntoAnApplication.c you’ll need to disable precompiled headers.
- Right click on loadValidatorIntoAnApplication.c and choose Properties…
- Change the Configuration combo to All Configurations.
- Expand C/C++ then choose Precompiled Headers.
- On the right hand side next to Precompiled Header change this to Not Using Precompiled Headers.
- Click OK
- Add #include “loadValidatorIntoAnApplication.h” to the file that contains main().
- In the main() function, add a call to loadValidatorIntoApplication(); as the first thing that main() does.
Building a .dll
If you are building .exe and .dll used by the .exe, ignore this section, follow the instructions for Building a .exe.
- Add both files to the project that builds the .dll you want to monitor. Ideally this should be the first DLL of yours that gets called (this assumes you are building more than one DLL).
- For loadValidatorIntoAnApplication.c you’ll need to disable precompiled headers.
- Right click on loadValidatorIntoAnApplication.c and choose Properties…
- Change the Configuration combo to All Configurations.
- Expand C/C++ then choose Precompiled Headers.
- On the right hand side next to Precompiled Header change this to Not Using Precompiled Headers.
- Click OK
- Add #include “loadValidatorIntoAnApplication.h” to the file that contains the first function of your DLL that will be called.
- In the first function of your DLL that will be called, add a call to loadValidatorIntoApplication(); as the first thing that function does.
- If you don’t know which function in your DLL will be called first, add the function call to DllMain() when (fdwReason == DLL_PROCESS_ATTACH).
We don’t recommend this approach because Microsoft state that doing complex work inside DllMain() can lead to undefined behaviour. Our experience is that starting Validators from here usually works, but that could change with future operating system releases.
#include "..\..\..\..\coverageValidator\API\loadValidatorIntoAnApplication.h" BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: loadValidatorIntoApplication(); break; case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: break; case DLL_PROCESS_DETACH: break; } return TRUE; }
Usage
If Validator is installed on your computer
If Validator is running, when you start your .exe (or load your DLL and call functions in it) it will automatically communicate with the Validator GUI and start reporting memory leaks, or collecting code coverage, etc.
If Validator is not running, it will be started automatically.
If Validator is not installed on your computer
If Validator is not installed on the computer, nothing happens. This allows you to leave this code in your product because you know your customers will never have Validator on their machine.
Dependencies
There are no DLL dependencies.
Once you’ve built your .exe/.dll with the included code you can deploy your .exe/.dll anywhere.