Re: "stop debugging" versus OnOK
User mode part of the video capture driver calls DeviceIoControl, which gets
sent to the driver as IRP packet. The driver can queue some of the IRPs in
its internal queue. When a handle to the driver is closed, the driver gets
IRP_MJ_CLEANUP IRP. It should release all resources and cancel all I/O in
progress.
When an application gets killed, all outstanding IRPs are cancelled
(IoCancelIrp is called for them). The driver should make sure it completes
the requests in finite time. Then all I/O handles are closed, the driver
receives IRP_MJ_CLEANUP and IRP_MJ_CLOSE.
The driver you're using seems to employ shared memory. Most reliable method
of sharing memory is to pend a IRP_MJ_DEVICE_CONTROL with DIRECT buffer
type.
The driver seems to allocate a kernel mode buffer instead, and maps it to
user mode space. This should be done very carefully. Make sure the buffer is
unmapped at IRP_MJ_CLEANUP.
Another lesson is that the driver should not trust the user mode code to
clean up (no special close/free buffer requests). All cleanup should be done
at IRP cancellation and IRP_MJ_CLEANUP.
Again, tell your hardware provider to fix the driver. Otherwise it's not a
product.
<runcyclexcski@yahoo.com> wrote in message
news:1164521253.259339.153790@l12g2000cwl.googlegroups.com...
Alexander Grigoriev wrote:
This means the driver you're using (video capture?) is not handilng IRP
cancellation correctly. I'd advise to change your hardware provider or
have
them fix the driver.
Alexander - do you mean that after the hard kill the buffer does get
cleaned up by SDK, but the video hardware still tries to write to the
memory? How nice. I do close the connection with the video hardware in
a soft kill. But the sofkill is not always possible (my app hangs here
and there, for other reasons). I found that a hard kill (Stop debuggin)
while the video is being written in the memory causes a blue screen
with a 100% certainty. Takes a minute. Takes longer if the frame size
in the video gets smaller.