Re-generating "Config" key in HKLM\System\CurrentControlSet\Control\Network

  • Thread starter Thread starter Allan Miller
  • Start date Start date
A

Allan Miller

In the post:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&[email protected]

Mike Johnston describes the technique of deleting the "Config" value
and having the system regenerate it. This works well and I have been
using it to correctly generate the key after altering bindings
manually. However, I've run into a problem with Windows Server 2003,
and I'm wondering if it's a bug in Windows, or if this technique is no
longer supported, or what.

Here's an easy way to reproduce the problem:

1. Start with a virgin install of Windows Server 2003 Standard Edition
on a system with one network card.

2. Open the Network control panel.

3. Enable the service "Network Load Balancing" and click OK.

4. Use RegEdit to delete the value "Config" from the key:

HKLM\System\CurrentControlSet\Control\Network

5. Now you can either restart the system, or more simply, just open
the Network control panel and then click on OK.

6. Use RegEdit to open up the key:

HKLM\System\CurrentControlSet\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}

Open up the last subkey in the list under this, and look in the key
"Linkage". The value "UpperBind" is empty.



At this point the network configuration is in an inconsistent state.
In this particular case, the network still works after a reboot, but I
have had several similar cases where the network just doesn't work.
I'll try to come up with a case like that but I thought maybe someone
(Mike?) could offer some advice at this point.

Thanks!

Allan Miller
 
In the post:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&[email protected]

Mike Johnston describes the technique of deleting the "Config" value
and having the system regenerate it. This works well and I have been
Click to expand...

....

I just realized that this may not be clear to everyone, so I'd like to be
explicit: do NOT do this procedure on a system that you care about, because
it isn't very easy to back out of the inconsistency in the network setup! You
should only try this on a test system where you can reinstall the operating
system (or restore the partition from an image) without losing anything.

Sorry that I wasn't clear about that.

Allan Miller
 
Hi Allan,
There is no reason to delete this key for Binding Order. The only reason
it should ever be removed is if you have been swapping your NIC's in and
out of the system, such as a NIC goes bad then, you replace it with
another. In Windows 2000 there was tendency for this key to corrupted
then the need for the deletion or you would loose the network information
on the card, IP address and such.

I would not be doing this for any other reason. Again, this has nothing to
do with the Binding Order of the NIC's.
I would also suggest NOT to do this on Windows 2003.

Is there something specific you are trying to accomplish. Again this
registry key to elleviate a very specific issue that has nothing to do with
how the NIC's Bind. The Binding of the NIC's occur based on the PnP upon
bootup and is not the recommended method of ever being a solution as you
never know what the binding order will after subsequent reboots.

If you explain what your trying to accomplish I will be more than happy to
address that.

Thank you,

Alan Wood[MSFT]

This posting is provided "AS IS" with no warranties, and confers no rights.
 
OK, I found a sequence that reliably demonstrates a more serious consequence of
this problem. Once again, don't do this on a system that you care about,
because it is not easy to back out of this situation without restoring the OS
partition.


1. Start with a virgin install of Windows Server 2003 Standard Edition on a
system with one network card.

2. Open the Network control panel, click "Install...", select "Service", click
"Add...", select "QoS Packet Scheduler", and click "OK". Once it is finished,
click "Close" on the Network control panel.

3. Open the Network control panel, enable the service "Network Load Balancing"
by checking the box next to it, and click "OK".

4. Use RegEdit to delete the value "Config" from the key:
HKLM\System\CurrentControlSet\Control\Network

5. Open the Network control panel, and click "OK".

6. Restart the system.


Now the network is in a state where it doesn't work. Windows networking will
not see any machines, "ping" will not work, "route print" shows only the local
loopback, and "ipconfig /all" gives empty output.

The problem is rather sensitive to the exact sequence. For example, the
network will still work if you try to combine steps 2 and 3 without closing
the Network control panel, or if you omit step 5.

Allan Miller
 
Hi Alan:

Thanks very much for replying. Here's what I'm doing; perhaps there is a
better approach.

Our product uses an intermediate driver that we have to install, in order to
monitor network traffic. The product manages its own installation and updates
automatically (and silently), so it can run the installation on an end user
machine at pretty much any time.

We started by using the Install method of the InetCfgClassSetup object, which
is "lightly documented" in some magazine articles, and essentially allows us
to duplicate the functions of the Network control panel (I assume that the
NCPL uses this same interface, at least for some operations).

However, this method has the same side-effect as a manual installation, namely,
that it interrupts all open network connections. At a customer site, this
means that an update causes a deluge of support calls to the local admin, and
can also cause operational problems when updates happen on servers that are
providing network services. Our customers have made it abundantly clear that
this behavior is not acceptable.

So, what we want is something that will do the installation and have it take
effect at the next reboot. (Well, what we really want is to do the installation
without interrupting the connections, but I think we have to settle for just
having it take effect at the next reboot.) So, we wrote code that sets up the
registry as though the installation had run. This wasn't trivial, but we had
to understand most of it anyway in order to write the oemsetup.inf file for the
NT 4 installation. In case you're wondering, yes, our code correctly handles
the complicated cases where multiple bindings are involved.

The only thing we can't easily handle is the "Config" key in
HKLM\System\CurrentControlSet\Control\Network
because its format isn't documented. I suppose we could reverse engineer it
but that would take time and we might miss an important case. So, after we
found that posting from Mike Johnston, we discovered that the key would get
regenerated correctly if we just delete it and then use the QueryInterface
method of the INetCfg object (the moral equivalent of opening up the Network
control panel).

This works fine in every case we can test except when that "Network Load
Balancing" gets involved on Windows Server 2003. It appears to me as though
the software is designed to regenerate the key, but there is some bug in that
one case. I admit that it could be something more subtle, though.

Sorry about the rather long post, but I figured that more detail would be
better than less. Thanks in advance for any help or advice!

Allan Miller
 
AlanWood@NoSpam ("Alan Wood" [MSFT]) wrote in message news: said:
Hi Allan,
There is no reason to delete this key for Binding Order. The only reason
it should ever be removed is if you have been swapping your NIC's in and
out of the system, such as a NIC goes bad then, you replace it with
Click to expand...

...

Hi Alan,

Hope you had a good holiday season. If you have a chance, could you take a
look at this and let me know anything you discover? Thanks!

Allan Miller
 
Back
Top