Getting "(400) Bad Request" exception on VS Development Server in Windows 7

Question

I have a bare-bones WCF service and client that fail when using the Visual Studio Development Server in Windows 7. I get the following exception:

The remote server returned an error: (400) Bad Request.

The inner exception from tracing:

<InnerException>

<ExceptionType>System.Xml.XmlException, System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType>

<Message>The body of the message cannot be read because it is empty.</Message>

<StackTrace>

at System.ServiceModel.Channels.HttpRequestContext.CreateMessage()

at System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived(HttpRequestContext context, ItemDequeuedCallback callback)

at System.ServiceModel.Activation.HostedHttpTransportManager.HttpContextReceived(HostedHttpRequestAsyncResult result)

at System.ServiceModel.Activation.HostedHttpRequestAsyncResult.HandleRequest()

at System.ServiceModel.Activation.HostedHttpRequestAsyncResult.BeginRequest()

at System.ServiceModel.Activation.HostedHttpRequestAsyncResult.OnBeginRequest(Object state)

at System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.WorkItem.Invoke2()

at System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.WorkItem.Invoke()

at System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.ProcessCallbacks()

at System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.CompletionCallback(Object state)

at System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.ScheduledOverlapped.IOCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)

at System.ServiceModel.Diagnostics.Utility.IOCompletionThunk.UnhandledExceptionFrame(UInt32 error, UInt32 bytesRead, NativeOverlapped* nativeOverlapped)

at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

</StackTrace>

<ExceptionString>System.Xml.XmlException: The body of the message cannot be read because it is empty.</ExceptionString>

</InnerException>

The identical code works fine when using the Visual Studio Development Server in Vista, or IIS7 in either Vista or Windows 7. Any ideas?

IService1.cs:

using System.ServiceModel;

namespace TestService

{

[ServiceContract]

public interface IService1

{

[OperationContract]

string GetData(int value);

}

}

Service1.svc.cs:

namespace TestService

{

public class Service1 : IService1

{

public string GetData(int value)

{

return string.Format("You entered: {0}", value);

}

}

}

Program.cs:

using System;

using System.Windows.Forms;

namespace Test_WCF

{

static class Program

{

[STAThread]

static void Main()

{

ServiceReference1.Service1Client client = new Test_WCF.ServiceReference1.Service1Client();

try

{

MessageBox.Show(client.GetData(12).ToString());

}

catch (Exception ex)

{

MessageBox.Show(ex.Message);

}

}

}

}

Answer 1

So far I've tried with all of the IIS7 / WAS features installed, none of the IIS7 / WAS features installed, running VS2008 normally and as admin, with Windows Firewall enabled and disabled, and at all levels of UAC. No changes.

I'd like to use Windows 7 more, but since i'm currently working on a WCF service it's rather difficult when WCF services don't work properly.

Answer 2

Same problem here, Development Server returns the exact same error on my new Windows 7 on two different WCF services. I'm going to try with IIS now.

Congrats for Windows 7 anyway :) 

Answer 3

Could you provide the client/server config?

Answer 4

Client:

<system.serviceModel>

<bindings>

<wsHttpBinding>

<binding name="WSHttpBinding_IService1" closeTimeout="00:01:00"

openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"

bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"

maxBufferPoolSize="524288" maxReceivedMessageSize="65536"

messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"

allowCookies="false">

<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"

maxBytesPerRead="4096" maxNameTableCharCount="16384" />

<reliableSession ordered="true" inactivityTimeout="00:10:00"

enabled="false" />

<security mode="Message">

<transport clientCredentialType="Windows" proxyCredentialType="None"

realm="" />

<message clientCredentialType="Windows" negotiateServiceCredential="true"

algorithmSuite="Default" establishSecurityContext="true" />

</security>

</binding>

</wsHttpBinding>

</bindings>

<client>

<endpoint address="http://localhost:49465/Service1.svc" binding="wsHttpBinding"

bindingConfiguration="WSHttpBinding_IService1" contract="ServiceReference1.IService1"

name="WSHttpBinding_IService1">

</endpoint>

</client>

</system.serviceModel>

Server:

<system.serviceModel>

<services>

<service name="TestService.Service1" behaviorConfiguration="TestService.Service1Behavior">

<!-- Service Endpoints -->

<endpoint address="" binding="wsHttpBinding" contract="TestService.IService1" />

<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

</service>

</services>

<behaviors>

<serviceBehaviors>

<behavior name="TestService.Service1Behavior">

<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->

<serviceMetadata httpGetEnabled="true"/>

<!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->

<serviceDebug includeExceptionDetailInFaults="true"/>

</behavior>

</serviceBehaviors>

</behaviors>

</system.serviceModel>

Answer 5

Hi Chris,

Can you try using a non-secure binding like basicHttpBinding and see if you run into the same issue ? Looks like a security issue.

Thanks,
Vinela

Answer 6

It did work after switching to basicHttpBinding. Any ideas on how to get wsHttpBinding working, now?

Answer 7

Just wanted to let you know that we've repro'ed the issue on our side, and will be investigating further. Thanks a lot for reporting this; we'll follow up when we have more concrete information.

Answer 8

Update: You should see this fixed in the next release of Win7. Thanks again for your reports.