3 Stimmen

LinkPoint-Zahlungsintegration mit IIS7 lässt w3wp.exe abstürzen

Meine Assemblies, die eine DLL eines Drittanbieters umschließen, funktionieren fein in meiner Windows-Test-Harness-Anwendung, und sie auch funktionieren in einem Webdienst einwandfrei, wenn sie im Debug-Modus (VS 2008 Visual Studio Development Server) erzeugt werden! Die Anwendung stürzt jedoch immer ab, wenn sie auf dem lokalen IIS 7-Webserver ausgeführt wird. Hier ist der Absturz Detail aus dem Ereignisprotokoll bei der Ausführung auf dem lokalen IIS-Server:

Fehlerhafte Anwendung w3wp.exe, Version 7.0.6001.18000, Zeitstempel 0x47919413, fehlerhaftes Modul ntdll.dll, Version 6.0.6001.18000, Zeitstempel 0x4791a783, Ausnahmecode 0xc0000374, Fehler Offset 0x000aada3, Prozess-ID 0x990, Startzeit der Anwendung 0x01c9b4133281d5d0.

Diskussion: Ich schrieb einen Wrapper um eine .NET dll von einem Drittanbieter (LinkPointTransaction.dll von FirstData), und ich schrieb einige andere Assemblys, die diesen Wrapper verweisen. Während der Code ausgeführt wird, wird ein Aufruf an die Drittanbieter LinkPointTransaction.LinkPointTxn.Send() sendet die Transaktion erfolgreich über das Internet an FirstData, aber meine Anwendung w3wp.exe stürzt irgendwo ab während diesen Aufruf, bevor er die nächste Zeile erreicht. Es wird keine verwaltete Ausnahme ausgelöst, die ich sehen kann; es stürzt einfach ab. Funktioniert überall auf meinem Rechner gut, außer in IIS7.

Ich führe 64bit Vista Home Premium (IIS7) aus, aber ich habe 32bit-Anwendungen in IIS aktiviert, einen separaten AppPool nur für diesen Webdienst erstellt und alle meine Baugruppen zu x86 gezwungen. Ich habe versucht, den App-Pool unter meinem Benutzerkonto mit Admin-Rechten auszuführen, anstatt als Netzwerkdienst. UAC ist ausgeschaltet. Ich habe den integrierten und den klassischen Modus ausprobiert. Ich habe den TCP/IP-Port in meiner lokalen Firewall explizit geöffnet, den die LinkPointTransaction.dll zur Kommunikation mit FirstData verwendet. Ich habe sogar meine Firewall abgeschaltet (hinter einem Router).

Mit jeder der von mir aufgelisteten Umgehungslösungen ist es immer funktioniert in einer Windows-Anwendung und auch in einem Webdienst innerhalb des VS Development Servers, aber niemals funktioniert auf dem lokalen IIS-Server.

Der AppPool für die IIS-Website befindet sich im klassischen Modus. (Als Antwort auf Gidon)

0 Stimmen

Ich habe das gleiche Problem, aber meine funktionierte für eine kurze Zeit, aber jetzt stürzt jedes Mal, wenn Sie versuchen, in MSTest laufen. Es wird keine Ausnahme geworfen. Gut, dass ich nicht der Einzige bin...

4voto

Scott Fletcher Punkte 1449

Ich glaube nicht, dass es sich hier um eine Programmierfrage handelt, also 'beantworte' ich sie.

Mit WinDbg habe ich das Problem auf die vom Hersteller bereitgestellte dll zurückgeführt. Wenn die Anwendung abstürzt, sieht es aus wie ein Problem mit der Art und Weise, wie die DLL die Speicherzuweisung freigibt. Der Aufrufstapel zeigt eine Speicherfreigabeoperation in der DLL, dann eine "Heap free"-Operation im Kernel, dann eine "Free Heap"-Operation in der NTDLL und eine anschließende "Report Heap Failure"-Operation (und dann RtlReportCriticalFailure), die das Ganze zum Absturz bringt.

Ich verstehe immer noch nicht, warum es in einer Windows Forms-Anwendung und in IIS 6 funktioniert, aber nicht in IIS 7. Dies ist jedoch eher eine Frage der Plattform als eine Frage der "Programmierung". Außerdem liegt es wahrscheinlich in der Verantwortung des Herstellers, das Problem zu beheben, und nicht in meiner, es zu umgehen.

