Určitáverze knihovny může být kompatibilní s určitýmiverzemisoftwaru, které ji používají. Bohužel nemusí být kompatibilní s jinými verzemi softwaru.Windows byl zvláště zranitelný, protože kladl velký důraz na dynamické linkovaníC++ knihoven a OLE objektů.C++ třídy obsahovaly velké množství metod a malá změna v jedné z jejich mohla způsobitnekompatibilitu s programy, které ji využívaly.Linkování a propojování objektů má řadu striktních pravidel, aby se právě tomuto zabránilo. Například používání rozhraní, která se nesmí měnit, nebo nepoužívánísdílené paměti. Ani to však není dostatečné, protože fungování uvnitř třídy může být stále změněno. Úprava knihovny může být pro jednu aplikaci opravou chyby, pro jinou odstranění důležité funkčnosti. SystémWindows před verzíWindows 2000 byl v tomto ohledu velmi citlivý, protožeCOM tabulka tříd byla sdílena všemi uživateli a procesy. VCOM objektu bylo pro každouDLL/EXE knihovnu vytvořeno pouze jedno specifické COM ID. Pokud nějaký program potřeboval vytvořitinstanci dané třídy nebo knihovny, použila se knihovna z centralizovaného úložiště. Naopak když se nainstaloval novýprogram, staráverze knihovny byla odstraněna a nainstalovala se verze s novým programem. Důsledkem toho bylo že instalací nového programu přestal fungovat ten starý.

Problém DLL podupávání (anglickyDLL stomping) nastal, když nový program přehrál jinému programu starou funkčníDLL knihovnu novou knihovnou, se kterou starý program nedokázal fungovat. Častým problémem byly knihovnyctl3d.dll actl3dv2.dll proWindows 3.1. Dodavatelé mohli používat ve svýchaplikacích Microsoftem vytvořené knihovny, ale raději ke svým programům přidávali knihovny vlastní. DupáníDLL se objevilo z důvodů:

• Microsoft distribuoval runtimeDLL knihovny jako systémové komponenty (původně v C:\WINDOWS a C:\WINDOWS\SYSTEM). Tím ušetřil místo v paměti, proto knihovny byly sdílené. To mělo smysl u strojů, které měly malou paměť.
• Instalátory aplikaci jsou typicky spuštěny v privilegovaném kontextu, který má přístup k instalaci DLL knihoven do systémových adresářů a má také přístup do registrů, kde může novéDLL knihovny registrovat jako COM objekty. Špatně napsaný instalátor může nainstalovat starší verzi systémovéDLL knihovny a nic ho v tom nezastaví. VeWindows Vista a vyšších to může provést pouze instalátor, který je označen jako důvěryhodný nebo si vyžádáadministrátorské heslo.
• Aplikacím veWindows bylo povoleno, aby v rámci svých instalací stahovaly aktualizaceoperačního systému. Pokud tedy nějaká aplikace potřebovala knihovnu, začlenila si ji k sobě už při instalaci.
• Před vydánímWindows Installeru existovaly pouzekomerční programy, které instalátor zastupovaly a spousta lidí si začala psát vlastní instalátory. Bohužel ne všichni znali pravidla, jakými by se instalátory měly řídit. Tím se dooperačního systému dostávaly různé verze DLL knihoven.
• Některávývojová prostředí automaticky nepřidávala verzi knihovny ke svým kompilovaným knihovnám a spoustavývojářů na to taky zapomínala. Tím se opět dostaly do systému knihovny, které neodpovídaly ve verzi, které softwary potřebovaly.
• Občas operační systémDLL knihovnu odstranil nebo nahradil starší nebo zastaralou verzí. Například systémWindows 2000 nahradil ovladač barevné tiskárny ovladačem černobílé tiskárny, pokud byla barevná tiskárna nainstalována první.

V COM objektech a další částechMicrosoft Windows je důležité, aby si všechny aplikace mohly registrovat svoje komponenty. Registry byly určeny pro to, aby řekly, která DLL se má ve výsledku použít. Pokud ovšem byla v registrech zapsána jináDLL (jináverze), tak program dostal knihovnu, která pro něj byla nefunkční. Toto se stalo, pokud jednaaplikace při instalaci přepsala jinému programu verzi knihovny, která měla sice stejné jméno, ale jinou verzi.

Všechny16bitové verzeWindows pro DOS načítají jen jednu instanci každéDLL knihovny. Všechnyaplikace odkazují na jednu kopii voperační paměti, a teprve když ji žádná aplikace nepoužívá, je DLL z paměti uvolněna. V řaděWindows NT (32bitové i64bitové) dochází ke sdílení knihoven mezi procesy pouze v případě, že různéspustitelné soubory načítají DLL modul ze stejného adresáře a souboru. Sdílí se pouze výkonný kód, nikoliv všakzásobník. Sdílení kódu meziprocesy je zajištěno mechanismemmapováním paměti (anglickymemory mapping), takže i když je požadovanáDLL knihovna umístěná v adresáři, kde je očekáváno její umístění, jako například v systémovém adresáři nebo v adresáři aplikace, sdílení se nepoužije, když jiná aplikace začala používat nekompatibilní verzi z jiného adresáře. Tento problém se může projevovat jako chyba 16bitové aplikace, ke které dochází pouze tehdy, když se aplikace spustily ve určitém pořadí.

