Windows hot-patching is a one-lane road, and rogue patchers cause a pileup
If somebody tries to hot-patch an already-hot-patched function
Raymond Chen explains that Windows hot-patching is designed for Windows Update alone, so if a function is already hot-patched by someone else, the system treats it as rogue patching and declares the file not hot-patchable, forcing a reboot. A race condition can leave a binary half-patched with no reliable rollback, like parking in a fire zone.
An application that uses the hot-patching space is parking in a fire zone. Everything seems to be fine until the fire truck shows up, and then somebody's house burns to the ground because the fire truck can't get there.
- drdexebtjl
Interesting framing that hooking functions is considered “rogue” by Microsoft, or something you’re “not authorized” to do, when Microsoft themselves makes the detours library and never framed it like this before.
Also, missing from this explanation: hooks are usually applied per process, from user space. The code pages in a dynamic library are CoW’d from the shared page when you write to them to apply a patch.
Does the Windows Update work similarly, or does it somehow modify the original, shared page, affecting all processes? Does a hook in a single process disable hot patching on the entire system?
- jonhohle
At a previous job I wrote a docker build for patching individual Java class files on top of a monolithic docker image. This was not runtime patching, but allowed a single layer that was only a few kilobytes to be deployed quickly in emergency situations.
Interestingly, it had similar constraints and checked them at build time: it could not be a public ABI change and only one patch at a time.
- fsfod
Windows parallel DLL loading also defensively disables itself for a process if it finds some NT DLL functions have been hooked https://stackoverflow.com/questions/42789199/why-there-are-t...