Win2012R2: STOP 0x139 or 0xD1 in NETIO!NsiEnumerateObjectsAllParametersEx+0x20d

  • Article

Status: Resolved

150516: Finally: https://support.microsoft.com/en-us/kb/3055343 has the updated version. Please install at earliest convenience!

150512: to all affected, please bear with us a few more days, until the new release is out. This should be later this week, or early next week. As soon as the hotfix is available, I will update this post.

150501: Thanks to all of you who sent me additional dumps for this. There have been additional releases of netcfgx.dll, for example in 3021052, and as part of the March Rollup. This explains why some of you started seeing this issue after March/April updates. Checking internally shows that the various issues seen in the dumps provided should be resolved with the May (REL15-05) release of netcfgx.dll. The root cause of the problem allows for this issue to exhibit itself in many different froms, which explains the various dumps and workarounds found by some of you. Stay tuned for the mid-May release! I will update here once it's available.

150429: one of my readers sent me that they had 0x139s after the April updates, like some of you are seem to be having. They appear to have resolved it by recreating their virtual switch. I suggest that if applicable you also try this step and share results.

150417: I only mentioned the workaround (uninstall KB2966087) below in the comments. Adding it here now. Note that this fix was encompassed in KB2975719, so if you do not have the first one installed check for the latter, which is the August Rollup.

150415: one of the blog readers sent me a minidump of a STOP 0x139 on Windows Server 2012 that might be confused with this issue. Do note that the issue below is specific to 2012R2. The 2012 issue was:

2883658 "0x00000139" Stop error on a Windows Server 2012-based computer that has many TCP connections
https://support.microsoft.com/kb/2883658/EN-US

Recently we're seeing quite a few STOP 0x139/0xD1 errors, where the 0x139 stack is below:

00 ffffd000`748c5fc8 fffff803`7b3d14e9 nt!KeBugCheckEx
01 ffffd000`748c5fd0 fffff803`7b3d1810 nt!KiBugCheckDispatch+0x69
02 ffffd000`748c6110 fffff803`7b3d0a34 nt!KiFastFailDispatch+0xd0
03 ffffd000`748c62f0 fffff800`6a2ee3b1 nt!KiRaiseSecurityCheckFailure+0xf4
04 ffffd000`748c6480 fffff800`6a209308 NDIS!ndisNsiEnumerateAllInterfaceInformation+0x24c51
05 ffffd000`748c65a0 fffff800`6b264fc1 NETIO!NsiEnumerateObjectsAllParametersEx+0x20d
06 ffffd000`748c6790 fffff800`6b264bea nsiproxy!NsippEnumerateObjectsAllParameters+0x201
07 ffffd000`748c6980 fffff803`7b6223ef nsiproxy!NsippDispatch+0x5a
08 ffffd000`748c69c0 fffff803`7b62198e nt!IopXxxControlFile+0xa4f
09 ffffd000`748c6b60 fffff803`7b3d11b3 nt!NtDeviceIoControlFile+0x56
0a ffffd000`748c6bd0 00007ff9`3d890dfa nt!KiSystemServiceCopyEnd+0x13

The issue is caused by a problem in netcfgx.dll. We currently have an internal repro, and we expect to resolve this in REL15-05 timeframe.

Note that this issue could also manifest itself as a STOP 0x3B.

As always, reach out when you have this issue!