Hi.

I have upgraded to Windows Server 2022 and Web Connection 8.2.

On the server, the messaging mechanism is in com mode, and the server count is 4.

After killing all the com servers in the server's task manager, it fails when I open the Hello World test page.

When I reopen it right away, it works.

And even though the server count is 4, only one of the com servers runs.

There was no problem under Windows Server 2008 R2 with WC 7.4.

What could be the problem?

For your information, everything is good when unloading the com servers on the Web Connection Administration page.

That looks like your COM server is locking up. Make sure your server is running with UnattendedComMode=On so that errors are failing immediately instead of hanging the server.

Actually I would add this to your server startup code (I think there's a bug that may have caused that flag to not work):

*** Put this in your yourServer::OnInit()
IF THIS.lComObject
	SYS(2335,0)  && on
ELSE
	SYS(2335,1)  && off 
ENDIF

This will report errors (except error as part of OnInit()) immediately instead of potentially firing a dialog that hangs the server.

This is supposed to be automatic but I think in one of the more recent updates this code was not triggering correctly. It's fixed for the next release...

+++ Rick ---

Hi.

After I added the code that you told me to myServer::OnInit(), I encountered another problem.

The problem is that I can't load the server on the Web Connection Administration page.

See below for the error message. The error message is in Korean, which might be inconvenient for you.

I translated only part of it into English for you.

2025-05-02 01:22:30.847 - COM Instance thread initialization failed (Instance.Run()): wwC4CR.wwC4CRServer #1: 80004005 Unspecified error. (Exception from HRESULT: 0x80004005 (E_FAIL)) Creating an instance of COM component with CLSID {0C6EA870-A6E7-4DCA-B8DF-34D4782F2F52} from IClassFactory failed due to error.

That looks like there's something wrong with the COM server.

Can you verify that you can launch the COM server via COM from FoxPro or Powershell (see here). Also make sure the server is set to Single Use when you compile the application and you compile to an EXE.

+++ Rick ---

If I add that code, the server won't load.

COM Error 0x80004005 is Access is denied, which points at invalid permissions.

Make sure you set up your Application Pool in IIS with the appropriate permissions.

• COM Server Security and Identity

Specifically look into the launch and activation permissions for the Application Pool. Start with SYSTEM and then dial back your security (if you need to), once you have it working with SYSTEM.

+++ Rick ---

The same happens when I create a new project using the New Project Wizard with no code changes and then test it.

Interestingly, when I unload using ReleaseComServers.wc on the Administration page, there is always no problem.

But when using ShutDownInstance.wc on the page, there is a problem.

As I said before, the same thing happens when killing all the com processes in the server's task manager

There is a background maintenance task in the server's task scheduler.

It does re-index and back up at 4 am every day.

That's why I have to kill all the processes.

Application Pool in IIS starts with the SYSTEM account.

I don't know why.

I don't quite get what you're saying. Your server display shows 1 instance running - presumably because the others were killed externally? If those were killed - the first request against that server that was externally killed is likely to fail because the server that's supposed to be there is not there. So the behavior you see with a bad request followed by a good request is actually correct - first request fails due to missing server, second request works because once it fails Web connection reloads that server. You only see one server firing back up because each server reloads only as needed - it won't load more servers until they are hit (and fail most likely).

The bigger issue is to figure out why the servers are hanging and failing. Are they crashing in which case they are going away immediately. Are they hanging? In which case they stick around and appear to be busy in the Web Connection server monitor on the admin page.

Watch your servers in task manager and make sure they are running under the right Windows accounts. Check the EXEs and also w3wp.exe (there may be more than one - those are the application pool processes). You'll want to watch the one that is loaded.

+++ Rick ---

One more thing - I've just release v8.3. I know there was one original release of a recent version that had a bug in the COM manager that was fixed. I can't recall off hand what version that affected (8.1 or 8.2) and it was very brief as it got updated and fixed right away.

What you're seeing sounds vaguely familiar to behavior I saw with discussions with Richard Kaye around the time of the bug.

Look for the confirmation email today... and try the new 8.3 DLL.

+++ Rick ---

Hi.

Since English is not my native language, it is difficult for me to give an accurate explanation.

This time, I will explain using situational images.

1. No Com Server is running.

2. When I hit the Hello World Test Page, two Com Servers are loaded immediately, as expected.

3. If I unload Com Servers on the Administration page, all Com Servers are unloaded.

4. When I hit the Hello World Test Page again, two Com Servers are loaded immediately, as expected.

5. I kill all the Server Instances on the Administration page.

6. An error occurs when I hit the Hello World Test Page again.

All Com Servers are unloaded, so two Com Servers should be loaded when a request comes in, but it doesn't.

That is what I would like to ask you.

Yes, that's expected behavior because you are hard killing a server by killing the process. That server button is there primarily as a debugging feature that lets you simulate what happens when a server is externally killed outside of a Web Connection server hit. For that reason it doesn't clear the COM reference that Web Connection tracks normally. That's why the next request that comes in fails - WC still has a (now dead) reference to the COM server but the server is not actually there anymore so the request fails.

That request fails, but when Web Connection hits it and it fails as part of a request, Web Connection now detects that failure and fires up a new instance of the server while reporting the request as failed (the error you see). While the initial request failed, subsequent requests work (assuming there isn't some other problem that causes the same issue) running on the newly loaded instance.

IOW, If you hit that page one more time (ie. a second time) the request works with the newly created COM instance.

The Kill button is just that: A button that literally kills the process without doing anything else. . It's meant as a debugging tool to allow you to simulate a hard server failure where the server crashes and disappears outside of pooled requests. it's useful when you're doing load testing and you want to simulate explicit server failures and see server recovery behavior.

All that said - if servers get 'killed' and not properly shut down, they affect the COM subsystem. There's limited amount of COM specific storage available and if this sort of 'unscheduled' failure happens too often eventually COM servers become unstable or won't reload. It takes a lot of failures before that happens, but it's a known issue with COM servers as Windows handles leak in that process. Under normal server operation this isn't a problem but if there is a problem with servers that crash frequently that is something to watch out for. Always monitor the logs for unscheduled shutdowns and if they regularly repeat you need to find the culprit. Also of note is that FoxPro has many scenarios where it will seemingly randomly crash, but it's fairly rare. So an occasional crash that shows up in the logs is usually nothing to worry about - what you want to look out for is repeated crashes of the same request or same type of requests.

+++ Rick ---

Thank you for the kind and detailed answer.

Now I understand what you are saying.

I'm asking, just in case, is WWWC 8.3 released?

I haven't received the email about the new release yet.

Yes 8.3 is released - I sent you an explicit email a couple of days ago.

You're running it in your screen shot?

+++ Rick ---