Detecting deadlocks in an IIS ISAPI DLL

This tutorial describes how to detect deadlocks in an IIS ISAPI DLL.

This tutorial covers the following:

    1. Modifying an ISAPI DLL to use the NT Service API.
    2. How to use the Thread Validator user interface to detect deadlocks in the IIS ISAPI DLL.

Related tutorials:

Detecting deadlocks in a child process.
Detecting deadlocks in a service.
Detecting deadlocks in a service child process.
Detecting deadlocks for a child process from the command line.

Native ISAPI and mixed-mode ISAPI

This tutorial applies to all native ISAPI DLLs and to mixed-mode ISAPI DLLs that uses the native Win32 services API.


Thread Validator ships with an example ISAPI DLL in the examples\isapiExample folder in the Thread Validator installation directory.

The ISAPI DLL has already been modified to use the NT Service API. In this tutorial we’ll describe the modification you would make to the ISAPI DLL to make it work correctly with Thread Validator.

What is the NT Service API?

The NT Service API is a simple API that allows you to load the Thread Validator profiling DLL and start the process of detecting deadlocks.

The API also includes some debugging functions to help provide debugging information via log files (the only way to get data out of an ISAPI DLL without a connection to the Thread Validator user interface).

Modifying your ISAPI DLL to use the NT Service API

  1. Identify your service’s GetExtensionVersion() function, and just before that function, add a new function definition called attachToThreadValidator()

    The purpose of attachToThreadValidator() is to use the NT Service API to instrument the ISAPI DLL with Thread Validator.

    // code to load Thread Validator into the IIS process for this ISAPI
    // this assumes the ISAPI is in C:\testISAPIWebsite\
    #include "..\..\svlTVStubService\svlTVStubService.h"
    #include "..\..\..\svlCommon\svlServiceError.h"
    static void attachToThreadValidator()
        SVL_SERVICE_ERROR   errCode;
    #ifdef IS6432
        // x86 with x64 GUI
        errCode = svlTVStub_LoadThreadValidator6432();
    #else   //#ifdef IS6432
        // x86 with x86 GUI
        // x64 with x64 GUI
        errCode = svlTVStub_LoadThreadValidator();
    #endif   //#ifdef IS6432
        if (errCode != SVL_OK)
            DWORD   lastError;
            lastError = GetLastError();
            svlTVStub_writeToLogFileW(L"Thread Validator load failed. \r\n");
            svlTVStub_writeToLogFileW(L"Thread Validator load success. \r\n");
            errCode = svlTVStub_StartThreadValidatorForIIS();
            if (errCode != SVL_OK)
                DWORD   lastError;
                lastError = GetLastError();
                svlTVStub_writeToLogFileW(L"Starting Thread Validator failed. \r\n");
            svlTVStub_writeToLogFileW(L"Finished starting Thread Validator\r\n");
  2. At the start of GetExtensionVersion() just after setting the ISAPI description pVer->lpszExtensionDesc add a call attachToThreadValidator().
  3. At the end of TerminateExtension() add a call to svlTVStub_UnloadThreadValidator().

Detecting deadlocks in the service

Now that the NT Service API has been implemented in your service, we can start collecting memory allocation data from the service.

  1. Choose the Launch > IIS > Monitor IIS and ISAPI… option.

    Thread Validator launch menu IIS and ISAPI

  2. The Monitor IIS and ISAPI dialog is displayed.

    Thread Validator IIS and ISAPI dialog

    1. Select the ISAPI DLL you are going to monitor. For this example, the application is C:\testISAPIWebsite\isapiExample_x64.dll. This assumes that IIS has been configured for this ISAPI DLL.
    2. Choose the appropriate native/mixed-mode/.Net option to specify which types of code you want to detect deadlocks for. Mixed-mode is the default, as this collects memory allocation information for all types of code.
    3. The web root will be automatically set to the same directory as that containing the ISAPI DLL. Directory permissions for the current user and for user group IIS_ISURS will be automatically set if the Automatically set directory permissions check box is selected. If this is not selected, permissions won’t be set, and a Show me how… link will be displayed beneath the web root. This link will open a tutorial explaining how to set the correct directory permissions to work with IIS_ISURS.
    4. Select a web browser of your choice. For this example we’ll choose firefox.exe.
    5. Specify the URL that you wish to test with the ISAPI DLL. For this example we’re going to test http://localhost:81\isapiExample_x64.dll?10
  3. When you click OK, Thread Validator will set up everything needed to interact with the IIS and the NT Service API and if all is OK, the web browser will be started to open the specified URL.

    If errors are found you will be presented with a dialog box specific to the error so that you can correct the error before starting the web browser.

  4. Thread Validator will instrument your ISAPI DLL and start detecting deadlocks.

Finishing detecting deadlocks

To finish detecting deadlocks, you need to stop IIS.

If you had selected Stop IIS when web browser is closed on the Monitor IIS and ISAPI dialog then you have nothing to do.

Otherwise, choose Launch > Services > Stop IIS

Thread Validator ISAPI stop IIS

Thread Validator will continue monitoring deadlocks during the service shutdown procedure and then present you with the deadlocks and threading report.

I’m not getting any threading data. What can I do?

There are a few things to check.

  1. Have you correctly added the NT Service API to the ISAPI DLL? 
  2. Check the log file for any errors. You specified the log file in attachToThreadValidator() with the call
  3. Check the diagnostics tab. If the NT Service API is working correctly, Thread Validator will have some data. Information on instrumentation failures will be on the diagnostic tab.
  4. Check the debug information dialog. You can access this from the Tools > DLL Debug Information… menu. This dialog will tell you which DLLs have debug information and which do not. Any DLLs that don’t have debug information you’ll need to ensure that debug information is built for these DLLs and is findable.


You have learned how to add the NT Service API to an ISAPI DLL, how to use Thread Validator to monitor ISS and ISAPI, and what to look at to diagnose errors if things don’t work first time.



Fully functional, free for 30 days