DLL Hell is the clever (almost rhyming) name given to the array of malfunctions caused by version mismatches between shared libraries on any Microsoftish operating system.
The above statement could be frightening to the uninitiated, so I'll slow down a bit. DLL stands for dynamic link library, which is IBM/Microsoft-ese for shared library. A DLL, like a shared library on any platform, is a lump o' program. Programs are distributed as executable files; that is, the program you run. Most executable files have a lot of overlap in their needs, and rather than reproduce the same code in each executable, the relevant parts are moved into a separate file, which is shared between all applications that need it. This is the shared library.
On any of the operating systems where DLLs are prevalent (mainly being the Windows family and OS/2), large portions of important operating system code exist in DLLs. So, if a program wants to show a "File Open" dialog box, change the video mode, allocate memory, or rename a file, it just calls a routine in an operating system DLL.
The idea is that because the application code and the library code exist in separate files, they can be upgraded independently. What fun! Theoretically, all you'll need to do is upgrade a few system DLLs, and all your applications will have fabulous new features. However, this does not work.
For example, COMDLG32.DLL is popular DLL that is responsible for several Common Dialog boxes on the 32-bit Windows operating systems, including File Open, File Save, and Select Color. Early in the release of Windows 95, there were at least three versions of this file floating around: the one released with Windows 95, the one released with Plus!, and one silently installed with Microsoft Office. The problem, and a serious case of DLL Hell, arose because each of these versions had subtle undocumented differences, and the existing documentation was not specific enough to determine the right way to use them. As a result, a program using COMDLG32.DLL that was developed with one version may be running with a different version, and as a result not function correctly. The errors are sometimes obvious (GPF) and sometimes not-so-obvious (failed file save with no error message). To make matters worse, it isn't trivial to determine which version you had: if you installed, but then removed, Mircosoft Office, its stealthy COMDLG32.DLL would still be on your system. This kind of DLL Hell is a result of bad implementation on Microsoft's part, exacerbated by slipshod upgrades: if they obeyed their own standards, the various COMDLG32.DLLs would have been interchangable. (Then again, there are those who argue that this particular instance of DLL Hell was an intentional play by Microsoft to cripple its competitors.)
Another flavor of DLL Hell arose in Windows 3.1, before a socket networking interface became part of the operating system. Sockets were implemented through WinSock, which served as glue between the network protocol and the application. WinSock was distributed as a DLL. The problem was that each ISP, including AOL, provided their own version of WinSock. If you wanted to connect to a different service provider, you would need to exit Windows, copy the appropriate WinSock DLL into your Windows directory, and restart Windows. God save the man who uses the wrong version of WinSock or accidentally overwrites the appropriate version.
Many of the reforms in Microsoft's .NET strategy attempt to solve DLL Hell. For example, .NET records in the application file which particular version of a DLL it expects. Also, multiple versions of the same DLL are allowed on the same system, and there is an intelligent search algorithm to find the correct one.