3

According to this KB article when you run the "netsh int ip reset" command, all it does is to reset the content of two registry keys:

SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
SYSTEM\CurrentControlSet\Services\DHCP\Parameters\

but on my test system it appears to do more than that.

On a Windows Server 2012 R2 x64 machine, after my application does something wrong, if I try to set up a static IP to a network interface I get instant BSOD.

To fix the issue I have to run "netsh int ip reset" and then I can set a static IP. Now, I'm trying to figure it out how does "netsh int ip reset" fix the problem.

I know is not the content of those 2 registry keys because I did the following on my virtual machine:

  • Make a VM backup when the system is troubled.
  • Launch the VM and run the "netsh int ip reset" command
  • Export the two registry keys
  • Roll back to the backup made before the "netsh int ip reset" command
  • Import the saved registries keys
  • Set up a static IP on an network interface, but I still get a BSOD

When my application tries to configure a network interface with an IP address that was already used by another network interface in the past, first it has to remove that IP configuration for the non-present device and then it can use that IP.

To do that it searches in every registry in SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces and sees if any of the interfaces did use the IP address I want to use by comparing the value in "IPAddress" property with the one I want to use. If it finds a match, first it checks if that interface is live, and if it's not, it deletes the value in "IPAddress" property and set property "EnableDHCP" to 1, then I can use that IP on my interface. This is what my application did wrong. When this interface comes back live again, it will set an IP configuration through DHCP, but it will BSOD if you try to set a static IP on it. The correct way to do it is to set "IPAddress" property to "0.0.0.0" and "EnableDHCP" to 1. If you leave "IPAddress" empty and set "EnableDHCP" to 1, something goes wrong in TCPIP configuration, that "netsh int ip reset" will fix .. but what exactly it fixes, I have no idea. All I know it's that it's not in the two registries keys that the KB article mentions.

So what else does "netsh int ip reset" do, except resetting the content of those two registries, that fixes the problem on my test system?

  • Did you look at the log it creates when using that command? The sample log file on that KB only shows changes to those 2 registry areas. But in the end this isn't really a sysadmin issue, but a coding/application issue on your end. You shouldn't need to run an IP reset on a server...let alone often. – TheCleaner Dec 11 '13 at 17:02
1

That same KB article mentions that running the command will save a resetlog.txt log file. What does that log say?

You can also run Process Monitor from SysInternals and have it monitor your netsh command.

I did this on my Windows 8.1 workstation, filtering ProcMon's output by "process name > contains > netsh" and pulled over 5,000 results. Looks like there's a LOT going on when you run this command. I'm sorry, but I'm not going to parse all of that output for you :)

  • The log file is never created, even though I specify a path for it ("netsh int ip reset c:\resetlog.txt"). All I get are some confirmation messages in command prompt window ("Resetting Global, OK!"). I will give a shot to ProcMon, but probably, most of those 5000 operations are reading operations and dll calls. – Chris Dec 11 '13 at 18:12
  • You're right about the majority of those 5000 operations being nonsense. There are a number of other registry settings that are accessed as well. I also noticed that the command did not create a log file - I guess MS needs to fix their KB article. But I honestly think the only person who really knows what the command does is probably the person who wrote it, and I doubt he (or she) is a member of SF. – Thomas Dec 11 '13 at 18:27
  • You are probably right. In fact I also asked this on Technet from Microsoft, but no answer yet. – Chris Dec 11 '13 at 18:30
  • @Chris, never heard back from TechNet? – theUg Feb 23 '15 at 2:09
  • 1
    @theUg Yes, but didn't answer to this question. All he told me was that the BSOD was caused by a driver/service, which I already knew, but didn't say how netsh fixes the TCP/IP configurations. TechNet discussion – Chris Feb 23 '15 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.