Dear Guacamole Community,

I am encountering a persistent issue with RDP connections to Windows Server
2008 R2 using Guacamole 1.6.0 that was not present in version 1.5.3. The
connection consistently fails with "Decompression failure!" messages in
the guacd logs, followed by a crash of the guacd process.

*Problem Description:* When attempting to establish an RDP session to a
Windows Server 2008 R2 machine via Guacamole 1.6.0, the guacd daemon
crashes. The logs indicate a decompression failure during the RDP Fastpath
update process, specifically related to pointer updates, leading to an
eventual crash within Guacamole's display layer management.

*Environment:*

   - *Guacamole Version:* 1.6.0 (worked fine with 1.5.3)
   - *Target RDP Server:* Windows Server 2008 R2
   - *guacd Host OS:* (Please specify your guacd host OS, e.g., Linux
   distribution and version)

*Relevant Log Snippets from guacd:*

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.474443
guacd[1404331]: DEBUG:#011transport_check_fds: transport->ReceiveCallback()
- -3

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.474452
guacd[1404331]: DEBUG:#011freerdp_check_fds() failed - 0

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.895953
guacd[1404331]: DEBUG:#011Decompression failure!

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.895980
guacd[1404331]: DEBUG:#01*1bulk_decompress() failed*

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.895988
guacd[1404331]: DEBUG:#011fastpath_recv_update_data() fail

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.895998
guacd[1404331]: DEBUG:#011transport_check_fds: transport->ReceiveCallback()
- -3

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.896008
guacd[1404331]: DEBUG:#011freerdp_check_fds() failed - 0

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.896178
guacd[1404331]: DEBUG*:#011Decompression failure!*

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.896199
guacd[1404331]: DEBUG:#011bulk_decompress() failed

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.896235
guacd[1404331]: DEBUG:#011fastpath_recv_update_data() fail

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.896246
guacd[1404331]: DEBUG:#011transport_check_fds: transport->ReceiveCallback()
- -3

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.896258
guacd[1404331]: DEBUG:#011freerdp_check_fds() failed - 0

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.900204
guacd[1404331]: DEBUG:#011Fastpath update Cached Pointer [a] failed, status
0

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.900238
guacd[1404331]: DEBUG:#011fastpath_recv_update() - -1

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.900245
guacd[1404331]: DEBUG:#011fastpath_recv_update_data() fail

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.900254
guacd[1404331]: DEBUG:#011transport_check_fds: transport->ReceiveCallback()
- -3

Oct 28 10:29:51   guacd[1404331]: 2025-10-28 10:29:51.900262
guacd[1404331]: DEBUG:#011freerdp_check_fds() failed - 0

Oct 28 10:29:49   guacd[1404331]: 2025-10-28 10:29:49.736738
guacd[1404331]: DEBUG:#011[0x22] UNKNOWN - Alternate Secondary Drawing
Order UNKNOWN

Oct 28 10:29:49   guacd[1404331]: 2025-10-28 10:29:49.736766
guacd[1404331]: DEBUG:#011[0x22] UNKNOWN - SERVER BUG: The support for this
feature was not announced!

*Backtrace of guacd Core Dump:*


 Show full code block

Thread 1 (Thread 0x7fea673ff640 (LWP 1402527)):

#0  0x00007fea6e48b52c in __pthread_kill_implementation () from
/usr/lib64/libc.so.6

#1  0x00007fea6e43e686 in raise () from /usr/lib64/libc.so.6

#2  0x00007fea6e428833 in abort () from /usr/lib64/libc.so.6

#3  0x00007fea6f40dfb2 in *guac_display_remove_layer*
(display_layer=0x7fea5c38e370) at display-layer-list.c:327

#4  0x00007fea6f40c683 in guac_display_free_layer (display_layer=<optimized
out>) at display.c:376

#5  0x00007fea6c3c4cf6 in pointer_cache_put () from
/opt/zscaler/lib64/libfreerdp2.so.2

#6  0x00007fea6c3c4e59 in update_pointer_new () from
/opt/zscaler/lib64/libfreerdp2.so.2

#7  0x00007fea6c41badc in fastpath_recv_update () from
/opt/zscaler/lib64/libfreerdp2.so.2

#8  0x00007fea6c41c080 in fastpath_recv_updates () from
/opt/zscaler/lib64/libfreerdp2.so.2

#9  0x00007fea6c414c60 in rdp_recv_pdu () from
/opt/zscaler/lib64/libfreerdp2.so.2

#10 0x00007fea6c4158f3 in rdp_recv_callback () from
/opt/zscaler/lib64/libfreerdp2.so.2

#11 0x00007fea6c420890 in transport_check_fds () from
/opt/zscaler/lib64/libfreerdp2.so.2

#12 0x00007fea6c4164a2 in rdp_check_fds () from
/opt/zscaler/lib64/libfreerdp2.so.2

#13 0x00007fea6c3fc004 in freerdp_check_fds () from
/opt/zscaler/lib64/libfreerdp2.so.2

#14 0x00007fea6c3fd0c4 in freerdp_check_event_handles () from
/opt/zscaler/lib64/libfreerdp2.so.2

#15 0x00007fea6c5814c7 in guac_rdp_handle_events
(rdp_client=0x7fea6c154010) at rdp.c:491

#16 guac_rdp_handle_connection (client=0x7fea6001a110) at rdp.c:626

#17 guac_rdp_client_thread (data=0x7fea6001a110) at rdp.c:944

#18 0x00007fea6e4897e2 in start_thread () from /usr/lib64/libc.so.6

#19 0x00007fea6e50e800 in clone3 () from /usr/lib64/libc.so.6


The backtrace indicates that the crash occurs
within guac_display_remove_layer and guac_display_free_layer, which are
Guacamole's display management functions, while processing a
FreeRDP fastpath_recv_update related to pointer caching. This suggests that
corrupted or malformed data, possibly due to the decompression failure, is
being passed to the display layer, leading to the crash.

*Question:* Given that this worked reliably with Guacamole 1.5.3 and fails
with 1.6.0, are there any known limitations, incompatibilities, or stricter
requirements introduced in Guacamole 1.6.0 (or the FreeRDP version it uses)
that might affect connections to older RDP servers like Windows Server 2008
R2? Specifically, are there any known issues with Fastpath updates or
pointer caching with older RDP server versions in the newer FreeRDP library?

This is easily reproducible with windows server 2008 R2 and would request
you to quickly try on it.

Any insights or guidance on troubleshooting this issue would be greatly
appreciated.

Thank you for your time and assistance.

Best regards,

Dilip

-- 


This communication (including any attachments) is intended for the sole 
use of the intended recipient and may contain confidential, non-public, 
and/or privileged material. Use, distribution, or reproduction of this 
communication by unintended recipients is not authorized. If you received 
this communication in error, please immediately notify the sender and then 
delete all copies of this communication from your system.

Reply via email to