U vremenima prije OS-a 2000, još od prvih verzija Windowsa, operativni sistem i aplikacije ovise o DLL-ovima, kratkim komadima koda koji obavljaju neke standardne, uobičajene funkcije potrebne kako aplikacijama tako i sistemu. Zajedničko im je ime OLE kontrole (object linking and embedding controls) - dynamic-link library (DLL) i ActiveX Controls (OCX).

DLL-ovi mogu biti vezani uz određenu aplikaciju ili mogu biti 'sistemski'; potonje dijele i aplikacije i OS. Prije Windowsa 2000 DLL-ovi su stvarali probleme jer su često mijenjali funkcionalnost i ponašanje kroz Microsoftove izmjene OS-a, a mijenjali su ih i programeri kroz proces razvoja aplikacije.

Microsoft je izmjene stvarao kroz patcheve i hotfixeve, a developeri su onda kao odgovor stvarali vlastite DLL-ove. Nevolje su se događale kad bi instalirane aplikacije zahtjevale različite verzije DLL-a: ili verzija nije bila dostupna u sistemu, ili je sistemska verzija bila zamijenjena pa je patio OS...

DLL-ovi su danas zaštićeni digitalnim potpisom koji nose unutar samih sebe, odnosno Windows File Protection sistemom. Originalne verzije smještene su u

%systemroot%\system32\dllcache

ili se nalaze na instalacijskom cd-u. Izmjene u DLL-u sada su dopuštene samo aplikacijama s odgovarajućim potpisom (service pack ili hotfix). Ako neautorizirana aplikacija pokuša izmijeniti neki DLL, takav se događaj otkriva preko potpisa i originalna verzija se automatski iz cachea vraća u prvobitno stanje. Na taj način developeri ne mogu u sistem ubaciti DLL koji bi eventualno stvorio probleme. Prinuđeni su ili ne koristiti sistemski DLL u svom kodu, ili kod moraju prilagoditi

radu sistemskog DLL-a. Prilikom prilagođavanja datoteke, Windows 2000 im omogućava korištenje "privatne" verzije DLL-a isključivo za potrebe aplikacije i tada se on može razlikovati od originala koje koristi OS. Tako se OS izolira od aplikacije i postiže bolju stabilnost od starijih verzija.

No, ova teorija i propušta. Na probleme sa DLL-ovima nailazimo i danas, iako mnogo rjeđe.

U situaciji kad neka aplikacija ili klijent pokazuju poruku o grešci u nekom modulu prilikom instalacije ili podizanja, možemo pokušati odregistrirati modul i pokrenuti aplikaciju opet,

regsvr32 /u imemodula.dll

ili naknadno pokušati u sistem uvesti originalnu verziju iz \dllcache direktorija ili pomoću naredbe sfc.exe

ili,

može se dogoditi da je DLL koji je potreban za rad aplikacije u nekom momentu instalacije deaktiviran, te ga je potrebno samo registrirati

regsvr32 imemodula.dll ili regsvr32 "path:\imemodula.dll"

u ovom slučaju DLL datoteka se može nalaziti i na drugom mjestu izvan %systemroot%-a.

Dobra je ideja provjeriti, preko komandno-linijskog alata depends (Dependency Walker), ovisnost ekzgekutabilne datoteke naše problematične aplikacije o sistemskim ili aplikacijskim DLL datotekama, te ih onda eventualno registrirati. Depends.exe će nas obavijestiti o datotekama koje nedostaju ili su oštećene.

Regsvr32.exe učitava datoteku koju želite registrirati ili deregistrirati zajedno sa svim njenim ovisnostima.

Greške prilikom korištenja regsvr32.exe su također moguće.

Evo jednog primjera iz Microsoft Knowledge Basea u kojemu se zahtijeva deregistracija oštećenog modula wuv3is.dll prije nego reinstaliramo originalnu verziju:

http://support.microsoft.com/default.aspx?kbid=241122

241122 WINUP- Invalid Page Fault in 'wuv3is.dll'

a opis korištenja i poruke greške mogu se vidjeti na:

Explanation of Regsvr32 Usage and Error Messages

http://support.microsoft.com/?kbid=249873

Ovdje bih želio naglasiti kako je dobro imati na umu da OLE objekti mogu biti uzrokom neposluha OS-a i aplikacija, te da pomoću ova dva alata možemo normalizirati rad problematične aplikacije, a rješenje tih problema može se izvesti brzo i efikasno.