[NTOSKRNL]
- Fix the unload path
- This does expose some bugs: 2 cont-able assertions in ARM3 after
unplugging a USB storage device (during usbstor unload), HID unload doesn't
seem to work correctly (somebody still has references to the devices), other
issues may pop up too
I've tracked this issue down to using loader heap to allocate the LDR data
entry (which gets freed by the kernel during init). This makes it invalid
when we go to read the module object when we unload it, causing a crash. I'm
not sure how to move forward from here but the changes needed are in
FreeLoader's peloader.c. After fixing that, I'm running into another issue
where it appears that LdrEntry->LoadedImports is no longer valid (set for
boot drivers during kernel init) so it results in a null pointer
dereference. I've confirmed that this crash only occurs when boot loaded
drivers are unloaded; any other PnP driver loaded after boot unloads
perfectly.
Richard (or someone else knowledgeable in the area), if you could take a few
minutes to figure this out for me that would be fantastic.
Here is the log and backtrace after I fixed the LDR data entry allocation
type:
(C:\Users\Cam\reactos\trunk\ntoskrnl\io\iomgr\device.c:447) Unloading driver
'\Driver\usbstor' (automatic)
(C:\Users\Cam\reactos\trunk\ntoskrnl\io\iomgr\driver.c:61) Deleting driver
object '\Driver\usbstor'
(C:\Users\Cam\reactos\trunk\ntoskrnl\mm\ARM3\sysldr.c:935) Leaking driver:
usbstor.sys
Entered debugger on first-chance exception (Exception Code: 0xc0000005)
(Page Fault)
Memory at 0x00000000 could not be read: Page not present.
kdb:> bt
Eip:
<NTOSKRNL.EXE:b0c71 (ReactOS/ntoskrnl/mm/ARM3/sysldr.c:389
(MiDereferenceImports@4))>
Frames:
<NTOSKRNL.EXE:b0a7f (ReactOS/ntoskrnl/mm/ARM3/sysldr.c:947
(MmUnloadSystemImage@4))>
<NTOSKRNL.EXE:5ce2c (ReactOS/ntoskrnl/io/iomgr/driver.c:80
(IopDeleteDriver@4))>
<NTOSKRNL.EXE:d63f5 (ReactOS/ntoskrnl/ob/oblife.c:211 (ObpDeleteObject@8))>
<NTOSKRNL.EXE:da790 (ReactOS/ntoskrnl/ob/obref.c:237
(@ObfDereferenceObject@4))>
<NTOSKRNL.EXE:59c24 (ReactOS/ntoskrnl/io/iomgr/device.c:61
(IopDeleteDevice@4))>
<NTOSKRNL.EXE:d63f5 (ReactOS/ntoskrnl/ob/oblife.c:211 (ObpDeleteObject@8))>
<NTOSKRNL.EXE:da790 (ReactOS/ntoskrnl/ob/obref.c:237
(@ObfDereferenceObject@4))>
<NTOSKRNL.EXE:73adc (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:1286
(IopSynchronousCall@12))>
<NTOSKRNL.EXE:73b23 (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:585
(IopSendRemoveDevice@4))>
<NTOSKRNL.EXE:7532a (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:2214
(IopEnumerateDevice))>
<NTOSKRNL.EXE:7550c (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:4672
(IoSynchronousInvalidateDeviceRelations@8))>
<NTOSKRNL.EXE:75530 (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:889
(IopAsynchronousInvalidateDeviceRelations@8))>
<NTOSKRNL.EXE:6a737 (ReactOS/ntoskrnl/io/iomgr/iowork.c:27
(IopWorkItemCallback@4))>
<NTOSKRNL.EXE:42056 (ReactOS/ntoskrnl/ex/work.c:162
(ExpWorkerThreadEntryPoint@4))>
<NTOSKRNL.EXE:efaca (ReactOS/ntoskrnl/ps/thread.c:156
(PspSystemThreadStartup@8))>
<NTOSKRNL.EXE:100d63 (ReactOS/ntoskrnl/ke/i386/thrdini.c:78
(KiThreadStartup@0))>
<NTOSKRNL.EXE:efa66 (ReactOS/ntoskrnl/ps/thread.c:625
(PsCreateSystemThread@28))>
Regards,
Cameron
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
