VMware Horizon View Client 2.1 crash during connecting to desktop pool

[solgae]

Upon updating to Horizon View Client to version 2.1 from 2.0, every time I try to connect to the desktop pool after logging in to the connection server, it stays on the "connecting..." message for a bit before it crashes. This has been the case regardless of which connection server I use. Are there any others who is having this similar issue with the new OS X client version?

[solgae]

I'll work with our service owner to fill the bug report - my account does not have the permission to open the SR for Horizon View. Thank you for your assistance.

[YunYiQun]

Hi Solgae,

Did you have a chance to report the bug?

We haven't received any related bug from customer to this issue.

[solgae]

Support request has been filled in: 13373460309

[YunYiQun]

Hi solgae,

OK, so far it hasn't been reached to us(the developer team).

Could you please have a look at in ~/Library/Logs/DiagnosticReports dir, if there is a crash report file that begins with vmware-remotemks_***.crash that has the same date as vmware-view_****.crash when this issue happened?

Is it possible for us to remote to your desktop to have a look?

[solgae]

I found that there is no vmware-remotemks_***.crash file on the directory ~/Library/Logs/DiagnosticReports - only the vmware-view_****.crash file is present when the crash occurs. So it looks like the crash happens before the remotemks process can be triggered.

I don't know if I'll have to time for a remote session, but I can send you the crash file if that helps - the crash always happens whenever I double-click on the desktop pool with PCoIP session, and when it is on the stage "Connecting to Desktop...". There are no problems if I choose the RDP option.

[YunYiQun]

Hi solage,