UPDATE : Innerhalb von zwei Tagen nach Einreichen des Support-Tickets beim Hersteller wurde ein aktualisierter Satz von Integrations-DLLs bereitgestellt, die ein COM-Objekt verwenden, das mit regsvr32 registriert wird und in IIS7 64-Bit funktioniert, wenn es im WOW64-Verzeichnis registriert wird. EIN HOCH AUF DEN TECHNISCHEN SUPPORT VON FIRST DATA!

0 Stimmen

Ich habe mit dem technischen Support gesprochen und mir die aktualisierten DLLs besorgt. Meistens funktioniert es, aber hin und wieder, einmal am Tag oder so, bleibt es "hängen". Wir erhalten dann COM-bezogene Fehlermeldungen. Normalerweise behebt das Recycling des Anwendungspools das Problem, aber das ist natürlich keine Lösung. Funktioniert es bei Ihnen gut? Vielen Dank!

0 Stimmen

P.S. Manchmal ist ein Neustart von IIS7 (64 Bit) erforderlich, das Recycling des Anwendungspools wird nicht ausreichen.

0 Stimmen

Inzwischen haben wir das Unternehmen für das Händler-Gateway gewechselt. Wir verwenden jetzt USAePay.

3voto

Mike Wills Punkte 20421

Ich fragte First Data nach den DLLs und der Möglichkeit, sie unter IIS7/.NET 4/Win 2008 64-bit auszuführen. Dies war ihre Antwort:

Vielen Dank für Ihre aktuelle Anfrage zu First Data Global Gateway. Die Webservice API ist unsere aktuelle Lösung für 64-Bit-Maschinen, die auf IIS 7 laufen, da keine der dll-Dateien (Linkpointtransaction.dll, LPICOM_6_.dll) aktualisiert wird, um mit dem 64-Bit-Server zu funktionieren. Für die Webservice-API muss das Client-Zertifikat installiert und die Transaktion per SOAP-Anfrage gesendet werden. Weitere Informationen zur Webservice API finden Sie unter http://www.firstdata.com/downloads/marketing-merchant/FDGG-Web-Service-API-v4.0.pdf .

Wenn Sie weitere Erklärungen oder Fragen haben, wenden Sie sich bitte an unseren Support unter der unten angegebenen Telefonnummer. Bitte beachten Sie, dass der API-Support von Montag bis Freitag von 9:00 bis 18:00 Uhr EST erreichbar ist.

Dies sollte anderen helfen, die in Zukunft nach ähnlichen Informationen suchen.

0voto

Gideon Punkte 17661

Wie ist die Website in IIS7 konfiguriert? Wenn sie im integrierten Modus ausgeführt wird, wechseln Sie zum klassischen Modus. Siehe Einschneidende Änderungen für ASP.NET 2.0-Anwendungen, die im integrierten Modus auf IIS 7.0 ausgeführt werden

0 Stimmen

Der AppPool, den die Website verwendet, läuft im klassischen Modus.

0 Stimmen

Haben Sie auch die anderen Migrationsfehler in dem Link überprüft, z. B. den neuen Platz für httphandlers und Module in der web.config?

0voto

CodingWithSpike Punkte 41513

Ich hatte ein sehr ähnliches Problem, und nachdem ich mich tagelang damit herumgeschlagen hatte, stellte ich fest, dass, wenn ich denselben Code immer wieder in MSTest ausführe, er manchmal fehlschlägt und den Testprozess komplett zum Absturz bringt, manchmal aber auch gut funktioniert.

Die wirklich seltsame Sache ist, dass es am häufigsten passiert, wenn ein MSTest zu debuggen, ABER, wenn ich innerhalb der Testmethode klicken, dann auf der Haupt-Buttonbar klicken Sie auf "debug Tests im aktuellen Kontext" dann es fast immer fehlschlägt. Wenn ich stattdessen den Test ausführe, indem ich im Fenster "Testergebnisse" auf "debuggen" klicke, wird er fast immer korrekt ausgeführt.

Es funktioniert auch fast immer korrekt, wenn ich nicht im Debug-Modus arbeite, aber manchmal schlägt es trotzdem fehl. Ich habe sogar gona so weit wie copy/pastign den gleichen Code zwischen 2 verschiedenen Projekten in 2 verschiedenen VisualStudio 2010 Instanzen, und in einer von ihnen der Code ordnungsgemäß ausgeführt wird, und in einem anderen wird es fehlschlagen.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X