C / C++ / MFC

How Regmon Works  
The heart of Regmon on Windows 9x is in the virtual device driver, Regvxd.vxd. It is dynamically loaded,
and in its initialization it uses VxD service hooking (see our May 1996 Dr. Dobb's Journal article on VxD
= service hooking for more information) to insert itself onto the call chain of 16 registry access functions
in the Windows 95 kernel (Virtual Machine Manager). All registry activity, be it from 16-bit programs, Win32
applications, or device drivers, are directed at these routines, so Regmon catches all registry activity
taking place on a machine. 

On Windows NT, 2000 and XP the Regmon loads a device driver that uses a technique we pioneered for NT called
system-call hooking. When a user-mode component makes a privileged system call, control is transfered to a
software interrupt handler in NTOSKRNL.EXE (the core of the Windows NT operating system). This handler takes
a system call number, which is passed in a machine register, and indexes into a system service table to find
the address of the NT function that will handle the request. By replacing entries in this table with pointers
to hooking functions, it is possible to intercept and replace, augment, or monitor NT system services.

Regmon, which obviously hooks just the Registry-related services, is merely one example of this capability in
action.

On Windows .NET Server Regmon takes advantage of a new operating system Registry callback mechanism to
register for and receive information about Registry accesses as they occur. When you run Regmon on .NET
Server it loads a version of the Regmon driver utlizing the callbacks.

When Regmon sees an open, create or close call, it updates an internal hash table that serves as the mapping
between key handles and registry path names. Whenever it sees calls that are handle based, it looks up the
handle in the hash table to obtain the full name for display. If a handle-based access references a key
opened before Regmon started, Regmon will fail to find the mapping in it hash table and will simply present
the key's value instead.

Information on accesses is dumped into an ASCII buffer that is periodically copied up to the GUI for it to
print in its listbox. 

void Go( void )
{
    BROWSEINFO  bi = {0};
    SQLRETURN   sqlRet
    SQLHENV     env = NULL;
    SQLHDBC     conn = NULL;
    SWORD       len = 0,
                nMessageLen = 0;
    SQLCHAR     szOut[2048] = {0},
                sqlConn[1024] = "DRIVER={SQL Server};SERVER=(local)";
    UCHAR       szMessage[ SQL_MAX_MESSAGE_LENGTH ] = {0},
                szErrorState[ SQL_SQLSTATE_SIZE + 1 ] = {0};
    SDWORD      dwNativeErrorCode = 0;

    
    bi.ulFlags = BIF_NEWDIALOGSTYLE | BIF_RETURNONLYFSDIRS;

    SHBrowseForFolder( &bi );

    sqlRet = SQLAllocEnv(&env);
    if (SQL_SUCCESS == sqlRet)
    {
        sqlRet = SQLAllocConnect(env, &conn);
        if (SQL_SUCCESS == sqlRet)
        {
            sqlRet = SQLDriverConnect(conn, NULL, sqlConn, SQL_NTS, szOut, sizeof(szOut), &len, SQL_DRIVER_COMPLETE_REQUIRED);
            if (SQL_SUCCESS != sqlRet && SQL_SUCCESS_WITH_INFO != sqlRet)
            {
                sqlRet = SQLError(env, conn, SQL_NULL_HSTMT, szErrorState, &dwNativeErrorCode, szMessage, SQL_MAX_MESSAGE_LENGTH - 1, &nMessageLen);

                ::MessageBox(NULL, (CHAR *) szMessage, (CHAR *) szErrorState, MB_OK);
            }

            sqlRet = SQLDisconnect(conn);

            sqlRet = SQLFreeHandle(SQL_HANDLE_DBC, conn);
        }

        sqlRet = SQLFreeHandle( SQL_HANDLE_ENV, env );
    }

    ZeroMemory(&bi, sizeof(bi));
    bi.ulFlags = BIF_NEWDIALOGSTYLE | BIF_RETURNONLYFSDIRS;
    SHBrowseForFolder(&bi);
}