If somebody tries to hot-patch an already-hot-patched function

Hot-patching on Windows uses reserved code space so Windows Update can replace function bodies on the fly; it’s supported primarily for server SKUs and newer enterprise desktops. The mechanism is intentionally single-owner: only Windows Update is authorized to write into the hot-patch area, and only functions marked as “safe for hot-patching” (no incompatible layout or invariant changes) are eligible. This simplifies design because the updater need not coordinate with arbitrary third-party patchers.

When the hot-patch logic finds evidence of an unexpected or “rogue” patch, it marks the file as not hot-patchable and falls back to requiring a reboot. A race between the prescan and the actual patching can lead to a half-applied update if another agent tampers with a function after the prescan, leaving an in-memory binary in an inconsistent state that can’t be reliably rolled back. The upshot is that applications that opportunistically use the hot-patch space risk breaking official updates and forcing reboots or crashes; hot-patching is a controlled facility meant only for the authorized update path.