HTTP 400 Bad Request inside get_DeclaringMethod() in mscorlib?

[Ken Yee]

Is there any way to debug into the web service proxy in asp.net 2.x?
You used to be able to do this in asp.net 1.1 and you could fix the proxy
if need be. This seems like a bug in the proxy generator

This API works fine most of the time, but occasionally get stuck where it
always gives an HTTP 400 Bad Request error for a certain data structure
that looks fine to me (they're all serializable objects of null, integer,
string, and datetime).

Stack dump is fairly useless:
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse
(SoapClientMessage message, WebResponse response, Stream responseStream,
Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String
methodName, Object[] parameters)
at Mycode.ReplicationService.addObject(ReplicationTable tableName,
ReplObj obj) in F:\work\ASSEMBLYSRC\Site\Web References\Replication
\Reference.vb:line 354

ReplObj is a simple array of name/value pairs.

When I look at the exception in the debugger, the targetsite exception
states:

Method may only be called on a Type for which Type.IsGenericParameter is
true.
at System.RuntimeType.get_DeclaringMethod()

Well..that's not too useful w/o me knowing what it's trying to parse and
what method and type it's having problems with :-(

Any other suggestions on what to do with this short of sticking a network
analyzer on it and making sure the soap/xml packets look ok? It's the
latest version of asp.net 2.0 if that matters...


ken

 

[John Saunders [MVP]]

Is there any way to debug into the web service proxy in asp.net 2.x?
You used to be able to do this in asp.net 1.1 and you could fix the proxy
if need be. This seems like a bug in the proxy generator

This API works fine most of the time, but occasionally get stuck where it
always gives an HTTP 400 Bad Request error for a certain data structure
that looks fine to me (they're all serializable objects of null, integer,
string, and datetime).

Stack dump is fairly useless:
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse
(SoapClientMessage message, WebResponse response, Stream responseStream,
Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String
methodName, Object[] parameters)
at Mycode.ReplicationService.addObject(ReplicationTable tableName,
ReplObj obj) in F:\work\ASSEMBLYSRC\Site\Web References\Replication
\Reference.vb:line 354

ReplObj is a simple array of name/value pairs.

When I look at the exception in the debugger, the targetsite exception
states:

Method may only be called on a Type for which Type.IsGenericParameter is
true.
at System.RuntimeType.get_DeclaringMethod()

Well..that's not too useful w/o me knowing what it's trying to parse and
what method and type it's having problems with :-(

Any other suggestions on what to do with this short of sticking a network
analyzer on it and making sure the soap/xml packets look ok? It's the
latest version of asp.net 2.0 if that matters...

Exceptions like this often have a nice chain of InnerException's. Check the
InnerException of this exception, etc. In fact, just try
Console.WriteLine(ex.ToString()), which will print the entire chain of
exceptions.

 

[Ken Yee]

Exceptions like this often have a nice chain of InnerException's.
Check the InnerException of this exception, etc. In fact, just try
Console.WriteLine(ex.ToString()), which will print the entire chain of
exceptions.

There was nothing...I rummaged through the exception object in the
debugger w/o luck.

I did find the actual cause of this...<drumroll>....trying to send a
string w/ null characters in it. The null characters weren't displayed
in the debugger; the debugger only displayed the string as a truncated
string (C# lets you include nulls in a string whereas C++ doesn't). I
had to packet capture the web service call/response to figure this
out...what a PITA because MS doesn't let you capture packets to localhost


So anyways, the solution was to strip all null characters from strings
before sending them via the web service calls. Otherwise, the receive
side would blow up claiming it was an invalid XML document, which it is.
MS needs to figure out a way to encode null characters or give a better
message about what character in what field of the parameter is causing
the issue... :-(


ken

 

[thom]

had similar issue, I was trying to pass strings constructed from bytes, which
caused http 400 error. So better to send directly bytes.