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.
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?
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).
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...
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?
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.
1 person found this helpful
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
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.
1 person found this helpful
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.
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.
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!
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.