If somebody tries to hot-patch an already-hot-patched function, how do they avoid conflicts?

The Old New Thing (Raymond Chen) News

Summary

Raymond Chen explains how Windows hot-patching handles the case where a function has already been patched by unauthorized code: such functions are declared non-hot-patchable, forcing a reboot, and race conditions can leave a binary half-patched in memory. The post explains why only Windows Update is authorized to use the reserved hot-patch space, and why mixing hot-patching with other detours is dangerous.

<p>For the past few days, I did a quick survey of hot-patching mechanisms. But the hot-patch design accommodates only one hot-patcher. If somebody goes to hot-patch a function and finds that it&#8217;s already been hot-patched, what happens?</p> <p>If somebody goes to hot-patch a function and finds that it&#8217;s already been hot-patched, then something has gone wrong.</p> <p>The intended audience of hot-patching is Windows Update on systems that support hot-patching (as of this writing, <a href="https://learn.microsoft.com/en-us/windows-server/get-started/hotpatch"> Windows Server</a> and more recently <a href="https://techcommunity.microsoft.com/blog/windows-itpro-blog/hotpatch-for-windows-client-now-available/4399808"> Windows 11 Enterprise</a>, as far as I can tell). The idea is that when a Windows Update arrives, and the administrator has opted into hot-patching, and a file in the update is marked as &#8220;safe for hot-patching&#8221;,¹ then Windows Update will use the space reserved for hot-patching to replace the affected functions on the fly.</p> <p>Since the only code authorized to use the hot-patch space is Windows Update, the system doesn&#8217;t have to deal with the case that the function has already been hot-patched by somebody else. There is no other code authorized to be somebody else!</p> <p>But what if the function has been detoured or otherwise patched by somebody not authorized to do so?</p> <p>My reading of the hot-patching code suggests that if the hot-patch code detects rogue patching, it declares the file to be not hot-patchable, and the system will have to reboot. (This tends to make customers unhappy.)</p> <p>There is a race condition: The prescan may show that all the functions are safe to patch, but then somebody might patch a function <i>after</i> the prescan completes. In that case, the patcher will get halfway through and then discover the rogue-patched function, and now it&#8217;s kind of stuck. It can&#8217;t continue forward, and it can&#8217;t reliably roll back (because the rollback is probably also going to fail because the patch got overpatched). You&#8217;re stuck with a binary in memory that is half-patched, and who knows what&#8217;ll happen now.</p> <p>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&#8217;s house burns to the ground because the fire truck can&#8217;t get there.</p> <p><b>Related reading</b>: <a title="Application compatibility layers are there for the customer, not for the program" href="https://devblogs.microsoft.com/oldnewthing/20100311-00/?p=14643"> Application compatibility layers are there for the customer, not for the program</a>.</p> <p>¹ Not all changes are safe for hot-patching, For example, if it changes a data structure&#8217;s layout or invariants, it isn&#8217;t hot-patchable because any instances of the data structure that were created before the hot-patch will not be in a legal state after the hot-patch.</p> <p>The post <a href="https://devblogs.microsoft.com/oldnewthing/20261005-00/?p=112755/">If somebody tries to hot-patch an already-hot-patched function, how do they avoid conflicts?</a> appeared first on <a href="https://devblogs.microsoft.com/oldnewthing">The Old New Thing</a>.</p>
Original Article
View Cached Full Text

Cached at: 10/06/26, 03:00 PM

# If somebody tries to hot-patch an already-hot-patched function, how do they avoid conflicts? - The Old New Thing Source: [https://devblogs.microsoft.com/oldnewthing/20261005-00/?p=112755/](https://devblogs.microsoft.com/oldnewthing/20261005-00/?p=112755/) For the past few days, I did a quick survey of hot\-patching mechanisms\. But the hot\-patch design accommodates only one hot\-patcher\. If somebody goes to hot\-patch a function and finds that it’s already been hot\-patched, what happens? If somebody goes to hot\-patch a function and finds that it’s already been hot\-patched, then something has gone wrong\. The intended audience of hot\-patching is Windows Update on systems that support hot\-patching \(as of this writing,[Windows Server](https://learn.microsoft.com/en-us/windows-server/get-started/hotpatch)and more recently[Windows 11 Enterprise](https://techcommunity.microsoft.com/blog/windows-itpro-blog/hotpatch-for-windows-client-now-available/4399808), as far as I can tell\)\. The idea is that when a Windows Update arrives, and the administrator has opted into hot\-patching, and a file in the update is marked as “safe for hot\-patching”,¹ then Windows Update will use the space reserved for hot\-patching to replace the affected functions on the fly\. Since the only code authorized to use the hot\-patch space is Windows Update, the system doesn’t have to deal with the case that the function has already been hot\-patched by somebody else\. There is no other code authorized to be somebody else\! But what if the function has been detoured or otherwise patched by somebody not authorized to do so? My reading of the hot\-patching code suggests that if the hot\-patch code detects rogue patching, it declares the file to be not hot\-patchable, and the system will have to reboot\. \(This tends to make customers unhappy\.\) There is a race condition: The prescan may show that all the functions are safe to patch, but then somebody might patch a function*after*the prescan completes\. In that case, the patcher will get halfway through and then discover the rogue\-patched function, and now it’s kind of stuck\. It can’t continue forward, and it can’t reliably roll back \(because the rollback is probably also going to fail because the patch got overpatched\)\. You’re stuck with a binary in memory that is half\-patched, and who knows what’ll happen now\. 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\. **Related reading**:[Application compatibility layers are there for the customer, not for the program](https://devblogs.microsoft.com/oldnewthing/20100311-00/?p=14643)\. ¹ Not all changes are safe for hot\-patching, For example, if it changes a data structure’s layout or invariants, it isn’t hot\-patchable because any instances of the data structure that were created before the hot\-patch will not be in a legal state after the hot\-patch\. ### Category ### Topics ## Author ![Raymond Chen](https://devblogs.microsoft.com/oldnewthing/wp-content/uploads/sites/38/2019/02/RaymondChen_5in-150x150.jpg) Raymond has been involved in the evolution of Windows for more than 30 years\. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie\-jeebies\. The Web site spawned a book, coincidentally also titled The Old New Thing \(Addison Wesley 2007\)\. He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information\.

Similar Articles

Why is there no Windows hot-patching support for other architectures like 32-bit ARM and MIPS?

The Old New Thing (Raymond Chen)

Raymond Chen explains why Windows hot-patching exists for x86-32, x86-64, 64-bit ARM, and Itanium but not for older or other architectures like 32-bit ARM, MIPS, Alpha AXP, PowerPC, and SH-3: most predated the hot-patching rules, while 32-bit ARM was excluded because hot-patching is a Windows Server feature and no Server version existed for that architecture.

A compatibility note on the abuse of Windows window class extra bytes

The Old New Thing (Raymond Chen)

Raymond Chen discusses a historical Windows compatibility issue where some 16-bit programs abused window class extra bytes to store private data, and how Microsoft blocked the loophole for 32-bit and 64-bit programs while maintaining backward compatibility.