Crash à l'appel en nvoglv32.dll sur la nouvelle carte vidéo
Il y a quelques jours-je configurer mon ordinateur et installé une nouvelle copie de Windows 8 en raison de certaines modifications sur le matériel. Entre autres, j'ai changé la carte vidéo Radeon HD 7870, la Nvidia GTX 660.
Après la mise en place de Visual Studio 11 encore une fois, j'ai téléchargé mon dernier OpenGL projet à partir de Github et reconstruit l'ensemble du projet. J'ai couru à l'application de Visual Studio et il s'est écrasé à cause de nvoglv32.dll
.
Exception non gérée à 0x5D9F74E3 (nvoglv32.dll) Application.exe: 0xC0000005: violation d'Accès lecture de l'emplacement 0x00000000.
Dans l'ancien environnement de l'application a fonctionné comme prévu. Je n'ai rien changé du projet ou du code source. La seule différence était la langue de l'Visual Studio domaines de l'installation qui est en anglais maintenant, et a été d'allemand avant de. Donc j'ai créé un nouveau projet et de l'adopté de tous les paramètres, mais l'erreur reste.
Afin de localiser la panne, j'ai remarqué que tous initialisation (fenêtre, shaders,...), a réussi, et l'erreur est à l'appel de glDrawElements()
qui fait référence à la gemoetry passer de mon moteur de rendu différé.
Après quelques recherche j'ai découvert que nvoglv32.dll
est de Nvidia et est sur un des services Compatible OpenGL ICD
. N'est que d'une certaine façon dire que mon application fonctionne dans un mode compatible? Qui sonne comme un mode de soutien des applications anciennes et je veux mine de s'exécuter dans un mode régulier! Au fait, j'ai installé les derniers pilotes de l'écurie pour ma carte vidéo.
Pour être honnête, je n'ai pas la moindre idée de comment l'approche de la résolution de ce crash. Quelle est la cause et comment y remédier?
Mise à jour: j'ai trouvé un post sur Geforce Forums au sujet de mon problème. Bien qu'il n'y a pas eu de réponse, l'auteur pourrait résoudre le problème en modifiant l'ordre des deux appels OpenGL.
Salut à tous,
Après avoir farfouillé avec mon code source de l'application pour quelques heures, j'ai trouvé que le fait d'appeler les fonctions...
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, #) glBindVertexArray(#)
...dans cet ordre les causes de l'accident nvoglv64.dll.
Inverser l'ordre de ces appels à...glBindVertexArray(#) glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, #)
...évite le crash, et semble s'être bien comportés.
Cheers,
Robert Graf
Depuis que je ne pas utiliser les vertex arrays je ne peux pas simple de faire ce correctif, mais il pourrait y avoir un problème similaire. Je vais faire part de mes progrès.
Mise à jour: je n'ai absolument aucune idée de comment résoudre mon problème. J'ai essayé vidéo différentes versions de pilote, mais il ne fait aucune différence. J'ai complètement réécrit le moteur de rendu en utilisant un minimum de shaders et simple de l'avant le rendu. Mais l'accident de seuil se produit lors du premier appel.
OriginalL'auteur danijar | 2013-02-23
Vous devez vous connecter pour publier un commentaire.
Plus probable que vous avait un hors-limites d'accès dans votre code tout le temps, mais l'AMD Radeon Catalyst drivers ne réserve plus d'espace d'adressage, ou pris au préalable. Et maintenant, votre NVidia GeForce pilote qui n'est pas.
Soit vous êtes de passage glDrawElements un trop grand nombre de
count
éléments de dessiner, ou votre index de la mémoire tampon contient des valeurs de l'indice au-delà de la portée de votre vertex arrays. Si c'est le plus tard, alors vous êtes probablement en utilisant côté client sommet des tableaux, comme des Organisations sises à vienne généralement attirer hors des limites du terrain accède; aussi ceux qui ne serait pas un crash de votre côté client du programme, mais juste de rendu des ordures.int count; glGetBufferParameteriv(GL_ELEMENT_ARRAY_BUFFER, GL_BUFFER_SIZE, &count); glDrawElements(GL_TRIANGLES, count/sizeof(GLuint), GL_UNSIGNED_INT, 0);
Pourriez vous s'il vous plaît vérifiez que vous avez réellement un GL_ELEMENT_ARRAY_BUFFER lié, lors de cette opération. Aussi je voudrais initialiser
count
à 0, et de vérifier la valeurglGetBufferParameters
la définit. Vérifiez également l'OpenGL erreurs à chaque étape (n'oubliez pas que vous devez appeler glGetError dans une boucle jusqu'à ce qu'il retourne GL_NO_ERROR). – Mon intuition est que la Radeon pilotes ont été un peu bâclée avec tampon de liaisons et serait de retour quelque chose d'utile, même s'ils ne devraient pas à cette situation.Le tableau tampon est lié,
count
est fixé à 144, il n'y a pas d'OpenGL erreurs. Mon chemin, voici le code source.C'est vraiment curieux. Dommage que je n'ai pas de Windows 8/NVidia machine disponible dès maintenant pour reproduire ce. Une dernière suggestion, alors je suis hors de suggestions pour le moment, et c'est plutôt désespérée: Comment vous appelez
glewInit()
chaque fois que vous entrez votre fonction rendu?L'approche habituelle est de désactiver unique codepaths, un à un, jusqu'à ce que l'erreur disparaisse. Proprocessor
#ifdef
déclarations sont à votre ami ici. Une fois que vous avez trouve la codepath responsable, en une seule étape de débogage chaque pas qu'il fait. Aussi j'avais énigme avec des tonnes de journalisation de débogage de chaque variable et de calcul impliqué dans un fichier dans le tampon d'accès en écriture.OriginalL'auteur datenwolf
Enfin j'ai trouvé une solution pour corriger le crash.
La SFML cadre-je utiliser pour créer la fenêtre et plus dispose d'une fonction de réinitialisation de l'état OpenGL du contexte. Je l'ai appelé juste après la création de fenêtre.
Même si je ne peux pas expliquer pourquoi, la suppression de la fonction d'appel a résolu le crash. Peut-être que c'est parce que GLEW ou quelque chose d'autre n'est pas encore initialisé ce moment.
OriginalL'auteur danijar