www.IT-Visions.de-Diskussionsforen (Version 2.1)
(Diese Seite wurde noch nicht auf das neue Layout umgestellt!)


Diese Foren stehen den Lesern unserer Bücher und allen anderen registrieren Benutzern dieser Website zur Verfügung. Wir würden uns freuen, wenn viele Nutzer dieser Website hier nicht nur Fragen stellen, sondern auch die Fragen anderer Nutzer beantworten. Diese Foren sind ein ehrenamtlicher, nicht-kommerzieller, unmoderierter Community-Dienst von www.IT-Visions.de. Wenn Sie kommerzielle Unterstützung für .NET/Scripting/PowerShell suchen, schauen Sie bitte auf unser Support-Angebot und unsere Schulungsangebote für Scripting und Schulungsangebote für .NET.



.net Framework 2.0 seltsamer Kommunikationsfehler
Autor:  AndreasMeyer
E-mail:  Antworten bitte nur in das Forum!
Datum:  30.04.2010 13:57:52
Subject:  .net Framework 2.0 seltsamer Kommunikationsfehler
Bezug zum Buch: 
Message:  Hallo,
Ich betreibe einen Server mit SQL Server 2005, Navision Application Server (und einer Datenbank im Hintergrund) und einem Webserver mit Windows Server 2003.
Der Webserver ist eine sehr schmalbrüstige Anwendung, die auf DotNet-Framework 2.0 basiert und nur ein paar TCP-Funktionen benutzt. Der Navision Application Server arbeitet mit diesem Webserver eng zusammen. D.h. wenn der Navision Application Server hoch fährt, lauscht dieser Webserver für ihn mit PID 4 auf dem Port, der für den NAS spezifiziert wurde. An einer Meldung im Eventlog kann ich sehen, ob und dass der NAS ordentlich hoch gefahren ist; zusätzlich überprüfe ich das mit netstat -aon an der Kommandozeile).
Das hat lange einwandfrei funktioniert und funktioniert auf anderen Servern immer noch.
Nur auf diesem einen Server funktioniert es nicht mehr. Alle anderen Anwendungen funktionieren, auch der NAS wenn ein anderere, älterer Webserver - nicht auf DotNet-basierend – genutzt wird.
Schnittstellenanfragen kommen an den Server auf dem für den NAS definierten Port rein, der NAS ist in Bereitschaft aber es kommt bei ihm nichts an. D.h. irgendwo ist ein für mich nicht einsehbarer Bruch, wo die Kommunikation nicht mehr klappt. Sobald ich die DB samt NAS und diesem Webserver auf einen anderen Server verlagere, geht es.
Wenn ich ein soapToolkit3.0 als Trace zwischenschalte, sehe ich, dass die Anfrage auf dem Server auf Port 8430 ankommt. Die Weiterleitung erfolgt auf Port 8431 dieses Servers, wo der Webserver im Auftrag des NAS lauscht. Das untere Fenster im Soap-Toolkit bleibt ganz weiß, d.h. keinerlei Reaktion und es kommt im NAS nichts an. Mit netstat –aon sehe ich, dass beide Ports abgehört werden: das Soap-Toolkit auf dem Port an den die Schnittstellenanfrage gestellt wird (wo es rein kommt) sowie der auf DotNet basierende Webserver (mit PID 4) für den NAS, auf dem Port, an den das SoapToolkit die Anfrage weiterleitet.
Wo ist der Kommunikationsbruch und wie kann ich das herausfinden/debuggen?
Die Tatsache, dass die PID des auf .Net-basierenden Webservers 4– und damit ein Systemport erster Güte ist – zeigt, dass es mit DotNet zu tun hat.
Ich habe .Net komplett auf dem Server entfernt, das .Net-CleanupTool drüberlaufen lassen und das .Net-Framework neu installiert; den Webserver neu installiert, den NAS neu installiert, dessen .dlls re-registriert. Dabei tauchen keinerlei Fehlermeldungen auf, dennoch: gleicher Fehler, keinerlei Kommunikation zwischen den Ports. Der NAS-Entwickler hatte den Code des NAS händisch gestartet und bestätigt, dass er "bereit" sei, aber nichts einläuft. Aber ich sehe, auf dem soaptoolkit, dass die Anfrage rein kommt.
Gibt es eine Möglichkeit, diesen Fehler herauszufinden? Ich habe gesehen, dass .Net einen Ordner mit einem recht undefinierbarem Namen auf einem Laufwerk anlegt: 4d1434a4de8d5691c89bf9d3befb.
Hier befinden sich einige .dlls, die aber leider alle nicht mit regsrv32 re-registriert werden können, da es stets zu dieser Meldung dabei kommt:
.dll was loaded, but the DllRegisterServer entry point was not found. This file can not be registered.
Weiß einer von Euch Entwicklungsspezialisten Rat?
Es ist doch eigentlich beschämend, dass ich jetzt wegen so einem Fehler den Server neu aufsetzen muss? Weiß ein Insider von Microsoft hier Rat?
Noch ein paar Bemerkungen:
sfc /scannow hat nichts genützt.
Das Re-Registrieren aller .DLLs in system32 hatte nichts genützt.
Neu-Installationen aller beteiligten Software-Komponenten hatte nichts genützt.
Die De-Installation und Neuinstallation vom ganzen TCP/IP samt Netzwerkkarte hatte nichts genützt.
Gilt es irgendwelche Registry-Einträge zu überprüfen?
Kann man .Net re-registrieren oder überprüfen?

DotNet ist an dieser Stelle für mich völlig undurchsichtig und ich habe das Gefühl es ist wie eine "Blackbox", die mich hier völlig im Regen stehen läßt.

Mit freundlichem Gruß
Andreas

Antworten

  Zurück zum Forum



 .NET Framework-Programmierung -- C#, VB.NET, ASP.NET, u.a.
 .net Framework 2.0 seltsamer Kommunikationsfehler von AndreasMeyer  am 30.4.2010 1:57:52 PM


www.IT-Visions.de - Dr. Holger Schwichtenberg / 1998-2019