Incompatibilités entre Indy 9 et Windows Server 2003?

Question

Je suis un problème avec une application Delphi sur certains serveurs Windows 2003. Il utilise un appel webservice pour se connecter avec un autre serveur et transmettre des données avant et en arrière. Dès que l'application arrive à la méthode d'authentification, l'application meurt. L'application a travaillé pendant des années sur les boîtes précédentes avec Windows Server 2003, mais il n'a pas sur les machines fraîchement construit. Les machines sont configurées de la même façon pour la plupart, mais il y a clairement un certain paramètre de configuration qui diffère que je ne suis pas en mesure de traquer. En outre, alors que l'erreur se manifeste dans l'appel à Authentifier, reniflage de paquets prouve que rien ne se passe jamais entre l'application et le serveur, il essaie de contacter, ce qui renforce mes pensées que quelque chose est en train de mourir tôt dans la mise en place de la connexion. Je ne peux pas reproduire l'erreur localement, donc je ne peux pas par l'application dans un débogueur soit. Toute réflexion sur pourquoi un Indy 9 connexion web Delphi pourrait échouer en mode silencieux?

Answer 1

est ici où il soufflait:

MySoapObject := GetNewSoapObject(usewsdl, addr, FHTTPRIO);  
 ...   
if MySoapObject <> nil then   
  MySoapObject.SomeFunction(); // BOOM! Access Violation here.

Solution trouvée! Il est avéré être le DEP (Prévention de l'exécution des données). Quand je Reconstruit notre code avec les bibliothèques de savon Delphi2007, le probelm est parti. Comme je ne voulais pas faire cela (de-sérialisation a causé des problèmes qui ont fait l'étrangleur du serveur sur notre XML), et mon mgr ne voulait vraiment pas faire cela (impliqué des tests de régression), je cherchais des différences entre le SOAP code source entre D2005 et D2007, avec l'idée de faire un changement ciblé sur tout ce qui était différent entre les deux. i.e. trouver la différence qui fait la différence. Beyond Compare était mon copain ici. Un changement de genre se distingue comme étant étrange - le RIO.PAS comprend maintenant une nouvelle PrivateHeap.pas unité. Vous vous demandez pourquoi, je googlé et trouvé un problème similaire avec une explication qui semblait être sur la bonne cible.

  

La question DEP est essentiellement que   en commençant par Windows XP Service Pack   2, si votre matériel est capable ,   Windows empêchera l'exécution de code   à partir de la mémoire non-exécutable.   Malheureusement, le moteur d'exécution SOAP Delphi   crée un tas de thunks et la   la mémoire allouée pour ces étaient pas   exécutable marqué. Ainsi, lorsque le système d'exploitation   mise à jour a été publiée sur mesure   matériel, vous obtiendrez un AV lorsque   l'invocation d'une méthode soutenue par un RIO   composante . Cette question a été abordée dans   une mise à jour avec l'unité PrivateHeap.
  - Jean-Marie Babet
       http://delphigroups.info/2/11/344230.html

Bingo! Maintenant, voici où il devient délicat. Le DEP a toujours été activée sur nos serveurs. Donc, au début, cela semblait comme il était peu probable. Mais DEP est délicate, et le nouveau matériel est plus performant que le matériel ancien. Je pense donc que nous partîmes des questions DEP dans le passé, et maintenant le matériel plus récent nous trébuchement. Notre serveur admin protection DEP off feuilleta (pour les applications 3ème partie), réamorcé, et notre ancien code a fonctionné! Alors que nous finirons par passer aux nouvelles bibliothèques, ce sera une grande solution à court terme pour nous car il nous permet d'éviter d'avoir à test de régression de cette application qui fonctionne très bien autrement.

Donc, pour résumer: Notre application Delphi2005 plantait sur les serveurs Windows2003 nouvellement construits en raison de l'exécution des données de prévention (DEP) interférer avec la création de l'objet HTTPRio. Le RIO serait créé sans exception, est apparu en cours de validité. Mais lorsque l'objet IInvokable associé a été utilisé, il jetterait une violation d'accès, avant de tenter de communiquer sur le fil du tout. Bravo à nos admins coopératifs et très patients, collègues dev Mcmar, Beyond Compare, et Jean-Marie Babet.

Answer 2

pourrait-il être le pare-feu causant des problèmes sur 2003?