The term DLL hell
is usually invoked with reference to conflicts between DLL versions, missing DLLs and multiple copies of DLLs. In the 14th century the poet Dante portrayed metaphysical hell as having multiple layers or circles, and in my opinion the analogy readily extends to DLL hell.
What concerns me lately I'll call the fifth circle - the swamp-like water of process address space, where wrathful DLLs fight over load addresses and slothful DLLs lie gurgling beneath the surface, fragmenting contiguous space.
A process running on 32-bit Windows has 2GB of address space by default. Into this space it needs to fit any operating system and application DLLs it loads, as well as any shared memory segments it attaches to. A DLL can have a default load address set at link time, and the operating system DLLs are usually set to load in the top 256 Mb of process address space, above 0x70000000. Incidently, a great tool to view DLL load addresses and process address space on Windows is Process Explorer
Applications which attach to IDS shared memory segments, such as oninit, onstat, onbar
need a contiguous free block of address space as large as the segment they are attaching to. So if onstat connects to the Resident segment
and onstat -g seg
shows it to be 1GB in size (due to the number of buffers configured for example), the onstat address space will need a 1GB contiguous gap where no DLLs are loaded. The first place it will try and attach the resident segment is the value of the onconfig parameter SHMBASE
which is where oninit attaches it. The default SHMBASE value on Windows is 0xC000000.
The problem starts when when a DLL has a base address somewhere in the middle of the process address space. This fragments the address space and reduces the maximum size of shared memory segment that could be attached. If base address is not set at link time, DLLs have a default address of 0x10000000. A DLL loaded there would certainly cause a problem as it's only 64 Mb higher than default SHMBASE. If a process loads multiple DLLs which have a default load address of 0x10000000, one will be loaded there and the rest will be dynamically rebased to wherever the OS sees fit.
There are currently two defects for XBSA DLLs loaded by onbar which are set to the default load address and hence onbar returns errors in larger IDS shared memory configurations:IC50382
ISM DEFAULT LOAD ADDRESS PREVENTS ONBAR FROM WORKING WITH IDS INSTANCES WITH LARGE SHARED MEMORY CONFIGURATIONSIC50204
TDPI CAUSING ONBAR ERROR CODE -43399 WITH RESIDENT SHARED MEMORY SEGMENT BEYOND CERTAIN SIZE ON WINDOWS - this one only relates to the XBSA DLLs supplied with Tivoli Storage Manager
CA Storage Manager XBSA DLLs also have this problem - in the past we've had to rebase their DLLs to make them play nicely with onbar.
These defects are currently open, though Technical Support can work around the problem for you by rebasing the DLLs manually using the Windows Platform SDK rebase tool.
What can be more frustrating is when an operating system DLL has a load address outside of the recommended system DLL range of 0x70000000 to 0x7FFFFFFF. Windows currently has several bad DLLs which can cause problems for IDS:873453 The base memory address setting of the Samlib.dll file in Windows Server 2003 may interfere with programs that require a large shared memory setting894472 Third-party programs that require lots of memory do not run in Windows XP Service Pack 2912570 Programs that require lots of memory may not run after you install Windows Server 2003 Service Pack 1913409 A program that allocates a large block of contiguous memory may not start or may intermittently fail in Windows Server 2003924054 Programs that request lots of contiguous memory may fail after you install security update 921883 (MS06-040) on a Windows Server 2003 Service Pack 1-based computer or a Windows XP Professional x64 Edition-based computer
If you are experiencing problems with onbar or other IDS utilities on Windows which go away when the number of buffers is reduced you may be in this particular circle of DLL hell. Depending on the problem the solution could be to request a patch from Microsoft, or seek help rebasing XBSA DLLs from tech support. Now would be a good time to familiarize yourself with Process Explorer to assist with the troubleshooting. A good way to determine the base address of a DLL is to use the Windows Platform SDK utility dumpbin.exe
. E.g. to see the base address of xpsp2res.dll type:
dumpbin /headers %windir%\system32\xpsp2res.dll | find "image base"
Some additional process address space can be opened up by setting the /3GB boot.ini switch
- this will provide an extra 1GB of address space above 0x80000000 for any process which is built with the IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header (and IDS binaries are built with this).
One glimmer of light on the horizon is that when x86_64 IDS is available for for Windows 64-bit, this problem should largely be a thing of the past. Shared memory segments larger than 2GB will be available, and we can start ascending the terraces of DLL Purgatory - ok I probably took the analogy too far that time.
Before anyone asks when the x86_64 Windows port of IDS will be ready, that has not been finalized yet; all I can say is that it is in progress.[Read More