[w2k3] MDAC geheugen lek na patch KB832483

[Verwijderd]

Sinds ik op deze machine patch KB832483 heb geinstalleerd (MS KB832483) loopt het geheugen van de server binnen een half uur vol.

Wij gebruiken Coldfusion 5.0 welke MDAC nodig heeft. De server is een Dell 2.8Ghz, 1GB ram. Het geheugen loopt op naar 1.6GB en dan stopt Coldfusion, restarten van Coldfusion volstaat. Het geheugen loopt dan direct terug naar 200-300MB. Maar binnen een half uur is het weer zover. Ik gebruik MDAC 2.8, die zit standaard in W2K3.

In de process list gebruikt Coldfusion normaal geheugen, dat wil zeggen ongeveer 200MB. Het rare is dat het oplopen van het geheugen onafhankelijk van de server load gebeurt, je kunt er de klok op gelijk zetten zeg maar. Op dit moment wordt Coldfusion met een job om de 20 minuten geherstart, maar daar worden je klanten niet zo blij van.....

Microsoft weet van het probleem, zoeken levert een aantal andere gevallen op(niet specifiek met Coldfusion) maar geen oplossing. Ik moet dus wachten op een oplossing. Zie de MS nieuwsgroep.

Wat ik geprobeerd heb te doen is de patcht terug te draaien. Hij staat niet als software geinstalleerd in het control panel. Dus heb ik de patch gedownload en gekeken wat hij doet. Deze patch update windows\system32\odbcbcp.dll en windows\system32\sqlsrv32.dll. Na de update zijn deze van build 1025. Standaard is build 1022. Ik heb de dll's van een originele installatie gekopieerd en eroverheen gezet en daarna gereboot. Maar het probleem is niet opgelost.

Ik denk dat de Windows 2003 DLL manager hiervoor zorgt. Concreet is mijn vraag weet iemand hoe ik die DLL manager kan omzeilen? Of ervoor zorgen dat die de correcte versie pakt? Uiteraard is een andere oplossing ook welkom .

De MDAC component checker van MS zegt wel netjes dat ik voor alle DLL's build 1022 heb...

[PROnline]

vervang de bestanden ook in de directory DLLcache. Dit is als het goed is een subdirectory van de system32 directory. standaard is deze map niet zichtbaar.
Heeft te maken met de beveiliging van systeembestanden in explorer.

lokatie is bij windows XP in iedergeval bij mij C:\WINDOWS\system32\dllcache

[ Voor 48% gewijzigd door PROnline op 12-02-2004 13:16 ]

[Verwijderd]

Die directory heb ik in system32 gevonden maar daar staan die DLL's niet in. Zien van alle bestanden staat aan.

[Verwijderd]

Zoeken op die DLL's levert ook geen resultaten op. Een detail, ik heb de oude DLL gerenamed naar naam.dll.old. Zo 'slim' is windows toch niet?

[elevator]

Nee - heb je wel gecontroleerd dat na het vervangen van die 2 DLL's de build ook nog steeds de oude is - ook nu?

Verder - ik mag hopen dat je dit allemaal doet op een test omgeving - en niet meteen in productie

[Verwijderd]

elevator schreef op 12 februari 2004 @ 13:35:
Nee - heb je wel gecontroleerd dat na het vervangen van die 2 DLL's de build ook nog steeds de oude is - ook nu?

Verder - ik mag hopen dat je dit allemaal doet op een test omgeving - en niet meteen in productie

Ja, dat build nummer klopt nu ook wel, en windows update geeft ook aan dat ik hem nog moet installeren.

Helaas heb ik niet de mogelijkheid voor een test omgeving. Bovendien, als je de MS patches al niet meer kunt vertrouwen.... Maarja misschien dat ik na dit geintje wel een testomgeving krijg Het grootste probleem is gewoon de tijd die je er dan aan kwijt bent, een testomgeving moet je ook nog testen, met stress tools etc.

[mutsje]

Misschien is het handig om het te monitoren en dan als bug te mailen naar microsoft met workaround dat je de oude dll's weer terug zet. Komen je credentials op een technet document

[elevator]

Verwijderd schreef op 12 februari 2004 @ 13:39:
Ja, dat build nummer klopt nu ook wel, en windows update geeft ook aan dat ik hem nog moet installeren.

Als je zeker weet dat er geen andere DLL's zijn die worden gebruikt (kijk eventueel even met Process explorer - iirc kan je daarmee zien welke DLL's worden gebruikt door een process) die geupdate zijn door de patch - dan is er waarschijnlijk nog iets anders mis.

Beter nog - als je dit geheel nabouwt op een willekeurige PC - kan je het probleem dan simuleren?

[Verwijderd]

elevator schreef op 12 februari 2004 @ 14:53:
[...]

Als je zeker weet dat er geen andere DLL's zijn die worden gebruikt (kijk eventueel even met Process explorer - iirc kan je daarmee zien welke DLL's worden gebruikt door een process) die geupdate zijn door de patch - dan is er waarschijnlijk nog iets anders mis.

Beter nog - als je dit geheel nabouwt op een willekeurige PC - kan je het probleem dan simuleren?

Idd er moet wel iets anders mis zijn. Zoeken op de twee dll's levert alleen maar de goede versie nummers op. Overigens wordt alleen sqlsrv32.dll geladen en alleen gebruikt door Coldfusion.

edit:
type foutje

[ Voor 4% gewijzigd door Verwijderd op 12-02-2004 15:24 ]

[Verwijderd]

Ik heb de server uit de productie gehaald, dus ik kan er even wat mee spelen. Heb Windows 2003 een 'in-place-upgrade' gedaan. Dit hielp niet. Heb nu Coldfusion geherinstalleerd. Dit lijkt te helpen. Ik ga nu alles weer patchen behalvde de MDAC update... Dan heb ik zekerheid dat het aan die MDAC update ligt.

Ik weet nu dus zeker dat het aan MDAC ligt. Hij draait weer als een zonnetjes met alle patches op dat MDAC geval na.

[ Voor 18% gewijzigd door Verwijderd op 13-02-2004 16:41 . Reden: resultaat patchen toegevoegd ]

[mutsje]

Verwijderd schreef op 13 februari 2004 @ 15:50:
Ik heb de server uit de productie gehaald, dus ik kan er even wat mee spelen. Heb Windows 2003 een 'in-place-upgrade' gedaan. Dit hielp niet. Heb nu Coldfusion geherinstalleerd. Dit lijkt te helpen. Ik ga nu alles weer patchen behalvde de MDAC update... Dan heb ik zekerheid dat het aan die MDAC update ligt.

Ik weet nu dus zeker dat het aan MDAC ligt. Hij draait weer als een zonnetjes met alle patches op dat MDAC geval na.

Meld dit even bij Microsoft zou ik zeggen!.