ISAPI-Filter stürzt unwillkürlich ab

[generic]

Moin Leute,

ich habe mich mal an einen ISAPI-Filter gewagt. Diese lief hier nun im Unternehmen ca. 3 Jahre.
Jetzt wollen wir eine neue Hardware einsetzten (Dual Xeon 3GHZ mit HT).
Auf der neuen Kiste stürzt der Filter ab.
Schutzverletztung oder AppPool startet sich einfach neu.
Bis auf die grössere Hardware ist die Konfiguration identisch.
W2k3+IIS6

Nun habe ich den Filter entkernt um den Fehler zu finden.
Sobald ich auf eine Servervariable zugreife und mit den Werten weiterarbeite dann geht halt manchmal nicht.

Wer eine Idee hat wo dran es liegt...

[Bernhard Geyer]

Bine mal deinen Filter per SetProcessAffinityMask-API-Funktion an einen Prozessor. Evtl. gibts ja Probleme mit mehreren Prozessoren (Das Problem kenn ich von MFC und TCP/IP-Kommunikation)

[generic]

hmm, hab das schonmal probiert. seit deinem post hatten wir keine abstürze mehr bei ca. 150.000 clicks/Stunde.

Nur Schade ist das 3 Virtuelle Prozessoren nichts mehr zu tun haben. Das hätten wir auch günstiger haben können.
ich bin am überlegen ob ich die einelnen isapi threads an einen prozessor binden sollte (roundrobin)

gruss und danke erstmal
--- edit ---
wenn ich die threads jeweils binde geht es auch nicht.
1 prozess wird nur gestartet - daher lohnt der rr nicht.

ergebnis: ich binde fest auf die erste cpu :-(

[generic]

500.000 klicks später ...

tut doch nicht, sah in den erste 2 stunden echt gut aus.

wer noch weitere vorschläge hat - bitte sehr

[sakura]

Hi generic
:party: :dance: :party:

Drei Wochen (inkl. Wochenenden) hat mich das Debugging gekostet. Und einen Workaround bekommst Du heute kostenfrei ins Haus geliefert. Es ist ein Bug in der RTL von Delphi und dem Klassenhandling :shock: Leider gibt es noch keinen Delphi-Compiler, der das Problem löst. Einfache Lösung, wenn auch nicht die wahre Schönheit.

Binde in die Uses-Klausel Deiner DPR als erstes ShareMem ein und kopiere die borlandmm.dll mit in das Verzeichnis, wo Du den Filter hast. Dann geht es wie von alleine alles wieder...

Ausfühlichere Diskussion in meinem Blog

...:cat:...

P.S.: Die Lösung läuft bei uns seit November 2005 fehlerfrei auf allen Kundenrechnern. Systemstabilität ist seit dem um einige hundert Prozent hoch. :thumb:

[Mavarik]

Hallo! Hoffe ich oute mich hiermit nicht... :roll:

Mal abgesehen von dem goto... :oops:

traue ich Deinem Mutex Aufruf nicht so ganz...

mir hat folgender Eintrag im Hilfesystem wachgerufen:

1. The owning thread uses the ReleaseMutex function to release its ownership.
2. Two or more processes can call CreateMutex to create the same named mutex. The first process actually creates the mutex, and subsequent processes open a handle to the existing mutex. This enables multiple processes to get handles of the same mutex, while relieving the user of the responsibility of ensuring that the creating process is started first. When using this technique, you should set the bInitialOwner flag to FALSE; otherwise, it can be difficult to be certain which process has initial ownership.

Ich nehme immer (TMultiReadExclusiveWriteSynchronizer;) kann natürlich sein, dass diese routine auch mit Mutex arbeitet, aber die
ist auf jeden Fall Thread sicher...

Frank :coder:

[Mavarik]

Zitat:

Zitat von sakura

Hi generic
:party: :dance: :party:

Drei Wochen (inkl. Wochenenden) hat mich das Debugging gekostet. Und einen Workaround bekommst Du heute kostenfrei ins Haus geliefert. Es ist ein Bug in der RTL von Delphi und dem Klassenhandling :shock: Leider gibt es noch keinen Delphi-Compiler, der das Problem löst. Einfache Lösung, wenn auch nicht die wahre Schönheit.

Binde in die Uses-Klausel Deiner DPR als erstes ShareMem ein und kopiere die borlandmm.dll mit in das Verzeichnis, wo Du den Filter hast. Dann geht es wie von alleine alles wieder...

Ausfühlichere Diskussion in meinem Blog

...:cat:...

P.S.: Die Lösung läuft bei uns seit November 2005 fehlerfrei auf allen Kundenrechnern. Systemstabilität ist seit dem um einige hundert Prozent hoch. :thumb:

Hattest Du diese Problem nicht in einen ganz anderen zusammenhang... Überladen det VMT Tabelle?

Oder habe ich da was falsches im Kopf... Hatte doch gar kein Bier getrunken...

mfg Frank :cheers:

[sakura]

Zitat:

Zitat von Mavarik

Hattest Du diese Problem nicht in einen ganz anderen zusammenhang... Überladen det VMT Tabelle?
Oder habe ich da was falsches im Kopf... Hatte doch gar kein Bier getrunken...

Ja, es war die VMT Table, welche intern aber mit einfachen Strings gehandelt wird - und da liegt imo das Problem. Und generic wirft ja nur so mit Strings um sich ;-)

...:cat:...

P.S.: Beim Quotieren musst Du nicht immer gleich ganze Beiträge quotieren ;)

[generic]

der mutex aufruf ist unproblematisch. das stürzt auch ohne die log procedure ab.

ich probiere jetzt nochmal das mit sharemem.
ergebnisse lasse ich euch wissen.
allerdings wenn es montag bei uns nicht läuft stellen wir das projekt ein und setzten dann auf eine PHP oder ASP.net lösung.

[generic]

1.5 mio klicks später.

nach den tipps von daniel habe ich mich nochmal dran gewagt (danke erstmal)

es läuft jetzt viel stabiler, allerdings steht jetzt im event log ca. alle 7 stunden ein eintrag welcher mit dem thema "arbeitsprozesse wiederverwenden" im iss zu tun hat.

Code:

Quelle: W3SVC
ID: 1074
Ein Arbeitsprozess mit Prozesskennung "5760" für Anwendungspool "<...>" hat eine Wiederverwendung angefordert, da dessen erlaubtes Betriebszeitlimit erreicht wurde.

Code:

Quelle: W3SVC
ID: 1009
Ein Prozess für Anwendungspool "<...>" wurde unerwartet beendet. Die Prozesskennung lautet "5760". Der Prozessexitcode lautet "0xc0000005".

eingrenzen auf das speicherproblem kann ich diesen fehler allerdings nicht.
wir testen jetzt nochmal auf einer anderen maschine, welche blank ist.
sprich nur iis und der filter.

ich halte euch auf den laufenden!