Kevin Ragsdale: Visual FoxPro 9.0

DLL Hell Rears Its Ugly Head

If there’s a moral to this story, it’s this: Watch Your Runtimes.

Oh, yeah, and this: Trust No One.

A little background:

Last year, I had an opportunity to develop a shrink-wrap application using Visual FoxPro 9.

The product was originally released in March of 2007, built with Visual FoxPro 9 Service Pack 1.

A couple of months ago, we released a major version update.

The new version was built with Service Pack 2.

Now, before the “I-Won’t-Install-Service Pack 2-Because-I-Heard-It-Has-Some-Bugs-And-Besides-I’m-Mad-At-Microsoft-For-Killing-FoxPro” crowd starts drooling at the prospect of this being a ‘Service Pack 2 Killed My App’ post, let me say this:

“Install VFP 9 Service Pack 2. Today. Stop reading this, and go try it out. Try it on a test machine. Try it on Virtual PC. Just try it! Quit whining about what it might do to your apps, and go see for yourself. You’ll never know until you try.”

Whew! That felt good to get that off my chest. Now, back to the story:

Everything was going great, until I received the following support email:

I’m getting a Visual Fox Pro error in shared file.
The error log is not telling me anything else.
Microsoft Visual FoxPro
Fatal error: Exception code=C0000005 @ 03/27/08 05:16:37 PM.
Error log file: C:Program FilesCommon FilesMicrosoft SharedVFPvfp9rerr.log
Does this mean anything to you?

A C0000005 error? Rut-roh…

I exchanged several emails with the user, trying to determine when, where, why, and how this was happening.

During the course of the email exchanges, the user sent me some screenshots.

She stated that the “first” error occurs immediately after clicking the application icon on the Windows desktop:

If she clicked the “What data does this error report contain?” link, she got the following:

Well, that tells me alot. 😉

She clicked close on the window above, then clicked Don’t Send on the previous window, then boom:

While researching the issue, another user sent me almost the exact same email. He was very upset about the error, because it seemed to him that this thing called Microsoft Visual FoxPro was obviously some kind of spyware/malware/virus or something. After all, why else would the error report contain all these weird-looking code-thingies like ModName, ModVer, ModStamp, fDebug and Offset? After Googling “Visual FoxPro”, he went onto an MSDN Forum to ask why this was happening.

In-house, we tried and tried and tried to recreate the issue. No go. We couldn’t recreate the error no matter how hard we tried.

The next day, the first user sent me another email:

I’ve figured it out!!!!

Your updated program is fighting with another Visual Fox Pro program on my machine:

I discovered this when I opened the program and received the same error.

Both programs are very important to me and I’ve also been in touch with them, too. I’m hoping we can get all the programmers heads together to figure out how to resolve the problem.

Can you tell me which VFP version you are using for your program so I can report back?

I asked her for the name of the “other” program, and I went to their website and downloaded a 30-day trial version of their software. I fired up Virtual PC and installed the program. Imagine my surprise when I saw the Wise Installer putting VFP9R.DLL in the C:WINDOWSSYSTEM32 folder.

While you’re at it, also imagine my expletive-filled shouts while watching the install.

These runtime files, from that “other” program, were Visual FoxPro 9 Service Pack 1 runtimes.

I then installed my app, which put the runtimes in the following folder:

Started up my app, and BOOM!!! The issue has now been “officially” recreated.

I contacted the makers of the other software, and pointed them to the FoxWiki pages about VFP Runtimes.

But, not wanting my app to be at the mercy of another development shop, I changed my installer to just dump the VFP 9 SP2 runtimes into the folder where the app is installed.

No registration, no nothing. Just a file copy.

I restarted my app, and it worked! Woo Hoo!!!

I sent the new installer out to the affected users, and they reported back that the “new version” worked. I loved the “new version” part, because the only thing that changed was the install itself.

Of course, the “other” app was still broken, because when my app was originally installed the new VFP runtimes were registered on the system.

A quick reinstall of the “other” app caused the VFP 9 SP1 runtimes to be re-registered in C:WINDOWSSYSTEM32, and now both programs “work” and my users are happy once again.

From now on, all of my apps will have the VFP Runtimes placed in the same folder as the app itself.

Watch Your Runtimes.

Trust No One.