Friday, March 14, 2008, 7:38:00 PM
I've been hearing from several people through Web Connection support over the last few weeks with problems running their Web Connection COM servers. The problem apparently occurred around the time of updating to Visual FoxPro SP2 which continues to produce problems in unexpected ways.
After a long debugging session with a customer I ended up duplicating the problem they were seeing locally on my own machine.This applies to any COM servers running under an impersonated account (ie. Configured in DCOMCNFG running with security other than the Interactive User) not just to Web Connection servers.
The issue is related to the _VFP and Application objects in VFP which are internally accessed as COM objects by VFP. Apparently SP2 fails to properly register its internal COM interfaces with a default installation, or if you simply install the the SP2 DLLs ontop of the SP1 or RTM DLLs without explicitly registering the VFP COM Servers.
The short story is: Make sure you register VFP9R.dll and VFP9T.dll on the server when updating to SP2 if you have any sort of COM hanging problems. If that still doesn't fix it - uninstall SP2 and SP1 then reinstall SP2. Do not simply copy the DLLs and leave them or even rely on the SP2 installer because on my machine it clearly DID NOT register the dlls correctly. Explicitly go in and register the DLLs! Also make sure that all the runtime files including the resource files are updated - again something that didn't quite happen correctly on my machine.
Finding the Problem
I ended up finding this problem as I was helping a customer debug their application. One of the problems was that COM servers stopped working all of a sudden after a reboot failing with CoCreateInstance errors which indicate that the server either didn't instantiate at all or aborted in the process. Looking in task manager we found hung instances of the VFP COM server so launching was happening but something in the startup process apparently kept hanging the server.
My usual tests for Web Connection include getting customers to test server operation outside of IIS to see if the server runs properly. What I would try to do is instantiate a FoxPro EXE com server in Visual FoxPro as follows:
o=CREATEBJECT("Wcdemo.WcDemoServer") && Hangs!
Which is a standard test to see if a Web Connection server is working properly for COM operation. It basically tests a Web Connection server hit. When the EXE server is configured for Interactive User mode in DCOMCNFG this works perfectly. The server loads - no problem.
However when switching to another user (ie. This User and specifying my own Admin User account) in DCOMCnfg and re-running the COM server would not load properly. Looking in task manager I'd see the EXE load but the call to CreateObject() would never return back to the command prompt in FoxPro – the VFP server was hung. Since it's not configured under the Interactive user the server is invisible so there's no error message.
After a bit of instrumenting and debugging I figured out that the code is getting hung up on the following line of code:
LogString("Init " + SYS(0),"c:\temp\log.txt")
lnStartMode = Application.StartMode
LogString("INit " + TRANSFORM(lnStartMode),"c:\temp\log.txt")
The code will log the first line, hit the second line of code and never go any further. Apparently Application.Startmode or _VFP.StartMode is causing the problem.
To understand the problem you have to understand the the VFP Application object (ie. Application or _VFP) is actually a COM object not a native VFP object. This COM object needs to be properly registered and it exists in the runtime libraries (VFP9r.dll and vfp9t.dll). On my development machine apparently VFP9r.dll was not properly registered and so it caused the hang on anything but the interactive user.
To be honest this doesn't explain the whole story though: It's not as simple as the servers not being registered because it works in interactive mode, but in any case the explicit re-registration made the servers work. Somehow the registration for the local machine reference isn't working.
It appears the problem on my machine at least was caused by the install of SP2 which didn't properly register the new VFP9R.DLL! Apparently whatever ClassID is used for the Application and _VFP objects are changed by the VFP9 SP2 install which causes the hanging.
I re-registered VFP9R.DLL and VFP9T.DLL but I still did not see it work, although I think that might have been a caching issue. I did not get this to work until I also manually re-registered VFP9.EXE with VFP9.EXE /RegServer. I sure hope that the latter isn't the issue because obviously VFP9.EXE won't be on a development machine.
Just for testing I un-registered VFP9T.dll and VFP9R.DLL and sure enough the hanging problem returned. Re-registered both DLLs and the problem disappeared. So registration of the two DLLs definitely has an effect on availability of the _VFP and Application objects.
Moral of the story – if you're using EXE COM servers on your servers and you've installed VFP 9 SP2 make sure you re-register the VFP9R.DLL and VFP9T.DLLs on the server to make sure the classids properly match up and calls to the _VFP and Application objects work correctly.