Run in background - inaccessable - reboot host needed

[jsa]

Workstation 6.5.0 118166 Windows Vista Ultimate Host.

I've grown fond of Run in background and have used it since extensivly. (I know how it used to work).

The Tray Icon is there, but only shows 1 virtual machine running, (two are) but the tray icon does not show the pop-up list of names and therefore there is no way to get the vmware window to re-appear so I canaccess theVMs.

I can launch another copy but I still can't access the running VM. Reboot seemsthe only way out.

How do you access a vm running in background to bring it to the foreground?

[admin]

This isn't a solution to re-attaching, but maybe a better workaround than rebooting. You can use vmrun to suspend the VM, and then resume it from the Workstation UI ('vmrun suspend /path/to/VM/VM.vmx'). That way, you don't loose the VM's running state.

As for the actual problem, try quitting Workstation, killing all the tray processes, re-run Workstation, and open the VM. Does it re-attach?

[Felix-The-Cat]

Hello jsa,

Could you please provide more info about yours Host System (x32/x64) and HOS (with/without SP1)?

Thanks,

FtC

[jsa]

Host is Vista Ultimate Sp1 on HP Intel Core 2 Quad. (x86_64)

Guests can be anything from Win98 to Xp or Ubuntu. It seems not to matter.

I can't even get the tray icon to appear anymore even tho task manager says it is running.

[admin]

Did you try quitting Workstation and killing (end process) the tray? When I do that, and re-run Workstation, I'm able to attach to the running VM again.

[jsa]

First, upon selecting the big X in the upper right hand corner of the Vmware window, it closes.

So right away, the "Quitting Workstation" is not an option. Its already gone.

The tray icon should 1) show how many are running, 2) provide a pop up list enableing me to

click on one to re-open that VM. It does neither. In fact, it shows to be running as well but

it is no longer visible.

Task manager shows those virtual machines running. A couple of vmware-vms.exe's are

still running. I can't connect to them.

I can re-launch Workstation, but it comes up and clicking on the corresponding machines

in the side bar, or selecting them from the "Window"menu item causes Vmware to just

sit there and do nothing.

All of the machines have the latest tools installed.

[Felix-The-Cat]

Just tried to reproduce same behavior on mine Dell380 System

with VistaEE-sp1_x32.(Ultimate was not ready yet).

For me everything works as expected - I have to even run 2

VMs -VistaEE and XPsp2 - and after "Run in Background" when Vista VM were ‘in

focus', both VM were restored.

BTW, you upgrade to 6.5 or did clean install?

Message was edited by: Felix-The-Cat

[jsa]

Un install, followed by install. I selected the option to leave license in the registry.

Odd thing about that Vmware Tray icon...

Before launching any Virtual machines, right clicking on it shows a menu.

After launching a VM no amount of clicking on it will show a menu.

I'm un-installing Vmware 6.5 and starting again.

I have two licenses. On my Linux host it all works correctly. Even Unity works.

[admin]

Odd thing about that Vmware Tray icon...

Before launching any Virtual machines, right clicking on it shows a menu.

After launching a VM no amount of clicking on it will show a menu.

