Re: [ros-dev] [ros-diffs] [cgutman] 56069: [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...

[Cameron Gutman]

[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