Tracking down error code 38 (driver still in memory).

On certain machines one of my drivers doesn’t unload and I get an error code 38 when I try to reload it. Unfortunately I haven’t been able to repro it on any of my machines other than my work desktop and I hate to force a crashdump on it for analysis. I could further instrument the driver but I doubt my work machine will accept its signature (or lack thereof). Does anyone know a user mode tool which would help with this? I tried sysinternals WinObj but I don’t think that will help. I suspect it’s some type of race condition or AV software which is holding onto a handle and preventing it from unloading.

To give you more details, this driver awvusbd.sys is a virtual host controller and it sends commands across a network to a remote USB hub. I suppose it is possible that a WSK object is not getting dereferenced. Anyway, I’ll persist on repro’ing it on a few other machines that I’ll need to re-image and hope I get lucky. BTW - I’ve only seen it on Windows 10 (1607).

There are two types of dangling references.

  1. your driver leaves a dangling reference on a dependency outside of your driver (file handle, reg handle, etc).
  2. an Ob reference on your driver (either on the device or driver object)

Type 1 will not prevent your driver from unloading and reloading propertly. In this case, you are “just” leaking memory and potentially causing the components with the dangling references from unloading.

Type 2 will prevent your driver image from successfully unloading. Even when this type of dangling reference happens, pnp device and DriverUnload will succeed. So you need to dig into mismatched ObRef/Deref calls to figure out where the ref is coming from. You can turn on ob ref tracking to help your debugging if you have a semi consistent repro.

Note that an outstanding file handle reference on your device object will prevent a pnp remove and not put you into a code 38 state.