Re: libusbk WDF_Violation (BSoD) if device removed during UsbK_SetCurrentAlternateSetting

I've pushed these changes to the repo:
https://code.google.com/p/usb-travis/source/detail?r=302

Some more information:
The FlushPipe function also starts/stops the pipe IO target but if you 
run this function in a tight loop it doesn't cause any problems.  It may 
be that this is only something that needs to be avoided when changing 
the alt setting.  If so, it sure isn't documented anywhere!

Regards,
Travis

On 4/13/2014 8:35 AM, Matt Liberty wrote:
> Travis,
>
> Great news, and thank you for the extremely quick turnaround!  I will 
> definitely read up on the links so that I better understand the issue 
> and start learning more about KMDF.  Are your changes suitable for 
> sharing through the repo 
> (https://code.google.com/p/usb-travis/source/checkout)?  If not, would 
> you mind posting a diff?
>
> Thanks again!
>    - Matt
>
> On Sun, Apr 13, 2014 at 10:23 AM, Travis <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     As it turns out, we don't need to start and stop the pipe IO targets
>     when changing an alternate setting. If I remove these calls, the
>     BSOD no
>     longer appears and the device operates normally.  When settings change
>     or the device is removed, the framework does this automatically
>     for us.
>     http://msdn.microsoft.com/en-us/library/windows/hardware/ff540746%28v=vs.85%29.aspx
>
>     The question still remains as to why calls to WdfIoTargetStop,
>     WdfIoTargeStart, and WdfIoTargetGetState cause a BSOD if the device is
>     being removed at the same time.
>
>     It's possible the problem is in the WDF library but that seems
>     unlikely.  These calls are certainly valid in the context of a USB
>     device:
>     http://msdn.microsoft.com/en-us/library/windows/hardware/ff553109%28v=vs.85%29.aspx
>
>     Regards,
>     Travis
>
>     On 4/12/2014 6:12 PM, Matt Liberty wrote:
>     > Hi Travis,
>     >
>     > That's great news, at least compared to the alternative of this
>     issue
>     > being device and platform dependent.  If you have time to check this
>     > out, let me know what you find and how I can best help.  If you
>     do not
>     > have time, please also let me know and I will start from the
>     KMDF basics.
>     >
>     > Regards,
>     >    - Matt
>     >
>     > On Sat, Apr 12, 2014 at 7:20 PM, Travis <[email protected]
>     <mailto:[email protected]>
>     > <mailto:[email protected] <mailto:[email protected]>>>
>     wrote:
>     >
>     >     Greetings,
>     >
>     >     Well it doesn't look like I'll have a hard time reproducing
>     it. It
>     >     blue
>     >     screened me the first time I tried it.
>     >
>     >     Regards,
>     >     Travis
>     >
>     >     On 4/12/2014 11:30 AM, Matt Liberty wrote:
>     >     > Travis,
>     >     >
>     >     > I pulled together a minimal example which demonstrates this
>     >     issue with
>     >     > my device.  You can find the project at
>     >     > https://github.com/mliberty1/libusbk_examples.  I also
>     published a
>     >     > 0.1.0 release that is already built using Visual Studio
>     2013 for
>     >     x64.
>     >     >
>     >     > Thanks for your recommendation to isolate ISO streaming
>     >     > from SetCurrentAlternateSetting.  Using this libusbk_examples
>     >     > altsetting.exe, I have found that the WDF_Violation/BSoD
>     occurs when
>     >     > just calling SetCurrentAlternateSetting without starting
>     any ISO
>     >     > streaming, and it does not even need to be switching from an
>     >     alternate
>     >     > setting that contains an ISO IN endpoint.  I am able to
>     >     replicate this
>     >     > fault very easily on my Windows 8.1 x64 machine and on another
>     >     Windows
>     >     > 7 x64 machine.  You can view my device descriptor at:
>     >     >
>     >
>     https://github.com/mliberty1/libusbk_examples/blob/master/results/device1_descriptor.txt
>     >     >
>     >     > The windbg output for the faults on the two machines are
>     under:
>     >     >
>     https://github.com/mliberty1/libusbk_examples/tree/master/results
>     >     >
>     >     > By default, running altsetting.exe will find the first
>     alternate
>     >     > setting with an isochronous IN endpoint and repeatedly switch
>     >     between
>     >     > that alternate setting and 0.  You can also explicitly
>     specify a
>     >     > different alternate setting like so:
>     >     > altsetting.exe --altsetting 1
>     >     >
>     >     > Hopefully you are able to replicate this result easily
>     using another
>     >     > device.  Please let me know if you have any questions or run
>     >     into any
>     >     > issues with the libusbk_examples project.  I likely will
>     not have
>     >     > another chance to spend significant time on this until
>     Tuesday.
>     >     >  Unless you have other recommendations, my next step will
>     be to
>     >     create
>     >     > a really stripped down device with just two empty altsettings
>     >     and see
>     >     > if I can still repeat this failure.
>     >     >
>     >     > Thanks and have a great weekend!
>     >     >
>     >     >    - Matt
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Put Bad Developers to Shame
>     > Dominate Development with Jenkins Continuous Integration
>     > Continuously Automate Build, Test & Deployment
>     > Start a new project now. Try Jenkins in the cloud.
>     > http://p.sf.net/sfu/13600_Cloudbees
>     >
>     >
>     > _______________________________________________
>     > Libusb-win32-devel mailing list
>     > [email protected]
>     <mailto:[email protected]>
>     > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>
>
>     ------------------------------------------------------------------------------
>     Put Bad Developers to Shame
>     Dominate Development with Jenkins Continuous Integration
>     Continuously Automate Build, Test & Deployment
>     Start a new project now. Try Jenkins in the cloud.
>     http://p.sf.net/sfu/13600_Cloudbees
>     _______________________________________________
>     Libusb-win32-devel mailing list
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
>
>
> _______________________________________________
> Libusb-win32-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees