?USB 驅動程序可以在堆棧中使用鏈接式 MDL 功能發送數據，并且USB驅動的客戶端可以將傳輸緩沖區作為 MDL 結構鏈發送。

大多數 USB 主機控制器要求傳輸緩沖區幾乎是連續的。 幾乎連續意味著緩沖區可以開始和結束頁中的任意位置，但緩沖區的其余部分必須在頁面邊界上開始和結束。 許多 USB 客戶端驅動程序都能夠滿足該要求。 但是，對于某些客戶端驅動程序，特別是那些需要向緩沖區添加或刪除其他數據的客戶端驅動程序，為傳輸緩沖區分配幾乎連續的內存是不可取的。

例如，假設網絡堆棧包含三個驅動程序、一個網絡協議驅動程序、一個中間驅動程序和一個微型端口驅動程序。 協議驅動程序啟動傳輸并將數據包發送到堆棧中的下一個驅動程序：中間驅動程序。 中間驅動程序希望向數據包添加單獨的內存塊中包含的自定義標頭 。 中間驅動程序將該標頭和收到的數據包發送到堆棧中的下一個驅動程序：微型端口驅動程序。 微型端口驅動程序與 USB 驅動程序堆棧接口，因此必須準備幾乎連續的傳輸緩沖區。 若要創建此類緩沖區，微型端口驅動程序會分配一個大型緩沖區，添加自定義標頭，然后復制有效負載。 由于有效負載通常很大，因此復制整個有效負載可能會對性能產生重大影響。

使用鏈式MDL

客戶端驅動程序可以通過將傳輸緩沖區作為 內存描述符列表 鏈 (MDL) 來克服這種性能影響。 Windows 8 中的新 USB 驅動程序堆棧能夠接受鏈接的 MDL (從客戶端驅動程序查看 MDL) 。 通過提供鏈接的 MDL，客戶端驅動程序可以引用內存中的不連續頁面，而不是執行無關的復制操作。 此功能消除了對緩沖區的數量、大小和對齊方式的限制，從而允許在物理內存中對傳輸緩沖區進行分段。

若要使用鏈接的 MDL，客戶端驅動程序必須檢測 Windows 加載的基礎 USB 驅動程序堆棧是否支持該功能，然后以正確的順序生成 MDL 鏈。

鏈式 MDL 功能僅支持批量傳輸、常時等傳輸和中斷傳輸。 在查詢鏈接 MDL 功能之前，請確保客戶端驅動程序具有 USBD 句柄，用于向 USB 驅動程序堆棧注冊驅動程序。 若要創建 USBD 句柄，請調用 USBD_CreateHandle。通常，客戶端驅動程序在其 AddDevice 例程中創建 USBD 句柄。

可以在客戶端驅動程序的 IRP_MN_START_DEVICE 處理程序中查詢鏈接的 MDL 功能，或稍后隨時查詢。 客戶端驅動程序不得在其 AddDevice 例程中查詢此功能：

1.調用 USBD_QueryUsbCapability 例程以確定 USB 驅動程序堆棧是否支持鏈接的 MDL 功能。 若要查詢該功能，請將 UsbCapabilityChainedMdls 指定為 GUID。 將 OutputBuffer 參數設置為 NULL， 將 OutputBufferSize 參數設置為 0；

2.檢查 USBD_QueryUsbCapability 返回的 NTSTATUS 值并評估結果。 如果例程成功完成，則支持鏈接的 MDL 功能。 任何其他值表示不支持該功能；

3.創建 MDL 鏈。 每個 MDL 都有一個指向另一個 MDL 的 Next 指針；

驅動程序可以通過手動設置 Next 指針來生成鏈 MDL；

在前面的示例中，協議驅動程序將數據包作為 MDL 發送。 中間驅動程序可以創建另一個 MDL，該 MDL 使用標頭數據引用內存塊。 若要創建鏈，中間驅動程序可以將標頭 MDL 的 Next 指針指向從協議驅動程序接收的 MDL。 然后，中間驅動程序可以將兩個 MDL 的鏈轉發到微型端口驅動程序，該驅動程序為請求的 URB 中的鏈接 MDL 提供引用，并將請求提交到 USB 驅動程序堆棧。?

