Before WMILIB has called you back at your QueryWmiRegInfo callback, you might get a few calls for IRP_MN_REGINFO with an uninitialized buffer. This is not a good thing at all, because the WppTraceCallback code does no sanity checking on the buffer whatsoever, and this can lead to an invalid memory access. This means that you need to include some logic in your code to zero this buffer every time you are called up until the point that your QueryWmiRegInfo callback is called.

Step 4: Add a BOOLEAN to your device extension that is set to TRUE in your QueryWmiRegInfo callback. Until this flag is set to TRUE, zero the data buffer sent with all IRP_MN_REGINFO requests.

Calling WppTraceCallback
It's finally time to add the final step: adding the call to WppTraceCallback within your driver. If you search the TPL files once more to find the definition of this routine, you'll find this in control.tpl:

NTSTATUS
WppTraceCallback(
    IN UCHAR minorFunction,
    IN PVOID DataPath,
    IN ULONG BufferLength,
    IN PVOID Buffer,
    IN PVOID Context,
    OUT PULONG Size
    ) ;

#define WPP_TRACE_CONTROL(Function,Buffer,BufferSize,ReturnSize) \
      WppTraceCallback(Function,NULL,BufferSize,Buffer,&WPP_CB[0],&ReturnSize);

We'll use the provided macro to call the routine, because it has fewer parameters and maybe that means we can leave early today.

What we want is for WMILIB to register itself and then for WPP to steal the last entry in the GUID table. Also, we want the WPP code to be able to handle the IRP_MN_ENABLE/DISABLE_EVENT requests that it needs in order to support turning the tracing on and off. But we also don't want to prevent WMILIB from handling any requests for custom events that we have created.

The only way to achieve this is by adding our final step:

Step 5: Add a call to WPP_TRACE_CONTROL in the IrpNotProcessed case of your IRP_MJ_SYSTEM_CONTROL routine. If WMILIB failed the request but WPP_TRACE_CONTROL completed with success, change the status and information fields of the IRP.

After following all of these steps you should end up with an IRP_MJ_SYSTEM_CONTROL routine that looks something like this:

