Wells Fargo Bank Issue?

I recently clean-installed (trial) BIS 2013 on my machine (MS Windows XP Home Edition 32-bit SP3). Safepay runs flawlessly on all financial sites so far except one. I notice that (USA based) Wells Fargo Bank's browser requirements might be causing the frequent crashes I am experiencing when I use the Safepay module?! It seems to work intermittently and transactions can be made sucessfully only about 30-40% of the time.

Is there anything I can do on my end to stabilize this? Do you foresee any chance of a possible "fix" in Safepay to allow smoother access to wellsfargo.com? Is this a Java issue that cannot be rectified?

Many Thanks and Best Wishes!

Happy Holidays.

Let me reverify this with a test engineer. The frequent crashes may have nothing to do with Wells Fargo website by itself; we do have a reported issue on Windows XP, but unfortunately is inside an XP module not used directly by us.

By any chance, did you submitted one (or more) crash reports using our submit tool?

Regards,

Cristian

Hi, Cristian. Thanks for responding!

Actually yes, lately the crashes have been intermittently occuring with ANY site...

Crashes usually happen at the instant when I click off the virtual keyboard -or- click a link within a page -or- click the upper-right x-off button.

And yes, most of the time I sent along the crash reports afterwards.

Thanks for the help.

I have asked a test engineer to try to reproduce. He managed to repro clicking continuously on the same link for nearly 20 minutes - which is quite insane to suppose in real life - but, anyways, the most likely culprit is happening inside a Windows system file (winhttp.dll). The issue is reported only on Windows XP.

Will try to escalate even more also to another team - while we are looking for a KB article from Microsoft that might help. Both Mozilla and Chrome have similar bugs reported with a similar behavior - as it sounds right now, it won't be easy.

I have assigned last week a colleague to handle this issue only. We are still gathering crash reports that may help us tracking down the issue and I hope to be able to come with a resolution in the near future.

About the crash when you click the virtual keyboard - this is new. Do you click on something special, click a key from virtual keyboard, or.. ? Any detail will help us understand what happens.

Regards,

Cristian

Wow! Thanks so much for the help!

Just tried a session again. Sent in three crash reports - all Wells Fargo this time (no crashes on two other sites)...

1. X-off virtual keyboard - no problem. First page to come up after successful login was their credit offer page - instantly crashed (with absolutely no delay at all) when I clicked the "no thanks" button to decline the offer.

2. Instantly crashed when I hit the enter key on virtual keyboard when logging in.

3. Instantly crashed while clicking a regular banking navigation link within their site.

On two other occasions from that session just now there were no crash occurrences at all?! I did experience a crash several days ago when clicking the X-off button of the virtual keyboard to remove it after successfully logging in to Wells...

Regards, Cristian.

I just send an email to QA team. A colleague of mine will investigate this and is possible that he (Andrei Burdun is his name) will also come back with a reply and perhaps ask for some more details.

Regards,

Cristian

I recently clean-installed (trial) BIS 2013 on my machine (MS Windows XP Home Edition 32-bit SP3). Safepay runs flawlessly on all financial sites so far except one. I notice that (USA based) Wells Fargo Bank's browser requirements might be causing the frequent crashes I am experiencing when I use the Safepay module?! It seems to work intermittently and transactions can be made sucessfully only about 30-40% of the time.

Is there anything I can do on my end to stabilize this? Do you foresee any chance of a possible "fix" in Safepay to allow smoother access to wellsfargo.com? Is this a Java issue that cannot be rectified?

Many Thanks and Best Wishes!

Happy Holidays.

I am glad to tell you that the issue was fixed and we'll push it to the next update.

It was as I suspected a race condition in winhttp.dll (it called back code in one of our dlls *after* that was unloaded, hence the access violation crash), which our core HTTP team solved it by keeping our client dll in memory.

Andrei tested extensively the fix (using an automated ****** clicking on a link every 0.5 seconds for more than an hour) and the crash seems fixed.

Most likely the update will be done after the new year (sadly) since almost everyone is going in vacation now - until then we'll have to wait

Regards,

Cristian