Accessing DeltaV Live shows blank white screen with RDP to Windows 10 Enterprise LTSB PC

I ran into an unexpected hurdle today with DeltaV Live and RDP.  We have a client with a Physical Workstation and they would like to access this Physical Workstation with RDP from a wireless Tablet.  This would allow them to perform some tasks around the process equipment while maintaining access to the DeltaV Console.  I've deployed this before with DeltaV Operate. 

I am able to connect to the Workstation with RDP and have access to DeltaV Explorer, Graphics Studio and other applications.  However, when Live launches, the session shows a blank white screen.  

Using the same Client side computers (Dell Laptop, Surface Pro tablet and a Dell PC) can can successfully open DeltaV Live with RDP on a Win 10 Enterprise LTSB Virtual Machine.   This tells me the client side machines are not the issue.  

Does anyone know why Live would show a blank white page from the physical computer while various other applications display correctly?  Using RDP on a physical DeltaV computer is not "supported".  RDP does not appear to be the issue given connection works and all other apps open as expected.  The computer locally supports DeltaV Live via its local graphics card.  Is there a setting required to allow Live to serve an image via RDP?

I'm drawing a Blank on this....Literally.

Andre Dicaire

4 Replies

  • I was successful with a second panel PC to connect via RDP and launch DeltaV Live. The difference between the two is installed RAM. The PC that worked has 16 Gb installed while the other had only 8 Gb.

    I’m wondering if with RDP, the PC needs more RAM to process the session display but when locally displayed the PC has the graphics card resources. I’m guessing but why would Live run locally but lock at the initial white screen in RDP?

    Any one have any thoughts?

    Andre Dicaire

  • In reply to Andre Dicaire:

    Here is an update. Verifying the PC Resources, with Live running locally, the RAM usage is only at 3 GB. This indicates that installed memory is not the issue.

    It was pointed out that there are Group Policy settings to enable RDP to use the resources of the local GPU of the PC to render the image. I was directed to a procedure to adjust the host side RDP settings. These changes did not help, but even worse, now Live no longer works on the local PC monitor either. We restored the original settings and still, DeltaV Live is now unable to get past the white screen. There is no error message displayed.

    This PC is still running WS19 Hotfix but the Pro Plus has been updated to WS25. I'm not sure if there may be an issue introduced as a result of this mismatch. The station that is working with RDP is in a workgroup and at the same version as the Engineering station. If bring the PC to WS25 does not restore Live locally, I'll be rebuilding the PC.

    On a separate VM PC, also at WS19, I observed this White Screen behavior once. So the obvious next step is to apply the hotfix to all stations.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Hi Andre,

    I hope the hotfix version matching helps, but if it doesn't and before you rebuild the PC, have you tried the following Win 10 "fix most things unexplained and weird with windows" commands?

    Open cmd, or powershell, run as administrator, then run the following commands shown within but not with the quotes:

    1. Run "dism.exe /online /cleanup-image /restorehealth" . Let that scan run until it's finished to 100%.

    2. Then run "sfc /scannow". Let that finish to Verification 100% complete. Sometimes it reports it found nothing and sometimes it reports Windows Resource Protection found corrupt files and successfully repaired them.

    Afterwards, restart the machine and check Live again.

    If I was working on that station, I'd run those commands before I'd rebuild it. It's saved me A LOT of grief on DeltaV and other SCADA system stations for weird, strange and unexplained Windows 10 behavior, especially after windows updates. I suppose there's no guarantees it will fix it, but after reading what you described, it's one of the steps I would try.
  • In reply to JessWilson:

    Thank you for your help JessWilson. I tried the DSM command, and received the error: 87. Before I looked further into this, I applied the Hotfix WS25. Good news, Live is now working on my PC.

    Full disclosure, this PC was actually running WS08, not WS19. I guess we missed it during the WS19 update.

    Lesson 1: Make sure your hotfixes are up to date.

    When LIVE launches it always shows a white screen before populating the menu bar and display frames. So it appears there was something changed in WS25 that affected WS08 to be able to proceed. In retrospect, I should have updated the WS25 hotfix before trying anything new.

    Back to DISM.EXE, I found some help explaining that forgetting a space before the / can cause this. Retried typed correctly and it completed successfully. It did not list any issues.
    I then ran sfc /scannow. Scan finished. It says it found corrupt files and successfully repaired them. I reviewed the log, but could not find any mention of a corrupt file.

    I've rebooted the computer and connected via RDP ( I did all the above via an RDP session). All is working as expected.

    Last thought, When updating the DeltaV Live hotfix, I would avoid publishing anything new until all workstations are updated. And if you have to update something, do not refresh the session on workstations that have not been updated. That way you will not pull a new item to that workstation that could negatively affect its operation. This workstation had been working with Live but we had not restarted or refreshed the session until I started my RDP experiment. This was not a normal activity for sure. Anyway, the issue had nothing to do with installed memory and the PC is working well with 8 GB installed RAM, showing 3.0 GB in use

    Andre Dicaire