Black Boxes on VMware View Windows 7 x64 Desktops (Bitmap Cache Issue)

[Rob81]

Hello there,

I've come here in the hope that some kind people will be able to give me some advice/pointers for an issue I currently have with our VDI setup, thats starting to seriously grate on me.

We have just started to witness what I believe to be caused by 'Bitmap Caching' on only SOME of our VDI Windows 7 desktops, and its only happening with the users running x64 desktops. The x86 users are completely fine and happy as can be.

The issue, appears to be exactly the same as the two links underneath:

- http://communities.vmware.com/message/1463298#1463298

- http://communities.vmware.com/message/1334250#1334250

In terms of setup, we have users using Dell Wyse P20 Zero clients, Dell Wyse CL10 units and then a minority of users running the View 5.0 client from their laptops to connect to desktops.

The issue is certainly more apparent in the users running the View client from their laptops and the users running P20 units.

I'm afraid, I am very new to alot of this, though I am aware that bitmap caching is the likely culprit, I am unsure what the best way is to disable it? I've imported the client.adm template from the View Management Server, which contains the GPO stuff for enabling/disabling. Doesnt seem to have worked though from what we can see and the GPO lists as RDP Settings, will this work given the majority of the suers are using the PCOIP protocol on the Wyse P20 units?

Can Bitmap Caching be disabled manually on each View desktop by adding specific entries to the registry? (Mainly the P20 users, but again, they're using PCOIP, so how is that even going to work given I'm under the impression Bitmap Caching is related to RDP and not PCOIP)

Any help on the issue would be massively appreciated, its causing huge amounts of frustration for users at present and really dimmed their view on the VDI experience I feel.

Many thanks in advance.

[MattLesak]

Rob,

P20s don't support client side caching, so if they're experiencing the issue, it has to be something else (which helps narrow down the issue).  Typically, this issue is seen because the guest VM isn't allocated enough video memory for the resolution they're requesting.  It could be that the users that aren't seeing this issue are running at lower resolutions, but again, this is just a guess at this point in time.

Questions:

Are these stand alone or linked clone desktops?

What the maxium resolution and monitors set for the pool?

On the master guest image, did you set the video memory within the VM settings or just leave at default?

Which protocol do you have enabled for the pool (RDP, PCoIP, or both)?

Regards,

Matt

[Stu_Robinson]

Hi Rob,

Matt has some good suggestions!  I have also heard reports of black borders/lines on both View clients and PCoIP zero clients, although it appears more frequent on the zero clients (may be that the zero client operates in full-screen mode).  As Matt points out, this is not related to bit-map caching since the Tera1 zero clients do not support caching (Tera2 zero clients will support caching).

Others have reported that the following may reduce or eliminiate the issue:

• For Office 2007 - disable display hardware acceleration in each office application
• For Office 2010 - disable display hardware acceleration in one office application (the setting is copied to other Office apps).  Ie For Excel - File> Options > Advanced>  Display section and click on "Disable hardware graphics accleration"
• Also, there appears to be a reduction of black lines/borders if the VM has 3D enabled AND the Windows 7 3D is turned on (run the Aero troubleshooter and enable 3D - you can turn transparency off). 

If those suggestions do not work, then I would suggest opening a SR with VMware.

Regards,

Stu

Director of Systems Engineering,

Teradici

[Rob81]

Thanks Matt and Stu for taking the time to reply with suggestions and feedback thus far, highly appreciated.

Firstly Matt, its good to hear that bitmap caching is not supported as indeed, this throws that theory out of the window, I did wonder if they did, given the fact they're zero clients and have no OS.

The vRAM for the video side is something I've looked at as I initially thought this may be having an effect.

Questions:

Are these stand alone or linked clone desktops?
- All of the guests are stand alone. Deployed from golden images direct via View.

What the maxium resolution and monitors set for the pool?

- Max resolution is currently 1680x1050, with max monitors set to 4. (All users have duel monitors) We had to set it to 4 initially because if we set it any lower, view would reconfigure the vRAM for the video display from 128mb to something much lower. When set to 4, View doesnt reconfigure it and keeps the video vRAM at 128mb.

