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), 但你眼巴巴地看着, 它就是一没用的东西, 你会什么感受?
而且, 为了折腾它, 花了不少时间.
有兴越的人可以参阅:
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 set 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"
第二十二篇:再写Windows驱动,再玩Windbg---NET,布布扣,bubuko.com
第二十二篇:再写Windows驱动,再玩Windbg---NET
原文地址：http://blog.csdn.net/u013140088/article/details/32713027