4.為使用鏈接的 MDL 的 I/O 請求生成 URB 時，請將關聯 URB 結構的 TransferBufferMDL 成員 (（如 _URB_BULK_OR_INTERRUPT_TRANSFER 或 _URB_ISOCH_TRANSFER) ）設置為鏈中的第一個 MDL，并將 TransferBufferLength 設置為要傳輸的總字節數。 數據可以跨 MDL 鏈中的多個 MDL 條目。

在 Windows 8 中添加了兩種新類型的 URB 函數，使客戶端驅動程序能夠使用鏈接的 MDL 進行數據傳輸。 如果要使用此功能，請確保將 URB 標頭的 Function 成員設置為以下 URB 函數之一：

• URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER_USING_CHAINED_MDL
• URB_FUNCTION_ISOCH_TRANSFER_USING_CHAINED_MDL

如何從 USB 管道錯誤中恢復

在數據傳輸到 USB 管道失敗時，USB設備可以嘗試某些步驟來處理這個異常信息。 本文中所述的機制涵蓋批量、中斷和常時常量管道上的中止、重置和循環端口操作。

USB 客戶端驅動程序通過將控制傳輸發送到默認端點來與其設備通信;數據傳輸到設備的批量、中斷和常時等量端點。 有時，這些傳輸可能會由于各種原因（例如端點中的停止條件）而失敗。 如果傳輸失敗，則在清除錯誤條件之前，關聯的管道無法處理請求。

對于控制傳輸，USB 驅動程序堆棧會自動清除錯誤條件。 對于數據傳輸，客戶端必須采取適當的步驟從錯誤條件中恢復。 數據傳輸失敗時，USB 驅動程序堆棧會通過失敗的 USBD 狀態代碼向客戶端驅動程序報告錯誤。 然后，驅動程序可以根據狀態代碼提供錯誤恢復機制。

下面是有關通過這些操作進行錯誤恢復的準則：

• 重置 USB 管道
• 重置設備連接到的 USB 端口
• 循環 USB 端口以重新枚舉客戶端驅動程序的設備堆棧

若要清除錯誤條件，請從重置管道操作開始，并僅在必要時執行更復雜的操作，例如 reset-port 和 cycle-port。

關于協調各種恢復機制：

客戶端驅動程序必須協調不同的恢復操作，并確保在給定時間僅使用一種方法。 例如，假設某個設備有兩個端點：批量端點和中斷端點。 向設備發送一些數據傳輸請求后，驅動程序會注意到請求在批量管道上失敗。 若要從這些錯誤中恢復，驅動程序會重置批量管道。 但是，該操作無法解決傳輸錯誤，并且批量傳輸將繼續失敗。 因此，驅動程序發出重置 USB 端口的請求。 同時，傳輸開始在中斷管道上失敗，然后重置設備請求。 若要從中斷傳輸失敗中恢復，驅動程序將在中斷管道上發出重置管道請求。 如果這兩個操作未協調，驅動程序可以同時啟動兩個重置設備操作，因為兩個管道都失敗。 這些同時操作可能會出現問題。

客戶端驅動程序必須確保在給定的時間，驅動程序只執行一個重置端口或周期端口操作。 在這些操作期間，不應在任何管道上進行重置管道操作，并且驅動程序不得發出新的重置管道請求。

先決條件

• 客戶端驅動程序必須已創建框架 USB 目標設備對象。如果使用 Microsoft Visual Studio Professional 2012 隨附的 USB 模板，則模板代碼將執行這些任務。 模板代碼會獲取目標設備對象的句柄并將其存儲在設備上下文中。KMDF 客戶端驅動程序必須調用 WdfUsbTargetDeviceCreateWithParameters 方法來獲取 WDFUSBDEVICE 句柄；?
• 客戶端驅動程序必須具有框架目標管道對象的句柄；?

步驟 1：確定錯誤條件的原因

客戶端驅動程序使用 USB 請求塊 (URB) 啟動數據傳輸。 請求完成后，USB 驅動程序堆棧將返回 USBD 狀態代碼，指示傳輸是成功還是失敗。 在失敗時，USBD 代碼指示失敗的原因。

