-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
USB redirection stuck #105
Comments
Just ran into this issue. Does the PR require more work? |
Facing the same issue. It's quite often need to force terminate the process in the development process, since then, StartRedirect() will never succeed again unless reboot the system. |
gwgill
added a commit
to gwgill/UsbDk
that referenced
this issue
Nov 10, 2023
…ving D0 power setting code, daynix#103 by adding more USB3 hub idetifiers, daynix#105 with counting fixes from kvojacheck. Hopefully fixed remaining daynix#124 issues by adding device configuration and hub port reset before attempting port CYCLE for devices with no function driver. Cleaned up no-function driver devices handling so that the RawFilter doesn't affect devices mis-classified on first plugin, as well as ensuring function driver install proceeds correctly after device has been used without a function driver.
gwgill
added a commit
to gwgill/UsbDk
that referenced
this issue
Nov 10, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If a client application which is holding an open handle to a redirected USB port is force-terminated by an external program (e.g. task manager), the redirected port becomes unresponsive, and cannot be used until system reboot.
Since UsbDk can receive device open/close requests from multiple processes concurrently, it tries to close the USB redirection only if the close was requested by the same process that started the redirection.
The problem is that the WDF file close callback is not guaranteed to be called from the same process that is opened the file handle, but from an arbitrary process context (see reference here), though in practice, it seems to be mostly called from the initiator process, making it difficult to trigger this bug.
One solution could be switching from
PsGetCurrentProcessId()
toWdfFileObjectGetInitiatorProcessId()
, which seems to return the expected PID in all cases. Unfortunately, this method is not available until KMDF 1.21, meaning that UsbDk wouldn't work on versions of Windows earlier than Windows 10, version 1703.Therefore, to keep compatibility, I would suggest adding a reference count to the device, so it could be ensured that the redirection is removed when the last reference is closed. This would improve the current situation without known functionality/compatibility losses.
The text was updated successfully, but these errors were encountered: