Is there a way to check which call cause the app blocked?

NTDEV
1

Hi
I am now debuging my virtual camera driver, once the application(zoom for example) opens the cam, it can not close
I mean I can not terminate the process, I guess it maybe blocked on some calls(ioctl ?)
Is there any means I can check which call lead to this?
It’s a virtual usb driver by the way
Thanks in advance

2

An application cannot close if you are still holding I/O requests. That’s almost always the cause.

Is it a virtual camera driver or a virtual USB driver? Are you dealing with AVStream calls, or are you receiving URBs from above? What drivers are above and below you?

3

Hi Tim
Thanks for your help

It’s a virtual usb driver and I am dealing with URBs, I am doing it follow the instructions below:
https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/writing-a-ude-client-driver

4

Well, thread termination is handled as a UM APC. Therefore, a thread cannot get terminated until it is about to return control to the userland.

Now consider what happens if your driver’s IOCTL handler enters a non-alertable wait or tries to wait at APC_LEVEL. In this case it is going to be impossible to terminate the calling thread until the wait condition gets satisfied. Therefore, if your driver’s IOCTL handler enters a non-alertable wait without a timeout on some event that never gets signaled, the calling thread is just bound to remain blocked for good.

An attempt to recursively lock a FAST_MUTEX (which inevitably leads to deadlocking the calling thread,of course) may be another possibility.
Once the calling thread is bound to infinitely spin at IRQL==APC_LEVEL, no APCs will be ever delivered to it, and hence,
it is doomed to the “eternal fife” (albeit a pretty boring one).

In any case, there is very obviously a bug in your driver…

Is there any means I can check which call lead to this?

This is what you have a debugger for…

Anton Bassov

5

It’s a virtual usb driver and I am dealing with URBs, I am doing it follow the instructions below

Why would you do that? What’s the point? It takes a hell of a lot of work to emulate a UVC device, and I frankly don’t see the benefit. UDE is a good solution if you’re writing a driver for a product that doesn’t exist yet, but if you’re doing a camera, then presumably you’re doing UVC and the driver already exists.

6

Hi Tim
Yes it’s a UVC device and I am using UDE
It seems there is something wrong when I complete the ISO transfer
From this link: https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/writing-a-ude-client-driver
It states:
If the URB was added to an endpoint’s queue and the driver starts processing it synchronously on the calling driver’s thread or DPC, the request must not be completed synchronously. A separate DPC is required for that purpose, which the driver queue by calling WdfDpcEnqueue
When I try to call **UdecxUrbCompleteWithNtStatus **from the dpc callback, the app will blcok,
When I use WdfRequestComplete, the app can close but seems no video data is transfered to app through URB

_VOID DpcCompleteUrb(IN WDFDPC Dpc){
	PIO_CONTEXT ioContext = WdfDeviceGetIoContext(WdfDpcGetParentObject(Dpc));
	//UdecxUrbCompleteWithNtStatus(ioContext->currentRequest, ioContext->status);
	WdfRequestComplete(ioContext->currentRequest, ioContext->status);
}_

Is there any sample code on how to complete the I/O for the UDE? I checked USBsample code but doesn’t help much
Thanks in advance

7

Yes it’s a UVC device and I am using UDE

But why? What could you possibly gain by going through this painful exercise?

I have no experience with UDE, so i don’t know the subtleties. I can’t imagine why this would make a difference.

I’m concerned by the WdfDeviceGetIoContext(WdfDpcGetParentObject(Dpc)). Is the parent object your WDFDEVICE? Are you only able to handle one request at a time? And if WdfDeviceGetIoContext is your function to fetch your context, then you shouldn’t start it with Wdf. It’s too confusing.

8

But why? What could you possibly gain by going through this painful exercise?

I need to support NDI camera through zoom, also need to support ptz feature, so I guess the only way is to create a uvc device so
zoom can control the cam through ptz command ,correct me if I am wrong

As for my driver, I just found that for iso transfer, the host controler send a lot of iso in request, more than hundred of packts per milli second
From what I have learned, the interval is supposed to be 1 milli second to a a full speed usb device, am I right?
I also checked the descriptors and even compared with a real device, no clue has been found so far
I think this maybe the root cause of the issue(can not complete the I/O request thus can not close the app)

