microsoft / microsoft/vscode

Closing a window with an attention notification throws "Object has been destroyed"

Open
#336,717 0 comments 0 reactions 1 assignee Claimed by @deepak1556 View on GitHub
bug
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

## What happens

Closing a window while its taskbar icon is flashing for attention can produce an uncaught error in the main process. The window has already been destroyed by Electron, but VS Code still tries to stop its flashing animation during cleanup.

This was observed in two recent Code - Insiders sessions on Windows. The logs do not establish that the whole application crashed; they do show an exception during window cleanup.

## Relevant logs

These are verbatim error lines from the two sessions:

```text
2026-09-17 15:43:15.510 [error] [uncaught exception in main]: TypeError: Object has been destroyed
2026-09-17 15:43:15.512 [error] TypeError: Object has been destroyed
```

```text
2026-09-18 02:29:45.514 [error] [uncaught exception in main]: TypeError: Object has been destroyed
2026-09-18 02:29:45.517 [error] TypeError: Object has been destroyed
```

Both stacks point to the same location in the installed build, whose directory was `0469440342`. Relevant frames, with local installation paths removed:

```text
at Uy._fn (.../out/main.js:97:55800)
at Uy.dispose (.../out/main.js:29:577)
...
at Da.dispose (.../out/main.js:97:58287)
...
at BrowserWindow.emit (node:events:526:24)
```

Immediately after the second exception:

```text
2026-09-18 02:29:45.518 [trace] Lifecycle#window.on('closed') - window ID 1
```

## Root cause

The installed bundle location maps to `BaseWindow.showNotifyFocus()` in `src/vs/platform/windows/electron-main/windowImpl.ts`:

```ts
disposables.add(toDisposable(() => this.win?.flashFrame(false)));
```

The `closed` handler disposes the window wrapper after Electron has destroyed the native window. At that point `this.win` still references an object, so `?.` does not prevent the call. `flashFrame(false)` throws because its native window no longer exists.

The exception also prevents `BaseWindow.dispose()` from reaching the statement that clears its stored window reference. A controlled before/after reproduction confirmed both the error and the uncleared reference with the original callback.

## Reproduction scenario

1. Trigger an attention notification for a background window, so its taskbar icon flashes (`FocusMode.Notify`).
2. Close that window before focusing it and clearing the notification.
3. Inspect the main-process log for `TypeError: Object has been destroyed`.

The native lifecycle was also exercised using an actual Electron `BrowserWindow`.

## Expected behavior

Window cleanup completes without an exception and releases the window reference. Stopping the flash is only necessary while the native window is still alive; focusing or disposing a live window should continue to stop it normally.

## Scope

This is another destroyed-window access in the notification cleanup area touched by #334782. The flashing callback predates that change; this is not evidence that #334782 introduced it. The proposed fix is limited to checking the native window's lifetime before calling `flashFrame(false)`.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.