Delen via


loaderLock MDA

Notitie

Dit artikel is specifiek voor .NET Framework. Dit geldt niet voor nieuwere implementaties van .NET, waaronder .NET 6 en nieuwere versies.

De loaderLock beheerde foutopsporingsassistent (MDA) detecteert pogingen om beheerde code uit te voeren op een thread die de loadervergrendeling van het Microsoft Windows-besturingssysteem bevat. Een dergelijke uitvoering is illegaal omdat het kan leiden tot impasses en het gebruik van DLL's voordat ze zijn geïnitialiseerd door het laadprogramma van het besturingssysteem.

Symptomen

De meest voorkomende fout bij het uitvoeren van code in de loadervergrendeling van het besturingssysteem is dat threads impasses wanneer wordt geprobeerd andere Win32-functies aan te roepen waarvoor ook de loadervergrendeling is vereist. Voorbeelden van dergelijke functies zijn LoadLibrary, GetProcAddress, FreeLibraryen GetModuleHandle. De toepassing roept deze functies mogelijk niet rechtstreeks aan; de COMMON Language Runtime (CLR) kan deze functies aanroepen als gevolg van een aanroep op een hoger niveau, zoals Load of de eerste aanroep naar een methode voor het aanroepen van een platform.

Impasses kunnen ook optreden als een thread wacht tot een andere thread begint of eindigt. Wanneer een thread wordt gestart of voltooid, moet deze de laadvergrendeling van het besturingssysteem verkrijgen om gebeurtenissen aan betrokken DLL's te leveren.

Ten slotte zijn er gevallen waarin aanroepen naar DLL's kunnen plaatsvinden voordat deze DLL's correct zijn geïnitialiseerd door het laadprogramma van het besturingssysteem. In tegenstelling tot de impassefouten, die kunnen worden vastgesteld door de stapels te onderzoeken van alle threads die betrokken zijn bij de impasse, is het erg moeilijk om het gebruik van niet-geïnitialiseerde DLL's te diagnosticeren zonder deze MDA te gebruiken.

Oorzaak

Gemengde beheerde/onbeheerde C++-assembly's die zijn gebouwd voor .NET Framework-versies 1.0 of 1.1, proberen doorgaans beheerde code uit te voeren in de loadervergrendeling, tenzij er speciale zorg is besteed aan het koppelen met /NOENTRY.

Gemengde beheerde/onbeheerde C++-assembly's die zijn gebouwd voor .NET Framework versie 2.0 zijn minder gevoelig voor deze problemen, met hetzelfde verminderde risico als toepassingen die gebruikmaken van niet-beheerde DLL's die de regels van het besturingssysteem schenden. Als bijvoorbeeld het toegangspunt van een niet-beheerde DLL DllMain wordt aangeroepen CoCreateInstance om een beheerd object te verkrijgen dat is blootgesteld aan COM, is het resultaat een poging om beheerde code uit te voeren binnen de loadervergrendeling. Zie Initialisatie van gemengde assembly's voor meer informatie over problemen met het vergrendelen van loaders in .NET Framework versie 2.0 en hoger.

Oplossing

In Visual C++ .NET 2002 en Visual C++ .NET 2003 konden DLL's die zijn gecompileerd met de /clr compileroptie, niet-deterministische impasse bij het laden van bestanden. Dit probleem werd het probleem met het laden of vergrendelen van een laadprogramma genoemd. In Visual C++ 2005 en hoger is bijna alle niet-determinisme verwijderd uit het gemengde DLL-laadproces. Er zijn echter enkele resterende scenario's waarvoor loadervergrendeling (deterministisch) kan optreden. Zie Initialisatie van gemengde assembly's voor een gedetailleerd overzicht van de oorzaken en oplossingen voor de resterende problemen met het vergrendelen van laders. Als dit onderwerp het probleem met het vergrendelen van het laadprogramma niet identificeert, moet u de stack van de thread onderzoeken om te bepalen waarom de loadervergrendeling optreedt en hoe u het probleem kunt oplossen. Bekijk de stacktracering voor de thread die deze MDA heeft geactiveerd. De thread probeert de beheerde code illegaal aan te roepen terwijl de laadvergrendeling van het besturingssysteem wordt vastgehouden. U ziet waarschijnlijk een DLL-bestand DllMain of een gelijkwaardig toegangspunt op de stack. De regels van het besturingssysteem voor wat u wettelijk vanuit een dergelijk toegangspunt kunt doen, zijn vrij beperkt. Deze regels sluiten elke beheerde uitvoering uit.

Effect op de runtime

Normaal gesproken loopt een aantal threads in het proces vast. Een van deze threads is waarschijnlijk een thread die verantwoordelijk is voor het uitvoeren van een garbagecollection, zodat deze impasse een grote invloed kan hebben op het hele proces. Bovendien voorkomt het extra bewerkingen waarvoor de laadvergrendeling van het besturingssysteem is vereist, zoals het laden en lossen van assembly's of DLL's en het starten of stoppen van threads.

In sommige ongebruikelijke gevallen is het ook mogelijk dat toegangsschendingen of soortgelijke problemen worden geactiveerd in DLL's die worden aangeroepen voordat ze zijn geïnitialiseerd.

Uitvoer

Deze MDA meldt dat er een illegale beheerde uitvoering wordt uitgevoerd. U moet de stack van de thread onderzoeken om te bepalen waarom de laadlaadvergrendeling optreedt en hoe u het probleem kunt oplossen.

Configuratie

<mdaConfig>
  <assistants>
    <loaderLock/>
  </assistants>
</mdaConfig>

Zie ook