Я сейчас еще раз попробовал, сейчас мне немного подругому анализ написался:
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: ff49a978, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: ffa4d4d7, address which referenced memory
Debugging Details:
WRITE_ADDRESS: ff49a978 Nonpaged pool expansion
CURRENT_IRQL: 2
FAULTING_IP:
+ffffffffffa4d4d7
ffa4d4d7 001400 add byte ptr [eax+eax],dl
DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
BUGCHECK_STR: 0xD1
PROCESS_NAME: Idle
TRAP_FRAME: 805487d4 -- (.trap ffffffff805487d4)
ErrCode = 00000002
eax=ffa4d4bc ebx=00000e20 ecx=ffb84008 edx=80da0200 esi=ffb9b8b8 edi=ffb8ef08
eip=ffa4d4d7 esp=80548848 ebp=8054887c iopl=0 nv up ei pl nz ac pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010217
ffa4d4d7 001400 add byte ptr [eax+eax],dl ds:0023:ff49a978=??
Resetting default scope
LAST_CONTROL_TRANSFER: from 804f79d7 to 80526fc8
STACK_TEXT:
80548388 804f79d7 00000003 805486e4 00000000 nt!RtlpBreakWithStatusInstruction
805483d4 804f85c4 00000003 ff49a978 ffa4d4d7 nt!KiBugCheckDebugBreak+0x19
805487b4 8053fa73 0000000a ff49a978 00000002 nt!KeBugCheck2+0x574
805487b4 ffa4d4d7 0000000a ff49a978 00000002 nt!KiTrap0E+0x233
WARNING: Frame IP not in any known module. Following frames may be wrong.
80548844 fb051c1f ffa4d4bc ffb84008 00000e20 0xffa4d4d7
8054887c f92a362d 80da0200 ffb84008 00000e20 tdifilter_testdriver!HookedClientEventReceive+0xaf [c:drvmain.c @ 160]
805488e0 f92a8e39 ffb84008 00001950 80548a00 tcpip!IndicateData+0x225
80548968 f929cef5 80dea670 2201a8c0 9bd03fa6 tcpip!TCPRcv+0x160d
805489c8 f92bae4d 00000020 80dea670 f929f076 tcpip!DeliverToUser+0x18e
80548a7c f929b922 80dea670 fa52d022 000001cc tcpip!IPRcvPacket+0x670
80548abc f929b84d 00000000 80f038f0 fa52d000 tcpip!ARPRcvIndicationNew+0x149
80548af8 fa895c9f ffb73008 00000000 fa717b40 tcpip!ARPRcvPacket+0x68
80548b4c fa71201d 00e61ed8 ffb961f0 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x1c2
80548b60 fa7121b4 ffb586a8 ffb961f0 00000001 psched!PsFlushReceiveQueue+0x15
80548b84 fa7125f9 80e017d8 00000000 ffb586a8 psched!PsEnqueueReceivePacket+0xda
80548b9c fa895d40 80e017d0 80df15d8 80df15e4 psched!ClReceiveComplete+0x13
80548bec fae05387 00e61ed8 80548e0c 00000001 NDIS!ethFilterDprIndicateReceivePacket+0x5a4
80549014 fa88bf09 80df15d8 80551d80 80551b20 vmxnet+0x2387
8054902c 80540f7d 80df1a8c 80df1a78 00000000 NDIS!ndisMDpcX+0x21
80549050 80540ef6 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
80549054 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26
STACK_COMMAND: kb
FOLLOWUP_IP:
tdifilter_testdriver!HookedClientEventReceive+af [c:drvmain.c @ 160]
fb051c1f 8945f4 mov dword ptr [ebp-0Ch],eax
FAULTING_SOURCE_CODE:
156: BytesIndicated,
157: BytesAvailable,
158: BytesTaken,
159: Tsdu,
> 160: IoRequestPacket);
161:
162: DbgPrint("tdi_sniffer
***NEXT***
n");
163:
164: return ntStatus;
165: }
SYMBOL_STACK_INDEX: 5
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: tdifilter_testdriver
IMAGE_NAME: tdifilter_testdriver.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 469d23da
SYMBOL_NAME: tdifilter_testdriver!HookedClientEventReceive+af
FAILURE_BUCKET_ID: 0xD1_W_tdifilter_testdriver!HookedClientEventReceive+af
BUCKET_ID: 0xD1_W_tdifilter_testdriver!HookedClientEventReceive+af
Followup: MachineOwner
В прошлый раз небыло раздела FAULTING_SOURCE_CODE. Т.е. я как понимаю вся загвоздка в последнем параметре IoRequestPacket который передается в оригинальную функцию??? Интересно из-за чего..