u/koffienl

TL;DR: Same Windows master image, in-place VDA upgrade from CVAD 2203 CU4 to 2507 LTSR. Since the upgrade, our radiotherapy contouring app (RaySearch RayStation) shows the previous patient's CT for a moment before redrawing, and the smart brush stutters during contouring. Reverting to 2203 fixes it. I've ruled out client, OS, GPU hardware, vGPU profile, app-side GPU rendering, and the entire HDX encoder/visual-quality layer. The only variable that correlates with good vs. bad is the VDA version. Looking for others who've hit this with GPU 3D / medical imaging apps on VDA newer than 2203, and for any capture/present-layer knob I'm missing.

Environment

• App: RayStation 2025 SP1 (radiotherapy treatment planning; contouring on CT/MRI — pixel-perfect fidelity matters here)
• Single-session VDI, NVIDIA vGPU, Q-profile (RTX vWS) throughout
• GPUs tested: RTX 8000 (old hosts) and L40S (new hosts) — both affected on 2507
• Good baseline: Windows 10 + CVAD 2203 CU4 — flawless for years
• Broken: CVAD 2507 LTSR, both via in-place VDA upgrade on the same Win10 image, and on a brand-new, clean Windows 11 build (NVIDIA 582.16). Also briefly seen on 2402, but I tested 2507 far more thoroughly.

