迁移问题:800a0ea9|未指定提供程序,也没有指派的默认提供程序。

这个月投入运营的共享设备比较多,从6月16号开始扫码支付模块就不是很稳定,在微信群提出的问题比较多,出现问题的第一天以为是服务器的问题,昨晚到8点以后又出现了扫码无法支付的问题,加载数据返回数据出错,那天的应急方案是把iis服务重启了,如果是高峰期,这真可怕的方案,共享设备有很多是投放在娱乐场所,晚上正是高峰期,钱の……

我是从今天才开始介入,刚好是618展会的第一天,公司的不少同事都派去展会现场了,下午14:30之后外地的同时反馈支付异常,在展会现场的同事也反馈问题,设备切换到投币模式,在后端也关停了支付功能,后面我也接到电话,介入解决问题,日志能参考的有限,连接数也没有态度,已经改过了MySQL的最大连接数,问题还是在程序,但是没有时间马上个改,服务能先用上,然后再考虑其他的方案,两位同事考虑升级服务器,先是升级成Windows Server 2016 , 然后是支付模块没法启动,然后切换到64位2003   一番折腾后,项目启动后登录页面可以打开,点登录后提示500错误,他们在说要不要重装成32位。。。我说我连上去试试

1.22:50连上服务器,项目是有起来的,先是检查报错的日志信息,方便定位问题,找IIS的日志,在C盘。。。LogFiles目录下,报错信息:800a0ea9|未指定提供程序,也没有指派的默认提供程序
2.之前的版本是32位,切换到64位可能遇到兼容性的问题,搜索了下类似的解决方法,这个网友的是一样的 ,进入:C:\Inetpub\AdminScripts,
执行:cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 “true”
3.开启Enable32BitAppOnWin64 这个开关,运行.net环境,重新注册,后面也重启了IIS,登录系统后提示的确实是                          Service Unavailable ,        
        

4.操作了两次,还是一样的结果,我选择的是64位的,操作完成,访问还是同样的问题,用C:\WINDOWS\Microsoft.NET\Framework路径下重新注册了

5.iisreset,重新打开终端平台,登录,正常了22:59,赶紧在微信群里和他们说下测试支付,原来说升级在半个小时内搞定的,拖了这么长时间,同事的手机都快打爆了。
6.经测试,扫码支付正常,后台也可以看到支付订单。

明天再商量是否先改版,投入运营的设备越来越多,这个问题需要优先处理。

越是紧急情况,越需要冷静处理,即使有一线希望,也不要放弃,这只是一个开始

记录下这次介入处理的问题,晚安。

 




    分享到:









点赞

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注


*

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>