NTSTATUS
NothingSystemControl(
    IN PDEVICE_OBJECT DeviceObject,
    IN PIRP Irp
    ) {

    PNOTHING_DEVICE_EXT    devExt;
    SYSCTL_IRP_DISPOSITION disposition;
    NTSTATUS               status;

    devExt = (PNOTHING_DEVICE_EXT)DeviceObject->DeviceExtension;

#ifdef WPP_TRACING
#ifdef W2K

    //
    // One of the mythical things that people tell you that
    //  you need to do to get WPP tracing to work on Windows
    //  2000 is to call the WPP_SYSTEMCONTROL macro in your
    //  DriverEntry entry point. The problem with this is that
    //  what is does is actually trash your IRP_MJ_SYSTEM_CONTROL
    //  entry point, meaning that you can no longer expose your
    //  driver through WMI. What we will do to get around this
    //  is to incorporate a call to the function that the WPP
    //  IRP_MJ_SYSTEM_CONTROL handler calls in order to handle
    //  WPP data. By doing this, we can satisfy WPP while
    //  also supporting our own WMI data.
    //
    //  You can find the code for the WPP SYSTEM_CONTROL
    //  handler (WPPSystemControlDispatch) in the km-init.tpl
    //  file located in the DDK's bin\wppconfig directory.
    //
    if (DeviceObject == (PDEVICE_OBJECT)stack->Parameters.WMI.ProviderId) {

        //
        // If this is a REG_INFO request and we have not registered
        //  with WMI yet, we must zero the buffer. The reason for this
        //  is that the WPP code will just blindly use it without
        //  verifying any of the members of the structure. We learned
        //  this trick from the WPPSystemControl handler code in
        //  km-init.tpl
        //
        if (stack->MinorFunction == IRP_MN_REGINFO &&
            !devExt->WmiRegistered) {

            RtlZeroMemory(stack->Parameters.WMI.Buffer,
                          stack->Parameters.WMI.BufferSize);

        }

        //
        // Yet another nice thing about trying to get tracing and WMI
        //  support working is that we can NOT allow an IRP_MN_REGINFO_EX
        //  request to get to the WMI library, we must do the registering
        //  of WMI through an IRP_MN_REGINFO request.
        //
        // Why? Because the W2K tracing code has no idea what an
        //  IRP_MN_REGINFO_EX is, so it will refuse to setup the
        //  parts necessary for WPP tracing support. So, if
        //  we see an IRP_MN_REGINFO_EX request come in and we're
        //  built for Windows 2000, that means that we need to
        //  reject it to force the code to send us an IRP_MN_REGINFO
        //  request instead.
        //
        // IRP_MN_REGINFO_EX isn't defined for Windows 2000, so we use
        //  its constant value of 0xb here.
        //
        if (stack->MinorFunction == 0xb) {

            //
            // Fail the request
            //
            Irp->IoStatus.Status = STATUS_INVALID_DEVICE_REQUEST;
            Irp->IoStatus.Information = 0;
            IoCompleteRequest(Irp, IO_NO_INCREMENT);
            OsrDecrementOutstandingIoCount(devExt,__FILE__,__LINE__);
            return STATUS_INVALID_DEVICE_REQUEST;

        }

    }

#endif // W2K
#endif //WPP_TRACING

    //
    // Call WMILIB to process the request.
    //

    status = WmiSystemControl(&devExt->WmiLibInfo,
                                 DeviceObject,
                                 Irp,
                                 &disposition);

    //
    // Check the disposition of the request, so that we can determine
    // what to do.
    //

    switch(disposition) {

        case IrpProcessed:
        {
            //
            // This IRP has been processed and may be completed or pending.
      //
            break;
        }
       
        case IrpNotCompleted:
        {

#ifdef WPP_TRACING
#ifdef W2K

            //
            // If the WMILIB didn't complete the IRP, then let's
            //  see if WPP will.
            //
            NTSTATUS wppStatus;
            wppStatus = WPP_TRACE_CONTROL(stack->MinorFunction,
                                          stack->Parameters.WMI.Buffer,
                                          stack->Parameters.WMI.BufferSize,
                                          bytesReturned);

            if (!NT_SUCCESS(status) &&
                NT_SUCCESS(wppStatus)) {
               

                //
                // WMILIB failed the IRP, but WPP completed it
                //  with success. Therefore, we'll change the IRP's
                //  status and bytes returned count to what WPP
                //  would like them to be.
                //
                Irp->IoStatus.Status = wppStatus;
                Irp->IoStatus.Information = bytesReturned;
                status = wppStatus;

            }

#endif // W2K
#endif //WPP_TRACING
 
            //
            // This IRP has not been completed, but has been fully processed.
            // we will complete it now.
            //
            IoCompleteRequest(Irp, IO_NO_INCREMENT);               
            break;
        }
       
        case IrpForward:
        case IrpNotWmi:
        {
            //
            // This IRP is either not a WMI IRP or is a WMI IRP targeted
            // at a device lower in the stack.

            IoSkipCurrentIrpStackLocation (Irp);
            status = IoCallDriver (devExt->DeviceToSendIrpsTo, Irp);
            break;
        }
                                   
        default:
        {
             //
            // We really should never get here, but if we do just forward.... 
            //
            ASSERTMSG("Unkown SYSCTL_IRP_DISPOSITION from WmiSystemControl",
                      FALSE);
            IoSkipCurrentIrpStackLocation(Irp);
            status = IoCallDriver(devExt->DeviceToSendIrpsTo, Irp);
            break;
       }       
    }

    return(status);

}

Yes, It Is That Complicated!
Unfortunately, it takes quite a bit of work to get WPP and WMILIB to coexist, but luckily it's mostly just a cut and paste job once you've seen how it's done.