调用PutScatterGatherList函数时发生蓝屏，参数IN PSCATTER_GATHER_LIST ScatterGather也没问题

我把dma传输驱动程序裁减得已经是最精简的了，只剩下dma的操作。目前的状况是dma读写工作一段时间（工作时间长度是随机的，也就是读写都能进行好多次，但不知道什么时候就出问题了）后会蓝屏。蓝屏时的调试信息和函数栈为：
BAD_POOL_CALLER (c2)
The current thread is making a bad pool request.  Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 00000007, Attempt to free pool which was already freed
Arg2: 00001163, (reserved)
Arg3: 00260000, Memory contents of the pool block
Arg4: 8c2a3008, Address of the block of pool being deallocated

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


POOL_ADDRESS:  8c2a3008 Nonpaged pool

FREED_POOL_TAG:  Hal

BUGCHECK_STR:  0xc2_7_Hal

DEFAULT_BUCKET_ID:  DRIVER_FAULT

PROCESS_NAME:  Idle

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from 80826967 to 80871f24


STACK_TEXT:  
8089a05c 80826967 00000003 00000000 00000000 nt!RtlpBreakWithStatusInstruction
8089a0a8 8082786b 00000003 00000001 8c2a3000 nt!KiBugCheckDebugBreak+0x19
8089a440 80827c63 000000c2 00000007 00001163 nt!KeBugCheck2+0x5e1
8089a460 808927bb 000000c2 00000007 00001163 nt!KeBugCheckEx+0x1b
8089a4c8 80a5b2ef 8c2a3008 00000000 8cecacc4 nt!ExFreePoolWithTag+0x477
8089a4ec 809bca69 8cecaea8 8d11c18c 8c2a3001 hal!HalPutScatterGatherList+0xe3
8089a514 baccd190 8cecaea8 8c2a3028 8c2a3001 nt!VfPutScatterGatherList+0x6b
                                                                                                KDmaAdapter::PutScatterGatherList+0x20
                                                                                                 KDmaTransfer::CompleteLastTransfer+0xf3

通过查看KDmaTransfer类的成员变量m_pScatterGather，发现m_pScatterGather指向的那块空间我也没有做free操作啊，且数据也是完好的。不知道为什么经常会随机地发生蓝屏。另外，请问针对这种现象我最好应该怎样调试？期待牛人的回答。谢谢。

建议把DMA相关的代码贴出来，才能知道问题出在哪？
有点记住
Call
PutScatterGatherList
GetScatterGatherList
之前要临时提升IRQL至DISPATCH_LEVEL。
另外建议用分配MDL去描述你分配的DMA data buffer。
并注意DMA Call back function里面的GatherList的页地址和长度偏移是否正确。

谢谢二楼的回答，前一个问题已经解决，是我没有处理好dma的中断处理函数导致的问题。目前又碰到了一个新的问题。问题描述如下：
MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.  This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened.  Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it.  The
first actually works, and the second fails.  Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second.  However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.
Arguments:
Arg1: 8c491a38, Address of the IRP
Arg2: 00000252
Arg3: 00000000
Arg4: 00000000

STACK_TEXT:  
b9185654 80826967 00000003 00000001 00000000 nt!RtlpBreakWithStatusInstruction
b91856a0 8082786b 00000003 80a5bf00 8cf40030 nt!KiBugCheckDebugBreak+0x19
b9185a38 80827c63 00000044 8c491a38 00000252 nt!KeBugCheck2+0x5e1
b9185a58 809b5822 00000044 8c491a38 00000252 nt!KeBugCheckEx+0x1b
b9185ad0 bacdcb30 b9185b00 b9185af8 bace9e91 nt!IovCompleteRequest+0x13e
b9185adc bace9e91 00000000 8cf40b00 00000001  KIrp::Complete+0x20
b9185af8 bacdeb74 8c491a38 8cf40000 8cf40bf0   KDriverManagedQueueCsq::NextIrp+0xf1
b9185b18 bacdf318 8c491a38 00000000 80006000 KDriverManagedQueueCsq::PnpNextIrp+0x54
b9185b34 bace102e 8c491a38 00000001 b9185b0e  SerialDeviceControl+0xb8
b9185b54 bace9d46 8c491a38 8cf40bf0 b9185b78 StartIo+0x8e
b9185b64 bacdf252 8c491a38 8cf400e8 00000000   KDriverManagedQueueCsq::QueueIrp+0x66
b9185b78 bace264e 8c491a38 ffffffff b9185bbc  DeviceControl+0x22
b9185bb0 bace0c35 8c491a38 80a5bf00 8cf40030 KPnpDevice::DeviceIrpDispatch+0x41e
b9185bc4 809b550c 8cf40030 8c491a38 8c491b0c KDriver::DriverIrpDispatch+0x55 b9185bf4 8081df33 809c560e b9185c14 809c560e nt!IovCallDriver+0x112
b9185c00 809c560e 80a5bf00 8cf3e020 00000000 nt!IofCallDriver+0x13
b9185c14 809b550c 8cf3e020 8c491a38 8c491a38 nt!ViFilterDispatchGeneric+0x2a
b9185c44 8081df33 808f5437 b9185c64 808f5437 nt!IovCallDriver+0x112
b9185c50 808f5437 8c491b14 8c32b268 8c491a38 nt!IofCallDriver+0x13
b9185c64 808f61bf 8cf3e020 8c491a38 8c32b268 nt!IopSynchronousServiceTail+0x10b
b9185d00 808eed08 00000154 00000000 00000000 nt!IopXxxControlFile+0x5e5
b9185d34 8088978c 00000154 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b9185d34 7c9585ec 00000154 00000000 00000000 nt!KiFastCallEntry+0xfc
0012ecb4 7c956fcb 7c8016f5 00000154 00000000 ntdll!KiFastSystemCallRet
0012ecb8 7c8016f5 00000154 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc
0012ed1c 100d6aa6 00000154 80006000 0012ee2c kernel32!DeviceIoControl+0x137

感觉这个蓝屏现象很难调试，在我的应用程序中会经常调用DeviceIoControl函数，出现蓝屏时也并非是第一次调用DeviceIoControl函数就发生了，而是调用了几百次甚至几千次以后才发生的，感觉这个问题很不好分析，请各位高手不吝赐教。谢谢。