昨天写一个简单的驱动，驱动的write例程会将IRP挂起放进自定义的队列中，然后在另一个线程中取消这些挂起的IRP：
NTSTATUS SampleCharWriteAsync(PDEVICE_OBJECT devObj, PIRP irp)
{
KIRQL oldIrql;
SampleCharDevContext* devCtx = (SampleCharDevContext*)devObj->DeviceExtension;
IoMarkIrpPending(irp);
KeAcquireSpinLock(&devCtx->devWriteLock, &oldIrql);
IoSetCancelRoutine(irp, SampleCharCancelIrp);
if (irp->Cancel == TRUE)
{
if (IoSetCancelRoutine(irp, NULL) != NULL)
{
irp->IoStatus.Status = STATUS_CANCELLED;
irp->IoStatus.Information = 0;
IoCompleteRequest(irp, IO_NO_INCREMENT);
KeReleaseSpinLock(&devCtx->devWriteLock, oldIrql);
//return STATUS_PENDING;
return STATUS_CANCELLED; //返回STATUS_CANCELLED后会蓝屏
}
}
InsertTailList(&devCtx->pendWrListHead, &irp->Tail.Overlay.ListEntry);
KeReleaseSpinLock(&devCtx->devWriteLock, oldIrql);
return STATUS_PENDING;
}kd> kb
ChildEBP RetAddr Args to Child
8cccac34 82a814bc 851d06e8 868473f8 868473f8 SampleChar!SampleCharWriteAsync+0x3a [c:\studio\samplechar0x44\samplechar\samplechar.c @ 243]
WARNING: Stack unwind information not available. Following frames may be wrong.
8cccac4c 82c82eee 86916038 868473f8 8684748c nt!IofCallDriver+0x64
8cccac6c 82c837a2 851d06e8 86916038 00000001 nt!RtlRandomEx+0x1340
8cccad08 82a8842a 851d06e8 0000008c 00000000 nt!NtWriteFile+0x6ee
kd> ?? irp
struct _IRP * 0x868473f8
+0x024 Cancel : 0 ''
kd> eb 0x868473f8+0x024 1
kd> ?? irp
struct _IRP * 0x868473f8
+0x024 Cancel : 0x1 ''
kd> !analyze -v
REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 84feb378, Object type of the object whose reference count is being lowered
Arg2: 86c76a08, Object whose reference count is being lowered
...
Debugging Details:
------------------
IRP_ADDRESS: 00129450
LAST_CONTROL_TRANSFER: from 82b24e71 to 82ab3394
STACK_TEXT:
...
a49c1bec 82ab0ed0 86c76a08 82aea363 612ca77a nt!ObfDereferenceObjectWithTag+0x4b
a49c1bf4 82aea363 612ca77a 87086f80 87129450 nt!ObfDereferenceObject+0xd
a49c1c38 82c85f36 00129490 a49c1c64 00000000 nt!IopCompleteRequest+0x24d
a49c1c6c 82c867a2 c0000120 87086f80 00000001 nt!IopSynchronousServiceTail+0x240
a49c1d08 82a8b42a 86312b98 0000008c 00000000 nt!NtWriteFile+0x6e8
a49c1d08 773464f4 86312b98 0000008c 00000000 nt!KiFastCallEntry+0x12a
00f6d5dc 77345ebc 756b90e3 00000080 0000008c ntdll!KiFastSystemCallRet
00f6d5e0 756b90e3 00000080 0000008c 00000000 ntdll!ZwWriteFile+0xc
00f6d644 7708121a 00000080 00f6e778 0000000b KERNELBASE!WriteFile+0xaa
00f6d660 01138af4 00000080 00f6e778 0000000b kernel32!WriteFileImplementation+0x76
...
Debugging Details:
------------------
IRP_ADDRESS: 00129450 <----失败时的IRP地址
kd> !irp 00129450
00129450: Could not read IrpNtWriteFile对写请求做了一系列检测处理，然后调用IopSynchronousServiceTail由这个函数调用IoCallDriver向设备栈发送IRP请求:
status = IoCallDriver( DeviceObject, Irp );
if (DeferredIoCompletion) {
if (status != STATUS_PENDING) {
PKNORMAL_ROUTINE normalRoutine;
PVOID normalContext;
KIRQL irql = PASSIVE_LEVEL; // Just to shut up the compiler
ASSERT( !Irp->PendingReturned );
if (!SynchronousIo) {
KeRaiseIrql( APC_LEVEL, &irql );
}
IopCompleteRequest( &Irp->Tail.Apc,
&normalRoutine,
&normalContext,
(PVOID *) &FileObject,
&normalContext );
根据堆栈回溯，出错时内核已经执行过IoCallDriver，并进入了IopCompleteRequest函数开始完成IRP请求。其实到这问题已经呼之欲出了：同一个IRP在我的驱动中已经调用过IopCompleteRequest；当驱动返回时，IO管理器试图再次操作IRP，因此出错了(在调试过程中，Windbg直接提示BugCheck Code 0x44----多次释放同一个IRP)。而导致内核调用IopCompleteRequest完成IRP的原因是status!=STATUS_PENDING----我在驱动中返回了STATUS_CANCEL。啊，果然手贱在驱动的派遣函数中写错了返回值：只要Irp没有同步完成，派遣函数的返回值就必须是STATUS_PENDING。
虽然问题已经定位，但另外还有一些比较重要的信息，可以用作这次分析的佐证----确认蓝屏确实发生在我的驱动中：
根据蓝屏前函数调用栈frame 06显示:
06 a49c1c38 82c85f36 00129490 a49c1c64 00000000 nt!IopCompleteRequest+0x24dIoCompleteRequest的第一个参数的值是0x00129490，这和!analyze -v输出的蓝屏时IRP的地址0x129450比较接近，不排除两者之间有关联。查看IRP的结构：
kd> dt ntkrpamp!_IRP
+0x000 Type : Int2B
+0x002 Size : Uint2B
+0x004 MdlAddress : Ptr32 _MDL
...
+0x02c UserEvent : Ptr32 _KEVENT
+0x030 Overlay : <unnamed-tag>
+0x038 CancelRoutine : Ptr32 void
+0x03c UserBuffer : Ptr32 Void
+0x040 Tail : <unnamed-tag>
windbg的帮助文档提到BugCheck 0x18的第2个参数代表了被错误解引用的对象，这里是0x86c76a08。查看这个对象的信息：
kd> !object 86c76a08 9
Object: 86c76a08 Type: (84feb378) Event
ObjectHeader: 86c769f0 (new version)
HandleCount: 1 PointerCount: 0
kd> !findhandle 86c76a08
Now checking process 84fcea20...Now checking process 863764c0...
[86ecb030 onlyForWrite.e] #<--------句柄86c7a08的属主进程：0x86ecb030
8c: Entry a5320118 Granted Access 1f0003
kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
...
PROCESS 88892d40 SessionId: 1 Cid: 0dfc Peb: 7ffdb000 ParentCid: 01ac
DirBase: 7eb7a440 ObjectTable: a52b8c30 HandleCount: 52.
Image: conhost.exe
PROCESS 86ecb030 SessionId: 1 Cid: 0e50 Peb: 7ffdc000 ParentCid: 0df4
DirBase: 7eb7a3a0 ObjectTable: 98258ec8 HandleCount: 50.
Image: onlyForWrite.exe
最后，我想确定这个Event是不是onlyForWrite调用WriteFile时传入的OVERLAPD!Event句柄：
OVERLAPPED overlapRd = { 0 },overlapWr = {0};
overlapRd.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
overlapWr.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
char writeBuff[4096] = { "_ThreadProc" }, readBuff[4096] = { 0 };
DWORD len = 0, writeLen, readLen;
while (1)
{
WriteFile(hDev, writeBuff, strlen(writeBuff), &writeLen, &overlapWr); //调用WriteFile时传入overlapWr!hEvent事件句柄
//WaitForSingleObject(overlapWr.hEvent, INFINITE);
Sleep(1000);
}NTSTATUS ZwWriteFile(
_In_ HANDLE FileHandle,
_In_opt_ HANDLE Event,
_In_opt_ PIO_APC_ROUTINE ApcRoutine,
_In_opt_ PVOID ApcContext,
_Out_ PIO_STATUS_BLOCK IoStatusBlock,
_In_ PVOID Buffer,
_In_ ULONG Length,
_In_opt_ PLARGE_INTEGER ByteOffset,
_In_opt_ PULONG Key
);
Parameters
Event [in, optional]
Optionally, a handle to an event object to set to the signaled state after the write operation completes. Device and intermediate drivers should set this parameter to NULL.0a 00f6d5dc 77345ebc 756b90e3 00000080 0000008c ntdll!KiFastSystemCallRet
0b 00f6d5e0 756b90e3 00000080 0000008c 00000000 ntdll!ZwWriteFile+0xc
0c 00f6d644 7708121a 00000080 00f6e778 0000000b KERNELBASE!WriteFile+0xaa
kd> .process 86ecb030
Implicit process is now 86ecb030
WARNING: .cache forcedecodeuser is not enabled
kd> !handle 0000008c
PROCESS 86ecb030 SessionId: 1 Cid: 0e50 Peb: 7ffdc000 ParentCid: 0df4
DirBase: 7eb7a3a0 ObjectTable: 98258ec8 HandleCount: 50.
Image: onlyForWrite.exe
Handle table at 98258ec8 with 50 entries in use
008c:<-左边是句柄值，右边是内核对象-> Object: 86c76a08 GrantedAccess: 001f0003 Entry: a5320118
Object: 86c76a08 Type: (84feb378) Event
ObjectHeader: 86c769f0 (new version)
HandleCount: 1 PointerCount: 0
扫一扫
2436
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