On the master guest image, did you set the video memory within the VM settings or just leave at default?

- This was left as default as far as I'm aware and wasnt touched at all during the image build.

Which protocol do you have enabled for the pool (RDP, PCoIP, or both)?

Both protocols are enabled and usable by the user for the pools.

I guess its worth re-mentioning this is only happening to Windows 7 x64 guests and generally only when using PCOIP.

Something else that may be of significance, is that one of the recent users developed it AFTER he was given a Wyse P20 for a day as he had left his laptop at home. He had been using the View client via a laptop for 4 months (duel monitors) without a single issue. He used the P20 and then swapped back to his laptop the next day. Several days later he started to develop these black box symptons, nearly always when first logging in after locking the desktop or first coming in at the start of the day. Rebooting the guest, would generally clear it up. The user is again using a Windows 7 x64 desktop and was using PCOIP. I recently changed the pool setting to RDP only and he was able to login straight away, without any black boxes or lines on the screen again. But again, in previous examples where users were using P20's the issue would nearly always occur after the screen had been locked. We're yet to see it in office or in mid use.

I have a SR open with VMware for this but were not really going anywhere at present and I get the impression they're struggling to find anything on this. One thing that has been suggested to me by someone, is changing the graphics display driver that the guests use.

Cheers

Rob

[MattLesak]

In regards to the master image you're using for cloning, you can check the virtual hardware settings to see if vRAM was set to a value or left at auto/default.  It should be never set to a value and left to the default config.  The View Agent communicates the endpoints video requirements to the guest dynamically.  If a value is set, it can break this process.

Do you have the latest version of firmware loaded on the P20s?

What is the monitor configuration of the P20s?  (If you have dual monitors, is it configured on the P20 for dual monitors, etc.)

Have you updated the VMware Tools lately?  If so, you must re-install the View Agent in order to ensure you have the correct video driver.  This can cause issues.  We realize it's a pain and we're working internally to remove this order of operations.  One of the "golden rules" with View is to always install the Agent last to ensure the proper video driver is used.

On the Windows 7 x64 guests where this is occuring, I would suggest checking the vRAM setting while the user is experiencing the issue.  I'm just curious to see if the P20 is somehow not reporting the proper # of monitors, etc. therefor causing the vRAM settings to be misaligned.

FYI - Caching occurs in RAM, not local disk, so it's disregarded once the session terminates.

[kingmarino]

Hello,

We just started testing the new Wyse P25 (with the new Tera2 chip that supports bitmap caching) and the black box problem just started for us.  We have been running Wyse P20 with Windows 7 64 bits VM's without this problem for the past 18 months, so this is 99.9% related to bitmap caching.

I just openned a case at Terradici, but the are allready trying to rebound this problem back to VMware.

Help/ideas needed please

Regards

Frank

[kingmarino]

Guys,

Correction: After trying to push the P20, we have gotten the same problem that we have on the P25.  So this is not 100% sure a bitmap caching problem after all.  Still doing test on video settings, will report back teh results here..

Frank

[kingmarino]

Hello,

I finally found a solution that corrects the problem for us.  In View, you configured the "Max number of monitors" to 4.  This will allocate close de 100MB RAM for video RAM and voila, no more black squares anymore.  Tested with Wyse P20 and Wyse P25...

Frank

[Rob81]

Hello all,

I thought prudent to give an update on the issue, given I initially started this topic.

We have been speaking to VMware in great depth about this issue, including a continued support ticket thats been open now for two weeks.

Essentially, following advice on here and from VMware, we have completely rebuilt one of our golden deployment images and thus far, though it is maybe a little early to start jumping around, but no sign of the black boxes all over the screens. We ensured the VMware View agent went onto the build in last position.

We've just rolled out a new starter this morning using the new template. We had tested the new template for a good week prior to today with a test desktop and didnt see the issue, so I'm really preying it doesnt bite back with an actual live user now =/

