Dépassement de stack de la DLL native appelée à partir d’une application gérée

Je reçois la 0xC00000FD exception 0xC00000FD (débordement de stack) de mon application lorsque j’appelle dans une DLL native. Cette opération est effectuée à partir d’une application C # gérée sous Windows CE 5 (processeur SH4). Comstackr la même DLL pour Windows XP en utilisant la même application gérée et tout fonctionne correctement (sans débordement). La routine dans la DLL effectue une récursion très complexe qui est finalement la cause du débordement, mais là encore, cela fonctionne correctement sur un PC.

Il semble que je puisse juste avoir besoin d’ajuster la taille de la stack lors de la construction de la DLL? Je pense que la taille de stack par défaut pour CE et XP est de 1 Mo lorsque vous utilisez le compilateur Visual C (j’utilise Visual Studio 2005, si cela compte). S’ils ont tous deux la même taille par défaut, je ne suis pas sûr de savoir pourquoi l’un déborderait et l’autre ne le ferait pas. J’ai essayé d’ajuster la taille de la stack avec l’indicateur / F du compilateur et l’indicateur / STACK de l’éditeur de liens, mais cela ne semblait rien faire. Il m’est également difficile de préciser la taille de la stack dans une DLL, mais l’exécutable doit la définir. Mais si tel est le cas, comment ajusterais-je la taille de la stack pour mon processus géré à utiliser lors de l’appel de la DLL native?

    Voici un lien vers une discussion sur l’architecture de la mémoire de Windows CE.

    En fin de compte, vous pouvez très peu modifier la taille de la stack par programmation ou au moment de la compilation; le système d’exploitation le fera varier en fonction d’un certain nombre de facteurs, notamment la disponibilité de la mémoire. Définir la taille de la stack avec / F ne définit qu’une valeur par défaut qui peut (et sera souvent) ignorée par le système d’exploitation. Et / F ne fonctionne pas sur un .DLL, de toute façon; cela ne fonctionne que lors de la compilation de l’exécutable. Les dll n’ont pas de stack; qui appartient au fil et (finalement) au processus.

    Il serait peut-être temps de revenir à la planche à dessin pour supprimer votre récursion.