This tutorial describes how to collect code coverage for a child process of a service (or any descendant process of the service).
This tutorial covers the following:
Related tutorials:
Code coverage for a .Net Core application.
Code coverage for a .Net Core application child process.
Code coverage for a service.
Code coverage for a service child process.
Code coverage for an IIS ISAPI DLL.
Code coverage for ASP.Net with IIS.
Code coverage for ASP.Net with Web Development Server.
This tutorial applies to all native applications and to mixed-mode applications where the startup code is native.
If your application is written entirely in .Net or .Net Core, or your application is mixed-mode with the startup code written in .Net or .Net core you can skip the part of this tutorial relating to the NT Service API and go straight to the collecting code coverage from a service child process section.
Coverage Validator ships with an example service and an example child process launched by the service. These can be found in the following directories in the Coverage Validator installation directory:
or
or
The childProcess has already been modified to use the NT Service API. In this tutorial, we’ll describe the modifications you would make to the child process to make it work correctly with Coverage Validator.
The NT Service API is a simple API that allows you to load the Coverage Validator profiling DLL and start the process of collecting code coverage.
The API also includes some debugging functions to help provide debugging information via log files (the only way to get data out of a service without a connection to the Coverage Validator user interface).
static void attachToCoverageValidator() { if (bLogging) { // Set the log file name. // When anything goes wrong the API will write error information to this file. // You can also write to this log file any status errors you need (you'll see examples in this source file) svlCVStub_setLogFileName(SZLOGFILENAME); svlCVStub_deleteLogFile(); } if (bLogging) { svlCVStub_writeToLogFileW(L"About to load Coverage Validator\r\n"); } SVL_SERVICE_ERROR errCode; #ifdef IS6432 // x86 with x64 GUI errCode = svlCVStub_LoadCoverageValidator6432(); #else //#ifdef IS6432 // x86 with x86 GUI // x64 with x64 GUI errCode = svlCVStub_LoadCoverageValidator(); #endif //#ifdef IS6432 if (bLogging) { if (errCode != SVL_OK) { DWORD lastError; lastError = GetLastError(); svlCVStub_writeToLogFileW(L"Coverage Validator load failed. \r\n"); svlCVStub_writeToLogFileLastError(lastError); svlCVStub_writeToLogFile(errCode); svlCVStub_dumpPathToLogFile(); } else { svlCVStub_writeToLogFileW(L"Coverage Validator load success. \r\n"); } } // DO NOT setup a service callback because this is a child application of a service, not a service // start Coverage Validator errCode = svlCVStub_StartCoverageValidator(); if (bLogging) { if (errCode != SVL_OK) { DWORD lastError; lastError = GetLastError(); svlCVStub_writeToLogFileW(L"Starting Coverage Validator failed. \r\n"); svlCVStub_writeToLogFileLastError(lastError); svlCVStub_writeToLogFile(errCode); } svlCVStub_writeToLogFileW(L"Finished loading Coverage Validator\r\n"); } }
Now that the NT Service API has been implemented in your application, we can start collecting code coverage from the service child process.
Select the application executable (the service’s child process) you are going to monitor. For this example the application is examples\serviceWithAChildProcess\serviceWithAChildProcess\x64\Release\childProcess_x64.exe.
Choose the appropriate native/mixed-mode/.Net option to specify which types of code you want to collect code coverage for. Mixed-mode is the default, as this collects code coverage for all types of code.
The collect data check box will not be modifiable if you are using breakpoints to instrument the code coverage.
There are a few things to check.
svlCVStub_setLogFileName(SZLOGFILENAME);
You have learned how to add the NT Service API to a native application that is going to be launched from a service, how to use Coverage Validator to monitor a service’s child process, and what to look at to diagnose errors if things don’t work first time.