与IIS7的LinkPoint支付集成崩溃w3wp.exe

Question

My assemblies that wrap a third-party DLL work fine in my windows test harness app, and they also work fine in a web service when spawned in debug mode (VS 2008 Visual Studio Development Server)! However, the app always crashes when running in the local IIS 7 web server. Here is the crash detail from the event log when running on the local IIS server:

Faulting application w3wp.exe, version 7.0.6001.18000, time stamp 0x47919413, faulting module ntdll.dll, version 6.0.6001.18000, time stamp 0x4791a783, exception code 0xc0000374, fault offset 0x000aada3, process id 0x990, application start time 0x01c9b4133281d5d0.

Discussion: I wrote a wrapper around a .NET dll from a third-party (LinkPointTransaction.dll from FirstData), and I wrote some other assemblies that reference that wrapper. As the code is running, a call to the third-party LinkPointTransaction.LinkPointTxn.Send() sends the transaction successfully to FirstData over the internet, but my application crashes w3wp.exe somewhere during that call, before it hits the next line. It does not throw a managed exception that I can see; it just crashes. Works fine everywhere on my machine except in IIS7.

I am running 64bit Vista Home Premium (IIS7), but I enabled 32bit apps in IIS, created a separate AppPool just for this web service, and have forced all of my assemblies to x86. I have tried running the App Pool under my user account with Admin privileges instead of as the Network Service. UAC is turned off. I have tried Integrated and Classic modes. I have explicitly opened the TCP/IP port in my local firewall that the LinkPointTransaction.dll uses to communicate with FirstData. I even have shut my firewall off (behind a router).

With any of these workarounds that I listed, it always works in a Windows app and also in a web service inside the VS Development Server, but never works in the local IIS server.

The AppPool for the IIS website is in Classic mode. (In response to Gidon)

Answer 1

I don't think this is a programming question anymore, so I am 'answering' it.

Using WinDbg, I have tracked it down to the dll provided by the vendor. When the app crashes, it looks like a problem with the way the dll is de-allocating memory. The call stack shows a memory free operation in the dll, then a "heap free" operation in the kernel, then a "free heap" operation in ntdll, and a subsequent "report heap failure" (and then RtlReportCriticalFailure) that tears down the whole thing.

I still don't understand why it works in a Windows Forms app and in IIS 6, but not work in IIS 7. However, this has become more of a platform question than a 'programming' question. Besides, it is probably the vendor's responsibility to fix it rather than mine to work around it.

UPDATE : Within two days of filing the tech support ticket with the vendor, they provided an updated set of the integration DLLs that use a COM object that you register with regsvr32, and it works in IIS7 64-bit if you register it in the WOW64 directory. YEA FOR FIRST DATA TECHNICAL SUPPORT!

Answer 2

I asked First Data about the DLLs and being able to run it on IIS7/.NET 4/Win 2008 64-bit. This was their response:

Thank you for your recent inquiry regarding First Data Global Gateway. The Webservice API is our current solution for 64 bit machines running on IIS 7 as none of the dll files (Linkpointtransaction.dll, LPICOM_6_.dll) will be updated to work with the 64bit server. Webservice API will require to install the client certificate and send the transaction via SOAP request. Additional information on Webservice API is found at http://www.firstdata.com/downloads/marketing-merchant/FDGG-Web-Service-API-v4.0.pdf .

If you need further clarifications or questions, please contact our support desk via phone number below. Please be advised the API support desk hours is from 9:00AM to 6:00PM EST Mon-Fri.

This should help others looking for similar information in the future.

Answer 3

I've had a very similar issue, and after messing with it for days, I've come to realize that if I run the same code over and over in MSTest, sometimes it fails and completely crashes the test process, other times it works fine.

The really strange thing is that it happens most often when debugging an MSTest, BUT, if I click inside the test method, then on the main buttonbar click "debug tests in current context" then it almost always fails. If I instead run the test by clicking "debug" in the "Test Results" window, then it almost always passes correctly.

It also almost always works correctly if I do not run in debug mode, but does still sometimes fail. I've even gona as far as copy/pastign the exact same code between 2 different projects in 2 different VisualStudio 2010 instances, and in one of them the code will run properly, and in another it will fail.

Answer 4

How is the website configured in IIS7? If it is running in Integrated Mode switch to Classic Mode. See Breaking Changes for ASP.NET 2.0 applications running in Integrated mode on IIS 7.0