Pourquoi .NET 4.0 indique-t-il une erreur "CRT non initialisé" lors du chargement d'une DLL non gérée?

Question

J'ai une DLL fournie par un tiers avec un assembly .NET 2.0 qui l'accompagne. Si je crée un projet .NET 3.5 avec VS2008, je suis capable d'appeler la DLL via l'assembly wrapper et cela fonctionne correctement. Toutefois, si je crée un projet .NET 4.0 équivalent avec VS2010, j'obtiens une erreur R6030 - CRT not initialized dans une boîte de message au moment du chargement de la DLL.

Y at-il quelque chose que je peux faire pour que cela fonctionne dans un projet .NET 4.0? Cela pourrait-il être lié aux changements du TAS, ou à autre chose?

Je porte mon travail dans VS2008 pour l'instant, mais il serait bon de comprendre ce qui se passe ...

Answer 1

Ce n'est pas une erreur .NET, c'est une erreur MS C Runtime (CRT, MSCRT).

Votre DLL tierce utilise vraisemblablement une DLL MSCRT (il y a beaucoup de versions). Au lancement du processus d'une application native, le CRT est initialisé (il contient le point d'entrée du programme qui appelle ensuite main). Il existe également un point d'entrée pour les nouveaux threads afin de garantir que les données par thread sont correctement configurées.

Si .NET 2 runtime ¹ utilise par défaut le même MSCRT que le code natif, il sera initialisé correctement. .NET 4 utilise vraisemblablement une version plus récente (les nouvelles versions de MSCRT tendent à venir avec de nouvelles versions de VS, comme le fait .NET) alors l'ancien MSCRT est seulement chargé comme une dépendance et non utilisé pour le démarrage de l'application.

La plupart du temps MSCT gère cela correctement, mais si la tierce partie dll fait quelque chose de «malin», il se peut qu'il contourne une certaine initialisation, et que cela fonctionne, la même version de MSCRT est utilisée par .NET. Un exemple d'une telle utilisation incorrecte consiste à appeler directement CreateThread plutôt que d'utiliser le wrapper MSCRT _beginthread.

À cause de cela, vous aurez besoin d'une compréhension suffisante de la 3ème partie DLL et wrapper — plus probablement vous avez besoin de fournir une recréer à la troisième partie pour eux de réparer.

---

¹ Rappelez-vous V3.5 est seulement des ensembles supplémentaires au-dessus de la CLI 2.0.

Answer 2

se fait-il que le débogage ou encore en cours d'exécution aussi bien?

Deux choses me viennent à l'esprit:

1) type d'application par défaut pour .NET est destiné au Client Framework .NET qui est le plus ennuyeux et je dois changer tout le temps. Vous pourriez obtenir toutes sortes d'erreurs bizarres si vous le gardez comme client qui au visage n'a rien à faire. Essayez de changer cela.

2) Avez-vous besoin de VS 2010 ou .NET 4.0? Si seulement VS 2010, vous pouvez définir la structure cible à 3.5 et essayer de voir si le problème est VS 2010 ou .NET 4.0. En regardant l'erreur sur internet, il semble que ce soit un problème de timing et que le runtime C ne soit pas chargé - un comportement qui ressemble à un changement dans .NET 4.0. Je n'ai aucune idée de comment le réparer.