Rant: Wells Fargo

August 2nd, 2011

A few months ago, I bought a couple of items using a 0% interest credit plan the store was offering. The credit was provided by Wells Fargo. Everything went through ok.

Shortly afterwards, I started receiving emails with someone else’s name but to my email address, encouraging me to sign into my account on the Wells Fargo online banking site. I don’t have online banking, just a store credit card, and that’s handled through a different site. I figured I should let them know. It’s probably just a simple data entry error, but might be a symptom of something more serious. In the small print at the bottom of the email, I found the line

Wells Fargo Online® customers, Sign On to your secure banking session and click ‘Contact Us’.
If you are not a Wells Fargo Online customer, contact us here.

As I’m not a Wells Fargo Online customer, I clicked “contact us here”. It redirected me to a customer service page, where it listed the email contacts as

  • Online Banking Customer?
    Sign On to send a secure email.
  • Not an Online Banking customer?
    Enroll Now to send a secure email.
Basically, there’s no way to contact them by email if you’re not a customer. Feel free to attempt calling the phone line or mail a letter.

Rant: Verizon

May 13th, 2011

If I buy a new phone before 10am, and pay extra for overnight delivery, don’t email me the next day to tell me order has been received and will be dispatched soon, estimating delivery as next week.

I’d be a little annoyed if you tried that.

Rant: Adobe

May 13th, 2011

We had a copy of Photoshop CS2 for Windows, and wanted to upgrade to Photoshop CS5 for Mac. Not an incredibly unusual event, I would imagine.

Adobe calls this a “cross-platform upgrade”. There’s a variation on this theme called a platform-switch  – switching platform on the same version with no upgrade; a process that seems to involve faxing promises that you won’t use the previous platform anymore. But no, it’s the cross-platform upgrade I’m after. Read the rest of this entry »

Missing MSVCR80.DLL, MSVCM80.DLL, MSVCP80.DLL

May 27th, 2010

I ran into a problem yesterday that took a few hours to decipher. I thought I’d share it here, in case Google manages to lead someone with a similar problem this way.

I made a minor change to a DLL in a program I’ve been working on and distributed it to the end users. The user that had requested the fix was happy with the result, and everything was fine for a couple of hours. Then I received an email from another user complaining the program was failing to load, reporting the error

System.IO.FileLoadException: Could not load file or assembly 'MyLIB, Version=1.0.3798.19982, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)

I’d seen this type of error before; typically it means MyLIB.dll requires another DLL that isn’t present. I checked his program folder, but everything was present – no missing DLLs. Tried re-patching and tried re-installing, and still no luck. I ran the dependency walker to see exactly what it was that it was missing. Turns out to be MSVCR80.DLL, MSVCM80.DLL and MSVCP80.DLL – the MS Visual C++ runtime.

Wait, what?

That didn’t make any sense, as he’d had the program running happily a few hours before. I tried re-installing the runtime, but that didn’t seem to help. Much scratching of heads and gnashing of teeth followed.

It turns out that the new build of MyLIB.DLL that I’d built had tied itself to the specific runtime version I had on my PC – 8.0.50727.4053. These runtime DLLs were installing into C:\Windows\WinSxS, where different versions of the same DLLs live side by side in an uneasy truce. I don’t pretend to fully understand what’s going on in there, but anyway. The different versions of runtimes were in different subfolders, the names of which contained the version number. When we checked the machine that the program was failing to run on, the .4053 version wasn’t there. We had to find that specific C++ redistributable version on microsoft.com as install it, which fixed the problem. The version of the runtime I had tried reinstalling earlier was an older version. It was then I realized that I have a new PC, and this is the first time I’ve rebuilt that particular DLL on this machine. Those with older machines were less likely to have the newer runtime installed.

Many sources on the interwebbings were simply saying “get the dll from here, and stick it in your Windows\System32 directory”. This is exactly wrong in this instance.

It would be nice if I could find an option in the project build configuration that says “Use runtime version X or later”, rather than it requiring the specific version it finds on my machine.