Hantera WebBrowser-kontrollens minnesläckor

Jag har under de senaste åren vid ett flertal tillfällen stött på WebBrowser-kontrollen, som är en .NET wrapper-klass till en underliggande ActiveX-kontroll motsvarande en Internet Explorer-instans. Kontrollen gör det enkelt att lägga in ett webbläsarfönster i sina .NET-baserade Windowsprogram, och även om den är lite bänglig att jobba med så har den definitivt sina tillämpningsområden.

Nu senast var det hos en kund som jag satt och fipplade med WebBrowser. Jag ville att popup-fönster skulle öppnas i en ny WebBrowser-kontroll istället för i ett vanligt Internet Explorer-fönster (vilket är standardbeteendet), och det gick att åstadkomma med lite pill. När användaren öppnat en popup och sedan stängde den så slängdes WebBrowser-instansen bort, med allt vad det innebär av Dispose():ande. Det jag insåg ganska snabbt var att det minne som allokerades vid skapandet av popup-webbläsaren inte frigjordes när den stängdes. En minnesläcka alltså. Detta var något som sett i tidigare projekt, men då handlade det mest om det minne som kontrollen läcker varje gång en ny sida laddas, vilket sker i ett mycket långsammare tempo. Jag hade aldrig tidigare kommit på varför minnesläckorna uppstått eller hur jag skulle komma till rätta med dem. Det har heller inte varit något affärskritiskt i de tidigare fallen, men för den här aktuella kunden var det just det.

Efter lite Googlande kunde jag konstatera att minnesläckorna i WebBrowser-kontrollen är kända av Microsoft, och att det även finns "hotfixes" för dem (som jag tror ska vara inkluderade i diverse service packs för olika versioner av Windows). Jag provade att installera en sådan hotfix och kunde inte se någon skillnad överhuvudtaget.

Några timmar senare hittade jag däremot ett mycket intressant API-anrop som jag faktiskt tror löser min kunds problem, nämligen SetProcessWorkingSetSize i assemblyn kernel32.dll. Metoden används för att ställa in övre och undre gränser för det reserverade arbetsminnet för en given process, men om man anropar den med -1 som parametrar för gränserna så frigörs så mycket arbetsminne som möjligt. Så här kan det se ut i ett program skrivet med C#:

// Importera metoder från kernel32.dll, någonstans i klassdefinitionen...
[DllImport("KERNEL32.DLL", EntryPoint = "SetProcessWorkingSetSize", SetLastError = true, CallingConvention = CallingConvention.StdCall)]
internal static extern bool SetProcessWorkingSetSize(IntPtr pProcess, int dwMinimumWorkingSetSize, int dwMaximumWorkingSetSize);

[DllImport("KERNEL32.DLL", EntryPoint = "GetCurrentProcess", SetLastError = true, CallingConvention = CallingConvention.StdCall)]
internal static extern IntPtr GetCurrentProcess();

// ...och frigör arbetsminne där det passar.
IntPtr pHandle = GetCurrentProcess();
SetProcessWorkingSetSize(pHandle, -1, -1);

Så var det med den saken. Den ursprungliga forumtråden där jag läste om detta hittar du här, och Microsofts dokumentation av de aktuella metoderna i kernel32.dll finns här. Hoppas det hjälper någon.