郁闷啊，在SFILTER里面写了小段代码，用Verifier检测，出现的奇怪问题。

int GetCreateFilePath(  
                IN PDEVICE_OBJECT DeviceObject,
                IN PIRP Irp
                )
{
    PIO_STACK_LOCATION            irpsp = NULL;
    PFILE_OBJECT                FileObj = NULL;
    UNICODE_STRING                volumeDosName;
    int                            retVal = 1;

    PAGED_CODE();
    if ( IS_MY_CONTROL_DEVICE_OBJECT( DeviceObject ) )
    {
        Irp->IoStatus.Status = STATUS_INVALID_DEVICE_REQUEST;
        Irp->IoStatus.Information = 0;
        IoCompleteRequest( Irp , IO_NO_INCREMENT );
        return STATUS_INVALID_DEVICE_REQUEST;
    }

    volumeDosName.Buffer =(PWSTR)ExAllocatePoolWithTag(NonPagedPool, 1024 , 'Lv');
    if ( volumeDosName.Buffer != NULL )
    {
        RtlZeroMemory(volumeDosName.Buffer , 1024);
    }
    else
    {
        return -1;
    }
    irpsp = IoGetCurrentIrpStackLocation(Irp);
    FileObj = irpsp->FileObject;

    IoVolumeDeviceToDosName( FileObj->DeviceObject, &volumeDosName );
    //RtlAppendUnicodeStringToString( &volumeDosName , &FileObj->FileName );
    DbgPrint("file name: %ws%ws",volumeDosName.Buffer , FileObj->FileName.Buffer );

    //if ( !wcscmp(volumeDosName.Buffer ,L"C:") && wcsstr( FileObj->FileName.Buffer , L"TEST" )!=NULL )
    //{
    //    retVal = 0;
    //}

    //if( volumeDosName.Buffer != NULL )
    ExFreePoolWithTag(volumeDosName.Buffer , 'Lv');
    return retVal;
}
     这个是小弟写的获得文件路径的代码，但是在Verifier打开后，加载和运行驱动都是正常的。一旦卸载就BSOD。抓出来DMP如下信息：

kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught.  This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
        Parameter 1 = 0x1000 .. 0x1020 - deadlock verifier error codes.
               Typically the code is 0x1001 (deadlock detected) and you can
               issue a '!deadlock' KD command to get more information.
Arguments:
Arg1: 00000060, A driver has forgotten to free its pool allocations prior to unloading.
Arg2: 00000000, paged bytes
Arg3: 0009a400, nonpaged bytes,
Arg4: 00000269, total # of (paged+nonpaged) allocations that weren't freed.
    To get the name of the driver at fault, type
    dp ViBadDriver l1; dS @$p
    Then type !verifier 3 drivername.sys for info on the allocations
    that were leaked that caused the bugcheck.

Debugging Details:
------------------

Page 175e3 not present in the dump file. Type ".hh dbgerr004" for details

PEB is paged out (Peb.Ldr = 7ffd300c).  Type ".hh dbgerr001" for details

PEB is paged out (Peb.Ldr = 7ffd300c).  Type ".hh dbgerr001" for details

OVERLAPPED_MODULE: Address regions for 'w70n51' and 'Rtlnic51.sys' overlap

BUGCHECK_STR:  0xc4_60

IMAGE_NAME:  sfilter.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  48ead21f

MODULE_NAME: sfilter

FAULTING_MODULE: ededf000 sfilter

DEFAULT_BUCKET_ID:  INTEL_CPU_MICROCODE_ZERO

PROCESS_NAME:  services.exe

LAST_CONTROL_TRANSFER:  from 8064e00c to 804f9aef

STACK_TEXT:  
ee8e1acc 8064e00c 000000c4 00000060 00000000 nt!KeBugCheckEx+0x1b
ee8e1af4 805a3149 84531048 848208f8 84820920 nt!MiVerifyingDriverUnloading+0x12a
ee8e1b20 80578ad8 84531048 84820908 ee8e1b4c nt!MmUnloadSystemImage+0x183
ee8e1b30 805b080f 84820920 84820908 00000000 nt!IopDeleteDriver+0x32
ee8e1b4c 8052301d 84820920 00000000 ee8e1c30 nt!ObpRemoveObjectRoutine+0xdf
ee8e1b70 804f5614 ee8e1c30 ee8e1cac 80579778 nt!ObfDereferenceObject+0x5f
ee8e1c14 80579787 ee8e1d0c 00000000 ee8e1c30 nt!IopUnloadDriver+0x288
ee8e1c24 8053da28 ee8e1d0c ee8e1d48 804ff8c9 nt!NtUnloadDriver+0xf
ee8e1c24 804ff8c9 ee8e1d0c ee8e1d48 804ff8c9 nt!KiFastCallEntry+0xf8
ee8e1ca0 804f547d ee8e1d0c ee8e1d64 0007f874 nt!ZwUnloadDriver+0x11
ee8e1d48 80579787 0007f87c 00000000 ee8e1d64 nt!IopUnloadDriver+0xf1
ee8e1d58 8053da28 0007f87c 0007f884 7c92eb94 nt!NtUnloadDriver+0xf
ee8e1d58 7c92eb94 0007f87c 0007f884 7c92eb94 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
0007f884 00000000 00000000 00000000 00000000 0x7c92eb94


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

FAILURE_BUCKET_ID:  0xc4_60_VRF_IMAGE_sfilter.sys_RECENT

BUCKET_ID:  0xc4_60_VRF_IMAGE_sfilter.sys_RECENT

Followup: MachineOwner
---------


看样子是说内存没有被释放引起的，但是又想不出来自己的代码哪里会出现内存没有被释放的。请高手们指点下。

看DDK帮助：

IoVolumeDeviceToDosName allocates the Unicode string buffer for the MS-DOS path from the memory pool. After the buffer is no longer required, a caller of this routine should use ExFreePool to free it.


========================


This routine is only available on Microsoft Windows XP and later. Drivers that must work on earlier versions of NT-based operating systems can use RtlVolumeDeviceToDosName, which behaves identically.

IoVolumeDeviceToDosName allocates the Unicode string buffer for the MS-DOS path from the memory pool. After the buffer is no longer required, a caller of this routine should use ExFreePool to free it.

On Windows Vista and later operating systems, you must ensure that APCs are not disabled before calling this routine. Call KeAreAllApcsDisabled for this purpose.

Callers of this routine must be running at IRQL = PASSIVE_LEVEL.

没看出来,-_-