Many thanks for the contributions on this thread. Will continue to keep this updated, and hopefully the next time will be with an "all clear"

[LarryBlanco2]

I too am suffering from this.   We didn't have any issues until we upgraded our VM HW to v8.  Previously they were all HW v7 in View 5.0.  When we migrated to View 5,1 and decided to upgrade the HW version of the VM themselves to v. 8 is when we started experiencing this issue.

I have tried all the recommended workarounds here to no avail.  It seems to occur when we run some processes within an application that does logistics management.

I've attached a picture of the screen.  If I try to do a screen print it does not show.  If I look at the desktop from within the vSphere console. I don't see the black lines.   I've tried it from View client on windows, P20, P25.  All with the same results.

Just to add if I have other applications open then the black borders are all over that too.  It doesn't matter what app.  It occurs all over the runing app as well.

Larry B.

[kingmarino]

Larry,

We fixed our black box problem this way:

Option 1: If you configure your VMware View pool to use the "3D rendering option", you need to enable AERO inside Windows 7 (you can have AERO transparency enable or disable, it works with both options)

Option 2: If you configure your VMware View pool without the "3D rendering option", you need to configure you pool options with "allow up to 4 monitors".  This will add mode RAM to the virtual video card and also solve the black box issue.

We have been using both methods for 2 different needs we have and neither have had the black box problem..

Regards

Frank

[LarryBlanco2]

Yeah, unfortunately it does not work for me.  I have aero enabled in windows.  In view I have 2 monitors (Max # with 3D on) and 128MB of video memory set.  

I still get the black lines.   Something goes on with the PCoIP rendering that causes the bitmaps on the screen to go whacky.  It does not occur with RDP.  I get a perfect picture with RDP.   I have had to have my users who use this specific application use RDP instead of PCoIP.

I'll too will need to create a ticket with VMWare, I guess, and see what they come up with.

I do still have my old environement and have 2 desktop   One with HW v.7 one with HW v.8 and exact same setup of apps and config on the VMs.  The HW v.7 VM has no issues. The one with HW v.8 suffers from the black boxes/lines problem.

Larry B.

[kingmarino]

Larry,

Do you have "build to loseless" PCoip group policy disabled on your pool?

[LarryBlanco2]

I do not have the group policy disabled.  So the desktops do build the screen to a lossless state.  Should I disable?

Larry B.

[LarryBlanco2]

Actually looking at the policy by default the system builds to a lossless state.  enabling the policy it will disable build to lossless.

Larry B.

[kingmarino]

Thats is Larry, you need to enable the group policy to disable "build to loseless".  VMware highly recommends disabling "build to loseless".  I saw a big improvment in performances when I did that.  Your Windows 7 VM will less work to display what they have to display.

[LarryBlanco2]

I will go ahead and disable build to lossless.  I will report my outcome once completed and tested.

Thank you,

Larry B.

[LarryBlanco2]

So I have tried everything I can with this issue and it still persists.  I have the policy "Turn off Build to Lossless" enabled.  3D turned on, and set the VM to 128MB of video memory and my results are still the same.  I get the black boxes/lines in the application.   Weird thing is that is seems only to occur when you actually make the application do something.  You click a button for the app to do some work and bam, black lines appears.  This only occurs with PCoIP.  RDP works without a hiccup.

I am opening a case with VMWare and hoping for the best.

Larry B.

[bhamm]

I'm seeing the same issue here.  We have one particular pool that does this, but we have several other windows7x64 desktops that don't.  There's one particular function in a program that this group uses that seems to kick off the issue.  In our case, it happens on the software clients (people testing before moving to virtual desktops), but not on the teradici zero clients.Most of the areas that have black lines seem to be objects that change when you mouseover them.

On my own desktop, I've seen something similar happen when I share my desktop in a WebEx session, or in ms remote assistance.  It ends when the application ends, though.

I've had a ticket open with VMware for about 3 weeks now.  No luck so far.

[jim_1980]

We are also suffering from the same issue. I am going to log a call myself with VMWare as it seems you guys are not having much luck either.

I will let you know what i find out.