rnk@: Do you think this is practical/actionable?

First, as a workaround, we should recommend running `sxi av` to ignore access violation exceptions when debugging an ASan binary. If you're debugging an asan crash, you should expect the binary to stop reliably on TerminateProcess, and you should be able to inspect state then. If not, you can put a breakpoint on one of the fatal error symbols and re-run.

---

In general, I do not think we can remove the vectored exception handler for shadow memory access violations without a substantial redesign of asan and discovering (or requesting) some new virtual memory APIs from the NT kernel.

If we treat it as a QoI issue, yes, there are some things we can do so that there are *less* access violations during normal operation to make debugging easier. For example, most instrumented memory operations fault when touching globals, stack, and heap.
- For globals, we know where every module is, at least the ones when asan initializes, so we can pre-commit shadow memory for each module.
- We intercept thread creation, so we can do the same for the stack.
- For heap, we intercept as many malloc and news as we can, but we miss some thing like VirtualAlloc and MapViewOfFile or whatever its called. At least for memory from ASan's heap, we could pre-commit the shadow memory for it.

If you do all of those things, there would be fewer AVs, but in general, anyone debugging an ASan build will still need to know that most first-chance AVs are internal to ASan.

Finally, I should mention that Windows ASan is unstaffed, but we'd love to find someone who wants to own it and make these kinds of things their project. It's hard for our team to stretch to cover maintaining it.

Available, but no owner or component? Please find a component, as no one will ever find this without one.