h1. Updated investigation results

Note: This is a crash on older versions of Unity and an exception on trunk.
h2. Simple repro steps

(from a comment by [~philip.zahoruyko])

[^ExceptionalWindowClosing.zip] is a repro project that is easier to show.

On macOS Unity 2022.3:
1. Open the attached project.
2. Click on ISSUE and open UtilityWindowThatThrows
3. Close the window and note the order of things in the console.
4. Click on ISSUE> NormalDockedWindowThatThrows, and then close it with the red circle.
5. Close the window and notice that `OnDestroy()` is *not* called. If you modify the script to not throw on `OnFocusLost()`, `OnFocusLost()` will print *twice* and `OnDestroy()` is called correctly.
6. Click on ISSUE> NormalDockedWindowThatThrows, and dock it in another window. Right click its tab and select close: The area goes black and NullreferenceExceptions are posted to the console multiple times and the Editor is not recoverable.

macOS does not crash as bad as the Windows case in 2022.3 LTS, but it does have bad behavior that the other OSes exhibit, all caused by throwing exceptions in OnFocusLost(), which is a legal thing that a script can do.
h2. Clarifications

(from a comment by [~abbapamela])

TLDR;
I this is a cross-platform issue with HostView and/or DockArea, or possibly a Scripting issue. See table (pic) for details.

Using the project that Phil has attached, you can reproduce the exact crash with a much simpler project. However, despite this being a crash on Windows, if you do the exact same steps but with the window DOCKED, you get a series of errors in the Editor console from HostView that are consistent with the errors from the crash.

The main source of the issue is throwing an Exception within OnLostFocus() for an EditorWindow. Some situations (detailed below) cause a series of errors in the Console and the EditorWindow becomes useless.

On Windows, Mac, and Linux when we are docked, we will get an unusable black box where the window was (see photo), and a series of HostView errors in the Editor console.

When we are undocked, on Mac and Linux we get the exception log in the Editor console, and on Windows we crash.

Behavior with it undocked and closing using the "Close Tab" option from the right click menu instead of clicking the "X" (or red dot on Mac) to close the window results with the same HostView errors in the Editor console with an unusable (black box) window.

Additionally the InputEvent crash is a result of this crash happening upon closing the window and the input event being tied to the click of the "X" button but not of the actual click itself.

I believe fixing the behavior of the errors above will alleviate this crash.

 
h1. Original report

Reproduction steps:
1. Open the attached project “CrashRepro“
2. Open “WINDOW_NAME“ if it is not open (Window > WINDOW_NAME)
3. Undock the “WINDOW_NAME“ window
1. Close “WINDOW_NAME“ window

Expected result: “WINDOW_NAME“ window is closed
Actual result: Editor crashes

Reproducible with: 2021.3.28f1, 2022.3.5f1, 2023.1.0a26
Not reproducible with: 2023.2.0a24
Fixed in: 2023.1.0b1

Reproducible on: Windows 10, Windows 11

First few lines of stack trace:
{noformat}
0x00007ff7e326f923 (Unity) GUIView::ProcessInputEventFromAPI
0x00007ff7e326f7f8 (Unity) GUIView::ProcessInputEvent
0x00007ff7e38360dc (Unity) GUIView::ProcessEventMessages
0x00007ff7e382fdfa (Unity) GUIView::GUIViewWndProc
0x00007ffb56ee8211 (USER32) DispatchMessageW{noformat}