Error: "The parameter is incorrect" when connecting to a server using WMI.


You test WMI connectivity remotely using WBEMTEST > Error: "The parameter is incorrect"



Network trace during the issue shows that communication is happening with TCP Port 135 but after that secondary connection other DCOM/WMI interface not happening on other DYNAMIC RPC ports (above 1024).
All ports between the client and the target server are open.


Network trace during the problem: communication only with TCP port 135    abizerh-lab  MSRPC   MSRPC:c/o Bind:  UUID{000001A0-0000-0000-C000-000000000046} IRemoteSCMActivator(DCOM)  Call=0x4  Assoc Grp=0x0  Xmit=0x16D0  abizerh-lab  MSRPC   MSRPC:c/o Bind Ack:  Call=0x4  Assoc Grp=0x71F7  Xmit=0x16D0  Recv=0x16D0    abizerh-lab  MSRPC   MSRPC:c/o Alter Cont:  UUID{000001A0-0000-0000-C000-000000000046} IRemoteSCMActivator(DCOM)  Call=0x4
abizerh-lab MSRPC   MSRPC:c/o Alter Cont Resp:  Call=0x4  Assoc Grp=0x71F7  Xmit=0x16D0  Recv=0x16D0    abizerh-lab  DCOM   DCOM:RemoteCreateInstance Request, DCOM Version=5.7  Causality Id={F756624A-7CA5-4534-9F62-6638201C68CD}
abizerh-lab DCOM   DCOM:RemoteCreateInstance Response, ORPCFLOCAL - Local call to this computer
                                                                              ----->ReturnValue: 0x00000057 - ERROR_INVALID_PARAMETER - The parameter is incorrect.


Working trace: You can see that apart from the connections to TCP 135, secondary connection are being made to other UUID of DCOM / WMI interface.   Abizerh-lab MSRPC   MSRPC:c/o Request: unknown   Call=0x3  Opnum=0x5  Context=0x0  Hint=0x0
Abizerh-lab MSRPC   MSRPC:c/o Response: unknown   Call=0x3  Context=0x0  Hint=0xE4  Cancels=0x0   Abizerh-lab  DCOM   DCOM:RemoteCreateInstance Request, DCOM Version=5.7  Causality Id={03728AE5-CD86-4477-BA31-7B275C0A7CFF}
Abizerh-lab DCOM   DCOM: Response, ORPCFLOCAL - Local call to this computer, Unknown IRemoteSCMActivator Method opnum=0   Abizerh-lab  MSRPC   MSRPC:c/o Bind:  UUID{00000143-0000-0000-C000-000000000046} IRemUnknown2(DCOM)  Call=0x1  Assoc Grp=0x0  Xmit=0x16D0 
Abizerh-lab MSRPC   MSRPC:c/o Bind Ack:  Call=0x1  Assoc Grp=0x7688  Xmit=0x16D0  Recv=0x16D0   Abizerh-lab MSRPC   MSRPC:c/o Auth3:  Call=0x1   Abizerh-lab DCOM   DCOM:IRemUnknown2:RemQueryInterface Request, DCOM Version=5.7  Causality Id={03728AE5-CD86-4477-BA31-7B275C0A7CFF}
Abizerh-lab DCOM   DCOM:IRemUnknown2:RemQueryInterface Response, ORPCFNULL - No additional information in this packet   Abizerh-lab MSRPC   MSRPC:c/o Alter Cont:  UUID{D4781CD6-E5D3-44DF-AD94-930EFE48A887} IWbemLoginClientID(WMIRP)  Call=0x2
Abizerh-lab MSRPC   MSRPC:c/o Alter Cont Resp:  Call=0x2  Assoc Grp=0x7688  Xmit=0x16D0  Recv=0x16D0


Dumped the endpoint mapper database of the TARGET server (we are trying to connect to via WMI) containing the details of the services asociation with different protocols/ports.
- RPCDUMP /s target_server /v /i > rpcdump.txt
**RPCDUMP is a part of windows resource kit.


This output during the problem, from the target server, showed services listening on ncacn_np, ncalrpc but NO services listening on ncacn_ip_TCP. In a normal scenario, the above output should show atleast a few services listening on Dynamically allocated TCP ports i.e. associated with ncacn_ip_TCP protocol. A few services that you should fine listening on all Windows server is SAM {12345778_1234_abcd_ef00_0123456789ac} or SVCCTL {367abb81_9844_35f1_ad32_98f038001003}.


You should see something like this in the RPC dump to confirm that Dynamic allocation of TCP ports is happening on the server.

 VersMajor 1  VersMinor 0


After receiving the hint from the RPCdump output, of the Target server, we looked up the following registry key/values on the Target server.

 - Ports
 - PortsInternetAvailable
 - UseInternetPorts


**These values were present and configured on the Target server.


Note: the above registry values are not present by default and are set it case you want to set a range of TCP ports for RPC dynamic port allocation.


How to configure RPC dynamic port allocation to work with firewalls


So was this RPC dynamic port allocation configuration causing the problem? NO NO NO


On the problem target server, we found that the RPC dynamic port allocation configuration were not set correctly i.e. the Port range had a space between them for example Ports = '5100 - 5200' instead of '5100-5200'. This was basically confusing the OS where it knew that the RPC dynamic allocation restriction was set but could make sence of the values, hence causing it not to allocate any ports to any services at all.


Further testing showed that even when "PortsInternetAvailable" or "UseInternetPorts" were mis-spelled, OS couldn't handle it correctly.


Correcting the above settings related to ‘RPC dynamic port allocation’ and rebooting the target server resolved the issue and now we were able connect to the server using WMI.



- Abizer



Comments (4)

  1. Roberto. says:

    Hey, thank you very much!!! 3 years later, your post has saved me maaaany debugging time…

  2. JustAdmin says:

    Abizer, good job! Thanks a lot!

  3. JustAdmin says:

    My previous extensive comment somehow was not saved… anyway, I was receiving error 0x80070057 while using WMI with remote server:

    C:temp>wmic /node:SERVER logicaldisk

    Node – SERVER


    Code = 0x80070057

    Description = The parameter ins incorrect.

    Facility = Win32

    It's a pitty you don't have this error in your article, probably it would help find this article and fix the root cause faster, because to reach this article I had to look quite a while.

  4. Karan says:

    I had a similar issue on one for the latest Windows 2012 R2 server, turns out because of Veeam , following blog post explain the solution

Skip to main content