@dinhngtu Yes, I've submitted a false positive report here: https://www.bitdefender.com/en-us/business/submit

@archw Bitdefender GravityZone is triggering on this file "C:\Program Files\XCP-ng\Windows PV Drivers\xenplus\xenplus.exe" with this signature: "Generic.Dacic.10760.DEAFFD1D". We use 9.2.350

I've updated from 9.1.200.0 to 9.2.350.0 on a Windows Server 2022 VM and encountered this during the update.

I clicked OK:

I clicked OK:

I clicked on Finish and after that on Yes to restart the VM.

Now, after the update, every time I log out a user session, I see an event by XenPlus being logged to the event log:

Category: XenPlus.Features.ClipboardFeature
EventId: 0

Failed to serve client 6

Exception: 
System.IO.EndOfStreamException: IO_EOF_ReadBeyondEOF
   at System.IO.Stream.<ReadAtLeastAsyncCore>d__48.MoveNext() + 0x1f2
--- End of stack trace from previous location ---
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16) + 0x23
   at XenPlus.Features.ClipboardFeature.<ServeClientLoopAsync>d__26.MoveNext() + 0xb0d
--- End of stack trace from previous location ---
   at XenPlus.Features.ClipboardFeature.<ServeClientAsync>d__27.MoveNext() + 0x45d

@dinhngtu Thank you, is it possible to set globally for all (new and existing) users when unable to use GPP?

Just came here to report that I've experienced the same issue on Windows Server 2025 Standard with XCP-ng Windows Guest Tools 9.1.146.0 installed.

Restarting the service "Xen Guest Agent (Rust-based)" works, but after a reboot of the VM the IP is not visible anymore in XO or XCP-ng Center.

When disconnecting the vNIC and connecting it again, the IP adress is displayed for a couple of seconds, but disappears af

I "fixed" it by setting the startup type of "Xen Guest Agent (Rust-based)" to "Automatic (Delayed start)"

No problems with Debian 12 or AlmaLinux 9.

We have the same issue here with the latest kernel since installing it yesterday.
4.18.0-553.50.1.el8_10.x86_64 does not boot while 4.18.0-553.47.1.el8_10.x86_64 boots fine.
Is there a fix or workaround available yet?