Web Connection
CoMarshalInterThreadInterfaceInStream). Err code = 800706be
Gravatar is a globally recognized avatar based on your email address. CoMarshalInterThreadInterfaceInStream). Err code = 800706be
  Michael B
  All
  Mar 31, 2019 @ 11:55am

Rick,

In the past month my vultr WWWC server starting throwing com errors

The following ole error occurred: WC Server instance not found (CoMarshalInterThreadInterfaceInStream). Err code = 800706be: The remote procedure call failed.

I refresh a few times and all is fine.

Any suggestions?

Gravatar is a globally recognized avatar based on your email address. re: CoMarshalInterThreadInterfaceInStream). Err code = 800706be
  Rick Strahl
  Michael B
  Mar 31, 2019 @ 01:55pm

That's a COM corruption error most likely happening when running with the ISAPI handler, right? Usually when I've seen this, this happens if there are problems with the application and servers have been stopped and restarted (or crashed and restarted) very frequently during the life time of the application pool.

Basically this is a fatal failure that likely will result in the application pool getting restarted (that's why it works after a couple refreshes I'm betting).

This problem is also worse with ISAPI (which does 'manual' COM marshalling in C++ code,) vs the .NET Module (which uses the Microsoft hardened .NET COM APIs and doesn't marshal COM objects over threads as they are pinned on a stationary thread).

I don't have a solution for this, other than making sure that your servers don't crash, or setting an occasional recycle time on your application pool to force it to refresh.

Also more recent versions of Windows Server 2016 and 2019 do a better job of this than older versions, especially 2008 which had lots of COM memory and marshalling problems.

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: CoMarshalInterThreadInterfaceInStream). Err code = 800706be
  Michael B
  Rick Strahl
  Mar 31, 2019 @ 03:45pm

Do you think this has anything to do with the fact that the VULTR servers are virtualized (it is 2012 running incidentally)? I have had a 2008 R2 running for 8+ years and I never see this issue (same software, same config, etc).

Gravatar is a globally recognized avatar based on your email address. re: CoMarshalInterThreadInterfaceInStream). Err code = 800706be
  Rick Strahl
  Michael B
  Mar 31, 2019 @ 03:46pm

Do you think this has anything to do with the fact that the VULTR servers are virtualized (it is 2012 running incidentally)? I have had a 2008 R2 running for 8+ years and I never see this issue (same software, same config, etc).

No. But if you are running with ISAPI you might want to think about switching to the .NET Module.

Look in your error logs - I wouldn't be surprised if you have a number of failures for server unloads.

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: CoMarshalInterThreadInterfaceInStream). Err code = 800706be
  Michael B
  Rick Strahl
  Apr 1, 2019 @ 05:13am

Rick as you suspected, lots of different errors in wcerrors.

RPC Server Unavailable due to thread timeout WC Server Unavailable. Attempting to reload Web Connection Request timed out RPC Server Unavailable (Invoke): Attempting to Reload Server COM Server Timed out - Next line releases

The pages that are failing are typically pages that use httpget() to call a third party service.

Is there some graceful way to set a timeout in the framework or do you have a different suggestion?

Gravatar is a globally recognized avatar based on your email address. re: CoMarshalInterThreadInterfaceInStream). Err code = 800706be
  Rick Strahl
  Michael B
  Apr 1, 2019 @ 02:02pm

Yeah - so you're likely timing out Web Connection requests which causes the COM servers to be killed explicitly (without shutting down through proper COM release) which eventually ends up corrupting the COM system which allocates a limited amounts of slots for STA components. When it runs out of slots - that's when the errors start due to stream not available etc. It takes quite a few failures before this becomes a problem, but it does eventually become a problem if the Application Pool is not recycled before it does.

So - you'll want to make sure that you have requests that take longer than your configured Web Connection request timeout. If you're making wwHttp service calls there's a timeout property on wwHttp that you can set. If you're calling remote APIs you shouldn't have anything that takes more than a few seconds, so if you're waiting more than 10 seconds you should just consider it failed.

+++ Rick ---

© 1996-2019