VMware Horizon Community
Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

Corrupted Excel files for some users

Hi all,

We're having a very weird issue here.

Environment:

  • Horizon 7.9, non-persistent linked clones
  • Windows Server 2019 and Office 2019 installed (no optimizations done, just Windows, updates, Office)

Problem:

  1. User1 on Computer1 accesses the VDI using Horizon Client:  Starts Excel, changes a document and saves it. Result: excel file is corrupted (Excel can repair, but formatting is lost)
  2. User1 on Computer1 accesses the VDI using the HTML5 Client: same actions as above: Excel file is fine
  3. User2 on Computer2 accesses the VDI using Horizon Client: same actions as above: Excel file is fine
  4. User2 on Computer1 accesses the VDI using Horizon Client: same actions as above: Excel is corrupt
  5. User1 on Computer2 accesses the VDI using Horizon Client: same actions as above: Excel file is fine

Computer1 & Computer2 are both Windows 10 devices, although not the same build/updates

I've been struggling with this for several weeks now, but can't find any logic in it. How could this be affected by the computer or the access method?

Before you ask, We've tried:

  • Different Horizon clients (5.0 ==> 5.4.3): same results
  • New master image with only Windows, office & updates (no profile management solutions, or other things) deployed to new pool: same results
  • Saved file to different locations: DFS share, normal network share, local VDI storage: same results
  • Removed local user profile of user1 on Computer1 (physical computer): seemed to solve the issue temporarily, but issue came back after a few days with other excel files

If anyone has any wonderful idea on what I could still try, I'd be very happy

Michiel.

Regards, Michiel.
Tags (2)
1 Solution

Accepted Solutions
Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

zhanghui1

Thanks for your explanation.

All our users are indeed getting their local default printer as default in their VDI, no problems there.

I can confirm the issue does not happen when using Virtual Printing(ThinPrint), but only when using the new Integrated Printing feature (using Horizon 7.9).

As we have the problem with people that have different default printers with different drivers, we'll be reverting our image back to virtual printing in stead of integrated printing.

If in the meantime you want me to do some additional testing, don't hesitate to ask. I'll keep a desktop pool aside on which I can do more testing.

Thanks a lot!

Michiel.

Regards, Michiel.

View solution in original post

Reply
0 Kudos
19 Replies
Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

Small update: the file corruption does NOT occur, when connecting to the VDI using HTML Access or the Windows 10 Horizon App from the store. It only happens when using the Windows Horizon Client.

Regards, Michiel.
Reply
0 Kudos
YunYiQun
VMware Employee
VMware Employee
Jump to solution

When you see file corruption happens, does the VDI desktop window corrupt or just the Excel window crashes?

If VDI desktop window crashes, could you provide dumps?

Reply
0 Kudos
Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

YunYiQun

There are no "crashes". Everything seems to work normal, but the Excel files are corrupted. After saving the file and trying to open it again, Excel says the file is corrupted. Excel can repair it, but almost all formatting is lost (data luckily seems to be recovered).

Regards, Michiel.
Reply
0 Kudos
YunYiQun
VMware Employee
VMware Employee
Jump to solution

Mickeybyte

That's weird. Looks like a more of MS office issue.

Reply
0 Kudos
Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

YunYiQun

That was my first idea too, but how do you explain that the exact same issue does not occur when you use the HTML access to access the VDI in stead of the Horizon Client?

And that it only happens with some users on some computers and not with those users on other computers, or with other users on those computers.

I can't find any reasonable logic to it. It's one of those cases...

Regards, Michiel.
Reply
0 Kudos
YunYiQun
VMware Employee
VMware Employee
Jump to solution

Mickeybyte2

Talked with my team, could you try to remove vdpservice.dll in the Horizon Client side and see if it makes a difference?

Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

YunYiQun​ You're the man!

I have a laptop here with me of one of the users who has the issue. I'm able to reproduce the issue by creating a new Excel file, adding some data and then applying a specific conditional formatting rule, which will render the file corrupt. If I do the same action using the HTML access, the file is fine. If I do the same actions on my computer, it works fine with both HTML access and Horizon Client.

So next I renamed the vdpservice.dll in c:\program files (x86)\vmware\vmware horizon view client\x64 and restarted the computer.

Created the same Excel file using the Horizon Client and now the excel file is fine!

Set back the vdpservice.dll and did the test again: file corrupted again.

Looks like you've found the cause of the problem! How can I help you any further into solving this "mysterious exceptional bug"? Do you need some debug logs or so?

