C
Chadusv
We receive this .Net 2.0 WebException on a specific machine when trying to
access a asmx service from within an Excel RTD Server.
Let me first give you the technical background of our add-in: We have one
UDF which calls into an Managed RTD server (using the Excel.RTD function);
the server implements the IRTDServer interface. Inside the RTD Server, I
batch up 25 (it is a configured number) request(s) to send to an asmx web
service.
Here is the problem:
Our add-in makes a couple of requests just fine and then fails until we
reinstall the add-in. Our log show it gets to the RTD server and then fails
with "Unable to connect to remote server" exception.
Here is a snippet of our log file:
TraceSource Verbose: 0 : Entering Connect Data. Finanical: , TickerySymbol
ibm, DateRequested , GetNewValues: True
TraceSource Verbose: 0 : Processing Request: 1
TraceSource Verbose: 0 : Initiating request coordinator. TopicId 1 Financial
..
TraceSource Critical: 0 : Exception after request completed, Exception
Message: Unable to connect to the remote server and Exception Stacktrace
at Excel.Addin.Formula.FinancialClient.OnRequestCompleted(Object sender,
GetFinancialsCompletedEventArgs e).
Here is the machine's configuration:
Office Pro 2003 sp1
Windows XP sp2
Norton Internet Security 2006
No internal or external proxies are installed.
Here is some troubleshooting steps we tried:
- We created a standalone app to communicate with the web service on the
problematic machine and it works fine. (of course, no RTD server is involved)
No firewall running internally (windows firewall and norton were turned off)
or externally on any routers.
- The web service uri is accessible from a web browser.
- Installed Sysinternals utilities (RegMon and FileMon) to find potential
errors but no issues manifested.
- Installed Sysinternals TcpMonitor and noticed the request never makes it
to the kernel tcp/ip stack.
So, after doing the above troubleshooting, we have come to a conclusion that
something is halting the execution of the asmx client connection before it
even make is to the tcp/ip stack.
Any ideas?
Thanks, Chad
access a asmx service from within an Excel RTD Server.
Let me first give you the technical background of our add-in: We have one
UDF which calls into an Managed RTD server (using the Excel.RTD function);
the server implements the IRTDServer interface. Inside the RTD Server, I
batch up 25 (it is a configured number) request(s) to send to an asmx web
service.
Here is the problem:
Our add-in makes a couple of requests just fine and then fails until we
reinstall the add-in. Our log show it gets to the RTD server and then fails
with "Unable to connect to remote server" exception.
Here is a snippet of our log file:
TraceSource Verbose: 0 : Entering Connect Data. Finanical: , TickerySymbol
ibm, DateRequested , GetNewValues: True
TraceSource Verbose: 0 : Processing Request: 1
TraceSource Verbose: 0 : Initiating request coordinator. TopicId 1 Financial
..
TraceSource Critical: 0 : Exception after request completed, Exception
Message: Unable to connect to the remote server and Exception Stacktrace
at Excel.Addin.Formula.FinancialClient.OnRequestCompleted(Object sender,
GetFinancialsCompletedEventArgs e).
Here is the machine's configuration:
Office Pro 2003 sp1
Windows XP sp2
Norton Internet Security 2006
No internal or external proxies are installed.
Here is some troubleshooting steps we tried:
- We created a standalone app to communicate with the web service on the
problematic machine and it works fine. (of course, no RTD server is involved)
No firewall running internally (windows firewall and norton were turned off)
or externally on any routers.
- The web service uri is accessible from a web browser.
- Installed Sysinternals utilities (RegMon and FileMon) to find potential
errors but no issues manifested.
- Installed Sysinternals TcpMonitor and noticed the request never makes it
to the kernel tcp/ip stack.
So, after doing the above troubleshooting, we have come to a conclusion that
something is halting the execution of the asmx client connection before it
even make is to the tcp/ip stack.
Any ideas?
Thanks, Chad