Details
-
Bug
-
Resolution: Fixed
-
Major
-
None
-
None
-
Operating System: ReactOS
Platform: x86 Hardware
URL: http://downloadcenter.intel.com/detail_desc.aspx?agr=Y&DwnldID=18719
Description
Created an attachment (id=7921)
Debug info from windbg, r56885
Assigned to Cameron on his request. To replicate this bug, a VM emulating Intel PRO/1000 card is required (VirtualBOX, VMWare) as well as XP driver for it (url provided). In 3rd stage, when prompted by new device wizard, provide the extracted driver location of XP/2003 driver. After device is installed, attempt to reboot ReactOS. Debugging information attached.
[21:24:56] <cgutman> we overwrote our own handlers
[21:25:04] <ctefa`o> we what?
[21:25:11] <cgutman> we modified the driver object
[21:25:18] <cgutman> so we overwrote our own IRP_MJ_SHUTDOWN handler
[21:25:25] <cgutman> so this is the miniport FDO
[21:25:38] <cgutman> but we blew away our major function table in NdisMRegisterDevice
[21:26:06] <cgutman> real NDIS keeps a dispatch table in the device extension
[21:26:31] <ctefa`o> but we don't?
[21:26:35] <cgutman> nope
[21:26:36] <ctefa`o> so the handlers get lost?
[21:26:42] <cgutman> yeah
[21:26:49] <ctefa`o> how do the other handlers work then?
[21:26:59] <cgutman> it was my fuckup but I'm really suprised that it actually worked
[21:27:02] <cgutman> they don't
[21:27:14] <ctefa`o> so...how does ndis use the driver?
[21:27:26] <cgutman> all those handlers are registered to NDIS
[21:27:29] <cgutman> not the driver
[21:27:48] <ctefa`o> yeah, I thought so, but how does NDIS forward the handling?
[21:27:48] <cgutman> we register NdisIShutdown, NdisIDeviceIoControl, NdisICreateClose
[21:28:05] <cgutman> it doesn't
[21:28:07] <ctefa`o> through some other NDIS-specific dispatch table?
[21:28:15] <cgutman> IRPs directed to the miniport driver are handled by NDIS
[21:28:22] <cgutman> that's why NdisMRegisterDevice exists
[22:14:55] <cgutman> we actually corrupt our own dispatch table in NdisMRegisterDevice