V přímém rozporu s problémem DLL podupávání: Pokud aktualizace DLL nemá vliv na všechny aplikace, které ji používají, tak se DLL knihovny stávají těžší na správu, což znamená k odstranění problémů, které se vyskytují v současných verzích DLL (bezpečnostní opravy jsou zvláště přesvědčivý a bolestivý případ). Místo použití pouze nejnovější verzeDLL, musí implementace v ideálním případě opravit problémy a otestovat jejich kompatibilitu na každé vydané verzi DLL.

Nejednoznačnost, s níž knihovny, které nejsou plně kvalifikované, mohou být vloženy dooperačního systémuWindows je v posledních letech zneužívánamalwarem k otevření nových cestzranitelnosti, které ovlivňují aplikace od mnoha různých dodavatelů software, stejně jako systémWindows.

Jedním z nejjednodušších řešení DLL pekla v aplikaci je k ní připojit všechny statické knihovny. Toto je běžné v Microsoft C/C++ aplikacích, kde místo toho, abychom se museli starat o to, které verze MFC42.DLL jsou nainstalovány, aplikace je sestavena tak, aby se propojila se statickými knihovnami. To eliminuje DLL úplně, a je přijatelné pro samostatné aplikace, které používají pouze knihovny, které nabízejí statické možnosti, jako je napříkladMicrosoft Foundation Class Library. Tím mizí hlavní výhoda DLL (sdílení knihoven v paměti mezi za účelem snížení zatížení paměti), ale zjednodušuje se další vývoj softwaru a komplikované nasazení bezpečnostních oprav nebo novějších verzí softwaru.

Problém přepsání DLL byl poněkud snížen s příchodemOchrany souborů systému Windows (Windows File Protection, WFP), která byla zavedena v systémuWindows 2000. WFP zabrání neautorizovaným aplikacím přepsání systémové knihovny DLL, pokud nepoužívají specifické rozhraníWindows API, které toto umožňují. Stále ale existuje riziko, že aktualizace od společnosti Microsoft budou neslučitelné s existujícími aplikacemi, ale toto riziko je obvykle sníženo v současných verzích systému Windows pomocí Side-by-side assembly (SFC).

Aplikace třetích stran nemohou měnit soubory OS, pokud neobsahují balík legitimních aktualizací systému Windows přímo v jejich instalaci, nebo v případě, že tuto službu zakázala ochrana souborů systému Windows během instalace. Od Windows Vista aplikace třetích stran nemohou převzít vlastnictví systémových souborů a udělit si k nim přístup. Nástroj SFC může kdykoliv tyto změny vrátit.

Řešení spočívá v tom, mít obě odlišné kopie stejné DLL knihovny pro každou aplikaci, obě nadisku i vpaměti.

Snadné manuální řešení konfliktů bylo umístění různých verzí problémových DLL knihoven do složek aplikací, než do společné složky celého systému. Toto funguje obecně tak dlouho, dokud aplikace je32bitová nebo64bitová a pokud DLL nepoužívá sdílenou paměť. V případě16bitových aplikací nelze spustit na 16bitové platformě dvě aplikace současně nebo na 16bitovémvirtuálním stroji pod 32bitovým operačním systémem. Před Windows 98 SE/Windows 2000 tomuto zabraňovalo Object Linking and Embedding (OLE), protože starší verze systému Windows měla jediný registrCOM objektů pro všechny aplikace.

SystémyWindows 98 SE/Windows 2000 představily řešení s názvem Side-by-side assembly (SFC), které načte samostatné kopie DLL pro každou aplikaci, která je vyžaduje (a tím umožňuje aplikacím, které vyžadují konfliktní DLL, se spustit současně). Tento přístup eliminuje konflikty tím, že aplikaci umožní načíst požadovanou verzi modulu do svého adresního prostoru, při zachování primárního přínosu sdílení DLL mezi aplikacemi (tj. snížení využití paměti) pomocí metody mapování paměti a sdílení společného kódu mezi různými procesy, které nadále používají stejný modul. Avšak u DLL knihoven využívajících sdílená data mezi více procesy tento přístup nemusí fungovat. Jeden negativní vedlejší efekt jsou osamocené instance DLL knihovny, které nemusí být aktualizovány během automatizovaných aktualizací.

V závislosti na architektuře aplikace a běhového prostředí může býtpřenosná aplikace efektivní způsob, jak snížit některé problémy s DLL, protože každý program obsahuje svazky svých vlastních soukromých kopií všech DLL knihoven, které potřebuje.

Virtualizace aplikací může také umožnit běh aplikace v „bublině“, která zabraňuje instalaci DLL knihoven přímo do souborů operačního systému.