Indy 9和Windows Server 2003之间不兼容？ [英] Incompatibilities between Indy 9 and Windows Server 2003?

问题描述

某些Windows 2003服务器上的Delphi应用程序出现问题。它使用Web服务调用与另一台服务器连接并来回传输数据。一旦应用程序进入Authenticate方法，该应用程序就会死亡。该应用程序在Win Server 2003的先前版本中已经使用了多年，但是在新构建的计算机上却没有。在大多数情况下，机器的设置方法相同，但是显然有些配置设置不同，我无法跟踪。另外，虽然在对Authenticate的调用中该错误变得很明显，但数据包嗅探证明在应用程序和它尝试联系的服务器之间什么也没有发生，这使我更加认为在建立连接时会早日消亡。我无法在本地复制该错误，因此也无法在调试器中逐步执行该应用程序。关于为什么Indy 9 Delphi Web连接可能会默默失败的任何想法？

I'm having a problem with a Delphi application on some Windows 2003 servers. It uses a webservice call to connect with another server and transmit data back and forth. As soon as the app gets to the Authenticate method, the app dies. The app has worked for years on previous boxes with Win Server 2003, but it doesn't on freshly built machines. The machines are set up the same way for the most part, but there is clearly some config setting that differs that I'm not able to track down. Also, while the error becomes apparent in the call to Authenticate, packet sniffing proves that nothing ever happens between the app and the server it's trying to contact, which strengthens my thoughts that something is dieing early on in setting up the connection. I can't duplicate the error locally, so I can't step through the app in a debugger either. Any thoughts on why an Indy 9 Delphi web connection might silently fail?

推荐答案

在这里它爆炸了：

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

找到解决方案！原来是DEP（数据执行保护）。当我用Delphi2007 soap库重新构建代码时，探针消失了。由于我不想这样做（反序列化导致使我们的XML陷入服务器阻塞的问题），而我的mgr确实不想这样做（涉及广泛的回归测试），因此我寻找SOAP之间的差异D2005和D2007之间的源代码，目的是针对两者之间的差异进行有针对性的更改。即找到可以有所作为的差异。 超越比较是我的好友。一种变化是奇怪的-RIO.PAS现在包括一个新单位PrivateHeap.pas。想知道为什么，我用谷歌搜索并发现了一个类似的问题，并给出了正确的解释。

Solution found! It turned out to be DEP (Data Execution Prevention). When I re-built our code with Delphi2007 soap libraries, the probelm went away. Since I didn't want to do that (de-serialization caused problems that made the server choke on our XML), and my mgr really didn't want to do that (involved extensive regression testing), I looked for differences between the SOAP source code between D2005 and D2007, with the idea of making a targeted change on whatever was different between the two. i.e find the difference that makes a difference. Beyond Compare was my buddy here. One change kind of stood out as being odd - the RIO.PAS now includes a new unit PrivateHeap.pas. Wondering why, I googled and found a similar problem with an explanation that seemed to be right on target.

DEP 问题基本上是
从Windows XP Service Pack
2开始，如果您的硬件具备功能，则
Windows会阻止执行
不可执行的内存。
不幸的是，Delphi SOAP运行时
创建了一堆thunk，分配给它们的
内存不是标记为
的可执行文件。因此，当在功能强大的
硬件上发布OS
更新时，当
调用由RIO
组件支持的方法时，您会得到 AV。此问题已在
中使用PrivateHeap单元进行了更新。

-Jean-Marie Babet

http://delphigroups.info/2/11/344230.html

The DEP issue is basically that starting with Windows XP Service Pack 2, if your hardware is capable, Windows will prevent execution of code from non-executable memory. Unfortunately the Delphi SOAP runtime creates a bunch of thunks and the memory allocated for these were not marked executable. So when the OS update was released on capable hardware, you'd get an AV when invoking a method backed by a RIO component. This issue was addressed in an update with the PrivateHeap unit.
-- Jean-Marie Babet
http://delphigroups.info/2/11/344230.html

宾果！现在，这里变得棘手。始终在我们的服务器上启用DEP。因此，起初似乎不太可能。但是DEP是棘手的，并且较新的硬件比旧的硬件更有能力。因此，我认为我们过去已经摆脱了DEP问题，现在，更新的硬件使我们陷入困境。我们的服务器管理员关闭了DEP保护（适用于第三方应用程序），重新启动后，旧代码正常工作！虽然我们最终将使用较新的库，但这对我们来说是一个很好的短期解决方案，因为它使我们避免了必须对该应用程序进行回归测试的情况，否则该程序可以正常运行。

Bingo! Now here's where it gets tricky. The DEP has always been enabled on our servers. So at first, this seemed like it wasn't likely. But DEP is tricky, and newer hardware is more capable than the older hardware. So I think we got away with DEP issues in the past, and now the newer hardware is tripping us up. Our server admin flipped DEP protection off (for 3rd-party apps), rebooted, and our old code worked! While we'll eventually move to the newer libraries, this will be a great short-term fix for us as it lets us avoid having to regression test this app that works fine otherwise.

所以总结一下：由于数据执行保护（DEP）干扰了HTTPRIO对象的创建，我们的Delphi2005应用程序在新建的Windows2003服务器上崩溃了。 RIO将毫无例外地创建，看起来有效。但是，当使用关联的IInvokable对象时，它会引发访问冲突，然后才尝试在网络上进行通信。感谢我们合作且耐心的管理员，开发人员Mcmar，Beyond Compare和Jean-Marie Babet。

So to summarize: Our Delphi2005 app was crashing on newly-built Windows2003 servers due to Data Execution Prevention (DEP) interfering with the creation of the HTTPRIO object. The RIO would be created without exception, appeared valid. But when the associated IInvokable object was used, it would throw an access violation, prior to attempting to communicate on the wire at all. Kudos to our cooperative and very patient admins, fellow dev Mcmar, Beyond Compare, and Jean-Marie Babet.

这篇关于Indy 9和Windows Server 2003之间不兼容？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！