Regards,

Michiel.

Regards, Michiel.
Reply
0 Kudos
Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

YunYiQun

I've been too enthusiast 😞 Seems like renaming the DLL has a nasty side effect of also preventing any local printers to be redirected to the VDI...

We are using linked clones with the (new) Integrated printing feature if that helps you.

Regards, Michiel.
Reply
0 Kudos
YunYiQun
VMware Employee
VMware Employee
Jump to solution

Yes, that's expected.

All the RX features that depend on vdpservice will be broken.

So for now, we know it must be some RX feature that causes the excel corruption, but we don't know which one.

The next step is to test RX feature one by one. Please add vdpservice.dll back and only add one of the RX feature dlls back one by one and let us know when it's broken when the last RX dll is added.

There are RX feature dlls (the name is not exactly matching, but should be similar):

1.mmredir_plugin for multi media

2.scredirection for smart card

3. mksvchanclient for clipboard

4. rdeclient for  common service

5. tsdrclient for CDR

6. usbredirection for USB

7. prvdpplugin for printer redirection

8. ViewMMDevRedir for RTAV

Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

YunYiQun

I've found out it was the vmwprvdpplugin.dll that is the cause of the corruption.

That would also explain why we don't have the issue on our 'old' VDI, which was using the virtual printing component of the Horizon Agent. On our 'new' VDI, we started using the integrated printing component in the Horizon Agent.

I will now see if I can change our VDI to use the virtual printing again in stead of the integrated printing and let you know the results.

Regards, Michiel.
Reply
0 Kudos
zhanghui1
VMware Employee
VMware Employee
Jump to solution

Hi Mickeybyte

I will take care of this issue. Let me clarify some thing firstly.

Vmware Integrated Printing was enabled in 21FQ1, after that we adopt our own solution to support print redirection. vmwprvdpplugin.dll is a plugin lives in both client and agent side. The only purpose of this dll is to create virtual channel between client and agent. It's no relationship with APP like Excel at all.  But now Excel keeps corrupt, one reason I can think of is that Excel is associated with a default printer always, when open a Excel sheet it will retrieve some settings from the default printer. If the printer has some problem. Excel might report corrupt.

So, can you do below steps:

1. Before connect to the agent, check all the printers on the CLIENT side. Suppose they are A,B, and C, and record which one is default printer.

2. Before connect to the agent, check all the printers on the AGENT side. Suppose they are D and E, and record which one is default printer.

3. Connect to the agent, wait all the client printer redirection is done. Then check all the printers on agent, you should see A, B, C, D and E. A, B, and C are redirected from client side and they are virtual printers. Record which one is default printer. By default the default printer should be same as the default on client side, same as you recorded in step 1.

4. Open Excel sheet and check the default printers in the Excel App.

If you can record a video, that would be better to identify this issue.

Thanks!

Brs,

ZHANG Hui

zhanghui1
VMware Employee
VMware Employee
Jump to solution

I revisit the below statements, all of them can be explained:

  • User1 on Computer1 accesses the VDI using Horizon Client:  Starts Excel, changes a document and saves it. Result: excel file is corrupted (Excel can repair, but formatting is lost)

=> Computer has a printer as the default printer, it is redirected to the agent as default printer as well. But this printer has some problems. When save an Excel sheet, it tries to get settings from the problematic printer, the issue happens.

  • User1 on Computer1 accesses the VDI using the HTML5 Client: same actions as above: Excel file is fine

=> With HTML access, no client-side printer will be redirected to the agent, so you will not see this problem.

  • User2 on Computer2 accesses the VDI using Horizon Client: same actions as above: Excel file is fine

=> Computer 2 has different printers attached and all of them are working well, so you will not see this issue.

User2 on Computer1 accesses the VDI using Horizon Client: same actions as above: Excel is corrupt

=> Same as User1 working on computer 1, it's no relationship with the user, it only relates to the client.

  • User1 on Computer2 accesses the VDI using Horizon Client: same actions as above: Excel file is fine

=> Same as User2 working on computer 2, it's no relationship with the user, it only relates to the client.

So let us check which printer on the client-side causes this problem. Looking forward to hearing from you.

Reply
0 Kudos
Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

zhanghui1

Thanks for your explanation.

All our users are indeed getting their local default printer as default in their VDI, no problems there.

I can confirm the issue does not happen when using Virtual Printing(ThinPrint), but only when using the new Integrated Printing feature (using Horizon 7.9).

