tags:

views:

94

answers:

3

We are currently in the process of migrating from Server 2003 to Server 2008. We have a few different environment changes for our ASP.NET application. Our Test Environment is working perfectly at this time, but the production machine with same code is injecting Invalid Characters into the SQL.

The following is the SQL I see via SQL Server Profiler.

exec sp_executesql N'SELECT [t0].[VenuePDID], [t0].[VenueID], [t0].[VenueNumber], [t0].[MarketID], [t0].[ProgramID], [t0].[VenueTypeID], [t0].[SalesTypeID], [t0].[BackBarPaymentID], [t0].[Goal], [t0].[LocationTypeID], [t0].[VenueStatus], [t0].[Tab1ConfirmDate], [t0].[Tab1ConfirmedBy], [t0].[Tab2ConfirmDate], [t0].[Tab2ConfirmedBy], [t0].[DateContractRequested], [t0].[ContractRequestedBy], [t0].[ContractTypeRequested], [t0].[ContractAmtRequested], [t0].[ContractAmtLimit], [t0].[ContractSalesAmtRequested], [t0].[ContractSalesAmtMax], [t0].[ContractPerVistAmtLimit], [t0].[ContractSalesPerVisitAmtLimit], [t0].[ActiveDate], [t0].[InactiveDate], [t0].[WebsiteRejected], [t0].[ResponsibleGM], [t0].[CreateDate], [t0].[CreatedBः㐈   [1]     
[1] 볧इ퀄㐀޼SELECT [t0].dBy], [t0].[timestamp], [t0].[DetailConfirmDate], [t0].[DetailConfirmBy], [t0].[SalesConfirmDate], [t0].[SalesConfirmBy], [t0].[ContractTypeId]
FROM [dbo].[tbl_VenueProgramDetails] AS [t0]
WHERE ([t0].[VenueID] = @p0) AND ([t0].[ProgramID] = @p1)',N'@p0 int,@p1 int',@p0=7477,@p1=27

I've copied all of the dll's from the working test environment and I get the same thing. I have also pointed the test web server at the live db and the code works. I've pointed the live web server to the test db and the code fails just like above. At this point the issue has to be with IIS7 configuration or .Net on the production server. I cannot seem to pin point it though. Has anyone see this before?

A: 

Make LINQ log what it thinks it's sending. This sounds like a SQL Server Profiler bug to me rather than a LINQ bug. I could be wrong, of course.

Jon Skeet
When I run the code from the other Web Server the SQL Profiler displays the correct SQL. It only renders that when it is coming from our New Production equipment. Luckily we have not cut over yet.
cjibo
Hmm. Connection string issue? What does the log show at the LINQ side?
Jon Skeet
Other LINQ statements are working when I dump the log it is literally generating the Unicode in the query. Me thinks I have an installation issue with this server. Migrated code to different server and it works.
cjibo
A: 

CreatedB\u0903\u3408 [1] \uffff

That's not really Unicode... U+FFFF is explicitly not a Unicode character, for one!

Something appears to be spitting binary corruption over arbitrary bits of your memory. This is not going to be fun to find because it'll most likely be something unpleasantly low-level. Are there any suspicious non-managed components used by your app, or ISAPI extensions on the production machine? (Or even other hooks, like dodgy anti-virus?)

bobince
You are correct it is not Unicode. This is a fresh installed server no ISAPI Filters except ASP.NET 1.1 and 2.0. I'm running my 3.5 code in pipeline. You now have me wondering if this is going to go as low as bad memory. I disabled AV to test with that disabled.
cjibo
Hmm, I doubt bad memory would behave as specifically as this, and though IMO AV has no place on a web server anyway, I can't really immediately see how it would manage to do it so consistently either. Curious! :-(
bobince
+1  A: 

The issue ended up being a network card driver. The physical machine was the issue not configuration or code.

EDIT: The machine I was having issues with is a HP DL360 with Broadcom Network Cards. We will be contacting HP regarding the issue. The packets were being assembled wrong when sending the LINQ request across the wire.

cjibo