Incompatibilidades entre Indy 9 e Windows Server 2003?

Question

Estou tendo um problema com um aplicativo Delphi em alguns servidores do Windows 2003. Ele usa uma chamada de serviço da web para se conectar com outro servidor e transmitir dados para frente e para trás. Assim que o aplicativo chega ao método autenticado, o aplicativo morre. O aplicativo trabalha há anos em caixas anteriores com o Win Server 2003, mas não em máquinas recém -construídas. As máquinas são configuradas da mesma maneira na maioria das vezes, mas há claramente alguma configuração de configuração que difere que não sou capaz de rastrear. Além disso, enquanto o erro se torna aparente na chamada para autenticar, o Sniffing de Pacotes prova que nada acontece entre o aplicativo e o servidor que ele está tentando entrar em contato, o que fortalece meus pensamentos de que algo está morrendo desde o início na configuração da conexão. Não posso duplicar o erro localmente, então também não posso passar pelo aplicativo em um depurador. Alguma idéia de por que uma conexão da Web Indy 9 Delphi pode falhar silenciosamente?

Answer 1

Aqui é onde estava explodindo:

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

Solução encontrada! Acabou sendo DEP (prevenção de execução de dados). Quando reconstruí nosso código com as bibliotecas de sabão Delphi2007, o Probelm foi embora. Como eu não queria fazer isso (a desperalização causou problemas que fizeram o servidor engasgar em nosso XML), e meu MGR realmente não queria fazer isso (envolveu testes extensivos de regressão), procurei diferenças entre o sabão Código -fonte entre D2005 e D2007, com a idéia de fazer uma alteração direcionada no que quer que fosse diferente entre os dois. Ou seja, encontre a diferença que faz a diferença. Sem comparação Era meu amigo aqui. Uma mudança se destacou como estranha - o Rio.PAS agora inclui uma nova unidade PrivateHeap.pas. Quer saber por que, pesquisei no Google e encontrei um problema semelhante com uma explicação que parecia estar certa no alvo.

o Dep A questão é basicamente que começando com o Windows XP Service Pack 2, Se seu hardware for capaz, O Windows impedirá a execução do código da memória não executável. Infelizmente, o tempo de execução do Soap Delphi cria um monte de thunks e a memória alocada para isso não foi marcada. Então, quando a atualização do sistema operacional foi lançada em hardware capaz, você obteria um AV ao invocar um método apoiado por um componente do Rio. Este problema foi abordado em uma atualização com a unidade PrivateHeap.
-Jean-Marie Babet
http://delphigroups.info/2/11/344230.html

Bingo! Agora é aqui que fica complicado. O DEP sempre foi ativado em nossos servidores. Então, no começo, isso parecia não provável. Mas o DEP é complicado, e o hardware mais recente é mais capaz do que o hardware mais antigo. Então, acho que nos saímos com problemas de DEP no passado, e agora o hardware mais recente está nos tropeçando. Nosso administrador do servidor desligou a proteção do DEP (para aplicativos de terceiros), reiniciado e nosso código antigo funcionou! Embora eventualmente mudemos para as bibliotecas mais recentes, essa será uma ótima correção de curto prazo para nós, pois nos permite evitar que a regressão teste este aplicativo que funcione bem de outra forma.

Portanto, para resumir: nosso aplicativo Delphi2005 estava travando em servidores Windows2003 recém-criados devido à prevenção de execução de dados (DEP) que interferia na criação do objeto HTTPRIO. O Rio seria criado sem exceção, parecia válido. Mas quando o objeto iinvokable associado foi usado, ele jogava uma violação de acesso, antes de tentar se comunicar no fio. Parabéns aos nossos administradores cooperativos e muito pacientes, companheiro de dev McMar, além da comparação, e Jean-Marie Babet.

Answer 2

Poderia ser o firewall causando problemas em 2003?