Thanks for your trying. View Client crashes because of rmks process failing to start. (RDP connect doesn't need rmks process)

So far we can't tell why rmks doesn't run successfully without rmks crash report and logs.

We are trying to get it fixed in 2.2, but we don't have an env to reproduce it locally, which makes us be stuck.

Could you please help to remove this folder and try again ?

/Applications/VMware Horizon View Client.app/Contents/PlugIns/PCoIPVMView.bundle/Contents/MacOS/pcoip/vchan_plugins/rdpvcbridge

[solgae]

Just tried that and no difference. Did not generate any crash report on remotemks process.

[YunYiQun]

Hi Solgae,

Does it only reproduce on the specific machine for 2.2 version?

Would you please escalate this issue in the SR you opened so that we can give you some debug version to have a test in order to locate the issue since we can't reproduce it?

[solgae]

I know at least one person who owns the MacBook Air that has version 2.1, and he doesn't have any issues with it using PCoIP. Mine is a Mid-2010 model Macbook Pro.

[jo_strasser]

Hi,

if you are connecting from a home network, please try to clean up your dns server (reboot router) or renew your ip/dns settings.

[zhanglin999]

Hi, solgae,

Developer team had analyzed the logs carefully and found the vmware-remotemks process exit unexpectedly so that it cause view client crashed, but team cannot reproduce this issue in local env and there is no rmks log in provided log, so it's very hard to dig out what's the root cause. Could you kindly help us to do some verify step and collect log again when this issue reproduced? Thanks in advance.

1. Please clean the log directory "~/Library/Logs/VMware/" and "~/Library/Logs/VMware Horizon View Client/" first.

2. Please make sure there is no zombie process with name "vmware-remotemks" before launching view client.

3. Add following two lines into "~/Library/Preferences/VMware Fusion/config", if this file doesn't exist, you can create it by yourself:

log.stderrMinLevel = 145

log.logMinLevel = 145

4. When view client crashed, run "ps -ef | grep vmware-remotemks" to verify the rmks process status and paste output here.

5. Attached the log files in  "~/Library/Logs/VMware/" and  "~/Library/Logs/VMware Horizon View Client/"

[solgae]

I followed your instructions and attached the log files here. The problem I'm seeing is that vmware-remotemks process seems to be failing to launch at all.

Performing ps -ef | grep vmware-remotemks command while the client is trying to connect to the desktop shows the following vmware-remotemks process:

vmware-remotemks -@ vmdbPipeHandle=81; vm=0; gui=true -H 83 -P 3 -# product=1;name=VMware Fusion;version=e.x.p;buildnumber=1197147;licensename=VMware Fusion for Mac OS;licenseversion=6.0; -s mks.vdp.plugin.name=pcoip_client -s mks.autoAnswer=TRUE -s msg.noOK=TRUE -s mks.keyboard.useETKeyboard=FALSE -s remotemks.noDoubleFork=TRUE

The process is exited once the client is crashed.

I'm not sure why the product name is indicating Fusion with the exp build number on it. I do remember having a public beta of Fusion at one point. Is that affecting the vmware-remotemks launch process?

[zhanglin999]

Hi, solgae,

Thanks for your log, developer team have found some clue about this issue, but we still need your help to confirm something:

1. Which type of network interface you used on your macbook air? wireless or usb ethernet adapter? Can this issue be reproduced on both type of network?

2. Could you provide the log when VMware View Client works well? Per the post before, I think only the version 2.0 works, right? If so, please provide the log of 2.0 client.

Thanks very much.

zhanglin

[solgaeDK]

1. I am not using a Macbook Air - it's a mid-2010 Macbook Pro model. I get this crash problem regardless of which network adapter I'm using - internal ethernet or wifi.

2. Logs attached while running 2.0 client (after clearing all the logs per the instructions).

[zhanglin999 · Accepted solution]

Thanks, solgae. Developer team may have found the root cause, so there is a patch which include the fix, could you help to verify it?

1. Backup the libpcoip_client.dylib in directory "/Applications/VMware Horizon View Client.app/Contents/PlugIns/PCoIPVMView.bundle/Contents/MacOS".

2. Replace it with the patched libpcoip_client.dylib.

3. If this patch doesn't work, please provide the log.

-- zhanglin

[solgae]

The patched file now allows me to connect to the desktop using PCoIP with 2.1 client - Thank you for staying with me to get to the bottom of this!

I do have a new problem in that USB redirection and print redirection isn't working, but that would be more because I'm now running OS X Mavericks. I confirmed USB redirection isn't working on 2.0 client as well.

(In case you're wondering, the crash was happening on Mavericks as well)

[yuleyl]

Hi solgae,

For your USB redirection issue, are you launching the Fusion while using View Client? And what's the Fusion version you're using?

There are some compatibility issue on USB redirection and Virtual Printing between View Client with Fusion 6.0. For USB redirection compatibility issue, it has been fixed in Fusion 6.0.1, you can upgrade to this version.

For the Virtual Printing compatibility issue, please refer KB "http://kb.vmware.com/kb/2054095" for the workaround.

Thanks.

[YunYiQun]

Hi solgae,

Good to know that you can connect with the attached libpcoip_client.dylib.

Our pcoip developer wants to ask below information from you, would you kindly provide them:
[1] iptable, routetable

[2] arp -a to get the arp cache

[3] netstat -a to get the ip infos.

[4] traceroute 8.8.8.8 to get the trace infos.

[solgae]

I'm using Fusion 6.0.2, and still see the problem. But it looks like USB redirection issue happens when I'm connected to View 5.1.2 desktop. When I'm connected to View 5.2 desktop, USB redirection works fine.

I followed the KB article for print redirection, and I confirmed it was working with View 5.2 desktop. Any plans on making it play nice with the Fusion without resorting to the workaround every time after using Fusion?

EDIT: Looks like I need to test more before I post it. View 5.1.2 seems to be more picky with the type of USB drive I use compared to View 5.2. Some USB drives will work with USB redirection while some won't.

[YunYiQun]

Hi solgae,

2.2 fixed the printing redirection issue that conflicts with Fusion. So the workaround for the printing redirection is not needed in 2.2.

Would you kindly provide below information, that will be helpful for us to know better why the connect failed in your case:
[1] iptable, routetable

[2] arp -a to get the arp cache

[3] netstat -a to get the ip infos.

[4] traceroute 8.8.8.8 to get the trace infos.