Skip to content

Workbench Preferences dialog blocked 60+ seconds in OS.DestroyWindow when closing after opening the Keys preference page #4395

Open
Open
Workbench Preferences dialog blocked 60+ seconds in OS.DestroyWindow when closing after opening the Keys preference page#4395

Description

@lyh061619
lyh061619
opened on Sep 19, 2026

Environment: Eclipse 2026-09 (4.41), Windows Server 2025, JDK 27, 2K display
(high-DPI, custom font configured), IME: Chinese input method active.

Reproducible: Open Window → Preferences → General → Keys → press Cancel.
Closing the dialog blocks the UI thread in OS.DestroyWindow for 24-83 seconds
(consistent across attempts, duration varies).

Captured by org.eclipse.ui.monitoring (full samples attached):
main thread: PreferenceDialog.cancelPressed → close → Shell.destroyWidget
→ OS.DestroyWindow (native), repeated samples over 80s, thread state RUNNABLE.

The longer the Keys page has been open, the longer the close takes.
Other preference pages do not reproduce this.

eclipse.buildId=4.41.0.20260903-0719
java.version=27
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_CN
Framework arguments: -product org.eclipse.epp.package.java.product
Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.java.product -data file:/D:/workspace/

org.eclipse.ui.monitoring
Info
Sat Sep 19 14:06:44 CST 2026
Sample at 14:06:19.720 (+68.496s)
Thread 'main' tid=3 (RUNNABLE)

Stack Trace
at org.eclipse.swt.internal.win32.OS.DestroyWindow(Native Method)
at org.eclipse.swt.widgets.Control.destroyWidget(Control.java:768)
at org.eclipse.swt.widgets.Shell.destroyWidget(Shell.java:759)
at org.eclipse.swt.widgets.Widget.release(Widget.java:916)
at org.eclipse.swt.widgets.Widget.dispose(Widget.java:488)
at org.eclipse.swt.widgets.Decorations.dispose(Decorations.java:371)
at org.eclipse.jface.window.Window.close(Window.java:330)
at org.eclipse.jface.dialogs.Dialog.close(Dialog.java:985)
at org.eclipse.jface.preference.PreferenceDialog.close(PreferenceDialog.java:305)
at org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.close(FilteredPreferenceDialog.java:656)
at org.eclipse.ui.internal.dialogs.WorkbenchPreferenceDialog.close(WorkbenchPreferenceDialog.java:129)
at org.eclipse.jface.preference.PreferenceDialog.cancelPressed(PreferenceDialog.java:272)
at org.eclipse.jface.preference.PreferenceDialog.buttonPressed(PreferenceDialog.java:236)
at org.eclipse.jface.dialogs.Dialog.lambda$0(Dialog.java:617)
at org.eclipse.jface.dialogs.Dialog$$Lambda/0x0000000037829c00.accept(Unknown Source)
at org.eclipse.swt.events.SelectionListener$1.widgetSelected(SelectionListener.java:83)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:290)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:91)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4363)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1217)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4161)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3749)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:819)
at org.eclipse.jface.window.Window.open(Window.java:799)
at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:64)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:474)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:581)
at org.eclipse.jface.action.ActionContributionItem.lambda$4(ActionContributionItem.java:415)
at org.eclipse.jface.action.ActionContributionItem$$Lambda/0x0000000036186400.handleEvent(Unknown Source)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:91)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4363)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1217)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4161)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3749)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1160)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1051)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680)
at org.eclipse.ui.internal.Workbench$$Lambda/0x000000003557dc00.run(Unknown Source)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:583)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:173)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:193)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:219)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:149)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:115)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:467)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:298)
at java.base@27/java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(DirectMethodHandle$Holder)
at java.base@27/java.lang.invoke.LambdaForm$MH/0x00000000350d4800.invoke(LambdaForm$MH)
at java.base@27/java.lang.invoke.LambdaForm$MH/0x0000000035042400.invokeExact_MT(LambdaForm$MH)
at java.base@27/jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:156)
at java.base@27/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base@27/java.lang.reflect.Method.invoke(Method.java:583)
at app//org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:615)
at app//org.eclipse.equinox.launcher.Main.basicRun(Main.java:563)
at app//org.eclipse.equinox.launcher.Main.run(Main.java:1415)

Activity

  1. vogella commented on Sep 30, 2026

    @vogella
    vogella
    on Sep 30, 2026
    Contributor

    Looks like the time goes into Windows freeing the Keys page's large tree. That usually takes milliseconds.

    Could you check:

    1. Does it still happen with an English keyboard layout instead of the Chinese IME?
    2. Are you on Remote Desktop, or running any accessibility or remote-support tools?
    3. During the hang, can you capture the main thread's native stack (Process Explorer: javaw.exe > Threads > Stack) and tell us which DLL is on top?

  2. lyh061619 commented on Oct 2, 2026

    @lyh061619
    lyh061619
    on Oct 2, 2026
    Author

    Looks like the time goes into Windows freeing the Keys page's large tree. That usually takes milliseconds.

    Could you check:

    1. Does it still happen with an English keyboard layout instead of the Chinese IME?

2. Are you on Remote Desktop, or running any accessibility or remote-support tools?

3. During the hang, can you capture the main thread's native stack (Process Explorer: javaw.exe > Threads > Stack) and tell us which DLL is on top?

    Thanks for the triage direction. Answers:

    1. English keyboard layout (ENG, US):
      Still reproduces. I repeated Preferences → Keys → Cancel with the ENG
      layout several times — the close still hangs for tens of seconds.
      In fact it happened twice more today alone (attached monitoring samples):

      • 2026-10-02 16:12 — UI frozen 37.0s in OS.DestroyWindow while closing
        the Preferences dialog
      • 2026-10-02 16:15 — same stack, 30.2s (Cancel button)
        Both with the English layout active. So the Chinese IME does not appear
        to be the trigger.

    2. Environment:

      • Local console session on a standalone workstation — no Remote Desktop.

    3. Native stack during hang:
      Not captured yet — will install Process Explorer and grab the main
      thread's stack during the next hang (reproduces reliably on closing
      Preferences) and attach it here.

    Additional observation: the freeze is not limited to the Keys page — both
    of today's samples occurred when closing the Preferences dialog in general
    (one without ever opening the Keys page), always inside OS.DestroyWindow.
    Happy to run any other experiments (e.g., -Dswt.autoScale settings, clean
    workspace, or a specific preference page isolation test).

    log2026-10-02.log

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions