22nd: Re-write Windows driver, then play WinDbg---NET

2011 up to now, no more Windows drivers.

Recently, as a result of the project needs, try to change a graphics card driver (kmdod), in practice, I proved in theory to a driving architecture is correct or not. (USB Display = Kmdod + avstream).

Among them, Kmdod is the completion of the display part of the function, complete the VIDPN (Video present network), the driver of the original post physical device into a USB physical device.

And avstream The reason for this, the completion is due to the USB Video class inspired, otherwise, there is no avstream filters, Pins, Dispatch tables, Automation tables, Nodes, Metho DS, Properties, events How do I interact with dshow?

Based on the above theoretical design, to realize the real USB display device driver, the previous workload evaluation is also the reason to play Windows driver again.

Drive code rewrite this way, there is not much to say, the workload, from the displaylink of communication space, they spent 10-20 people, 1-2 years, to complete a USB display driver.

Always, no matter kmdod this WDDM miniport in the VidPN, USB, or Avstream filters, Pins, to do it, are not as simple as I had imagined.

At least, I am currently in the kmdod of the transformation process, encountered a series of problems, and then the table.

About WinDbg Debugging:

WinDbg is a good debugging tool, and there is no comment on this assertion.

But my concept still stays on the "shotgun" of com 115200 bps, so the "slow" response to WinDbg is always very impatient.

Currently, my configuration is, host Win7 Test Mode, build 7601, slave Win8.1 Pro build 9600.

I directly upgraded from Win8 Pro Build 9200 to 9600, this upgrade resolves the WDDM1.1 to WDDM1.2 update, otherwise Kmdod is not running on WDDM1.1 (note).

After the update:

–NVIDIA Quadro NVS 285–NVIDIA Geforce 210–Intel (R) q45/q43 Expresschipset
Only the first video card can not use kmdod (reason and so have time to find, anyway is not my product), the other two pieces, can be installed correctly and use Kmdod driver.

Debug drivers using COM ports:

1. Slow

2. A lot of printing, resulting in more "slow"

3. To set a breakpoint and other operations, "slow" to later, so you do not know whether the target is dead, or the target is still running, do you want to continue to wait, or forcibly restart it?

4. Wasting time, setting breakpoints again and again is unsuccessful, finally, the code did not track success, the reason did not find, things did not.

Therefore, we have to find another way to replace the debugging of COM port.

USB2.0

Many people have not used USB2.0 debug CABLE, or have never seen this gadget.

The reason is: first expensive, second, this thing bad buy, third, even if bought, some PC also does not support USB debug this extension function.

As a result, I was the third case, so expensive thing to get, and there are two (Ajays technology USB2.0 Debug Cable), but you look helplessly, it is a useless thing, how do you feel?

And, in order to toss it, it took a lot of time.

People who have Xing Yue can refer to:

How to Debug the Windows OS using USB

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

Believe that no one will go to see such an article, completely wasted time.

1394:

Used before, notebook with 1394, is debugged machine, buy a pci/pcie to 1394 card, use up or more convenient, but the actual environment is, now the notebook without 1394, also do not have this Pci/pcie 1394 card.

USB3

WIN8 kernel debugging support USB3, but need a a-a cable, no hardware, had to give up.

Finally, choose the net way that everyone can have:

Three network cable, a router, side to the local area network (two network cable, add a router, not connected to the local area network, I did not succeed, because the network card of both computers are in the "Yellow point" state; if there is only one crossover cable, I have not tried, because there is no such crossover cable, also do not know whether can succeed. , Whql-->dtm test time, is to use such a crossover cable to test, later, I also played whck, but also no longer with the crossover cable.)

Host installed the latest Windows KITS 8.1 with the latest WinDbg, my current version is: 6.3.9600.16384, record the IP address of the host.

TARGET:

Bcdedit/dbgsettings Set hostip:xxx.xxx.xxx.xxx port:50000 key:aaa.bbb.ccc.ddd

Bcdedit-debug on

If you have more than one network card:

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

Bus, device, function is found in the property of the Device Manager.

After that, the host sets port number, KEY, to wait:

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 ...

After restarting the slave, the connection is successful, as shown below:

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 June 15:21:02.168 (UTC + 8:00am)), Ptr64 FALSE
Kernel Debugger Connection established.

At present, the speed of net debugging is obviously improved, but I still have a situation where I can not set breakpoints, not find the specific reason,

After careful observation of the reader, how to try it on their own, will see in Device Manager, the system has a more network card:

Microsoft Kernel Debug Network Adapter.

and the original network card: Intel (R) 82567lm-3 Gigabit network connection appears in the "Legendary Yellow dot."

Don't worry, this time, the real physical network card is the former, the latter can not represent the physical network card.

This, I have tried, that is, you will be with the yellow dot of the network card is forbidden, the host WinDbg can still control the slave, "G"