vmware-tray takes some time connecting to the running VMs, so it sometimes take a short while before it becomes responsive when you first run VMs. If waiting doesn't help, then it sounds like it's stuck waiting (which also explains why you wouldn't be able to reconnect to the VMs through Workstation). Does this always happen, even with a single VM running in the background? Also, is vmware-authd running?

BTW, instead of rebooting your host, it's probably easier to remotely connect to your VMs (e.g. via Remote Desktop or ssh) and to shut down the guests.

[jsa]

Vmware-tray takes some time connecting to the running VMs,

Why? how long does it take to make a socket connection to the same machine?

I have just re-installed, and have a VM running for 15 minutes, and still the tray icon shows no VMs

running. Prior to starting that VM, with workstation running (no vm's launched) I could right click the

the tray icon and get a menu. Now that the vm is running, the tray icon does not honor any clicks.

Does this always happen, even with a single VM running in the background? Also, is vmware-authd running?

Yes, and Yes.

BTW, instead of rebooting your host, it's probably easier to remotely connect to your VMs

Well, ti seems to be the best thing would be avoid running in the BG till Vmware finds this bug because this was

utterly reliable in 6.0.4.

This system seems half 32bit half 64bit. Vmware.exe shows as 32bit in task manager, but vmware-vmx.exe shows

as 64bit. Tray is 32bit. What's up with that?

[admin]

I have just re-installed, and have a VM running for 15 minutes, and still the tray icon shows no VMs

running. Prior to starting that VM, with workstation running (no vm's launched) I could right click the

the tray icon and get a menu. Now that the vm is running, the tray icon does not honor any clicks.

Hm, yeah, that's definitely not right. Could you try opening a background VM in Workstation and then post the UI log file (the location is given in the About dialog)? The vmware-authd log might be helpful too (to enable that, you'd first need to edit "%ALLUSERSPROFILE%\Application Data\VMware\VMware Workstation\config.ini" and add:

vmauthd.logEnabled = "TRUE"

Then restart the VMware Authorization Service (vmauthdservice), and it should create a log file in %WINDIR%\Temp\vmware-SYSTEM.)

This system seems half 32bit half 64bit. Vmware.exe shows as 32bit in task manager, but vmware-vmx.exe shows

as 64bit. Tray is 32bit. What's up with that?

There's nothing wrong with that. The VM itself runs in a 64-bit process (which allows it to use more than 4 GB of memory), but the UI is still a 32-bit process (there's not much benefit to making that a 64-bit process).

[jsa]

> Hm, yeah, that's definitely not right. Could you try opening a background VM in Workstation

Well, not sure what you mean by that, because the whole focus of this thread is that I can't do didly with a backgrounded machine. If I background it, its lost for good, and all I can do is open task-manager and kill it. I've already corrupted one machine to the point I have to restore from a backup.

I did see this reference to authd in the log of a windows 2000 backgrounded machine after it was shutdown:

Sep 25 21:02:40.942: mks| MKS switching absolute mouse on

Sep 25 21:02:54.630: mks| CnxHandleConnection: WSASocket returned error 10022.

Sep 25 21:02:54.630: mks| MKS REMOTE failed to complete async op for authd connection!

Sep 25 21:02:54.644: vmx| VMXVmdbCbVmGuestResolutionSetJob: Sending rpcMsg = Resolution_Set 1920 1170

Sep 25 21:02:54.769: mks| SVGA: Sync FIFO with SVGA disabled

Authd shows its running in task manager.

> The vmware-authd log might be helpful too (to enable that, you'd first need to edit "%ALLUSERSPROFILE%\Application Data\VMware\VMware Workstation\config.ini"

The only thing vaguely like that is located in C:\ProgramData\VMware\VMware Workstation\

Log follows in-line below:

I restarted the authd service, fired up Workstation, opened a windows machine (tray icon became unresponsive),

Exited Worstation (backgrounding windows vm), tray icon still unresponsive, fired up Task Manager and

Terminated the vmware-vmx (At which point all pending clicks upon the tray icon took effect and it popped

up its context menu. Then I shut down authd service so I could get access to the log, and pasted it in

here. Its fairly short.

Sep 26 01:26:13.263: app| Log for VMware Workstation pid=4032 version=6.5.0 build=build-118166 option=Release

Sep 26 01:26:13.263: app| Host codepage=windows-1252 encoding=windows-1252

Sep 26 01:26:13.263: app| Log file is C:\Windows\Temp\vmware-SYSTEM\vmware-vmauthd-SYSTEM-4032.log

Sep 26 01:26:13.357: app| totalPhysicalMemoryInBytes = 4293275648, totalPhysicalMemoryInPages=1048163

Sep 26 01:26:13.357: app| Slack(1024) Skip (1)

Sep 26 01:26:13.357: app| minPercentTotalMemForMonitor=50

Sep 26 01:26:13.357: app| minTotalMemForMonitorInPages=524081

Sep 26 01:26:13.357: app| HostFilterInit: No host policy file found or HQ not enabled and no policy server configured. Not initializing filter.

Sep 26 01:26:13.357: app| Service Started.

Sep 26 01:26:18.365: app| Initialize hardLimit.

Sep 26 01:26:28.380: app| HardLimitMonitor. Too many page faults (590). Scale limit down to 748391

Sep 26 01:26:33.387: app| HardLimitMonitor. Too many page faults (1228). Scale limit down to 748386

Sep 26 01:26:38.395: app| HardLimitMonitor. Too many page faults (1679). Scale limit down to 748380

Sep 26 01:26:43.418: app| HardLimitMonitor. Too many page faults (1802). Scale limit down to 748373

Sep 26 01:26:48.426: app| HardLimitMonitor. Too many page faults (1551). Scale limit down to 748375

Sep 26 01:26:53.433: app| HardLimitMonitor. Too many page faults (1168). Scale limit down to 748371

Sep 26 01:26:58.441: app| HardLimitMonitor. Too many page faults (551). Scale limit down to 748373

Sep 26 01:27:03.443: app| HardLimitMonitor. Too many page faults (692). Scale limit down to 748387

Sep 26 01:27:08.446: app| HardLimitMonitor. Too many page faults (1029). Scale limit down to 748384

Sep 26 01:27:13.469: app| HardLimitMonitor. Too many page faults (1202). Scale limit down to 748385

Sep 26 01:27:18.476: app| HardLimitMonitor. Too many page faults (796). Scale limit down to 748383

Sep 26 01:27:23.484: app| HardLimitMonitor. Too many page faults (745). Scale limit down to 748386

Sep 26 01:27:28.492: app| HardLimitMonitor. Too many page faults (1288). Scale limit down to 748384

Sep 26 01:27:33.499: app| HardLimitMonitor. Too many page faults (1547). Scale limit down to 748389

Sep 26 01:27:38.507: app| HardLimitMonitor. Too many page faults (1843). Scale limit down to 748322

Sep 26 01:27:43.530: app| HardLimitMonitor. Too many page faults (1434). Scale limit down to 748316

Sep 26 01:27:48.538: app| HardLimitMonitor. Too many page faults (1175). Scale limit down to 748318

Sep 26 01:27:53.545: app| HardLimitMonitor. Too many page faults (521). Scale limit down to 748315

Sep 26 01:27:58.553: app| HardLimitMonitor. Too many page faults (400). Scale limit down to 748315

Sep 26 01:28:03.560: app| HardLimitMonitor. Too many page faults (1474). Scale limit down to 748325

Sep 26 01:28:08.568: app| HardLimitMonitor. Too many page faults (2008). Scale limit down to 748328

Sep 26 01:28:13.591: app| HardLimitMonitor. Too many page faults (1966). Scale limit down to 748332

Sep 26 01:28:18.599: app| HardLimitMonitor. Too many page faults (1518). Scale limit down to 748330

Sep 26 01:28:22.858: app| Username associated with named pipe: jsa

Sep 26 01:28:22.858: app| HOSTINFO 284942347724 @ 14318180Hz -> 0 @ 1000000Hz

Sep 26 01:28:22.858: app| HOSTINFO ((x * 2399728063) >> 35) + -19900737917

Sep 26 01:28:22.889: app| Cannot connect to VMX: C:\Users\jsa\VMware\xubuntu\Ubuntu.vmx

Sep 26 01:28:23.606: app| HardLimitMonitor. Too many page faults (4927). Scale limit down to 747820

Sep 26 01:28:26.414: app| Username associated with named pipe: jsa

Sep 26 01:28:26.446: app| Cannot connect to VMX: C:\Users\jsa\VMware\win98\win98.cfg

Sep 26 01:28:28.614: app| HardLimitMonitor. Too many page faults (5122). Scale limit down to 746218

Sep 26 01:28:33.622: app| HardLimitMonitor. Too many page faults (6059). Scale limit down to 746280

Sep 26 01:28:33.715: app| Username associated with named pipe: jsa

Sep 26 01:28:33.715: app| Allocating a new session

Sep 26 01:28:33.715: app| CreateLogonSession: spawn with username: jsa

Sep 26 01:28:33.715: app| (Account is NOT administrator)

Sep 26 01:28:33.715: app| (Account is interactive)

Sep 26 01:28:33.762: app| Not mapping drives for acct

Sep 26 01:28:33.762: app| Process '-# "product=1;name=VMware Workstation;version=6.5.0;buildnumber=118166;licensename=VMware Workstation for Win32;licenseversion=6.0 build-118166;" -@ pipe=
.\pipe\vmx9ab00c182959ebbe; C:\Users\jsa\VMware\win98\win98.cfg' created with pid 5744

Sep 26 01:28:34.916: app| Username associated with named pipe: jsa

Sep 26 01:28:35.105: app| Username associated with named pipe: jsa

Sep 26 01:28:38.630: app| HardLimitMonitor. Too many page faults (7590). Scale limit down to 752328

Sep 26 01:28:43.632: app| HardLimitMonitor. Too many page faults (7751). Scale limit down to 756917

Sep 26 01:28:48.639: app| HardLimitMonitor. Too many page faults (8338). Scale limit down to 761354

Sep 26 01:28:53.653: app| HardLimitMonitor. Too many page faults (3154). Scale limit down to 762989

Sep 26 01:28:58.668: app| HardLimitMonitor. Too many page faults (4462). Scale limit down to 774387

Sep 26 01:29:03.683: app| HardLimitMonitor. Too many page faults (2399). Scale limit down to 775672

Sep 26 01:29:08.698: app| HardLimitMonitor. Too many page faults (2511). Scale limit down to 776142

Sep 26 01:29:13.729: app| HardLimitMonitor. Too many page faults (3103). Scale limit down to 776370

Sep 26 01:29:18.742: app| HardLimitMonitor. Too many page faults (4119). Scale limit down to 776357

Sep 26 01:29:23.755: app| HardLimitMonitor. Too many page faults (3729). Scale limit down to 776352

Sep 26 01:29:28.769: app| HardLimitMonitor. Too many page faults (1283). Scale limit down to 776344

Sep 26 01:29:33.783: app| HardLimitMonitor. Too many page faults (410). Scale limit down to 776344

Sep 26 01:29:38.796: app| HardLimitMonitor. Too many page faults (1193). Scale limit down to 776325

Sep 26 01:29:43.821: app| HardLimitMonitor. Too many page faults (1314). Scale limit down to 776313

Sep 26 01:29:48.834: app| HardLimitMonitor. Too many page faults (1222). Scale limit down to 775908

Sep 26 01:29:53.847: app| HardLimitMonitor. Too many page faults (428). Scale limit down to 775885

Sep 26 01:29:58.861: app| HardLimitMonitor. Too many page faults (306). Scale limit down to 775936

Sep 26 01:30:03.874: app| HardLimitMonitor. Too many page faults (181). Scale limit down to 775940

Sep 26 01:30:08.888: app| HardLimitMonitor. Too many page faults (6772). Scale limit down to 775725

Sep 26 01:30:13.914: app| HardLimitMonitor. Too many page faults (6926). Scale limit down to 776059

Sep 26 01:30:18.928: app| HardLimitMonitor. Too many page faults (7623). Scale limit down to 775999

Sep 26 01:30:23.943: app| HardLimitMonitor. Too many page faults (1607). Scale limit down to 775986

Sep 26 01:30:28.956: app| HardLimitMonitor. Too many page faults (1463). Scale limit down to 776088

Sep 26 01:30:33.971: app| HardLimitMonitor. Too many page faults (1174). Scale limit down to 775942

Sep 26 01:30:38.985: app| HardLimitMonitor. Too many page faults (628). Scale limit down to 776028

Sep 26 01:30:44.009: app| HardLimitMonitor. Too many page faults (808). Scale limit down to 776032

Sep 26 01:30:49.047: app| HardLimitMonitor. Too many page faults (578). Scale limit down to 746205

Sep 26 01:30:54.055: app| HardLimitMonitor. Too many page faults (3421). Scale limit down to 745662

Sep 26 01:30:54.242: app| Username associated with named pipe: jsa

Sep 26 01:30:54.258: app| Cannot connect to VMX: C:\Users\jsa\VMware\xubuntu\Ubuntu.vmx

Sep 26 01:30:54.772: app| Username associated with named pipe: jsa

Sep 26 01:30:54.788: app| Cannot connect to VMX: C:\Users\jsa\VMware\win98\win98.cfg

Sep 26 01:30:59.062: app| HardLimitMonitor. Too many page faults (3988). Scale limit down to 745726

Sep 26 01:31:04.070: app| HardLimitMonitor. Too many page faults (3963). Scale limit down to 745839

Sep 26 01:31:09.078: app| HardLimitMonitor. Too many page faults (1522). Scale limit down to 745845

Sep 26 01:31:10.357: app| Username associated with named pipe: jsa

Sep 26 01:31:10.388: app| Cannot connect to VMX: C:\Users\jsa\VMware\win2000Pro\win2000Pro.cfg

Sep 26 01:31:14.101: app| HardLimitMonitor. Too many page faults (977). Scale limit down to 745781

Sep 26 01:31:19.108: app| HardLimitMonitor. Too many page faults (779). Scale limit down to 745677

Sep 26 01:31:24.116: app| HardLimitMonitor. Too many page faults (389). Scale limit down to 745676

Sep 26 01:31:29.139: app| HardLimitMonitor. Too many page faults (256). Scale limit down to 745677

Sep 26 01:31:34.146: app| HardLimitMonitor. Too many page faults (292). Scale limit down to 745952

Sep 26 01:31:39.153: app| HardLimitMonitor. Too many page faults (271). Scale limit down to 745956

Sep 26 01:31:44.161: app| HardLimitMonitor. Too many page faults (385). Scale limit down to 745974

Sep 26 01:31:48.232: app| Username associated with named pipe: jsa

Sep 26 01:31:48.264: app| Cannot connect to VMX: C:\Users\jsa\VMware\xubuntu\Ubuntu.vmx

Sep 26 01:31:48.310: app| Username associated with named pipe: jsa

Sep 26 01:31:48.326: app| Cannot connect to VMX: C:\Users\jsa\VMware\win2000Pro\win2000Pro.cfg

Sep 26 01:31:48.763: app| Username associated with named pipe: jsa

Sep 26 01:31:48.778: app| Cannot connect to VMX: C:\Users\jsa\VMware\win98\win98.cfg

Sep 26 01:31:49.168: app| HardLimitMonitor. Too many page faults (3568). Scale limit down to 745753

Sep 26 01:31:54.176: app| HardLimitMonitor. Too many page faults (3662). Scale limit down to 745988

Sep 26 01:31:59.184: app| HardLimitMonitor. Too many page faults (3502). Scale limit down to 746004

Sep 26 01:32:04.191: app| HardLimitMonitor. Too many page faults (889). Scale limit down to 746011

Sep 26 01:32:09.199: app| HardLimitMonitor. Too many page faults (1207). Scale limit down to 746001

Sep 26 01:32:14.222: app| HardLimitMonitor. Too many page faults (1369). Scale limit down to 746064

Sep 26 01:32:19.231: app| HardLimitMonitor. Too many page faults (786). Scale limit down to 746057

Sep 26 01:32:24.243: app| HardLimitMonitor. Too many page faults (6653). Scale limit down to 745659

Sep 26 01:32:29.250: app| HardLimitMonitor. Too many page faults (6556). Scale limit down to 745907

Sep 26 01:32:34.258: app| HardLimitMonitor. Too many page faults (6510). Scale limit down to 745920

Sep 26 01:32:36.270: app| Service Stopped.

[admin]

I don't think there's a need to kill the vmx process. I'll explain my earlier suggestion in more detail. There's a separate program included with Workstation, called 'vmrun', which can be used to interact with VMs (locally and remotely). You can use this program on the command line to suspend the VM (whether or not Workstation is running). So, if you can't access a VM through Workstation or the tray, try vmrun.

If that doesn't work, please attach some log files to a post (there's an attach files dialog below this text entry box). To get better logs, put this into "C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\config.ini":

vix.debugLevel = "9"

Then run vmrun, and attach the most recent versions of these log files (check the date of the files):

1) C:\Documents and Settings\\vmware.log

[jsa]

> There's a separate program included with Workstation, called 'vmrun'

Sorry, I saw that post above, but forgot to respond.

I did indeed try that.

The command line invocation, nasty as it was due to the horrendous pathing issue, just sat there and did nothing. The backgrounded machine didn't respond, and nothing seemed to change. The more I look at this the more it seems that nothing can talk to the control channel of these backgrounded VM.

I know the VM is working in the background, because I can start processes in the VM and communicate with them from elsewhere.

Side rant: Wat deid Vmwhere do 2 my firefax spellink cheka?

[admin]

> Hm, yeah, that's definitely not right. Could you try opening a background VM in Workstation

Well, not sure what you mean by that, because the whole focus of this thread is that I can't do didly with a backgrounded machine.

I meant: make an attempt to open the VM in Workstation (at which point Workstation might write some hint about the failure reason to its log file). But given the authd connection errors, it seems unlikely that the Workstation log will provide much insight. I'm not sure what could be causing those.

If I background it, its lost for good, and all I can do is open task-manager and kill it. I've already corrupted one machine to the point I have to restore from a backup.

Hence my suggestion that you remotely shut down the guest via RDP/ssh/psshutdown/etc. instead of hard killing the process.

[jsa]

The 'vmrun' program will start a VM that is not running, but it then just hangs till the VM is shutdown. The command never returns to the command line and theVM will not respond to additional vmrun commands issued subsequently from additional cmd windows.

I'm not sure that is how its supposed to run that way in Windows. Seems unlikely, since it doesn't run that way in Linux. The command line terminates as soon as the vm launches.

This sounds to me like this all part of the same problem, where the VMs can't be communicated with by the Vmware control channel.

I've shutdown the windows firewall, and my virus scanner. The VMs are all using (only) bridged connections (if that matters).

[jsa]

So it looks like I am oging to have to burn a support incedent on this issue?

No one else having problems restoring backbrounded machines?

[Merlin1]

Same problem - actually just very similar - by me. Closing the workstation window, choosing the run in backgound mode and than I can't activate this guest again. Well, as I said not exactly: The tray icon is OK (I have another story to this), and shows that "n" virtual machine is running, so I choose the open all background VM option and the things starts working strange here. I become an error message: "Another instance of VMware Workstation is already running this configuration file. Module VWAutomatization initialization failed.", in meanwhile I can access the guest in the workstation window. But just until I click on the OK button on the first metioned error message. At this point the guest windows closing themself and again another message simply just say that "Pipe: Read failed".

By the way: Also an error generated in the host's (XP-x64) event log right after I started the vmware application to every guest op system.All the same, for example: "Cannot connect to VMX: D:\VirtualMachines\wsrv2k8coree\w2k8coree.vmx"

Fortunately I don't have that problem with vmrun.exe and I can access the guest with it. Even I can access its web interface (for example by the openfiler distro) -using NAT- from the host's browser.

About the tray icon: This is a reinstalled VMware, because at first time the vmware-tray.exe act just like by jsa. First time I installed VMware just simply choosed hiding the icon, which I didn't do now. Of course, I still don't understand why was I unable at first time to "reactivating" it, but whatever....it's just a test environment for learning.

[DuncanArmstrong]

You two aren't alone - I've got the same issue. I suspect that it's occurring on 64-bit systems only.

I'm running Vista x64 here, it never happened on my 32-bit installations on various flavours of Windows. I'm going to have to talk to our boys in Hosted to see if they know what's up, and if not, to get a bug filed.

If you do, or have engaged VMware Support, please post the end-result.

[TShepherd]

I have the same or similar issue. I'm running on Windows XP 64-bit with 8GB of ram using VMWare Workstation 6.5.0 build 118166.

One interesting thing I just noticed is VMWare Workstation detects my host OS as Windows Server 2003 Standard Edition with SP2. I have XP 64-bit with SP3.

I had two VMs up and running for several days. This morning I walked away from my PC and when I came back VMWorkstation was no longer open, and there was no VMWare tray icon visible. The VMs are still running in the background as indicated by two vmware-vmx.exes running using 2 GB of ram each.

I had this problem sometime before, but was able to resolve using what someone suggested earlier: vmrun. I suspended both VMs, then restarted my host machine. You could also probably remote desktop to the VM (if enabled) and shutdown from within the VM itself.