Problems with NIC kernel debugging Windows 8 - Realtek 8169

Hi,

I’m trying to start doing kernel debugging and it’s being completely frustrating by now. I’ve done kernel debugging before using virtual machines, but this is the first time I try with two real computers over a network cable. Host machine is Windows 8.1, target machine Windows 8.

I bought a TP-Link TG-3269 network card specifically for this task, which PCI identifier is 8169 (PCI\VEN_10EC&DEV_8169&SUBSYS_816910EC&REV_10). The 8169 device is listed as supported by Windows 8. Unfortunately after ordering this card I read another thread saying that Realtek sells different hardware using the same identifier. (I’m wondering if this could be the problem, please keep reading)

Both computers are connected by means of a TP-Link TL-SF1005D switch, that does not support DHCP so I’m using static IPs for both computers. Actually the target machine is getting an automatic private IP as you can see below. The firewall is disabled in both computers, and I can ping each other succesfully when in Windows.

So I follow the instructions in MSDN for setting up network debugging, reboot the target machine, and I get this in Windbg:

Microsoft (R) Windows Debugger Version 6.3.9600.17029 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Using NET for debugging
Opened WinSock 2.0
Waiting to reconnect…
Connected to target 169.254.41.219 on port 50000 on local IP 192.168.2.1.
Connected to Windows 8 9200 x64 target at (Wed Aug 6 17:12:00.621 2014 (UTC + 2:00)), ptr64 TRUE
Kernel Debugger connection established.

************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*d:\Temp\pdb*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*d:\Temp\pdb*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9200 MP (1 procs) Free x64
Built by: 9200.16384.amd64fre.win8_rtm.120725-1247
Machine Name:
Kernel base = 0xfffff8038c07a000 PsLoadedModuleList = 0xfffff8038c344a60
System Uptime: 0 days 0:01:00.803

After that, it stays there forever. The progress wheel on the target machine gets frozen at this point. On Windbg, the message “Debuggee not connected” is shown all the time. However I can’t access nearly any option because it complains it is busy. However if I CTRL+Break, it does nothing. All I can do close Windbg and shut down the target machine from the power button. The disk gets corrupted after that and it can’t boot into Windows 8 anymore, I actually need to boot into a Windows 7 install in a separate partition in order to repair the disk, and disable debugging for the Windows 8 partition so I can access the system again.

I have accessed the registry in HKEY_Local_Machine\System\CurrentControlSet\Services\kdnet but there’s nothing interesting there. As a note, if just for testing I try using the onboard NIC (Intel, unsupported), I do get an “NIC not supported” error in there, and when I do this Windows 8 does start without problems.

I have also tried using a common router with DHCP support. I get the same exact result, although it actually gets there faster, I guess because it obtains an IP from the router.

So at this point, I would highly appreciate any advice or suggestion. Maybe this Realtek chip is not fully supported after all? Am I doing something wrong?

Thanks in advance,

Antonio

In my experience the 8169 Realtek devices don’t work very well.

Could you please send the device ID of the Intel NIC you have in your target machine? (Go to device manager, double click on your Intel NIC, click on the details tab, select hardware ids from the drop down property menu, and send the values you see there.)

I actually developed the original Realtek KDNET support using a Rosewill RC-411. You can get them from Newegg, although they appear to be out of stock at the moment. It has a Realtek 8168 chip in it.

Another thing you should try is to press ctrl-alt-k in Windbg, so that it says “Will breakin at next boot.”

Then reboot the target, and see if you actually end up in the debugger.

If you do, try running a few commands.

If you end up losing the ability to run commands while you are broken into the debugger then it is most definitely the 8169 that is failing. (ie: if commands work for 10-30 seconds, and then stop working)

There is a reasonable possibility that the Intel NIC you have in your target machine is supported in 8.1. If so, why can’t you just put 8.1 on the target and do your development that way?

We may also be doing a backport of the Intel 8.1 NICs back to 8.0, but the final decision on that has not yet been made. If we do that, then there would be patch that goes up on WU.

Joe.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@abadiadelcrimen.com
Sent: Wednesday, August 6, 2014 9:29 AM
To: Kernel Debugging Interest List
Subject: [windbg] Problems with NIC kernel debugging Windows 8 - Realtek 8169

Hi,

I’m trying to start doing kernel debugging and it’s being completely frustrating by now. I’ve done kernel debugging before using virtual machines, but this is the first time I try with two real computers over a network cable. Host machine is Windows 8.1, target machine Windows 8.

I bought a TP-Link TG-3269 network card specifically for this task, which PCI identifier is 8169 (PCI\VEN_10EC&DEV_8169&SUBSYS_816910EC&REV_10). The 8169 device is listed as supported by Windows 8. Unfortunately after ordering this card I read another thread saying that Realtek sells different hardware using the same identifier. (I’m wondering if this could be the problem, please keep reading)

Both computers are connected by means of a TP-Link TL-SF1005D switch, that does not support DHCP so I’m using static IPs for both computers. Actually the target machine is getting an automatic private IP as you can see below. The firewall is disabled in both computers, and I can ping each other succesfully when in Windows.

So I follow the instructions in MSDN for setting up network debugging, reboot the target machine, and I get this in Windbg:

Microsoft (R) Windows Debugger Version 6.3.9600.17029 AMD64 Copyright (c) Microsoft Corporation. All rights reserved.

Using NET for debugging
Opened WinSock 2.0
Waiting to reconnect…
Connected to target 169.254.41.219 on port 50000 on local IP 192.168.2.1.
Connected to Windows 8 9200 x64 target at (Wed Aug 6 17:12:00.621 2014 (UTC + 2:00)), ptr64 TRUE Kernel Debugger connection established.

************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*d:\Temp\pdb*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*d:\Temp\pdb*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9200 MP (1 procs) Free x64 Built by: 9200.16384.amd64fre.win8_rtm.120725-1247
Machine Name:
Kernel base = 0xfffff8038c07a000 PsLoadedModuleList = 0xfffff8038c344a60 System Uptime: 0 days 0:01:00.803

After that, it stays there forever. The progress wheel on the target machine gets frozen at this point. On Windbg, the message “Debuggee not connected” is shown all the time. However I can’t access nearly any option because it complains it is busy. However if I CTRL+Break, it does nothing. All I can do close Windbg and shut down the target machine from the power button. The disk gets corrupted after that and it can’t boot into Windows 8 anymore, I actually need to boot into a Windows 7 install in a separate partition in order to repair the disk, and disable debugging for the Windows 8 partition so I can access the system again.

I have accessed the registry in HKEY_Local_Machine\System\CurrentControlSet\Services\kdnet but there’s nothing interesting there. As a note, if just for testing I try using the onboard NIC (Intel, unsupported), I do get an “NIC not supported” error in there, and when I do this Windows 8 does start without problems.

I have also tried using a common router with DHCP support. I get the same exact result, although it actually gets there faster, I guess because it obtains an IP from the router.

So at this point, I would highly appreciate any advice or suggestion. Maybe this Realtek chip is not fully supported after all? Am I doing something wrong?

Thanks in advance,

Antonio


WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hi Joe,

Thank you for your quick response, it helped a lot.

Following your advice I used ctrl + alt + k in windbg and now it actually breaks here:

