Ok, I've figures it out after stepping through their assembly code.
- It assumes that the driver object path can be inferred from the driver file name. This is a 100% wrong assumption to begin with.
- When #1 fails, it crashes due to a memory management bug.
We can work around this issue by renaming our driver object to match our driver file name. Because the driver object is derived from the service name, we would have to rename our kernel service. I've already tried this workaround, and it does resolve the crash.
On a personal note, it seems to me that this A/V driver is badly coded and, in general, I would stay away from it.