Dépassement de capacité arithmétique ou une exception de dépassement de capacité lors du débogage

Question

C'est le jour de comportement bizarre.

Nous avons un projet Win32 fait avec Delphi 2007, qui accueille les .NET et les appels .NET pour montrer de nouvelles formes, dans le cadre d'une période de transition.

Récemment, nous avons commencé à éprouver des exceptions en apparence aléatoire des endroits et points de notre code:L'arithmétique de dépassement supérieur ou inférieur.

La trace de la pile de l'un de ces ressemble à ceci:

at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
at Gatsoft.Gat.UI.Windows.Forms.Remanaging.RemanageForm.DelphiOpenInNewMode(String employeeCode, String departmentCode, DateTime date) in C:\Dev\VS.NET\Gatsoft\Gatsoft.Gat.UI.Windows\Forms\Remanaging\RemanageForm.Delphi.cs:line 67

Dans la solution Visual Studio, l'un de la plus haute classe des bibliothèques (ie.tire dans toutes les références qu'il peut), a un programme de débogage, prévu pour le Delphi projet de sortie.Cela nous permet de déboguer .NET code de Visual Studio, même si la majeure partie du programme est écrit en Delphi.

Le problème se produit uniquement lorsque vous exécutez à partir du débogueur, pas si nous suffit d'exécuter le fichier exe directement (soit par le biais de l'explorateur, les raccourcis, ou même Ctrl+F5 à l'intérieur de Visual Studio).

Il n'y a apparemment pas de logiciels espions sur l'ordinateur (comme évoqué par cette).

Toutes les autres choses que nous pouvons vérifier?

---

Edit: Il ressemble à l' .NET débogueur est l'activation de cette SNaN drapeaux, et le Delphi débogueur ne pas.Nous allons étudier cette question plus loin, mais pour l'instant, je vais accepter @Lorenzo Boccaccia's réponse.

Apparemment Résolu

Ok, il semble, comme nous l'avons finalement cloué à ce problème.Le problème a commencé interviennent sans avoir le débogueur ainsi, pour nos testeurs, nous avons donc dû prioriser le problème vers le haut.

Enfin, nous avons constaté un problème courant avec les machines qui ont le problème, ils sont Dell Latitude D620 les ordinateurs portables avec une carte NVIDIA Quadro NVS 110M, avec un ancien pilote à partir d'une image système utilisé pour la fourniture des ordinateurs portables, de retour en 2006.

J'ai trouvé un post sur le web, bien que j'ai perdu l'url lorsque j'ai redémarré pour mettre à jour le pilote d'affichage, qui avait un .NET service s'écraser, surtout quand la machine était occupé à faire quelque chose sur l'écran.Un moyen de reproduire le son problème était d'ouvrir une invite de commande C:\ et de faire un DIR /S juste la force d'une énorme quantité de mises à jour d'écran, qui allait déclencher le crash.

Il a lui aussi une carte vidéo NVIDIA.

Le problème sur ma machine s'est produite à peu près tous les 2 à 4 startups de notre programme, mais après la mise à jour du pilote vidéo j'ai eu 123 succès des startups sans aucun problème.(BTW, je peux recommander AutoHotKey pour de telles choses).

Donc il semble que nous avons trouvé le coupable, un vieux/buggy pilote NVIDIA.

Mise à jour de cette question, de sorte que peut-être quelqu'un dans l'avenir pouvez enregistrer un peu de temps.

Maintenant, si vous m'excuserez, je vais aller pleurer dans un coin.

Poisse!

Je devais avoir ensorcelé il.À peine avais-je posté ci-dessus mise à jour qu'un collègue ordinateur portable a échoué, après la mise à jour du pilote vidéo.

Pourtant, je suis certain que c'est un problème à l'extérieur de notre application maintenant, il reste juste à comprendre que des choses spécifiques à la mise à jour.

---

D'autres mises à jour:Ok, ma machine est maintenant apparemment résolu, pas si avec mes collègues de la machine.Jusqu'à présent, nous avons mis à jour le BIOS, les pilotes du Chipset, et actuellement SP3 pour XP est sur son chemin.

Burn-in test sera fait ce soir, où l'application sera laissé pour la nuit de départ, ainsi que le problème a surgi, soit lors du démarrage, ou à la première fois, certains WinForms .NET code a été exécuté.Cette application est principalement un Delphi Win32 application, mais il accueille de la .NET runtime, et le problème semble être lié à .NET code.Lorsque nous "boot" le .NET, le problème peut apparaître, ou lorsque nous avons le feu le premier .NET fenêtre de Win32, puis il peut aussi apparaître.

---

Statistiquement, je suis prêt à libérer ce code maintenant.Au cours de la nuit de l'application a été commencé 3051 fois sans erreurs, alors qu'avant, j'ai mis à jour le pilote vidéo, il s'est écrasé tous les 2 à 4 fois.

Poussé trouvé(!/?)

Ce bug de fixation épreuve se sent comme aller chez le médecin, où la conversation suivante s'ensuit:

Doc: Does this hurt?
Me: No...
Doc: What about now?

Je l'ai poussée et levée de l'application et, enfin, je crois que j'ai trouvé quelque chose que nous avons fait qui présente ce problème.

Dans notre application, nous organisons la .NET runtime, à partir de Delphi 2007 application Win32, et dans notre colle-code la ligne suivante (maintenant):

  rc := CorBindToRuntimeEx('v2.0.50727', 'wks',
  STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN or STARTUP_CONCURRENT_GC,
  @clsid, @iid, UnkRuntimeEngine);

Les deux constantes dans le milieu, il était à l'origine seulement un 0, ce qui signifie choisissez les paramètres par défaut.Cette modification a été introduite il y a quelques mois et le problème a été lentement rampant sur nous après ce.Le changement a été introduit dans le but d'encourager les FOURMIS profiler à la charge de notre application Win32 + accueilli .NET runtime afin de faire de profilage des performances et les modifications que nous avons introduit alors faite que de travail.En outre, le problème de dépassement de capacité arithmétique/underflow a lentement fait qu'empirer, donc je parie que le problème n'apparaît pas pendant un certain temps après le changement de sorte qu'il n'était pas attribuée à l'un des changements que nous avons fait.

Aussi, étant donné que nous n' (à l'origine) a vu le problème lors de l'exécution à travers le débogueur, nous avons pensé que quelque chose n'allait pas avec Visual Studio et/ou Delphi.

De toute façon, statistiquement maintenant, avec un navigateur sur un écran de fait répétées de défilement haut et bas déclenchée par un javascript (apparemment nécessaire pour déclencher le bug), puis j'ai réussi à démarrer l'application 726 fois avec un 0 dans l'appel, et il se bloque 5 de 17 fois avec les deux valeurs constantes.

Doc: Does this hurt?

Et ne parlons pas du changement en premier lieu.Je suis sûr que le coupable veut rester anonyme... la toux

Answer 1

une version de débogage de dll peut être compilé avec la signalisation nan prise en charge, voir http://blogs.msdn.com/oldnewthing/archive/2008/07/02/8679191.aspx pour un exemple de ce problème.

que heisenbug a été causé par les variables non initialisées, ici, il pourrait y avoir un lien dll permettant le snan fonction de la cpu et de l'oubli de le désactiver lors de son retour

Answer 2

Faire les erreurs se produisent encore se produire si vous attacher le débogueur après le démarrage de l'application?