Don't fear the Thread Reaper, a Windows ghost of bugs past To celebrate Halloween this week, Windows veteran Raymond Chen has dug into the lengthy list of Windows bug check codes and come up with something obscure and vaguely threatening – the Thread Reaper. It is bug check 0x13 and named EMPTY_THREAD_REAPER_LIST. Where did this code come from? After all, it was never used in any …
As much as it would be easy to rip in to Bugzilla's code once again, for once I have to credit the developers for checking that something that should never happen did (or did not).
I guess that was way back when they had actual engineers working on code, not today's "move fast and break it" kids.
Looks like ancient code is the best . . .
We had a similar situation with a library many years ago. As an implementor I toyed with the idea of 'ERROR: This is not an error.' but then because I was into Terry Pratchett's work at the time I went with 'ERROR: Mr Beekle is a Poo'.
Then one day would you believe it another bug actually triggered that error for a customer. Luckily they thought it was funny.
Looks like ancient code is the best . . .
For whatever value you choose as ancient. There must have been a golden age.
In the 80s I had to rewrite a Pl/1program written in the 70s that used gotos, and not even semi structured gotos.(Manglement ran some sort of program over our entire codebase looking fror files with gotos in them - everybody was given a program to structure properly as a side project for when we were waiting for jobs to run, walkthroughs etc). Code was jumping everywhere.
Would be interesting to know what the thread reaper was checking just so you could provoke the error on an NT4 kernel and watch the fireworks. :)
I have a NT4 SP6 CD somewhere - for many years I had to run a NT4 system with a hardware dongle on a centronics port to support(license) some some irreplaceable software for some equally irreplaceable hardware (instrument) from a long gone vendor. I remember the NT4 CD also had a MIPS version (and Alpha?)
I imagine it was a specific data structure. No structure = no thread corpse.
Weird things can happen in asynchronous code. Especially at the higher levels. I have had an error message thrown from a section of code that should never have been executed.
Since that's an address-family constant for Winsock, I presume the comment means they saw it on a network but didn't know what it was for.
These days, AF 20 is XTP over IPv6, but I wouldn't be surprised if someone was just using it without registration back when Winsock was first being developed, because networking was a wilder place then.
What you say is true from user-space, but may not necessarily be correct from the kernel’s point of view (but I have very little knowledge of WNT beyond the origin of its name... hint: 'WNT'-0x010101== ?).
I suspect that you calling the user-space exit function might just set a byte somewhere that prevents the thread from being scheduled, and marks the thread object as ready for disposal, leaving it to another kernel task to go through those marked objects and dispose them.
...Microsoft was vying with Novel for the SMB OS crown. Win 3.11 and Win95 were exposing their rotten behaviors in full view of the public and someone had to clean up the mess. That someone was a man I never met and who's name I have never know. He had the bright idea of editing the SYSTEM.INI and changing the "SHELL=" variable to equal "D:\Setup.exe /P f" and if the Windows CD was in the CDROM drive the Windows (DOS) OS would reinstall itself with just a little user intervention. You wouldn't even need to reinstall your programs because of the magical /P switch.
So yeah, when it comes to legacy baggage I won't put anything past the folks at Redmond. It was all designed from the ground up to be reinstalled when it fell over. They just never made that information public. Yet the public figured it out anyway then Norton Ghost was born and lived a short life before Clonezilla superseded it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
