阅读:1848回复:6
大牛帮我看下尸体,感觉也死得太神奇了
NTSTATUS
UsbmonIoControl( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp ) { PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation(Irp); ULONG functionCode, inputLength; functionCode = irpSp->Parameters.DeviceIoControl.IoControlCode; inputLength = irpSp->Parameters.DeviceIoControl.InputBufferLength; switch (functionCode) { case IOCTL_REG_APPLICATION: if (inputLength == sizeof(REG_APP_INTERFACE)) { KdPrint(("UsbmonIoControl IOCTL_REG_APPLICATION\n")); // //注意更改密钥可能导致数据损坏[写],务必在USB拔出状态下进行 // memcpy(&Globals.App, Irp->AssociatedIrp.SystemBuffer, sizeof(REG_APP_INTERFACE)); } break; case IOCTL_USB_REMOVE_DONE: KeSetEvent(&Globals.UsbRemoveDoneEvent, IO_NO_INCREMENT, TRUE); KdPrint(("UsbmonIoControl IOCTL_USB_REMOVE_DONE\n")); break; } //完成IRP Irp->IoStatus.Status = STATUS_SUCCESS; Irp->IoStatus.Information = 0; IoCompleteRequest(Irp, IO_NO_INCREMENT); return STATUS_SUCCESS; } WINDBG -DMP 分析 MODULE_NAME: usbmon FAULTING_MODULE: 804d8000 nt DEBUG_FLR_IMAGE_TIMESTAMP: 48ff2a03 WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart unable to get nt!MmSpecialPoolEnd unable to get nt!MmPoolCodeStart unable to get nt!MmPoolCodeEnd 0000ffdf CURRENT_IRQL: 1c FAULTING_IP: nt+68d09 80540d09 8908 mov dword ptr [eax],ecx CUSTOMER_CRASH_COUNT: 6 DEFAULT_BUCKET_ID: WRONG_SYMBOLS BUGCHECK_STR: 0xA LAST_CONTROL_TRANSFER: from 804f270c to 80540d09 STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. a8a60bac 804f270c 862503d0 861d23b0 00000000 nt+0x68d09 a8a60be0 a8ecd227 80000018 86250400 00000004 nt+0x1a70c a8a60bf8 804f00b5 8631a828 86250390 806e5410 usbmon!UsbmonIoControl+0xa7 [g:\usb\usbmon.c @ 225] a8a60c1c 8058056d 8631a828 86250390 861d23b0 nt+0x180b5 a8a60cb8 805790c2 0000006c 00000000 00000000 nt+0xa856d a8a60cec a9fc75d8 0000006c 00000000 00000000 nt+0xa10c2 a8a60d34 8054188c 0000006c 00000000 00000000 klif+0x105d8 a8a60d64 7c92eb94 badb0d00 0012fb44 a8a60d98 nt+0x6988c a8a60d68 badb0d00 0012fb44 a8a60d98 a8a60dcc 0x7c92eb94 a8a60d6c 0012fb44 a8a60d98 a8a60dcc 00000000 0xbadb0d00 a8a60d70 a8a60d98 a8a60dcc 00000000 00000000 0x12fb44 a8a60d74 a8a60dcc 00000000 00000000 00000000 0xa8a60d98 a8a60d98 00000000 7c92eb94 0012fd3c 00000102 0xa8a60dcc STACK_COMMAND: kb FOLLOWUP_IP: usbmon!UsbmonIoControl+a7 [g:\usb\usbmon.c @ 225] a8ecd227 ?? ??? FAULTING_SOURCE_CODE: 221: Irp->IoStatus.Status = STATUS_SUCCESS; 222: Irp->IoStatus.Information = 0; 223: IoCompleteRequest(Irp, IO_NO_INCREMENT); 224: > 225: return STATUS_SUCCESS; 226: } 227: 228: NTSTATUS 229: HookPnpDevice( 230: IN HANDLE OrgFunction, SYMBOL_STACK_INDEX: 2 FOLLOWUP_NAME: MachineOwner IMAGE_NAME: usbmon.sys SYMBOL_NAME: usbmon!UsbmonIoControl+a7 BUCKET_ID: WRONG_SYMBOLS Followup: MachineOwner --------- |
|
沙发#
发布于:2008-10-22 22:29
很多时候死的凄惨的诡异问题都很诡异~~
比如pool死亡,随机驱动随机位置... |
|
|
板凳#
发布于:2008-10-23 13:57
应该是崩在IoCompleteRequest里了,关键在于你对IRP做了哪些修改,提供的信息太少了,嘿嘿......
|
|
|
地板#
发布于:2008-12-29 20:15
看起来像是内存写越界造成了的。
比如,你分配了10个字节的一个BUFFER, 却写了11个字节的数据, 就会出这个问题。 |
|
|
地下室#
发布于:2008-12-30 23:31
你的set event的最后一个参数?
If the Wait parameter is TRUE, the return to the caller is executed without lowering IRQL or releasing the dispatcher database spin lock. Therefore, the call to KeSetEvent must be followed immediately by a call to a KeWaitXxx routine. This allows the caller to set an event and wait as one atomic operation, preventing a possibly superfluous context switch. Note that if the caller is executing at IRQL = DISPATCH_LEVEL or in an arbitrary thread context, the Timeout parameter to KeWaitXxx must be zero. If Wait is set to FALSE, the caller can be running at IRQL <= DISPATCH_LEVEL. Otherwise, callers of KeSetEvent must be running at IRQL <= APC_LEVEL and in a nonarbitrary thread context. 你要是填true的话 你就没有释放dispatch spinlock |
|
5楼#
发布于:2009-01-02 11:06
谢谢tiamo!!!你真是神 就是这个原因
不过你要早点提示我该多好啊,害我搞了好久才搞定的,丫的回帖也太TMD的老了吧 |
|
6楼#
发布于:2009-01-02 21:11
怪我
你发贴的时候没看到 或者看到了没点进来 这次被顶上来浮到上面 才看到才点进来.... 哈哈 |
|