Uploaded image for project: 'Core ReactOS'
  1. Core ReactOS
  2. CORE-3212

Multiple problems with drivers when loading / unloading services & drivers

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • Major
    • None
    • NTCore
    • None
    • Operating System: ReactOS
      Platform: x86 Hardware

    Description

      Created an attachment (id=2795)
      Custom debugging

      Problem 1:
      Unloading kernel drivers causes a Bugcheck, CORE-2942. Theres a patch to fix it.

      Problem 2:
      Trying to stop a service fails with access denied, CORE-3185. Theres also a patch.

      Problem 3:
      Deleting a service ends up in rpcserver.c function RDeleteService. This function never deletes the service from the registry. It marks in pending, and upon reboot the os is suppose to delete it, which it doesnt.
      Cant post temporary patch due to CORE-3185 not being accepted yet.

      Problem 4:
      High count on the Kernel Object's Header, CORE-3184. Commented on the problem in the problem. Think OBJ_KERNEL_HANDLE parameter should be 0.

      Problem 5:
      Once all the previous bugs are fixed. So you wont get this far without previous patches.

      Heres what im seeing, see attached debug file, when running the program that creates a service, see follow on attachment for source code of driver and user mode program to load, this program/driver work in win2k and winxp.

      Please see attachment....

      On the second run of the program. IopLoadUnloadDriver uses an existing object that it found in the Object Directory with the function IopGetDriverObject.
      So the drivers DriverEntry never gets called (hence the missing debugging message from the driver on the second run)
      The previous call to the drivers UnLoad function in the driver deleted the SymLink and the Device. After which MmUnloadSystemImage was called to remove the driver image.
      So now an IoDeleteDevice is called from the driver with garbage. (garbage in garbage out)
      To support this,look at the DeviceObject passed to IoDeleteDevice, its 0.
      And of course line 897 for IoDeteleDevice is
      if (DeviceObject->Flags & DO_SHUTDOWN_REGISTERED)
      So soon as its touched, Crash
      So i only can conclude that the object is never deleted from the object directory. Searching the source code I cannot find
      any function call that deletes it from directory. I find it in Handle functions.
      which is never called for the driver when its unloaded.

      In my working copy its all good to go.
      I would post my patch for this but it requires modifying /ntoskrnl/io/iomgr/driver.c, which already has a patch pending for CORE-2942.
      So manually, you can manually add the following
      /* Make the object temporary */
      ObMakeTemporaryObject(DriverObject);

      /* Dereference one more time to have the object manager delete the object */
      ObDereferenceObject(DriverObject);
      to function IopUnloadDriver in /ntoskrnl/io/iomgr/driver.c, place them at the end of this function right before the return STATUS_SUCCESS; statement.

      The second part of this fix is we still need a call that will delete the object from the object directory.
      Since im not posting patches, Add the following
      /* Remove the object from the object directory */
      ObpDeleteNameCheck(Object);
      to the function ObpDeleteObject in /ntoskrnl/ob/oblife.c, place it at the end right before
      /* Now de-allocate all object members */
      ObpDeallocateObject(Object);

      Attachments

        1. driverasservicesproblem.txt
          3 kB
        2. drvsrc.zip
          31 kB
        3. FixForDriverUnloading.diff
          1 kB
        4. Steps.txt
          16 kB

        Issue Links

          Activity

            People

              fireball fireball
              bugboy bugboy
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: