FIX for IPCONFIG failing with Unknown media status code error

If the following error occurs when attempting to run IPCONFIG when using
a wireless network adapter:

The likely problem is a wired network adapter that isn't connected, and
as a result has been automatically Disabled in Network Connections by
its network driver, while still being enabled in Device Manager.
IPCONFIG reports an error because the wired network hardware is enabled
but it can't get the media status since the Network Connection (driver)
is disabled. (Turning off Power Management doesn't help.)

This issue is known to affect at least some Intel wired network adapters
with Windows XP drivers dated 2006 and later. For example, a
disconnected Intel PRO/1000 MT Mobile wired network adapter in a
ThinkPad T41 stays at Network Cable Unplugged with driver e1000325.sys
6.4.16.36 (06/13/2003), which allows IPCONFIG to work, but switches
automatically to Disabled after about 30 seconds or so with any driver
dated in 2006 (e.g., 8.7.1.0 [04/27/2006] from Microsoft/Windows Update,
8.7.9.0 [10/24/2006] from Lenovo), which causes IPCONFIG to fail.

Fix:

* Use Windows XP Driver Roll Back or Uninstall/reboot/reinstall to
go back to the original Windows XP driver, or otherwise install an old
driver that doesn't exhibit this problem.
* Hide any updated driver in Microsoft/Windows Update to prevent
unintentionally recreating this problem in the future. Likewise avoid
driver updates from hardware vendors.

Workarounds:

1. (Verified)
1. Click Start > Control Panel > Network Connections, and for
any wired network adapters that are Disabled:
2. Right-click on My Computer, and click Manage to start Device
Manager
3. Disable wired Network Adapters that are disabled in Network
Connections
4. Run IPCONFIG as desired
5. Re-Enable wired network adapters in Device Manager

2. (Verified)
1. Click Start > Control Panel > Administrative Tools
2. Double-click Services
3. Scroll down to Routing and Remote Access
4. If Routing and Remote Access is Disabled, change it to
Manual
5. Start Routing and Remote Access, or Stop and Re-Start it if
it's already running

3. (Not verified, applies to ThinkPads, possibly other computers)
1. Uninstall Access Connections, Keyboard Customizer, Wi-Fi
drivers, and Ethernet drivers
2. Reinstall in this order Ethernet, Wi-Fi, Keyboard
Customizer, Access Connections

 

UPDATE: I used Lenovo Software Installer on the ThinkPad T41 to update
the original Windows XP driver 6.4.16.36 (06/13/2003) to 7.2.17.101
(10/26/2004), which also works properly (Network Cable Unplugged instead
of automatic Disable). Thus my working hypothesis is that this problem
was introduced by Intel in Version 8 of its drivers, probably as a
well-intended improvement that fell prey to the Law of Unintended
Consequences.

 

NOTES on the ThinkPad T41:
1. ThinkVantage Access Connections isn't installed, so wouldn't seem to
have any bearing on the problem.
2. Intel PROSet for Windows Device Manager isn't installed, so likewise
wouldn't seem to have any bearing on the problem.
3. There is no apparent option for turning off auto Disable when
disconnected in Intel Version 8 drivers.

 

My gut instinct is that the "disabled" showing up in the Network
Connections is probably a symptom of the bug in the driver rather than
part of the causal chain. If you look in WMI, there are driver
response code for "media status". My guess is that the problem is
related either to power management or to link negotiation of some
sort. I've noticed that it's almost exactly 40 seconds after
unplugging the cable that the problem arises - in the 40 second
window, it will properly report that the media is disconnected, but
once that 40 second window is up you start to get the ipconfig
crashes. Win32_NetworkAdapter will report 7 for media status (i.e.
disconnected media) in that 40 second window, but starts reporting 0
(i.e. driver disabled) once the driver starts outputing bogus values,
even though as we well know the driver isn't disabled.

I believe Win32_NetworkAdapter (in root\cimv2) is built on top of the
more primitive stuff in root\wmi (i.e. all the MSNdis_* classes), and
all of that talks to the drivers (as far as I can tell). My guess is
that when Win32_NetworkAdapter gets an illegal value, it simply
reports that the device is disabled (even if the driver isn't),
because it has to do something (and it's better to decide the device
is disabled than to crash).

I've tried messing with the GUI power management as well as
"AutoPowerSaveModeEnabled", "SavePowerNowEnabled", and
"ReduceSpeedOnPowerDown" in the registry. I've tried messing with the
WaitForLink stuff as well. All to no avail.

In the end I ended up modifying my network adapter management code to
disable the interface (you can do it using devcon and code like
devcon.exe disable "@PCI\VEN_8086&DEV_101E&SUBSYS_05491014&*")
whenever it's not plugged in and then to turn it on for 10 seconds
once a minute to check to see if it got plugged in. Annoying as all
get out (since the user sees the notification icons flashing), but I
didn't write the driver!

--Toby Ovod-Everett

 

Agreed, although I suspect Intel would call it a "feature" rather than a
bug.

Power management settings have no effect on the problem. I think it's
intentional, to eliminate the Windows "cable disconnected" popup (that
can be annoying or confusing, depending on your level of expertise).

 

Just because the power management settings have no effect on the
problem doesn't mean it's not power management. The driver could be
ignoring the settings! Also, the proper behavior shows up in the PRO/
100 drivers (VM, VE) from the same driver set, so if they did do it
deliberately, they didn't do it across both drivers (although that
wouldn't be surprising). That said, if it was intentional, they
picked a strange way to do it. Finally, the 40 second timeout is one
of the things that makes me think it might be a power management deal
- if it were to eliminate the popup, don't you think they'd do it
immediately, rather than waiting 40 seconds. Whereas if there's a
hardware setting to automatically reduce power consumption by the port
whenever it's been disconnected for 40 seconds or more, and the driver
is somehow reporting that, then that would be an explanation.

When I get a chance, I'll investigate and see if the same behavior is
seen on our Dell GX260's, which have "Intel(R) PRO/1000 MT Network
Connection" (versus the "Intel(R) PRO/1000 MT Mobile Connection" on
the T41). Unfortunately, all of our other Gigabit notebooks are using
the Broadcom chipset, so I can't use them for comparison.

--Toby Ovod-Everett

 

I verified last night that the "Intel(R) PRO/1000 MT Network
Connection" driver (same version of the driver file - 8.7.9.0) on a
Dell GX260 (which is a desktop as opposed to a notebook) works fine
(i.e. two minutes after unplugging the network cable, ipconfig was
still reporting "Media disconnected"). So whatever the problem is,
it's not present on all PRO/1000 MT hardware, but appears to be linked
to the Mobile variant of it for the notebooks.

Which lends some weight to my hunch that it may be related to some
form of power saving functionality (whether or not the behavior is
configurable via the power management settings), since power saving
functionality isn't as critical in a desktop system.

--Toby Ovod-Everett

 

Thanks for the info. My ThinkPad T41 is currently out for repair by
Lenovo. I'll do some more investigation when I get it back.

 

So it's apparently just MT _Mobile_ that's affected. Interesting.

I don't think so. I think something else is going on.

As I promised (long ago), I've now run more tests on my ThinkPad T41,
using Microsoft Update to install Intel PRO/1000 MT Mobile wired network
adapter driver 8.9.1.0 (03/25/2007), which is later than the version
from Lenovo that I tested earlier. With this driver, the Unknown media
status code error returns, and turning off power management in the
driver again has no effect on the problem.

Interestingly, this latest driver does not disable the network adapter
in Network Connections -- when not in use, it stays at Network cable
unplugged -- so that theory of mine wasn't valid. (This change suggests
that Intel might have responded to my initial report but failed to fix
the problem.)

When I rolled the driver back to 7.2.17.101 (10/26/2004), the Unknown
media status code error again went away. Hence this remains the only
known work-around to the problem. For what its worth, I carefully
compared all settings (including power state) of this driver to the v8
driver and could find no differences.