STATUS_ACCESS_VIOLATION about windows-app-rs HOT 5 CLOSED

Hey @drewcrawford! The Window is getting disposed when OnLaunched returns, which is a bit awkward for WinUI.

Stash the main window instance in the App structure (that's why that field is there). There's a sample here as well: https://github.com/microsoft/windows-samples-rs/blob/master/windows_app_sdk/simple_window/src/main.rs#L59

from windows-app-rs.

I appreciate that workaround! However, this is a soundness issue. STATUS_ACCESS_VIOLATION is a memory violation, which isn't expected in safe rust. Assuming that's not a winui bug, it implies the rust projection ought to be marked unsafe.

For the rust side, see https://github.com/microsoft/windows-rs/blob/bf9da585055128b423473aae5e36df7bd5c91019/.github/safety.md#safety

For the winui side, it seems a bit awkward that an API like Window::new would be unsafe. Rust developers have a tendency to make wrappers for these cases, I'm a little uncertain whether that's in-scope here or more of a third-party crate.

from windows-app-rs.

In general, the xaml api will call C's abort function when used incorrectly in order to produce a Watson dump. This is considered safe on Windows because the process is immediately suspended and then terminated to prevent curruption.

from windows-app-rs.

Wouldn’t abort raise SIGABRT? Here we have access_violation, which I assume is some different signal (SIGSEGV presumably)

It’s a bit surprising that C abort could present like this crash, although maybe that is just how windows implements it?

from windows-app-rs.

I'm not a debugging expert but I think it depends on whether the abort was explicit or implicit. On Windows at least, you can abort explicitly via terminate/abort functions or implicitly by dereferencing a null pointer. The result is the same - suspension, dump, termination. This is a long-standing practice in COM code particularly and provides reliable crash dump information.

from windows-app-rs.