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"