<一>
用D7写了一个调用C#的WebService客户端程序。开了一个线程,定时访问WebSerice的接口。
程序在我的本本上(WINXP)测试时,跑的很欢畅。
<二>
昨天晚上,把这个WebService客户端以NT服务的形式注册部署到服务器上(Win2003 Server)。
这样开机后便可以服务方式自动运行,不用人工监管。
待部署完毕后,启动服务。但执行时间一到,日志中监测到报错:调用WebService时异常。
可原本好好的,咋这就纳闷了呢!?
并且这是个很简单的东东,于是,郁闷。
服务器没有IDE环境,Debug非常痛苦,日志记录跟踪。
跟踪发现,得到WebService对象的时候是没有问题的,但在调用其接口的时候产生了异常。
又单独写了WebService客户端可执行的测试程序,在服务器上运行。
结果Throw出的Exception是“Access violation at address 00E24255. Write of address 00E24255”。
晕菜。这就是出名的“Access violation”。
没办法,解决问题吧。
通常访问对象(内存地址)不存在或COM异常时会有这种报错。
先在网上搜,看看是不是WebService的问题。
baidu+google,搜个底朝天,无解,继续郁闷。
“Access Violation”果真是大名鼎鼎--“最令人气恼的Windows程序遇到的错误之一”。
关于“Access violation”,的确有N多条记录被搜到,但无对症的。
其中说法不一,各有特色。
有关于系统dll的,有关于硬件设备及其驱动的。
还有一贴,好像是老猫写的,关于Delphi Access violations 问题的解决之道,亦非我所需者。
另有一贴,说是线程中访问ADO的问题,但我已经初试化了COM接口。
于是打开程序,把线程排查看了一边,没问题,好好的。
另外,一般关于Delphi打造WebService客户端的例子中,都会提到THTTPRIO的。
而我一向是不用这个东东的,嫌麻烦。
莫非是这个小东东在搞鬼,它也就是起到接口转换的作用。
我加了一个。转了一下。试了一次。
徒增加了一点郁闷。
<三>
接下来琢磨:程序在笔记本上无误,但部署在到服务器上出错。说明服务器的环境有问题,而非程序本身之过。
莫非在线程中调用WebService服务,在客户端需要部署什么插件或注册什么东东乎?
就象部署MIDAS的时候,需要注册midas.dll一样。
于是乎,狂搜。
在CSDN上发现了一个哥们说--
>使用Delphi在客户端调用WebService
>确保你的电脑上装了SoapToolkit
>新建项目,要Uses ComObj
很好奇:SoapToolkit。
于是乎,搜。下载。
把“SoapToolkit30.EXE”,装到服务器上。
然,问题依然。
可选择的:急死,或气死。
<四>
时值深夜,大雨如注。
抓耳挠腮,百思不解。
蚊虫袭来,浑然不觉。
青灯古佛,颇有禅意。
凄凄惨惨戚戚中,我只能独自一遍一遍大喊:买嘎的!买嘎的!
再想办法~~
待从头,收拾旧山河。
<五>
想来想去,没办法了。换台机子试试。
于是找了一台PC,同样是Win2003 Server。
试了。没有问题。
信心大增。
突然,慢着--莫非是Delphi的问题?--这台PC上装有D7的IDE,而服务器上没有安装Delphi。
莫非在Delphi在安装的时候,注册了什么东东,这样WebService客户端就可以运行了。
而没有安装IED的机器就不能运行?--按说不会,调用WebService不会太依赖客户端的环境。
但,总结以往血淋淋的教训,从业的经验告诉过我们--这是值得试试的。
高人曾说过:绝望的时候,稻草是可以救命的。
<六>
我的稻草是一张D7的安装光盘,哪怕是盗版的。 *_*
But,就在这个深夜--华南的多雨的闷热的深夜里--我的稻草没有在身边。 :(
(转折句,的确能够加强语感,我喜欢!)
它在光盘包里。光盘包在行李箱里。而行李箱在住所。
住所在X公里外(X>=5)。
<七>
坐上车的时候,雨已经停了。
回到住所,巴西正对克罗地亚。
那群跳桑巴舞的家伙在拼命的时候,WK,我也在北京时间里奋斗。
不过,对不起了,兄弟们!你们继续,俺洗洗睡了。
天生对某些运动不敢兴趣。
辗转反侧。
绕树三匝。
终于睡去。
<八>
7点01分,短信。是昨夜比赛结果。免费赠的。
起床。
D7光盘。
吃点喝点。
上班。
<九>
D7在哪里?D7在光盘上。光盘在光驱中。
光盘是好光盘。光驱是好光驱。不错。
茶叶还没有泡展,已安装完毕。
对一些人来说,我们深爱着D7--我们吃饭的家伙。
欣欣然。
D7的启动画面已经在Win2003 Server的服务器上出现了。
但是,报错了--
是“Can't load package:dclite70.bpl”的异常。
同样显示的,还有“Access Violation”的错误。
我,脸绿了。
不止是简单的faint!
难道安装出有问题了?在安装时没有报错。
第一次遇到这种问题--我信赖的D7啊!
要有怀疑精神。怀疑自己安装错了。
卸载。
OS重启。
再次安装。
再次安装完毕。
再次启动D7。
再次是“Can't load package:dclite70.bpl”的异常。
再次显示的,还有“Access Violation”的错误。
于是,开始缺氧+眩晕。
<十>
从昏厥中醒来,深深太平洋的深深质疑 Win2003 Server + D7 的组合。
而且,这个还是个“刀片”服务器。
当时,有了一个决定。
凡遇到用Win2003者,先爆打一顿,弄成半死不活,半身不遂,半条命,爆头。
然后再用“刀片”想法弄成酱。
酱油也行。
:"(
<十一>
行走江湖。安全第一。
风平浪静。海阔天空。
平时对Win2003使用不多,了解不深。
看了看系统,是Standard Edition + Service Pack 1的。
上网了解了一下,N个人曾在Win2003 Server下遇到过各种各样的“Access Violation”。
打过各种各样的补丁。
又特意去看了看那台PC,装的是Enterprise Edition + Service Pack 1的。
版本果然不一样。
于是,找补丁。
期待--蓦然回首。那X却X。
<十二>
百二秦关终属楚。
三千越甲可吞吴。
微软的补丁可真及时,勘比宋押司。
补丁号码是:KB904639
名称是:Windows Server 2003(32 位 x86)更新程序 (KB904639)
快速描述:安装本更新程序可以解决一个使某些应用程序无法在 64 位环境中运行的问题。
文件名: WindowsServer2003-KB904639-x86-CHS.exe
版本: 904639
知识库 (KB) 文章: KB904639
发布日期: 2005/10/24
语言: 简体中文
下载大小: 560 KB
概述:
安装本更新程序可以解决一个使某些应用程序无法在 64 位环境中运行的问题。
尝试运行使用 Microsoft 数据访问组件 (MDAC) 2.8 的接口远程处理组件的 64 位应用程序时,
您可能会收到“access violation”(访问冲突)错误消息,
或者在使用任务管理器查看时 dllhost.exe 进程可能会显示 100% CPU 占用率。
安装本更新程序之后,可能需要重新启动计算机。
莫非这就是传说中的Cut the Gordian Knot的亚历山大之剑?抑或是达摩克利斯之剑?
试。
果然--不爽。
念去去。
千里烟波。
凝噎。无语。崩溃。
<十三>
又找其他的补丁。
没有合格的。
D7仍启动仍报错:Can't load package:dclite70.bpl。
但在PC机上(Enterprise Edition + Service Pack 1)是可以的。
诅咒Microsoft。
废池乔木。
犹厌言兵。
崩溃中。
<十四>
怎么办?
接着搜。
随便。摧残。
飞沙走石。天昏地暗。
风雨如晦。鸡鸣不已。
黄河之水天上来。
一片孤城万仞山。
两岸猿声啼不住。
日照香炉升紫烟。
如履薄冰。如临深渊。
如芒在背。如坐针毡。
如切如磋。如琢如磨。
<十五>
最是那一低头的温柔,恰似水莲花不胜凉风的娇羞。
以dclite70.bpl为关键字,搜索。
感谢互联网吧!
感谢搜索引擎吧!
感谢发贴回贴的兄弟吧!
俺的神啊上帝以及老天爷啊!
亚历山大来了!
在52SDN找到一个标题为“delphi 7 能不能在windows 2003 server上安装?”的帖子。
内容如下:
安装在2003上想试试,没想到打开提示dclite70.bpl访问非法地址。
后果就是项目的选项窗口打不开(访问非法地址)。
那位兄弟有解决办法?
------------
安装过的兄弟提示一下,谢谢!
------------
可以...我装过了...
------------
对delphi 关闭数据执行保护就好了 :)
------------
看到最后一行!
疯了!
<十六>
右击“我的电脑”。单击“属性”。
在“系统属性”中单击“高级”。
在“性能”中单击“设置”。
在“性能选项”中单击“数据执行保护”。
单击“添加”。选择要运行的程序。
OK。就这么简单。
<十七>
借用温大侠的话。
如鹤临风。
如鸢凌空。
如鸾舞松。
如鹏回峰。
疯了!
<十八>
小项,before Game Over,say:天亡我,非用兵之罪也。
Windows 2003 Standard Edition。
今天,你疯了没有!?
By JRQ
2006/06/14 夜 小记于穗
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=797566