Kernel base = 0xfffff80103a0d000 PsLoadedModuleList = 0xfffff80103cd7a60
System Uptime: 0 days 0:01:03.296
nt!DebugService2+0x5:
fffff801`03a82985 cc int 3

Then I can trace the disassembly normally, I’ve been stepping over the code without problems for several minutes, in fact it is faster than I had ever dreamed, I was used to an important latency when using virtual machines.

However, once I return the control to the debugee with the ‘g’ command the target system hangs after a while. Just for testing I set a random breakpoint ‘bp nt!kiIdleLoop’ and I can see it’s hit a couple of times, after that I loose the control and the target machine is frozen.

So I’m starting to think that the support for this 8169 NIC is fine after all, but there’s something wrong with debug mode and this specific machine, if this makes any sense.

The reason I’m stuck with Windows 8 is I can’t install 8.1 because it doesn’t support the Pentium 4 HT cpu on my target machine. I’m using an i7-4771 as host and have a couple of old spare identical Dell Dimension 5150 boxes which I hoped to use as target machines so I could do kernel debugging on both of them at the same time. I gather I’m in a suboptimal situation here trying to use old hardware for this task, but they’re still solid machines and having seen how surprisingly well Windows 8 runs on them I was hoping they might serve this purpose.

Regarding the onboard Intel NIC, it is this one: PCI\VEN_8086&DEV_27DC&SUBSYS_01AB1028&REV_01

If I just allow the target machine to boot without attaching windbg on the host then it fails to boot too. The sequence is: it waits for a while, then the progress wheel starts, it stays moving for a while, then the little balls freeze and the system becomes unresponsive so I need to shut it down from the power button.

I’ve tried to set it to log the boot process so I could see the point where it dies but no ntbtlog.txt is created when in debug mode. I’ve also tried booting in Safe Mode, same result.

Thanks for the suggestion on the Rosewill RC-411. I think I might find it in local ebay. However now the 8169 seems to work.

Do you have any suggestion as to why the target machine fails to complete the boot process when in debug mode?

Thanks in advance,

Antonio

Package up the 8169 card, send it back to where you got it and get your money back.

Then buy a cheap NIC that has an Intel 1GBit chip on it. Preferably a PCIe x1 card. Make sure the Intel device ID is in the Windows 8 supported NIC list. Either that or get the Rosewill card I mentioned before and use that.

The reason your on board Intel NIC is not supported for KDNET is because it is a 100Mbit NIC, and we don’t have support for any Intel 100Mbit NICs.

The behavior you are seeing is because the 8169 randomly starts failing to either send or receive packets after 20-40 seconds, and KDNET is not like the native NDIS miniport that repeatedly checks if the card is hosed and resets it.

KDNET assumes that the NICs actually work, and does not attempt to reset them if they fail.

So you actually have to get a reasonably decent NIC in order for KDNET to work properly.

The software is working as designed. The reason it is not working for more than a few tens of seconds is because your NIC hardware is broken.

Joe.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@abadiadelcrimen.com
Sent: Thursday, August 7, 2014 5:09 AM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Problems with NIC kernel debugging Windows 8 - Realtek 8169

Hi Joe,

Thank you for your quick response, it helped a lot.

Following your advice I used ctrl + alt + k in windbg and now it actually breaks here:

Kernel base = 0xfffff80103a0d000 PsLoadedModuleList = 0xfffff80103cd7a60 System Uptime: 0 days 0:01:03.296
nt!DebugService2+0x5:
fffff801`03a82985 cc int 3

Then I can trace the disassembly normally, I’ve been stepping over the code without problems for several minutes, in fact it is faster than I had ever dreamed, I was used to an important latency when using virtual machines.

However, once I return the control to the debugee with the ‘g’ command the target system hangs after a while. Just for testing I set a random breakpoint ‘bp nt!kiIdleLoop’ and I can see it’s hit a couple of times, after that I loose the control and the target machine is frozen.

So I’m starting to think that the support for this 8169 NIC is fine after all, but there’s something wrong with debug mode and this specific machine, if this makes any sense.

The reason I’m stuck with Windows 8 is I can’t install 8.1 because it doesn’t support the Pentium 4 HT cpu on my target machine. I’m using an i7-4771 as host and have a couple of old spare identical Dell Dimension 5150 boxes which I hoped to use as target machines so I could do kernel debugging on both of them at the same time. I gather I’m in a suboptimal situation here trying to use old hardware for this task, but they’re still solid machines and having seen how surprisingly well Windows 8 runs on them I was hoping they might serve this purpose.

Regarding the onboard Intel NIC, it is this one: PCI\VEN_8086&DEV_27DC&SUBSYS_01AB1028&REV_01

If I just allow the target machine to boot without attaching windbg on the host then it fails to boot too. The sequence is: it waits for a while, then the progress wheel starts, it stays moving for a while, then the little balls freeze and the system becomes unresponsive so I need to shut it down from the power button.

I’ve tried to set it to log the boot process so I could see the point where it dies but no ntbtlog.txt is created when in debug mode. I’ve also tried booting in Safe Mode, same result.

Thanks for the suggestion on the Rosewill RC-411. I think I might find it in local ebay. However now the 8169 seems to work.

Do you have any suggestion as to why the target machine fails to complete the boot process when in debug mode?

Thanks in advance,

Antonio


WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hi Joe,

I’ll follow your advice and buy an Intel 1GBit PCIe x1 card. I’ll post back. I really appreciate your help.