• 如果通過調用 WdfUsbTargetDeviceSendUrbSynchronously 方法提交了 URB，請在方法返回后檢查 URB 結構的 Hdr.Status 成員。
• 如果通過調用 WdfRequestSend 方法異步提交了 URB，檢查EVT_WDF_REQUEST_COMPLETION_ROUTINE中的 URB 狀態。 Params 參數指向WDF_REQUEST_COMPLETION_PARAMS結構。 若要檢查 USBD 狀態代碼，請檢查 Usb-UsbdStatus> 成員。 有關代碼的信息，請參閱 USBD_STATUS。

傳輸失敗可能是由設備錯誤引起的，例如USBD_STATUS_STALL_PID或USBD_STATUS_BABBLE_DETECTED。 它們也可能是由于主機控制器報告的錯誤（例如USBD_STATUS_XACT_ERROR）導致的。

步驟 2：確定設備是否已連接到端口

在發出重置管道或設備的任何請求之前，請確保設備已連接。 可以通過調用 WdfUsbTargetDeviceIsConnectedSynchronous 方法來確定設備的連接狀態。

步驟 3：取消到管道的所有掛起傳輸

在發送任何重置管道或端口的請求之前，請取消對管道的所有掛起的傳輸請求，USB 驅動程序堆棧尚未完成這些請求。 可以通過以下方式之一取消請求：

• 通過調用 WdfIoTargetStop 方法停止 I/O 目標：

若要停止 I/O 目標，請首先通過調用 WdfUsbTargetPipeGetIoTarget 方法獲取與框架管道對象關聯的 WDFIOTARGET 句柄 。 通過使用 句柄，調用 WdfIoTargetStop。 在調用中，將操作設置為 WdfIoTargetCancelSentIo (see WDF_IO_TARGET_SENT_IO_ACTION) ** 指示框架取消 USB 驅動程序堆棧尚未完成的所有請求。 對于已完成的請求，客戶端驅動程序必須等待框架調用其完成回調。

• 發送中止管道請求。 可以通過調用以下方法之一來發送請求：

調用 WdfUsbTargetPipeAbortSynchronously 方法。

調用是同步的，僅在取消所有掛起的請求后返回。 WdfUsbTargetPipeAbortSynchronously 采用可選的 Request 參數。 建議將 WDFREQUEST 句柄傳遞給預先分配的框架請求對象。 參數允許框架使用指定的請求對象，而不是驅動程序無法訪問的內部請求對象。 此參數值可確保 WdfUsbTargetPipeAbortSynchronously 不會因內存不足而失敗。

調用 WdfUsbTargetPipeFormatRequestForAbort 方法以格式化 abort-pipe 請求的請求對象，然后通過調用 WdfRequestSend 方法發送請求。

如果驅動程序異步發送請求，則必須指定指向驅動程序實現的驅動程序 EVT_WDF_REQUEST_COMPLETION_ROUTINE 的指針。 若要指定指針，請調用 WdfRequestSetCompletionRoutine 方法。

驅動程序可以通過將 WDF_REQUEST_SEND_OPTION_SYNCHRONOUS 指定為 WdfRequestSend 中的請求選項之一來同步發送請求。 如果以同步方式發送請求，請改為調用 WdfUsbTargetPipeAbortSynchronously 。

步驟 4：重置 USB 管道

通過重置管道啟動錯誤恢復。 可以通過調用以下方法之一來發送重置管道請求：

• 調用 WdfUsbTargetPipeResetSynchronously 以同步發送重置管道請求；
• 調用 WdfUsbTargetPipeFormatRequestForReset 方法以格式化重置管道請求的請求對象，然后通過調用 WdfRequestSend 方法發送請求。 這些調用類似于中止管道請求的調用，如步驟 3 中所述；

在重置管道操作完成之前，不要發送任何新的傳輸請求。

重置管道請求清除設備和主機控制器硬件中的錯誤條件。 為了清除設備錯誤，USB 驅動程序堆棧使用ENDPOINT_HALT功能選擇器向設備發送CLEAR_FEATURE控制請求。 請求的接收方是與管道關聯的端點。 如果錯誤條件發生在常時常量管道上，則驅動程序堆棧不會執行任何操作來清除設備，因為發生錯誤時，會自動清除常量端點。

