vmrun "one of the parameters was invalid"

[KevinRaftery]

Here are two Windows PowerShell executions of the vmrun command. On one of my hosts, both commands work fine. On another host, the first command works but the second command fails with the message

                     Error: one of the parameters was invalid.

In both cases the guest machine is running Windows XP with VMware Tools at the highest supported level, 10.0.12

It is necessary that the guest machines remain on Windows XP.

# ======================================== 1 ===================================================

$toolsState = $(vmrun -T ws -gu $me -gp $myPwd checkToolsState $VMlocation)
$vmrunExitCode = $LASTEXITCODE

if (($vmrunExitCode -ne 0) -or ($toolsState -ne "running"))
{ [System.Windows.MessageBox]::Show("VMware Tools are not running in the VM", "Failed")
   exit
}

# ======================================== 2 ===================================================

$sourceExistence = $(vmrun -T ws -gu $me -gp $myPwd fileExistsInGuest $VMlocation $source)
$vmrunExitCode = $LASTEXITCODE

if ($vmrunExitCode -ne 0)
{
  $errTitle = "Failed to verify " + $source
  [System.Windows.MessageBox]::Show($sourceExistence, $errTitle)
   exit
}
# This fails with Error: one of the parameters was invalid.

# ==============================================================================================

It seems clear to me that the problem is not the userid or password or $VMlocation because those don't cause any problem in the first of the two commands.

One might think that $source is the problem. But on the successful machine it contains a filename which includes spaces, whereas on the failing machine it is simply "C:\junk.txt" which is a file that does indeed exist on the guest.

I'm stumped!

Kevin

############################

Update: I've changed $source on the first machine to be "C:\junk.txt" just like on the failing machine. It works fine on the first machine.

############################

That is a wonderful compendium of advice which I very much appreciate, Allan! I'm in the process of following your various suggestions. Currently comparing the vmware.log files between the two machines, in case it helps me to answer any of your hints. I'm unaware of a method for uploading the log files to this forum. More later ...

[Allan Solomon Mejia]

Since checkToolsState succeeds using the same VM path and credentials, I agree that $VMlocation, $me, and $myPwd are probably not the issue.

 

Focus on the Guest Operations path used by fileExistsInGuest. That command requires VMware Tools guest authentication and file-operation functionality, whereas checkToolsState only checks the Tools state.

 

One thing that stands out is VMware Tools 10.0.12. Broadcom documents Guest Operations authentication behavior affecting VMware Tools versions from 9.10 through versions earlier than 10.2, including the VGAuth mechanism.

 

As a test, compare the two hosts/VMs for:

 

• Exact VMware Workstation build/version
• Exact VMware Tools installation/components inside XP
• Whether the VMware VGAuth Service and VMware Tools service are running inside the guest
• Any difference in tools.conf
• Whether another guest operation such as listDirectoryInGuest or runProgramInGuest works

 

I’d also try explicitly quoting the guest path:

 

vmrun -T ws -gu "$me" -gp "$myPwd" fileExistsInGuest "$VMlocation" "$source"

 

Since changing $source to C:\junk.txt on the working system still succeeds, the path itself doesn't appear to explain the difference.

 

If the failing VM is using the older VGAuth implementation, Broadcom's documented workaround for Guest Operations issues with Tools 9.10–10.2 is to create:

 

[guestoperations]

useVGAuth = false

 

in C:\ProgramData\VMware\VMware Tools\tools.conf, then restart the VM/Tools service. Treat that as a diagnostic/workaround, though, rather than changing it immediately, because Broadcom also notes security/functionality implications and recommends upgrading Tools where possible.

 

Given that XP has to remain and Tools 10.0.12 is effectively the ceiling here, first compare the VMware Tools/VGAuth services and Workstation versions between the working and failing machines. That should help isolate whether this is a Guest Operations compatibility issue rather than a PowerShell parameter problem.

[KevinRaftery]

Many thanks, Allan!

Following the sequence of your suggestions:

VMware Workstation is the same on both machines (VMware Workstation 17 Pro version 17.5.2 build-23775571).

VMware Tools, according to what I see in vmware.log, look the same. Both logs say:
   TOOLS installed legacy version 10252, available legacy version 12416
   VMX build 23775571, UI build 23775571
   ToolsISO: Selected Tools ISO 'winPreVista.iso' for 'winxppro' guest
   TOOLS setting legacy tools version to '10252' type 1, manifest status is 9
   Using ToolsMinVersion = 8384
   Using ToolsMaxVersion = 10252
   Guest: toolbox-dnd: Version: build-14792880

VGAuthService.exe and vmtoolsd.exe are both running on both guest machines.
On both guests, vmtoolsd.exe is version 10.0.12.2406 and VGAuthService.exe is version 10.0.12.30580.

I can’t find tools.conf - not in ProgramData nor the folder which contains the .vmx file nor on the guest machine. Does it exist in my version?

listDirectoryInGuest and runProgramInGuest both run fine on the successful machine and fail on the other machine with "Error: one of the parameters was invalid".

I tried explicitly quoting the guest path but it made no difference.

So, I've tried to follow your advice and hope that I followed it correctly. Feeling like a failure, however, I snooped further in the vmware.log files.

## 1 ####################################

These errors appear in vmware.log on the failing host, immediately after I’ve run checkToolsState
(nothing similar appears in the successful host’s log):

FILE: FileLockMemberValues file size failure on 'D:\Dell500mVirtualMachine\CloneOfDell500m.vmsd.lck\M62872.lck': The data is invalid

SNAPSHOT: SnapshotConfigInfoLockVmsd: Failed to lock 'D:\Dell500mVirtualMachine\CloneOfDell500m.vmsd': 'Insufficient permission to access the file'.

SNAPSHOT: SnapshotConfigInfoReadEx failed for file 'CloneOfDell500m.vmx': Insufficient permission to access the file (3)

SnapshotVMX_GetDictionaryBuffers: GetDictionaryBuffers failed. Insufficient permission to access the file (3).

VMAutomation: Vix unable to get snapshot tree.

In spite of these log messages, checkToolsState returns a value of “running” and a zero exit code.

I’m puzzled because on neither machine, at no time do I see a vmsd.lck file. Why is this lock file an issue then, on the failing machine?

## 2 ####################################

The very next lines in the failing system’s log are:

SOCKET 7 (908) send error 10054: An existing connection was forcibly closed by the remote host

Vix: [mainDispatch.c:2813]: VMAutomation: Connection Error (4) on connection 1.

SOCKET 7 (908) send error 10054: An existing connection was forcibly closed by the remote host

… whereas the corresponding lines in the successful system’s log are:

SOCKET 7 (3092) recv error 10054: An existing connection was forcibly closed by the remote host

Vix: [mainDispatch.c:2813]: VMAutomation: Connection Error (1) on connection 1.

(These are the only two lines in the log following checkToolsState execution on the successful machine.)

What strikes me is that checkToolsState triggers a send error on one host and a recv error on the other, and the Connection Error numbers differ. Is this meaningful?

## 3 ####################################

My execution of fileExistsInGuest results in only two lines in the log, for both machines, even though the command fails on one machine. Failing:

SOCKET 8 (1828) recv error 10054: An existing connection was forcibly closed by the remote host

Vix: [mainDispatch.c:2813]: VMAutomation: Connection Error (1) on connection 2.

Successful machine:

SOCKET 8 (3164) recv detected remote shutdown

Vix: [mainDispatch.c:2813]: VMAutomation: Connection Error (4) on connection 2.

Is the difference meaningful?

###################################

I'm very willing to follow any more hints. And I appreciate any insights. Thanks again.