views:

1977

answers:

2

I have a WCF service that does some document conversions and returns the document to the caller. When developing locally on my local dev server, the service is hosted on ASP.NET Development server, a console application invokes the operation and executes within seconds.

When I host the service in IIS via a .svc file, two of the documents work correctly, the third one bombs out, it begins to construct the word document using the OpenXml Sdk, but then just dies. I think this has something to do with IIS, but I cannot put my finger on it.

There are a total of three types of documents I generate. In a nutshell this is how it works

SQL 2005 DB/IBM DB2 -> WCF Service written by other developer to expose data. This service only has one endpoint using basicHttpBinding

My Service invokes his service, gets the relevant data, uses the Open Xml Sdk to generate a Microsoft Word Document, saves it on a server and returns the path to the user.

The word documents are no bigger than 100KB.

I am also using basicHttpBinding although I have tried wsHttpBinding with the same results.

What is amazing is how fast it is locally, and even more that two of the documents generate just fine, its the third document type that refuses to work.

To the error message:

An error occured while receiving the HTTP Response to http://myservername.mydomain.inc/MyService/Service.Svc. This could be due to the service endpoint binding not using the HTTP Protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the server shutting down). See server logs for more details.

I have spent the last 2 days trying to figure out what is going on, I have tried everything, including changing the maxReceivedMessageSize, maxBufferSize, maxBufferPoolSize, etc etc to large values, I even included:

 <httpRuntime maxRequestLength="2097151" executionTimeout="120"/>

To see maybe if IIS was choking because of that.

Programatically the service does nothing special, it just constructs the word documents from the data using the Open Xml Sdk and like I said, locally all 3 documents work when invoked via a console app running locally on the asp.net dev server, i.e. http://localhost:3332/myService.svc

When I host it on IIS and I try to get a Windows Forms application to invoke it, I get the error.

I know you will ask for logs, so yes I have logging enabled on my Host.

And there is no error in the logs, I am logging everything.

Basically I invoke two service operations written by another developer.

MyOperation calls -> HisOperation1 and then HisOperation2, both of those calls give me complex types. I am going to look at his code tomorrow, because he is using LINQ2SQL and there may be some funny business going on there. He is using a variety of collections etc, but the fact that I can run the exact same document, lets call it "Document 3" within seconds when the service is being hosted locally on ASP WebDev Server is what is most odd, why would it run on scaled down Cassini and blow up on IIS?

From the log it seems, after calling HisOperation1 and HisOperation2 the service just goes into la-la land dies, there is a application pool (w3wp.exe) error in the Windows Event Log.

Faulting application w3wp.exe, version 6.0.3790.1830, stamp 42435be1, faulting module kernel32.dll, version 5.2.3790.3311, stamp 49c5225e, debug? 0, fault address 0x00015dfa.

It's classified as .NET 2.0 Runtime error.

Any help is appreciated, the lack of sleep is getting to me.

Help me Obi-Wan Kenobi, you're my only hope.

A: 

Yes, we'd want logs, or at least some idea of what you're logging. I assume you have both message and transport logging on at the WCF level.

One thing to look at is permissions. When you run under Cassini the web server is running as the currently logged in user. This hides any SQL or CAS permission problems (as, lets be honest, your account is usually a local administrator). As soon as you publish to IIS you are now running under the application pool user, which is, by default, a lot more limited.

Try turning on IIS debug dumps and following the steps in KB919789

blowdart
Yeah permissions are fine it seems, the service begins to write the document but just chokes, it starts writing the .docx file , gets to 2kb and dies, basically i see the document being written to the filesystem, but it seems to be dying at somepoint.
RandomNoob
A: 

Fyi, I changed IIS 6 to work in IIS 5.0 Isolation mode and everything works. Odd.

RandomNoob