Windows系统USB驱动的断电异常处理STATUS_NO_SUCH_DEVICE

USB设备除非特殊需要，一般都是系统自带。所以我们根据不用开发相应的驱动，就算是我们要搞自定义的USB设备，微软也贴心的帮我们搞了一个WinUSB,只我们的的固件按照某定的要求，也可以实现自定义通讯。
所以从上面的来看，没有什么特殊的地方要我们开发Windows系统的USB驱动。不过有的时候就是那么奇怪，本人就在这个坑里，真是一条没有任何前途的事业。
Windows系统由于其闭源性，导致很难拿到参考的源代码，虽然它的文档写的很多，但是绝对没有一份源代码让我们可以快速地搞定我们需要的事，然后躺下享受这美好的生活。所以本人心中有一万人理由要想去搞Linux驱动开发，抄抄代码，复制粘贴，还有各位大佬指点一下，甚至实在没办法，对照LINUX驱动的源代码也是一件不至于很绝望的事。

做Windows驱动开发，特别是USB设备驱动开发，往往要完成一些非常规的框架，所以最终这件事就变成了一个虚拟总线驱动了。对下实现USB特理设备的枚举，选择配置，数据通讯，对上一部分是实现标准的USB设备接口，比如我们搞一个标准的UVC摄像头，一个标准UAC麦克风，或都一个标准的键盘之类。另一部分就是实现千奇百怪的需求，所以就是一大堆的自定义通讯。

在做USB设备工作时，需要不停地通过端点来读硬件返回上来的数据。这就要搞一个线程来搞，不然在应用层调用，再到内核，再发给总线，这个实时性就不怎么高的，所以只能在内核中搞一个线程，让它永不止休地帮我们干活。当读到数据时，通过完全例程将数据返回到我们的数据缓存队列中，这时当应用层或上层驱动需要返回数据时，就构造其需要的数据结构，然后返回就行了。以上基本可以满足一般的需求。但是，你没有想到，当设备在工作的进候，有人直接把设备给拨了，这样，遇到最多的就是蓝屏或者系统的设备管理器挂起。

当然，以上的蓝屏还是好解的。使用神器Windbg分析就可以了，但是对于设备管理器卡死或者安驱动卸载驱时一直给你转圈圈或者这时再插入一个U盘之类，人家系统根据就不鸟你。这可就难办了。
这就是USB驱动开发中的三体问题。我们不光要同步标准设备层，自定义应用层和固件层返回的异常，还要处理设备本身的一些问题。

比如我的一个USB摄像头驱动正在从固件中读数据，突然设备掉电了：

通过BUSHOUND抓包，如上图所示：
设备收到IRP_NM_SURPRIZE_MOVE，并同下发给下层的PDO设备的IPR被部会被取消，同时第一个会返回STATUS_NO_SUCH_DEVICE。
这时:

• 对于上层标准驱动，应返回STATUS_DELETE_PENDING.
• 对于应用层，需要尽快通知让其CloseHandle,因为你再慢一点，就设备管理器就要卡死了。