apache
NetBeans closes when Remote Desktop connection is established
Apache NetBeans version
Apache NetBeans 24
What happened
Almost every time I make a Remote Desktop connection (RDP) to a server with NetBeans, NetBeans closes immediately.
Language / Project Type / NetBeans Component
No response
How to reproduce
Start NetBeans in a RDP session on server. Close RDP session but leave account signed in. Reconnect to server and NetBeans exits immediately.
Did this work correctly in an earlier version?
Apache NetBeans 23
Operating System
Windows Server 2025
JDK
21
Apache NetBeans packaging
Apache NetBeans binary zip
Anything else
Most of the time.
Are you willing to submit a pull request?
No
I don't see anything added to messages.log after I reconnect to the server but here is the messages.log Folder = %appdata%\netbeans\var\log
@pquiring was the log from a run where NetBeans disappeared when you connected?
Yes, I connected, started NetBeans. Disconnected and reconnected and NetBeans exited immediately.
Thanks,
This could be a JVM crash. If that is the case, nothing would be visible on the application level. You could check if you can find a hs_err_pid file, which would hold the JVM final report. You can also try a different, up to date, JDK (Corretto, Zulu, ...) there were at least to minor releases (you are on 21.0.4, 21.0.6 is current).
on linux the JVM will attempt to print the crash dump header to console which includes the path to the core dump itself. However I can't remember if this also happens on windows. Would be worth a try to run NB from terminal and check if it dumps some crash details on exit.
looks like:
#
# A fatal error has been detected by the Java Runtime Environment:
...
# An error report file with more information is saved as:
# /home/mbien/NetBeansProjects/JDKExperiments/hs_err_pid81616.log
...
edit: learned something new: JVM has a flag to influence the dump location:
-XX:ErrorFile=/tmp/nb_jvm_crash.log
something we might be able to set too (analog to heapdump path) so that the dumps appear in the log folder. Ideally we keep this outside of the launcher though.
Could this be related to https://github.com/adoptium/adoptium-support/issues/1203 ?
Yes, found some hs_err*.log files. Definitely awt related. Attached some log files found in the bin folder.
Looks like jdk-21.0.7 will fix the issue once released. Thanks for the link.
@pquiring I would try downgrading to 21.0.3, which should not be affected by that issue, to verify that is the cause. It seems somewhat similar, but the description there does not mention a VM crash in native code.
21.0.3 is the version I'm currently running. Let me try something else like 17.
I was wrong, Java version pointed to by registry is 21.0.4. Let me downgrade that.
Ok, after downgrading to 21.0.3 the problem is gone. Connected a dozen times and did not exit.
I must have updated Java and NetBeans at the same time and thought it was a NetBeans issue.
Thanks for your help.
Still a problem in JDK24 bundled with NB26.
The hs_err_pid files are in temp (c:\Documents and Settings\MyUser\Ustawienia lokalne\Temp\hs_err_pid13932.log)
Got three dumps in one day.
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffe361fb006, pid=13932, tid=33448
#
# JRE version: OpenJDK Runtime Environment Zulu24.30+11-CA (24.0.1+9) (build 24.0.1+9)
# Java VM: OpenJDK 64-Bit Server VM Zulu24.30+11-CA (24.0.1+9, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C [awt.dll+0xdb006]
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffe3605bd4c, pid=16564, tid=15780
#
# JRE version: OpenJDK Runtime Environment Zulu24.30+11-CA (24.0.1+9) (build 24.0.1+9)
# Java VM: OpenJDK 64-Bit Server VM Zulu24.30+11-CA (24.0.1+9, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C [awt.dll+0xdbd4c]
#
Cannot post a full memory dump, but here is a stack:
Host: Intel(R) Core(TM) i5-9600K CPU @ 3.70GHz, 6 cores, 47G, Windows 11 , 64 bit Build 22621 (10.0.22621.5415)
Time: Wed Jul 9 20:00:00 2025 Windows 11 , 64 bit Build 22621 (10.0.22621.5415) elapsed time: 1917.132447 seconds (0d 0h 31m 57s)
--------------- T H R E A D ---------------
Current thread (0x0000016499a1e900): JavaThread "AWT-Windows" daemon [_thread_in_native, id=15780, stack(0x0000004eeea00000,0x0000004eeec00000) (2048K)]
Stack: [0x0000004eeea00000,0x0000004eeec00000], sp=0x0000004eeebfebc0, free space=2042k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [awt.dll+0xdbd4c] (no source info available)
C [awt.dll+0x978cb] (no source info available)
C [awt.dll+0x97916] (no source info available)
C [awt.dll+0x94cff] (no source info available)
C [awt.dll+0xdfddc] (no source info available)
C [awt.dll+0xb0d4d] (no source info available)
C [awt.dll+0x97e4d] (no source info available)
C [USER32.dll+0x18eb8] (no source info available)
C [USER32.dll+0x184fb] (no source info available)
C [awt.dll+0x16543] (no source info available)
C [COMCTL32.dll+0x18dc2] (no source info available)
C [COMCTL32.dll+0x18ba7] (no source info available)
C [USER32.dll+0x18eb8] (no source info available)
C [USER32.dll+0x184fb] (no source info available)
C [flatlaf-windows-x86_64.dll+0x1889] (no source info available)
C [flatlaf-windows-x86_64.dll+0x1489] (no source info available)
C [USER32.dll+0x18eb8] (no source info available)
C [USER32.dll+0x18771] (no source info available)
C [awt.dll+0xd508e] (no source info available)
C [awt.dll+0xd6e82] (no source info available)
C 0x000001643abcce20 (no source info available)
The last pc belongs to native method entry point (kind = native) (printed below).
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j sun.awt.windows.WToolkit.eventLoop()V+0 [email protected]
j sun.awt.windows.WToolkit.run()V+56 [email protected]
j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 [email protected]
j java.lang.Thread.run()V+19 [email protected]
v ~StubRoutines::call_stub 0x000001643abc0fcd
siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000004
Will reopen this, although as it's a JDK bug, there's little we can do about it.
As a workaround, use the binary zip instead and configure it to run on an older JDK. Or install an older JDK and configure the shortcut from the installer to use that instead.
The problems are gone on NB26 using JDK 21.0.7+6. So this is weird. I would expect JDK24 to get updates from the JDK21 branch.
I asked for JDK24 replacement in the semi-official installers: https://github.com/Friends-of-Apache-NetBeans/netbeans-installers/issues/7
The community installers will always ship with the latest available JDK. That is also, in most cases, the recommended JDK to run NetBeans.
For some reason the original change was reverted in JDK 21, but at the moment doesn't seem to have a solution in JDK 24? Unless adding -J-Djava.awt.headless=false to the launch options helps?
JDK issue - https://bugs.openjdk.org/browse/JDK-8336862
NB 27 release candidates are now also available: https://github.com/apache/netbeans/discussions/8672
if this problem persists in current JDK 24.0.2 (which is the final update), we should probably add a note to the download page for RDP users linking to JDK-8336862. (and probably recommend to set --jdkhome to JDK 21 when affected?)
https://bugs.openjdk.org/browse/JDK-8348625
if I read this correctly, JDK 21.0.7 and later update releases should work since the change which caused this was reverted there. Not sure about JDK 25 but I couldn't find anything about it, so I suppose it is unresolved at this point in time still.
@mbien yes, as far as I can tell, the revert was applied to 17 and 21. Latest JDK 24 update, to be used in the NB27 installers, doesn't seem to have the revert, and not sure the discussed new behaviour has made it into 25 as yet.
Wondering if this might be related to a reversed issue I have - closing NetBeans kills it and VNC server. Doesn't happen on first close, but after 2-3 following a restart.