9

… correct me if I’m wrong …

Of course you’re wrong! I cannot imagine the line of thinking that led to this solution. When you have a camera, you write a camera driver. You don’t simulate a USB device! That’s just insane. Windows already has support built-in for ONVIF cameras, no driver required. If nothing else, a simple user-mode DirectShow capture filter could have done it.

The host controller will send one IN token per interval. If it is a full-speed device, then the interval is measured in millisecond frames. However, God only knows what the simulated host controller does. I don’t know how accurately they try to simulate the real device. You’re sure your descriptors are USB 2.0, and that you are advertising full-speed support?

10

@lugang said:
Hi Tim
Yes it’s a UVC device and I am using UDE
It seems there is something wrong when I complete the ISO transfer
From this link: https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/writing-a-ude-client-driver
It states:
If the URB was added to an endpoint’s queue and the driver starts processing it synchronously on the calling driver’s thread or DPC, the request must not be completed synchronously. A separate DPC is required for that purpose, which the driver queue by calling WdfDpcEnqueue
When I try to call **UdecxUrbCompleteWithNtStatus **from the dpc callback, the app will blcok,
When I use WdfRequestComplete, the app can close but seems no video data is transfered to app through URB

_VOID DpcCompleteUrb(IN WDFDPC Dpc){
	PIO_CONTEXT ioContext = WdfDeviceGetIoContext(WdfDpcGetParentObject(Dpc));
	//UdecxUrbCompleteWithNtStatus(ioContext->currentRequest, ioContext->status);
	WdfRequestComplete(ioContext->currentRequest, ioContext->status);
}_

Is there any sample code on how to complete the I/O for the UDE? I checked USBsample code but doesn’t help much
Thanks in advance

Go you got any clue?
when I tried , UdecxUrbCompleteWithNtStatus data is transfered. but when I try to complete using WdfRequestCompleteWithPriorityBoost data is not transferred, I want to utilize prority boost. I tried to replace with WdfRequestCompleteWithInformation and also WdfRequestSetInformation followed by WdfRequestComplete nothing is working out only UdecxUrbCompleteWithNtStatus is working.

11

@lugang said:
Hi Tim
Thanks for your help

It’s a virtual usb driver and I am dealing with URBs, I am doing it follow the instructions below:
https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/writing-a-ude-client-driver

Umm … no. You’re going entirely down the wrong pathway with a UDE device; as the documentation describes, it’s to make a virtual UBS host controller which isn’t want you want; you are writing a driver for an NDI camera, which is an entirely different animal than a UVC camera (or even a USB device in general) [ https://support.panopto.com/s/article/NDI-Support ] … the key difference being that in a traditional USB device the “source” is some hardware attached to the USB PCIe root complex; in an NDI camera the “source” is a TCP stream from somewhere … and please correct me if I’m completely in the weeds here!

The reason why this is important is understanding the data flow; in a traditional UVC camera there is an isoch endpoint “source” that the device exposes for a USB driver to attach to, the USB driver tells the device to start sending and you start getting URB’s with data from the USB stack. In an NDI camera the “source” is a TCP socket to the source, which has nothing to do with URB’s or even the USB stack.

When you are looking at your device, sitting on your desk, how does it physically attach to the computer; through a USB port or through an ethernet port? Is it a single complete unit (lenses and such with a short USB or ethernet cable) or is the thing with the lenses unattached tot he computer but there is a “dongle” that plugs into the computer (either USB or ethernet)?

12

Actually, @craig_howard , we don’t have any clue what this new poster has. He replied to a thread that has been dead 14 months. To @davs_shrus , you need to post a new question with whatever difficulty you’re having, and please describe what the overall project is.

13

Ah crapples … a necropost! Really, REALLY have to check the “best by” label on these things … sigh …

14

To @davs_shrus , you need to post a new question with whatever difficulty you’re having, and please describe what the overall project is.

This. And I’m closing this thread because it is out of date.

Don’t post to threads older than a month or so. Don’t reply to posts that are made to such posts, except to tell the poster “please start a new thread”

Peter