Hi, Here is some networking dumps, I have a rtl8029 with io D000 and irq B,
(dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 ne2000!NICIndicatePacket: Indicating (64) bytes. (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (io/irp.c:877) Thread with dead IRPs!Assertion FALSE failed at io/irp.c:878 Entered debugger on embedded INT3 at 0x0008:0x800058e3. kdb:> bt Eip: <ntoskrnl.exe:58e4 (ke/i386/brkpoint.c:31 (DbgBreakPoint))> Frames: <ntoskrnl.exe:4c63e (io/irp.c:881 (IoCancelThreadIo))> <ntoskrnl.exe:7f603 (ps/kill.c:308 (PspExitThread))> <ntoskrnl.exe:7f9ca (ps/kill.c:500 (NtTerminateProcess))> <ntoskrnl.exe:36d2 (/tmp/cctdxNWF.s:180 (KiSystemService))> <kernel32.dll:27e20 (process/proc.c:593 (ExitProcess))> ping.EXE:11f6 ping.EXE:1238 <kernel32.dll:289b1 (process/create.c:331 (BaseProcessStart))> <deadbeef> kdb:> cont ne2000!NICIndicatePacket: Indicating (142) bytes. ne2000!NICIndicatePacket: Indicating (142) bytes. LAN WORKER BUSY 9e3e0390 80e10c18 ne2000!NICIndicatePacket: Indicating (142) bytes. LAN WORKER BUSY 9e3e0390 80e12738 ne2000!NICIndicatePacket: Indicating (142) bytes. LAN WORKER BUSY 9e3e0390 80e187f8 ne2000!NICIndicatePacket: Indicating (64) bytes. LAN WORKER BUSY 9e3e0390 80e1ecb8 ne2000!NICIndicatePacket: Indicating (64) bytes. LAN WORKER BUSY 9e3e0390 80e2cd28 ne2000!NICIndicatePacket: Indicating (142) bytes. LAN WORKER BUSY 9e3e0390 80e73c80 ne2000!NICIndicatePacket: Indicating (142) bytes. LAN WORKER BUSY 9e3e0390 80ef4b30 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0 (io/irp.c:877) Thread with dead IRPs!Assertion FALSE failed at io/irp.c:878 Entered debugger on embedded INT3 at 0x0008:0x800058e3. kdb:> bt Eip: <ntoskrnl.exe:58e4 (ke/i386/brkpoint.c:31 (DbgBreakPoint))> Frames: <ntoskrnl.exe:4c63e (io/irp.c:881 (IoCancelThreadIo))> <ntoskrnl.exe:7f603 (ps/kill.c:308 (PspExitThread))> <ntoskrnl.exe:7f9ca (ps/kill.c:500 (NtTerminateProcess))> <ntoskrnl.exe:36d2 (/tmp/cctdxNWF.s:180 (KiSystemService))> <kernel32.dll:27e20 (process/proc.c:593 (ExitProcess))> ping.EXE:11f6 ping.EXE:1238 <kernel32.dll:289b1 (process/create.c:331 (BaseProcessStart))> <deadbeef> kdb:> cont ne2000!NICIndicatePacket: Indicating (64) bytes. (dispatch.c:166)(dispatch) Select: 0 ne2000!NICIndicatePacket: Indicating (142) bytes. ne2000!NICIndicatePacket: Indicating (142) bytes. LAN WORKER BUSY 9e3e0390 812618f8 (dispatch.c:166)(dispatch) Select: 0 (dispatch.c:166)(dispatch) Select: 0
You are very likely seeing the same problems I am. If you have tcpip debugging on, you may see messages like this:
(tcpip/main.c:559)(TiDispatch) Called. IRP is at (0x809189A8). (tcpip/main.c:575)(TiDispatch) TCP_QUERY_INFORMATION_EX (tcpip/dispatch.c:1248)(DispTdiQueryInformationEx) Called. (tcpip/dispatch.c:1351)(DispTdiQueryInformationEx) InputBufferLength 36 OutputBufferLength 0 (tcpip/info.c:143)(InfoTdiQueryInformationEx) InfoEx Req: 100 100 0!0000:0 (tcpip/info.c:84)(InfoTdiQueryListEntities) About to copy 3 TDIEntityIDs to user (tcpip/info.c:186)(InfoTdiQueryInformationEx) Status: c0000023 (tcpip/dispatch.c:1396)(DispTdiQueryInformationEx) Leaving. Status = (0xC0000023) (tcpip/dispatch.c:1399)(DispTdiQueryInformationEx) Leaving. Status = (0xC0000023) (tcpip/main.c:602)(TiDispatch) Leaving. Status = (0xC0000023). (tcpip/irp.c:21)(IRPFinish) Called: Irp 809189a8, Status c0000023 Event 80b9cdac
On 5/9/05, James Tabor jimtabor@adsl-64-217-116-74.dsl.hstntx.swbell.net wrote:
Hi, Here is some networking dumps, I have a rtl8029 with io D000 and irq B,
<snip>
I've emailed arty the details of what I have already. c0000023 is STATUS_BUFFER_TOO_SMALL.
WD
Hi WD! WaxDragon wrote:
You are very likely seeing the same problems I am. If you have tcpip debugging on, you may see messages like this:
Wow, its funny, ping.exe both of them still resident in memory. I executed them minutes before the kernel debugs. Strange stuff!?! 8^o dazed and in awe, wow can you see the nice colors! James
James Tabor wrote:
Hi WD! WaxDragon wrote:
You are very likely seeing the same problems I am. If you have tcpip debugging on, you may see messages like this:
Wow, its funny, ping.exe both of them still resident in memory. I executed them minutes before the kernel debugs. Strange stuff!?! 8^o dazed and in awe, wow can you see the nice colors! James
That's a result of rev 15069. If a irp is created by IoBuildDeviceIoControlRequest or IoBuildSynchronousFsdRequest, it must be always completed by IoCompleteRequest. The changes from rev. 15069 bypass a part of IoCompleteRequest if the irp was canceled. The irp is still on the threads irp list. A terminated threads waits some time for completion of all irps on the thread list. If not all irps are removed, ros does bucheck. While the waiting time, you can see ping in memory.
- Hartmut
WaxDragon wrote:
I've emailed arty the details of what I have already. c0000023 is STATUS_BUFFER_TOO_SMALL.
WD
Art and I have found the problem. Art was failing the IRP with STATUS_BUFFER_TOOS_AMALL and expecting the I/O Manager to fill in UserIosb->Information, so that the usermode application could then request the correct number of bytes. Since this does not happen on NT/ROS (the source of much heated discussion :P), it fails after my patches. After some analysis of 3rd-party drivers and some reading, the solutions are either:
1) return STATUS_BUFFER_OVERFLOW which is a 'warning', so the IO manager will write the stuff back. But this would break compatibility with apsp which use TDI directly to query this information 2) do like I have seen other 3rd-part drivers do, which is to wrap in SEH somethign along: *Irp->UserIosb = Irp->IoStatus; and then return STATUS_BUFFER_OVERFLOW. After testing, I can confirm method #2...Art will be fixing this.
I want to mention this in case anyone is aware of any other of our drivers which does this trick and hopes the I/O manager will return the UserIosb (it did befor emy changes). I'll grep the tree for any STATUS_BUFFER_OVERFLOW in /drivers myself.
Best regards, Alex Ionescu
Alex Ionescu wrote:
WaxDragon wrote:
- do like I have seen other 3rd-part drivers do, which is to wrap in
SEH somethign along: *Irp->UserIosb = Irp->IoStatus; and then return STATUS_BUFFER_OVERFLOW.
My bad, this shoudl be STATUS_BUFFER_TOO_SMALL.
After testing, I can confirm method #2...Art will be fixing this.
Best regards, Alex Ionescu
-
Alex Ionescu -
Hartmut Birr -
James Tabor -
WaxDragon