Incompatibilidades entre Indy 9 y Windows Server 2003?

Question

Estoy teniendo un problema con una aplicación Delphi en algunos servidores de Windows 2003. Se utiliza una llamada de servicio web para conectar con otro servidor y transmitir datos de ida y vuelta. Tan pronto como la aplicación obtiene con el método de Autenticación, la aplicación muere. La aplicación ha trabajado durante años en las cajas anteriores con Windows Server 2003, pero no en las máquinas recién construido. Las máquinas están configurados de la misma manera en su mayor parte, pero hay claramente un cierto ajuste de configuración que se diferencia de que no soy capaz de rastrear. Además, mientras que el error se hace evidente en la llamada a autenticar, la detección de paquetes demuestra que nunca pasa nada entre la aplicación y el servidor que está tratando de ponerse en contacto, lo que refuerza mi pensamiento de que algo está muriendo desde el principio en el establecimiento de la conexión. No puedo reproducir el error a nivel local, por lo que no puede dar un paso a través de la aplicación en un depurador tampoco. ¿Alguna idea de por qué un Indy 9 conexión web Delphi podría fallar en silencio?

Answer 1

Aquí es donde se soplaba:

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

Solución encontrado! Resultó ser DEP (Data Execution Prevention). Cuando reconstruido nuestro código con las bibliotecas de jabón Delphi2007, la probelm fue. Como yo no quiero hacer eso (de-serialización causó problemas que hicieron que el estrangulador servidor en nuestra XML), y mi mgr realmente no quería hacer eso (las pruebas de regresión extensa involucrados), me puse a buscar diferencias entre el jabón código fuente entre D2005 y D2007, con la idea de hacer un cambio objetivo en lo que fuera diferente entre los dos. es decir encontrar la diferencia que hace una diferencia. que no tiene comparación era mi amigo aquí. Uno de los cambios de tipo destacaba como extraño - el RIO.PAS ahora incluye un nuevo PrivateHeap.pas unidad. Se pregunta por qué, en Google y encontró un problema similar con una explicación que parecía estar justo en el blanco.

  

La DEP tema que es básicamente   comenzando con Windows XP Service Pack   2, si su hardware es capaz   Ventanas evitará la ejecución de código   de la memoria no ejecutable.   Por desgracia, el tiempo de ejecución de SOAP Delphi   crea un grupo de procesadores y la   memoria asignada para estos no eran   marcado ejecutable. Así que cuando el sistema operativo   actualización se publicó el capaces   hardware, se obtendría un AV cuando   invocar un método respaldado por un RIO   componente . Esta cuestión se abordó en   una actualización con la unidad PrivateHeap.
  - Jean-Marie Babet
       http://delphigroups.info/2/11/344230.html

Bingo! Ahora aquí es donde se pone difícil. El DEP siempre ha sido habilitada en nuestros servidores. Así que al principio, esto parecía que no era probable. Pero DEP es complicado, y más reciente hardware es más capaz que el hardware antiguo. Así que creo que conseguimos acabar con los problemas de DEP en el pasado, y ahora el nuevo hardware nos está tropezar. Nuestro administrador del servidor volcó la protección DEP fuera (para aplicaciones 3 ª parte), reiniciado, y nuestro antiguo código funcionó! Mientras que con el tiempo movemos a las bibliotecas más recientes, esto va a ser una gran solución a corto plazo para nosotros, ya que nos permite evitar tener que prueba de regresión esta aplicación que funciona bien lo contrario.

Para resumir: Nuestra aplicación Delphi2005 estaba fallando en los servidores de nueva construcción Windows2003 debido a la Prevención de ejecución de datos (DEP) interferir con la creación del objeto HTTPRIO. El RIO sería creado sin excepción, apareció válida. Sin embargo, cuando se utilizó el objeto IInvokable asociado, sería lanzar una violación de acceso, antes de intentar comunicarse en el cable en absoluto. Felicitaciones a nuestros administradores de cooperación y muy paciente, compañero dev Mcmar, Beyond Compare, y Jean-Marie Babet.

Answer 2

¿Podría ser el cortafuegos causando problemas en el 2003?