Another issue - this with the working release of our app built under WC 6.22.

We did a fresh install on a customer server using the .NET handler. The app runs fine in File mode, but when we switch to Com and try to load servers, we get:

unknown application error
Retrieving the COM class factory for component with CLSID {A9F7EA54-1EFF-4AC0-A08B-7728BD4A58BF} failed due to the following error: 8000401a The server process could not be started because the configured identity is incorrect. Check the username and password. (Exception from HRESULT: 0x8000401A).

We've run into this before on a different customer site - your advice at that time was to make the App Pool identity an admin on the server, and that seemed to solve the problem. However, we tried the same thing in this instance and it did not help.

We have verified that the AP identity has permissions to the relevant folder, and in fact when running in File mode we are logged in with that account. Since things work under File, that would seem to indicate it has the access it needs. We also went into the Security tab under DCOM properties and explicitly added that account.

FWIW, the account in question is a domain account, not a local, but it is an admin on the local machine.

--stein

If would help to look at their interface, I can send credentials to their admin.aspx page by a backchannel post.

-sg

That sounds like a bad DCOM configuration. Make sure whatever account you are using has permissions. You may also want to re-register the COM server explicitly ( yourapp.exe /regserver) to make sure the type libraries are up to date with the server interface since they have changed since 6.22.

I can take a look at the remote machine if you like.

https://west-wind.com/contact/

+++ Rick ---

Note that this is using our production release which is still running under 6.21 so the type libraries should not be an issue. I will get with the customer and have them re-register the server and double-check permissions, but I am fairly sure that they have DCOM set to use the Launching User. As noted the App Pool Identity is a domain account (named ENGISQL) with admin privileges on the local server.

Decided I'd better check with the customer before giving out credentials - they would prefer not to do that but would not object to having you join a GoToMeeting session if we can't fix this ourselves. I did grab a screen shot of the Handler Status Page (after switching to Com) which I will paste below. As soon as we try to load Servers we get the "unknown application error" reported earlier, so we are leaving File mode active.

Make sure the egnisql account has full access in the temp folder...

But I think the problem is that something is going with the FoxPro app not writing the output file - it's creating the return file but not the actual output file.

+++ Rick ---

Will check the permissions when I get back on the customer's server.

But I think the problem is that something is going with the FoxPro app not writing the output file 
- it's creating the return file but not the actual output file.

I assume this refers to my other issue with the WC7 upgrade. (I know it's confusing to have 2 threads going at once.) The problem in this case was the inability to load Com servers on a customer site.