We have been using WebConnect for years with our product iChannel. One of our customers using the product has started receiving “Invalid Request ID” messages back from the DLL. This happens randomly, about 10% of the time, and is not reproducible on demand. What can cause this and how can we troubleshoot it?

We have 4 web connect server processes running that talk to WC.dll.
The environment is on Windows Server 2012 and IIS 8 and we are running in FILE mode not COM mode.

We have tried WC.dll version 5.43 and 5.66.

Here is output from wcErrors.txt log file

2014.09.17 15:45:53:915 - 8624_47650360B6D7 - 8624_47650360B6D7 - Request Completed (1328) - /wc.dll?CADoc~CADocLogIn~UMPQ03C~JENNIFERHOLLENBECK@UMPQUABANK.COM - 3 - 8624 - Com: -1:0:0
2014.09.17 15:45:54:426 - 8720_21CEFF2089E5 - 8720_21CEFF2089E5 - Request Started - /wc.dll?CADoc~CADocLogIn~UMPQ03C~JENNIFERHOLLENBECK@UMPQUABANK.COM - 0 - 8720 - Com: -1:0:0
2014.09.17 15:45:55:132 - 8624_C4F9C3CFE6DD - 8624_C4F9C3CFE6DD - Request Started - /wc.dll?CADoc~CADOCMANAGE~DMCHANNELS~LISTCHANTOPIC~15767 - 0 - 8624 - Com: -1:0:0
2014.09.17 15:45:55:132 - 8512_EA63FCCDF678 - 8512_EA63FCCDF678 - Request Started - /wc.dll?CADoc~WorkArea - 0 - 8512 - Com: -1:0:0
2014.09.17 15:45:55:960 - 8720_21CEFF2089E5 - 8720_21CEFF2089E5 - Request Completed (1531) - /wc.dll?CADoc~CADocLogIn~UMPQ03C~JENNIFERHOLLENBECK@UMPQUABANK.COM - 3 - 8720 - Com: -1:0:0
2014.09.17 15:45:57:438 - 8512_EA63FCCDF678 - Invalid Request Id: 8720_21CEFF2089E5 - /wc.dll?CADoc~WorkArea - 1008 - 8512 - Com: -1:0:0
2014.09.17 15:45:57:438 - 8512_EA63FCCDF678 - 8512_EA63FCCDF678 - Request Completed (2297) - /wc.dll?CADoc~WorkArea - 3 - 8512 - Com: -1:0:0
2014.09.17 15:45:57:885 - 8624_C4F9C3CFE6DD - Invalid Request Id: 8720_21CEFF2089E5 - /wc.dll?CADoc~CADOCMANAGE~DMCHANNELS~LISTCHANTOPIC~15767 - 1008 - 8624 - Com: -1:0:0

Thanks for your help!

Hi Rick,

The invalid request id is meant to ensure that requests are valid through the entire pipeline - essentially it prevents session cross-talk (which is a serious bug when it happens). It sounds like you're running into this particular problem.

I've only seen this on a couple of occasions in the past and it only occurred under very heavy load with many servers loaded. The problem is caused by load bugs in the Windows COM subsystem when running under IIS under heavy load - essentially the COM marshalling is faulting and occasionally marshalling threads to the wrong COM instances which results in these errors. The invalid request id error handler inside of wc.dll checks for the original request Id and what it gets back when the request is done and catches those situations wher the two don't match and prevents invalid information being displayed to users.

There are two ways this can happen - a) the aforementioned COM load issues and there's really no fix for this. b) is make sure that the requests that are failing indeed have the RequestId header in them - ie the header isn't stripped or you're sending out raw HTTP headers as part of your requests that bypass Web Connection's automatic injection of the ID.

However, the best solution to this problem is to not use wc.dll, but rather the Web Connection .NET Module. The module is redesigned from scratch and works with isolated threads, so there's no thread marshalling. The module instantiates threads, loads up the COM objects and leaves them running on those same threads. There's never any marshalling and so this should never be a problem. Performance of the .NET module should also be better as the marshalling is rather resource intensive.

+++ Rick ---