I’ve decoded a #pragma detect_mismatch error and fixed the mismatch, but I still get the error

The Old New Thing (Raymond Chen) News

Summary

Explains why a #pragma detect_mismatch error persists after fixing the mismatch and rebuilding the project—because the mismatched object file is in an external library that needs to be recompiled as well.

<p>Some time ago, I showed <a title="How do I decode a #pragma detect_mismatch error?" href="https://devblogs.microsoft.com/oldnewthing/20220427-00/?p=106537"> how to decode a <code>#pragma detect_mismatch</code> error</a>. A colleague ran into this error because they sync&#8217;d a change that modified the configuration of a common header file. &#8220;No problem, I&#8217;ll just rebuild after sync&#8217;ing.&#8221; But when they rebuilt their project, the error persisted. What went wrong?</p> <p>The error message tells you the two pieces that are conflicting. In my colleague&#8217;s case, one of the pieces was an object file inside a library, and the other piece was an object file in their project. The catch was that the library was not part of their project. Therefore, rebuilding their project doesn&#8217;t rebuild the library.</p> <p>After you fix a <code>#pragma detect_mismatch</code> mismatch, you need to recompile all of the object files that were dependent upon the header file that contained the mismatch. This rule isn&#8217;t special to <code>#pragma detect_mismatch</code>; it applies to any ODR error. If a structure changed definitions in a common header file, you need to recompile all of the object files that were dependent on the header file so they all agree on the new structure definition.</p> <p>The fix was to rebuild the library that had been compiled against the old version of the header file. Safer would be to do a clean rebuild of the entire repo, to make sure no stale contents from the old header file still linger.</p> <p>The post <a href="https://devblogs.microsoft.com/oldnewthing/20260709-00/?p=112512">I&#8217;ve decoded a &lt;CODE&gt;#pragma detect_mismatch&lt;/CODE&gt; error and fixed the mismatch, but I still get the error</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: 07/09/26, 07:36 PM

# I've decoded a #pragma detect_mismatch error and fixed the mismatch, but I still get the error - The Old New Thing Source: [https://devblogs.microsoft.com/oldnewthing/20260709-00?p=112512](https://devblogs.microsoft.com/oldnewthing/20260709-00?p=112512) July 9th, 2026 ![like](https://devblogs.microsoft.com/oldnewthing/wp-content/themes/devblogs-evo/images/emojis/like.svg)1 reaction ![](https://devblogs.microsoft.com/oldnewthing/wp-content/uploads/sites/38/2019/02/RaymondChen_5in-150x150.jpg) Some time ago, I showed[how to decode a`\#pragma detect\_mismatch`error](https://devblogs.microsoft.com/oldnewthing/20220427-00/?p=106537)\. A colleague ran into this error because they sync’d a change that modified the configuration of a common header file\. “No problem, I’ll just rebuild after sync’ing\.” But when they rebuilt their project, the error persisted\. What went wrong? The error message tells you the two pieces that are conflicting\. In my colleague’s case, one of the pieces was an object file inside a library, and the other piece was an object file in their project\. The catch was that the library was not part of their project\. Therefore, rebuilding their project doesn’t rebuild the library\. After you fix a`\#pragma detect\_mismatch`mismatch, you need to recompile all of the object files that were dependent upon the header file that contained the mismatch\. This rule isn’t special to`\#pragma detect\_mismatch`; it applies to any ODR error\. If a structure changed definitions in a common header file, you need to recompile all of the object files that were dependent on the header file so they all agree on the new structure definition\. The fix was to rebuild the library that had been compiled against the old version of the header file\. Safer would be to do a clean rebuild of the entire repo, to make sure no stale contents from the old header file still linger\. ### 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\. ## Read next ## Stay informed Get notified when new posts are published\. Follow this blog - [https://twitter.com/ChenCravat](https://twitter.com/ChenCravat) - [![youtube](https://devblogs.microsoft.com/oldnewthing/wp-content/themes/devblogs-evo/images/social-icons/youtube.svg)](https://www.youtube.com/playlist?list=PLlrxD0HtieHge3_8Dm48C0Ns61I6bHThc) - [https://github.com/oldnewthing](https://github.com/oldnewthing) - [https://devblogs.microsoft.com/oldnewthing/feed/](https://devblogs.microsoft.com/oldnewthing/feed/)

Similar Articles

It's not me, it's the compiler

Lobsters Hottest

A Rust programmer discovers a compiler bug where casting 'bool as u32' produces incorrect results, leading to a parser error. The bug is reported and linked to GitHub issue #158206.

the perils of parsing type inference declarations in c

Lobsters Hottest

This blog post explores parsing ambiguities in C23 involving `auto` as a type inference specifier or storage-class specifier, showing how GCC and Clang disagree on parsing declarations like `auto x = 67;` when `x` is a typedef, and how attributes complicate the situation.