Just shows that nobody cares about debugging the parity flag any more

The Old New Thing (Raymond Chen) News

Summary

A bug in the Windows debugging engine for x86-64 incorrectly reported the parity flag, going unnoticed for over two decades, highlighting how rarely the flag is debugged.

<p>The x86-64 architecture inherited the parity flag (PF) from the x86-32, which in turn inherited it from the 8080, which inherited it from the 8008, which implemented it because it was the processor for the Datapoint 2200 serial terminal.</p> <p>The parity flag also has a secondary purpose of being a place for the <code>FXAM</code> (x87) and <code>UCOMISD</code> (SSE) instructions to record the results of floating point comparisons. You can still entice compilers into checking the parity flag by checking a value for NaN or performing a floating point equality or inequality comparison (because NaN always fails equality and inequality comparison).</p> <p>It turns out that the Windows debugging engine for x86-64 had a bug where it reported the parity flag as the opposite of what it actually is. When the parity flag was set, it said &#8220;po&#8221; instead of &#8220;pe&#8221;, and vice versa.</p> <p>The fact that this went unreported for over two decades tells you that nobody cares about debugging the parity flag.</p> <p>A fix has gone in. We&#8217;ll see if it makes it out before this article gets posted.</p> <p>The post <a href="https://devblogs.microsoft.com/oldnewthing/20260518-00/?p=112334">Just shows that nobody cares about debugging the parity flag any more</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: 05/19/26, 03:34 PM

# Just shows that nobody cares about debugging the parity flag any more - The Old New Thing Source: [https://devblogs.microsoft.com/oldnewthing/20260518-00?p=112334](https://devblogs.microsoft.com/oldnewthing/20260518-00?p=112334) May 18th, 2026 ![heart](https://devblogs.microsoft.com/oldnewthing/wp-content/themes/devblogs-evo/images/emojis/heart.svg)![like](https://devblogs.microsoft.com/oldnewthing/wp-content/themes/devblogs-evo/images/emojis/like.svg)![mind blown](https://devblogs.microsoft.com/oldnewthing/wp-content/themes/devblogs-evo/images/emojis/mind-blown.svg)4 reactions ![](https://devblogs.microsoft.com/oldnewthing/wp-content/uploads/sites/38/2019/02/RaymondChen_5in-150x150.jpg) The x86\-64 architecture inherited the parity flag \(PF\) from the x86\-32, which in turn inherited it from the 8080, which inherited it from the 8008, which implemented it because it was the processor for the Datapoint 2200 serial terminal\. The parity flag also has a secondary purpose of being a place for the`FXAM`\(x87\) and`UCOMISD`\(SSE\) instructions to record the results of floating point comparisons\. You can still entice compilers into checking the parity flag by checking a value for NaN or performing a floating point equality or inequality comparison \(because NaN always fails equality and inequality comparison\)\. It turns out that the Windows debugging engine for x86\-64 had a bug where it reported the parity flag as the opposite of what it actually is\. When the parity flag was set, it said “po” instead of “pe”, and vice versa\. The fact that this went unreported for over two decades tells you that nobody cares about debugging the parity flag\. A fix has gone in\. We’ll see if it makes it out before this article gets posted\. ### 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

Core dump epidemiology: fixing an 18-year-old bug

OpenAI Blog

OpenAI engineers detail the diagnosis of seemingly impossible crashes in Rockset's C++ data infrastructure, revealing both a silent hardware corruption bug on Azure and an 18-year-old race condition in GNU libunwind, resolved through epidemiological analysis of crash data.

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.

Let's Decode the Mystery Bytes [video]

Hacker News Top

This video uses disassembly and the WinDbg debugging tool to reveal that the eight mystery bytes that appear when calloc allocates memory in an x86 environment are actually the entry header of the Windows heap manager, containing information such as the current block size and the previous block size.