(Context / why I can't just stay on 2203: see my earlier thread (https://www.reddit.com/r/Citrix/comments/1ujqmvb/wem\_2603\_agent\_fails\_with\_reading\_encrypted\_data/) Short version: in a validated medical environment I'm tied to what the vendor validates, and staying frozen on 2203 indefinitely isn't an option. 2025 SP1 on CVAD 2507 is vendor-validated, so this should work.)

Symptoms

1. Open patient A → Patient Modeling → CT shown. Close A, open patient B → Patient Modeling → I briefly see A's CT, then it updates to B. Clear delay before the correct images appear.
2. Smart brush stutters/lags during contouring (was buttery smooth on 2203).
3. In a separate 2D viewer (Elekta Monaco) scrolling through slices shows low-res first, sharpening if you pause — classic build-to-lossless behaviour, but see below, that's not the whole story.

What I've ruled out (with testing)

• Client / CWA version — reproduces on every endpoint type (Linux Wyse thin clients, thick Win11), all my test runs from the same Win11 machine.
• Guest OS — Win10 and Win11 both affected.
• GPU hardware — RTX 8000 and L40S both affected on 2507 (this pre-dates our L40S migration, so the GPU swap is not it).
• vGPU profile — Q-series in all cases.
• App renders on GPU — nvidia-smi shows RayStation.exe as C+G; nvidia-smi dmon -s u shows sm clearly peaking when Patient Modeling renders. No software-rasterizer fallback.
• Entire HDX encoder / visual-quality layer — tested Use-when-preferred (selective), For-the-entire-screen (full-screen H.265), Always Lossless (pixel-perfect toggle), and For-actively-changing-regions (i.e. Intelligent Build to Lossless disabled per Citrix docs). None of them changes the behaviour.

Graphics Status Indicator, 2203 vs 2507, identical policy

Nearly identical readouts on both: H.265 (Yuv444), hardware encoding enabled, Build to Lossless, full-screen. The one visible difference: 2203 shows an "HDX 3D Pro: Enabled" line; 2507 does not (shows "Not applicable" in pixel-perfect). I suspect that's just the relabel to "HDX Graphics" rather than a functional flag, but noting it.

nvidia-smi dmon -s u during a patient switch, both versions

sm peaks where rendering happens; enc sits at 0 the whole time on both (so no measurable NVENC difference, likely CPU-encode or too-low-to-register). GPU-side, I see no difference between the good and bad version. Which is itself telling: the difference isn't in how much GPU work happens.

Where I think it lives

Since every encoder choice is exhausted with no effect, and the app demonstrably renders on the GPU on both versions, my working hypothesis is the frame capture / present layer of the VDA — the bit between "app has drawn on the GPU" and "encoder gets a frame to send" — which was rebuilt across versions. The stack changed a lot after 2203: HDX 3D Pro → "HDX Graphics", Optimize for 3D graphics workload is now deprecated in favour of a Full Screen Encoder, and Intelligent Build to Lossless is default-on for VDAs with a GPU from 2503+. The stale-previous-frame symptom in particular smells like a change-detection / region-invalidation timing difference upstream of the codec, not a compression setting.

What I'm asking the hive mind

1. Anyone running GPU-accelerated 3D / medical imaging (RayStation, MIM, Eclipse, PACS, CAD) seeing display regressions after moving off VDA 2203 to 2402/2503/2507?
2. Is there a non-documented VDA-side registry knob for the capture/present cadence or damage-region handling that reverts the pre-2503 behaviour? Encoder policies don't touch this.
3. Any known-issue / LCM number I've missed? The 2402/2507 known-issues lists don't mention anything matching.
4. If you fixed something similar — what actually moved the needle?

I have a clean reproducible A/B (same image, only the VDA version differs) and I'm opening cases with both Citrix and RaySearch, but I'd love to hear from anyone who's walked this path. Happy to share indicator screenshots, dmon captures, or policy exports.

English isn't my first language, so I used AI to help write this up clearly — the technical content, testing and findings are all my own.

Hoping someone has run into this.
Brand-new WEM deployment from scratch (fresh infrastructure service install, new database, new config set), so no legacy/upgrade baggage on the broker side.
The VDA master image is also freshly built — not an old image that's been carried along and updated over time, but a clean new Windows 11 install.

Quick note on why I'm on CVAD 2203 in the first place: I run into GPU handling issues with medical software on CVAD versions after 2203, so I'm deliberately staying on CVAD 2203 CU7 LTSR on Windows 11. That's a hard constraint for me, not something I can just upgrade away from.

Setup:

• WEM Infrastructure Service (broker) + web console: 2603
• VDA: CVAD 2203 CU7 LTSR, Profile Management engine 2203
• OS: Windows 11, non-persistent MCS

The problem: with the WEM 2603 agent, the agent connects to the broker fine (reads broker FQDN, port 8286, site name, language file — all OK), then immediately dies at config decryption:

MainController.ReadAgentConfiguration() : Reading Encrypted Data...

Exception -> VuemAgentConfigurationHelper.ReadEncryptedData() : The creator of this fault did not specify a Reason.

Exception -> MainController.ReadAgentConfiguration() : Reading Encrypted Data Failed. Exiting...

Result: no apps/printers delivered, agent menu only shows "Refresh" (Manage Applications/Printers greyed out), red Profile Management health in console.

Here's the kicker: I installed the 2203 agent instead, on the exact same setup — same broker, same config set, same user store, same user — and everything works perfectly. Apps delivered, menu functional, no decryption error, green PM health.

So the only variable is the agent version. 2603 agent = broken, 2203 agent = fine, against a 2603 broker on a 2203 LTSR stack.

I tested with a clean agent install (no local cache/upgrade leftovers) and the broker was freshly rebooted, so I've ruled out stale cache and broker state. The connection itself isn't failing (it gets past the broker handshake) — it's specifically the encrypted config payload it can't read.

Questions:

1. Is the 2603 current-release agent actually supported against a 2203 LTSR VDA/PM engine? I'm starting to think the agent needs to match the LTSR level of the Citrix stack, not the broker version.
2. Anyone seen ReadEncryptedData fail like this and found a fix, or is this just a hard version-mismatch I should stop fighting?

Sticking with the 2203 agent for now since it works, but would love to know if there's something I'm missing.

We are staying in a agriturismo near Modica for a week, and still be here for a week.
Looking to go to Scicli tommorow (saturday). Any tips for a tourist? Will there be a market (with different offers beside fruit and vegetables)?

https://www.telegraaf.nl/video/zo-weinig-verdient-amerikaans-horecapersoneel-per-uur-het-systeem-is-corrupt/152918992.html

Dutch reporter but the interviewed are American.
I hate het US tipping system, but wasn't aware of the fact that the wage was below the minimum wage. Still a fucked up system to underpay part of your staff and ask the costumer to pay on top of the product/service to pay the waiter.