As we have the problem with people that have different default printers with different drivers, we'll be reverting our image back to virtual printing in stead of integrated printing.

If in the meantime you want me to do some additional testing, don't hesitate to ask. I'll keep a desktop pool aside on which I can do more testing.

Thanks a lot!

Michiel.

Regards, Michiel.
Reply
0 Kudos
zhanghui1
VMware Employee
VMware Employee
Jump to solution

Hi, Mickeybyte

Could you help to collect some info on the computer where you can reproduce the issue?

1. List all the printers on the client-side.

2. List which one is the default printer.

3. After the VDI session is established. Check and make sure the default printer is shown on the agent side.

4. Open Excel sheet and check in the Print dialog, make sure the printer is the default printer in step 3.

5. Modify Excel sheet and save it.

6. Check if the Excel keeps corrupt.

If you can reproduce this issue, you can:

1.  change the default printer to another.

2. Open Excel sheet and check in the Print dialog, make sure the printer is the default printer.

3. Modify Excel sheet and save it.

4. Check if the Excel keeps corrupt.

Hope this is helpful.

Reply
0 Kudos
Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

zhanghui1

I've checked this. By default the user has a Ricoh printer locally. That is redirected to the VDI and is set as default there too. In Excel it shows the Ricoh printer as default. Saving the Excel file corrupts it.

When I change the local default printer to "Microsoft Print To PDF", it reflects in the VDI also and then the Excel corruption does not occur.

Regards, Michiel.
Reply
0 Kudos
zhanghui1
VMware Employee
VMware Employee
Jump to solution

Mickeybyte,

Glad to hear from you. Now it's confirmed that "Ricoh" is the root cause.

Next, we can do:

1. Keep "Rocho" as the default printer on the client-side.  Try to open Excel on the client-side, change it, and save to see if the issue happens.  there are 2 possible results:

1.1. Yes. This means the "Rocho" itself is not installed properly on the client-side. Try to reinstall it.

1.2. No. That means on the client-side, the printer driver works fine. then you can do the below steps:

2. Check if the printer driver is installed on the agent side. You can check it from "Print Management /All Drivers” to see if the specific driver is installed. there are 2 possible results as well:

2.1. Installed: it means the "Rocho" driver is not installed on the agent side properly.

2.2. Not installed. it means "Ricoh" works fine on the client-side, but after is redirected to the agent, it has some problem. You can submit an SR and we will investigate it soon.

I guess you will stop on step 1.1 or 2.1.

Brs,

ZHANG Hui

Reply
0 Kudos
Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

zhanghui1

On the "client" side there's no Excel/Office installed.

On the "Agent" side, the driver for the Ricoh Printer shows as "VMWare Universal EMF driver". I've also checked the "Microsoft Print to PDF" printer on the agent side and it is using the same driver.

2020-07-22 17_00_45-Clipboard.png

Regards,

Michiel.

Regards, Michiel.
Reply
0 Kudos
zhanghui1
VMware Employee
VMware Employee
Jump to solution

Mickeybyte,

This info is very useful.

Consider "Microsoft Print to PDF" and  "Ricoh" are using the same printer driver - ”Vmware Universal Printer Driver“. One works but another failed.

Could you help to install Excel on the client-side to see whether the printer works fine?

Before installing Excel, you can try to print any document on that printer to see if it works fine.

Reply
0 Kudos
Mickeybyte2
Hot Shot
Hot Shot
Jump to solution

zhanghui1

I've done some additional troubleshooting and found out the corruption occurs only on certain printers when set to default as we already found out.

I can now confirm that those printers are using the following driver locally: "Microsoft Enhanced Point and Print"

When I set a printer with a "real" driver like "Ricoh Class driver" as default, the problem doesn't occur.

It seems the combination of a local "Microsoft Enhanced Point and print" driver and the agent "VMware Universal EMF driver" seems to cause the issue.

Would you be able to reproduce this in a lab environment? It seems that "Microsoft Enhanced Point and print" driver is something in Windows server2012R2 based on a quick google search (our print server is running on W2K12R2). Our printers have specific vendor drivers on the print server, but when installed on the clients, some of them seem to use the "Microsoft Enhanced Point and Print" driver instead of the one specified on the print server:

2020-07-24 10_01_20-PrintProperties.png

For the record, we don't have any issues with printing.

Regards,

Michiel.

Regards, Michiel.
Reply
0 Kudos