In my usb-serial driver, I need to complete one pending request before surprise removal is completed.
I tried below two approaches, but got 7E and D1 bug-checks.
The situation is:
1.Application is uses Event driven approach and waits for the read event using WaitCommEvent API
2. Driver gets new WAIT_ON_MASK and completes previous WAIT_ON_MASK ioctl
3. During Device removal, new WAIT_ON_MASK is not received as we are not handling/completing the same at Surprise removal or removal stage.
4. Hence application will not know the last WaitCommEvent API status
At point#3, we tried fixing using two different approaches to complete the wait mask and both failed with different bug-checks, below are the details:
Approach1: We tried adding Wdf Completion request for “CurrentWaitRequest” in EvtSupriseRemoval callback, It resulted in 7E bug-check immediately
Approach2: Even We tried sending custom ioctl from upper filter to indicate the function driver to complete this wait request.
This custom ioctl we added using “Serenum_IoSyncIoctlEx” at the “default case” of
“Serenum_FDO_PnP” function before pass-through for surprise removal is sent, this resulted in D1 bug-check.
The wait request is getting completed successfully, however the D1 bug-check occurs at the surprise removal pass-through stage (i.e. when IoCallDriver is executed).
Can anybody suggest better approaches to complete the Wait mask request before the device removal.
In my usb-serial driver, I need to complete one pending request before surprise removal is completed.
I tried below two approaches, but got 7E and D1 bug-checks.
The situation is:
1.Application is uses Event driven approach and waits for the read event using WaitCommEvent API
2. Driver gets new WAIT_ON_MASK and completes previous WAIT_ON_MASK ioctl
3. During Device removal, new WAIT_ON_MASK is not received as we are not handling/completing the same at Surprise removal or removal stage.
4. Hence application will not know the last WaitCommEvent API status
At point#3, we tried fixing using two different approaches to complete the wait mask and both failed with different bug-checks, below are the details:
Approach1: We tried adding Wdf Completion request for “CurrentWaitRequest” in EvtSupriseRemoval callback, It resulted in 7E bug-check immediately
That doesn’t make sense, because that’s the right way to do it. You
should be able to complete the request, assuming the request hasn’t
already been canceled. Are you holding the request in a WDFQUEUE so it
is cancel-safe? What status are you using to complete the request?
You’re going to want to signal an error in some way, because your device
is dead at that point.
Can anybody suggest better approaches to complete the Wait mask request before the device removal.
Remember that the device is already gone when the surprise removal
notification comes in. You can’t send anything to the device in a
surprise removal handler.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
If you’re sending an URB to watch for status change to the USB device, you may want to cancel that IRP. But you need to synchronize the cancel with the URB completion, because the request will fail shortly if the device is unplugged.
In XP+, SURPRISE_REMOVAL was handled in completely retarded way. The USBPORT deleted the device-specific structures AS SOON AS IT DETECTED THE DEVICE GONE. It was then fixed in completely half-assed way. The structures were still deleted early, but at least USBPORT validated the SRB pipe pointer. But the completion status was now different.