為了清除主機控制器錯誤，驅動程序堆棧會清除管道的 HALT 狀態，并將管道的數據開關重置為 0。

步驟 5：重置 USB 端口

如果重置管道操作未清除錯誤條件，并且數據傳輸繼續失敗，請發送重置端口請求。

• 1.取消到設備的所有傳輸：為此，請枚舉當前配置中的所有管道，并取消為每個管道計劃的掛起請求；
• 2.停止設備的 I/O 目標：調用 WdfUsbTargetDeviceGetIoTarget 方法以獲取與框架目標設備對象關聯的 WDFIOTARGET 句柄。 然后，調用 WdfIoTargetStop 并指定 WDFIOTARGET 句柄。 在調用中，將操作設置為 WdfIoTargetCancelSentIo (WDF_IO_TARGET_SENT_IO_ACTION) ；
• 3.通過調用 WdfUsbTargetDeviceResetPortSynchronously 方法發送重置端口請求；

重置端口操作會導致設備在 USB 總線上重新枚舉。 USB 驅動程序堆棧在 枚舉后保留設備配置。 客戶端驅動程序可以使用以前獲取的管道句柄，因為驅動程序堆棧可確保現有管道句柄保持有效。

無法重置復合設備的單個功能。 對于復合設備，當特定函數的客戶端驅動程序發送重置端口請求時，將重置整個設備。 如果 USB 設備保持狀態，該重置端口請求可能會影響其他功能的客戶端驅動程序。 因此，客戶端驅動程序必須在重置端口之前嘗試重置管道。

步驟 6：循環使用 USB 端口

循環端口操作類似于拔出電源并插回端口的設備，不同之處在于設備未以電氣方式斷開連接。 設備在軟件中斷開連接并重新連接。 此操作會導致設備重置和枚舉。 因此，PnP 管理器會重新生成設備節點。

如果重置端口操作未清除錯誤條件，并且數據傳輸繼續失敗，請發送周期端口請求。

1.取消到設備的所有傳輸。 請確保取消針對當前配置中每個管道計劃的掛起請求 ；

2.停止設備的 I/O 目標：調用 WdfUsbTargetDeviceGetIoTarget 方法以獲取與框架目標設備對象關聯的 WDFIOTARGET 句柄。 然后，調用 WdfIoTargetStop 并指定 WDFIOTARGET 句柄。 在調用中，將操作設置為 WdfIoTargetCancelSentIo (WDF_IO_TARGET_SENT_IO_ACTION) ；

3.通過調用以下方法之一發送循環端口請求：

• 調用 WdfUsbTargetDeviceCyclePortSynchronously 以同步發送周期端口請求。
• 調用 WdfUsbTargetDeviceFormatRequestForCyclePort 方法以格式化循環端口請求的請求對象，然后通過調用 WdfRequestSend 方法發送請求。 這些調用類似于中止管道請求的調用，如步驟 3 中所述；

客戶端驅動程序只能在周期端口請求完成后向設備發送傳輸請求。 這是因為在 USB 驅動程序堆棧處理周期端口請求時刪除了設備節點。

循環端口請求會導致設備重新枚舉。 USB 驅動程序堆棧通知 PnP 管理器設備已斷開連接。 PnP 管理器會拆掉與客戶端驅動程序關聯的設備堆棧。 驅動程序堆棧重置設備，在 USB 總線上重新枚舉該設備，并通知 PnP 管理器設備已連接。 然后，PnP 管理器為 USB 設備重新生成設備堆棧。

由于循環端口操作，如果應用程序注冊了此類通知，則任何對設備打開句柄的應用程序都會獲得設備刪除通知 。 作為響應，應用程序可能會向用戶報告設備斷開連接的消息。 因為它會影響用戶體驗，因此僅當其他恢復機制無法解決錯誤條件時，客戶端驅動程序才應選擇周期端口請求。

與步驟 6) 中所述的重置端口操作 類似，對于復合設備，循環端口操作會影響整個設備，而不是設備的各個功能驅動模塊。