In normal operation, very uncommon. Many protections to prevent it from happening in the normal, day-to-day activity. However, in diagnostics it is extremely c

In normal operation, very uncommon. Many protections to prevent it from happening in the normal, day-to-day activity. However, in diagnostics it is extremely common, because it's how debuggers and a ton of other necessary tools work. Debuggers go in even more deeply than that, they can pause execution and single step it, etc. So it's hard to remove the things these tools use to work. Beyond that, Windows has its own weird concerns here. At the very bottom layer of the way Windows was designed, all windows were in a common space on a single-user system (think Windows 3.0 era here), and all windows can send arbitrary messages to each other, and those messages are often very powerful commands. Not quite literally "set this memory value to that", but things like "set text to this" or "redraw yourself" or "terminate yourself", plus any additional arbitrary things the programs added for their own message loop internally. While Windows has had the basic process model protections of not allowing direct memory access to other process, etc., historically speaking being able to send Windows messages to arbitrary processes has any number of ways of escalating to code execution, even before we get into buffer overflows and such (though there were plenty of those). It has been a long and bumpy road securing Windows against all of these issues to make it multi-user safe. While this particular hack doesn't use windows messages to do all of the work, note that there can still be some legitimate surprise at how much access a program can get to Notepad just by sending messages, like, directly telling it to run its rendering loop to redraw its screen.