That is called a “ghost window”. What happens is that the process hangs or gets deadlocked and thus cannot respond to the paint message to update its window. To handle this situation, Windows takes over and paints the window until the program becomes responsive again and paints itself (or is killed or crashes).
In older versions of Windows, a frozen window was painted solid with its background color, but in XP, Windows takes a screenshot of the window as it was the last time it was updated, and uses that to paint it. Of course if parts of the window are covered (like if you drag it offscreen), then Windows can only paint it with the background color (which is why after dragging it offscreen in all directions, it ends up completely blank).
In addition, when you drag other windows over it, they leave a trace behind because the frozen window does not respond to the paint message when part of it is uncovered.
In Vista+, Windows still paints ghost windows like in XP, but it uses a trick to make the window seem like it is still alive to some degree; you can still move and minimize it without losing the last-updated image or getting the hall-of-mirrors effect. What it does now is to hide the actual frozen window, and replace it with a new, temporary window that is made in the same size and shape as the frozen one. The new window is painted with a screenshot of the frozen window, but with a pale white-wash. Now, when you drag other windows over it, it retains the original (ghosted) image because it is not actually frozen; it processes the paint message by painting the stored screenshot.
Microsoft employees Raymond Chen and Matt Eason covered it well.
Of course Mac, Linux, etc. all handle window drawing and management in their own ways, so they respond to frozen windows in different ways.