2011年到現在,就沒再怎麼搞過Windows驅動了.

最近, 由於專案需要, 試著改一改一個顯示卡驅動(KMDOD), 從實踐上證明, 我在理論上對一個驅動的架構的正確與否.(USB Display = KMDOD + AVStream).

其中, KMDOD是完成顯示的部分功能, 完成其中的VidPN(Video present network), 將驅動中原來的POST物理裝置轉變為USB物理裝置.

而AVStream之所以這樣提出, 完成是由於USB Video class的啟發, 要不然, 沒有AVStream的Filters, Pins, Dispatch tables, Automation tables, Nodes, Methods, Properties, Events怎麼實現與DShow的互動?

基於以上的理論設計, 去實現真正的USB Display裝置驅動, 前期的工作量評估也是這次再次玩Windows驅動的原因.

驅動程式碼改寫這邊, 就不多說了, 工作量方面, 從DisplayLink的交流空間中瞭解, 他們花了10-20個人, 1-2年的時間, 來完成一個USB Display驅動.

總得一點, 無論KMDOD這個WDDM miniport中的VidPN, USB, 還是 AVStream中的Filters, Pins, 要做起來, 都不像我當初想象的那麼簡單.

至少, 我目前在KMDOD的改造過程中, 碰到一系列的問題, 以後再表.

關於WinDbg除錯:

WinDbg是很好的除錯工具, 關於這一論斷, 沒有任何意見.

但我的觀念還停留在COM 115200 bps的"鳥槍"上, 所以, 對WinDbg的"慢"反應, 總是非常不耐煩.

目前, 我的配置是, 主機Win7 Test Mode, build 7601, 從機Win8.1 Pro Build 9600.

我是直接從Win8 Pro Build 9200直接升級到9600的, 這個升級解決了 WDDM1.1 到 WDDM1.2的更新, 否則KMDOD是不能在WDDM1.1上執行的(注意了).

在更新後:

使用COM口除錯驅動:

1. 慢

2. 一大堆列印, 導致更"慢"

3. 要設定一個斷點之類的操作, "慢"到後來, 讓你不知道是TARGET宕機了,還是說TARGET還在執行, 搞得你是要繼續等呢, 還是強行重啟呢?

4. 浪費時間, 一次次設定斷點不成功, 最後, 程式碼沒跟蹤成功, 原因沒找到,事情沒辦成.

所以, 不得不找別的辦法來代替COM口的除錯.

USB2.0

好多人沒有用過USB2.0的DEBUG CABLE, 或者是根本沒有見過這個GADGET.

原因, 就是:第一貴, 第二, 這玩意兒不好買, 第三, 即使買了, 有些PC也不支援USB DEBUG這個擴充套件功能.

結果, 我就是第三種情況, 這麼貴的玩意到手了, 而且有兩個(Ajays technology USB2.0 Debug Cable), 但你眼巴巴地看著, 它就是一沒用的東西, 你會什麼感受?

而且, 為了折騰它, 花了不少時間.

有興越的人可以參閱:

How to Debug the Windows OS using USB

http://www.codeproject.com/Articles/132313/How-to-Debug-the-Windows-OS-using-USB

相信沒有人會再去看這樣的文章, 完完全全地在浪費時間.

1394:

以前使用過, 筆記本帶1394口, 被除錯的機器, 買一張PCI/PCIE轉1394的卡, 使用起來還是比較方便的, 但目前的實際環境是, 現在的筆記本不帶1394, 也沒有這種PCI/PCIE轉1394的卡.

USB3

Win8核心除錯支援USB3了, 但需要一根A-A電纜, 沒有硬體, 只好放棄.

最後, 選擇了人人都能有的NET方式:

三根網線, 一個路由器, 邊接到區域網 (兩根網線, 加一個路由器, 不接入區域網的方式, 我沒弄成功, 因為兩臺計算機的網絡卡都處於"黃點"狀態；如果只有一根交叉網線, 我也沒有試過, 因為沒有這樣的交叉網線, 也不知道能不能成功. 記得以前, WHQL-->DTM 測試的時間, 就是用的這樣的一根交叉網線來測試的, 後來, 我也玩過WHCK, 但也不再用交叉網線了.)

HOST安裝了最新的WINDOWS KITS 8.1, 帶了最新的WINDBG, 我目前的版本是:6.3.9600.16384, 記錄HOST的IP地址.

TARGET:

bcdedit /dbgsettings net hostip:xxx.xxx.xxx.xxx port:50000 key:aaa.bbb.ccc.ddd

bcdedit -debug on

如果有多個網絡卡:

bcdedit /set {dbgsettings} busparams bus.device.function

bus, device, function在裝置管理器的property中查詢.

之後, 主機設定PORT NUMBER, KEY, 等待:

Microsoft (R) Windows Debugger Version 6.3.9600.16384 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Using NET for debugging
Opened WinSock 2.0
Waiting to reconnect...

重啟從機, 連線成功後,如下顯示:

Connected to target 10.38.188.159 on port 50000 on local IP 10.38.188.162.
Connected to Windows 8 9600 x86 compatible target at (Fri Jun 20 15:21:02.168 2014 (UTC + 8:00)), ptr64 FALSE
Kernel Debugger connection established.

目前, NET除錯的速度明顯提高了, 但我這裡還是有不可以設定斷點的情況, 沒有找到具體原因, 

仔細觀察的讀者, 如何自己嘗試後, 會在DEVICE MANAGER中, 看到系統多了一個網絡卡:

Microsoft Kernel Debug Network Adapter. 

而原來那個網絡卡: Intel(R) 82567LM-3 Gigabit Network Connection卻出現在"傳說中的黃點".

不用擔心, 這個時候, 真正的物理網絡卡就是前者, 而後者已經不能代表這塊物理網絡卡了.

這一點, 我已經嘗試, 即你將帶黃點的網絡卡禁止, 主機WINDBG還是可以控制從機的, "g"