Two months into my use of Windows Vista 64-bit Edition, I now stumbled upon a design flaw which allows any user, regardless of privileges, to make the OS totally unresponsive, even on a dual-core system.

The flaw is that the operating system allows the user to write a tight loop of calls to CreateThread() which effectively hogs all the resources on the system. When the system is in this tight loop, and in particular after creating 37,000 or so threads and counting, it starts thrashing and becomes totally unresponsive, even on a dual-core system. Ctrl+Alt+Del doesn't work and a hard reset is necessary to regain control of the operating system.

In 32-bit Windows, this method won't lockup the machine because the limited virtual address space doesn't allow you to create more than about 1,500-13,000 threads anyway (depending). In 64-bit Windows though, the virtual address space is many factors of magnitude larger, so the system starts thrashing long before it exhausts the virtual address space by creating new threads.

I think Windows lacks a crucial feature which, on the push of a certain key combination, would allow you to immediately suspend execution of all user-mode processes and would then come up with a user interface that would allow you to view the processes and kill them off if necessary. As long as there is no such functionality, Windows will probably always be at the whim of badly designed applications such as the one I contrived to create an unlimited number of threads.

I believe I spotted another bug as well - the x64 version of Windows ignores all stack size information set by a 32-bit program (whether by linker or in the code). In order to start a thread with a smaller than default stack on a 64-bit platform (e.g. a 64K stack instead of 1MB), the program must be compiled for x64.

Presumably, at least according to Raymond, 32-bit Windows respects the stack size as set in the executable by the linker.