KBug revision 15386

[James Tabor]

Hi,
SVB revision 15386,


(KERNEL32:mem/global.c:412) Memory Load: 18
(MSVCRT:io/open.c:103) not valid fd 0, g_fdend 5, fdinfo 7802d2f0, bucket 7802d2
f0, fdflags 0
(MSVCRT:io/open.c:700) _setmode: inval fd (0)
(io/irp.c:937) Thread with dead IRPs!Assertion FALSE failed at io/irp.c:938
Entered debugger on embedded INT3 at 0x0008:0x800058e3.
kdb:> bt
Eip:
<ntoskrnl.exe:58e4 (ke/i386/brkpoint.c:31 (DbgBreakPoint))>
Frames:
<ntoskrnl.exe:4c53c (io/irp.c:941 (IoCancelThreadIo))>
<ntoskrnl.exe:7f6b3 (ps/kill.c:308 (PspExitThread))>
<ntoskrnl.exe:7f786 (ps/kill.c:346 (PsExitSpecialApc))>
<ntoskrnl.exe:fdb7 (ke/apc.c:593 (KiDeliverApc))>
<hal.dll:3f62 (../generic/irql.c:189 (HalpLowerIrql))>
<hal.dll:3fe9 (../generic/irql.c:223 (KfLowerIrql))>
<ntoskrnl.exe:12b2f (ke/kthread.c:223 (KiBlockThread))>
<ntoskrnl.exe:17014 (ke/wait.c:336 (KeWaitForSingleObject))>
<tcpip.sys:a373 (datalink/lan.c:147 (NDISCall))>
<tcpip.sys:a3c1 (datalink/lan.c:177 (TcpipLanGetDwordOid))>
<tcpip.sys:12353 (network/interface.c:215 (GetInterfaceConnectionStatus))>
<tcpip.sys:9e27 (tcpip/iinfo.c:46 (InfoTdiQueryGetInterfaceMIB))>
<tcpip.sys:a104 (tcpip/iinfo.c:96 (InfoInterfaceTdiQueryEx))>
<tcpip.sys:9026 (tcpip/info.c:182 (InfoTdiQueryInformationEx))>
<tcpip.sys:48b5 (tcpip/dispatch.c:1320 (DispTdiQueryInformationEx))>
<tcpip.sys:77f0 (tcpip/main.c:573 (TiDispatch))>
<ntoskrnl.exe:4c5f8 (io/irp.c:1014 (IofCallDriver))>
<ntoskrnl.exe:4c570 (io/irp.c:959 (IoCallDriver))>
<ntoskrnl.exe:45c20 (io/file.c:622 (IopDeviceFsIoControl))>
<ntoskrnl.exe:46e91 (io/file.c:1655 (NtDeviceIoControlFile))>
<ntoskrnl.exe:36d2 (/tmp/ccPsw4wN.s:180 (KiSystemService))>--- Press q to abort,
  any other key to continue ---

<kernel32.dll:20b73 (file/deviceio.c:107 (DeviceIoControl))>
<iphlpapi.dll:1582 (ifenum_reactos.c:232 (tdiGetMibForIfEntity))>
<iphlpapi.dll:17e0 (ifenum_reactos.c:358 (getInterfaceInfoSet))>
<iphlpapi.dll:1ddb (ifenum_reactos.c:572 (getInterfaceIndexTableInt))>
<iphlpapi.dll:1ea8 (ifenum_reactos.c:612 (getInterfaceIndexTable))>
<iphlpapi.dll:45e6 (iphlpapi_main.c:947 (GetInterfaceInfo))>
<ipconfig.EXE:1644 (ipconfig.c:144 (ShowNetworkInterfaces))>
<ipconfig.EXE:188d (ipconfig.c:297 (main))>
<ipconfig.EXE:11e7>
<ipconfig.EXE:1238>
<kernel32.dll:289b1 (process/create.c:331 (BaseProcessStart))>
<deadbeef>
kdb:>

[Hartmut Birr]

James Tabor wrote:

>   Hi,
>  SVB revision 15386,
>  
It is the same problem like the attached mail.

- Hartmut


Subject:
Re: [ros-dev] Networking
From:
Hartmut Birr <hartmut.birr(a)gmx.de>
Date:
Tue, 10 May 2005 22:40:01 +0200
To:
ReactOS Development List <ros-dev(a)reactos.com>

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
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev

[WaxDragon]

Yes, this issue has been around since the network breakage last
weekend.  We need our fearless Art to fix it. (If he ever comes back!)
;0)

WD

On 5/17/05, Hartmut Birr <hartmut.birr(a)gmx.de> wrote:
>   James Tabor wrote:
>  
> >   Hi,
> >  SVB revision 15386,
> >  
>  It is the same problem like the attached mail.
>  
>  - Hartmut
>  
>  
>  Subject:
>  Re: [ros-dev] Networking
>  From:
>  Hartmut Birr <hartmut.birr(a)gmx.de>
>  Date:
>  Tue, 10 May 2005 22:40:01 +0200
>  To:
>  ReactOS Development List <ros-dev(a)reactos.com>
>  
>  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
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>  
>   

-- 
"<arty> the tree was touched a lot recently"