Sie sind nicht angemeldet.
Lieber Besucher, herzlich willkommen bei: Aqua Computer Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
Body
unregistriert
PharaoHat-Mo-Neten
unregistriert
Zitat von »Body«
google hat mir nicht geholfen, oder ich bin zu blöd dafür
Zitat
Netzwerk API Treiber müssen die API-Anfragen entgegennehmen und in Low-Level Netzwerkprotokoll-Anfragen für die Übertragung im Netz umsetzen. Die API Treiber bauen dabei auf Transport-Protokoll Treibern im Kernel Mode auf. Das Trennen der APIs von den darunterliegenden Protokollen bietet der Netzwerkarchitektur die Flexibilität, dass APIs verschiedene Protokolle verwenden können.
Damit Netzwerk API Treiber nicht unterschiedliche Schnittstellen für jedes Protokoll mitbringen müssen, hat Microsoft ein Standard-Interface namens Transport Driver Interface (TDI) bereitgestellt. Transportprotokolle, die sich an den TDI-Standard halten, exportieren dieses zu den Clients, was die Netzwerk-API Treiber, wie z.B. afd.sys und npfs.sys enthält. Ein Transportprotokoll, das als NT Gerätetreiber implementiert ist, wird TDI-Server genannt. Da TDI-Server Gerätetreiber sind, formatieren sie Anfrage, die sie von Clients erhalten, in I/O request packets (IRPs).
Support Funktionen in der tdi.sys Library, einhergehend mit Definitionen, die die Entwickler in ihre Treiber packen, machen TDI aus. Diese Schnittstelle stellt eine Konvention zur Verfügung, wie Netzwerkanfragen in IRPs umgewandelt werden. Zusätzlich bietet TDI eine Methode, mit der TDI Clients einen callback (d.h. Funktionen, die direkt aufgerufen werden) am TDI-Server registrieren können. Wenn z.B. ein TDI-Server Daten über das Netzwerk erhält, kann er einen "registered-client-recieve callback" aufrufen. Diese ereignisbasierte Callback-Fähigkeit eliminiert einigen Overhead des Belegen und Verteilen von IRPs, und so können Clients diese Fähigkeit nutzen, um höhere Performance zu erreichen.
Wie bereits erwähnt, kann eine Netzwerk-API möglicherweise nur bestimmte Protokolle nutzen. So wissen z.B. der Arbeitsstations- und der Server-Dienst nicht, wie sie das TCP/IP-Protokoll verwenden sollen. Aber sie versehen die NetBIOS-Schnittstelle und NT bietet einen Treiber (netbt.sys) der eine TDI-kompatible API zur NetBIOS-Programmierung implementiert, der wiederum auf TCP/IP aufsetzt. So können Arbeitsstations- und Serverdienst NetBIOS over TCP/IP nutzen.
Body
unregistriert
Zitat
BugCheck 100000D1, {0, 2, 0, f7880f4a}
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
Unable to load image SYMTDI.SYS, Win32 error 2
*** WARNING: Unable to verify timestamp for SYMTDI.SYS
*** ERROR: Module load completed but symbols could not be loaded for SYMTDI.SYS
Unable to load image afd.sys, Win32 error 2
*** WARNING: Unable to verify timestamp for afd.sys
*** ERROR: Module load completed but symbols could not be loaded for afd.sys
Probably caused by : TDI.SYS ( TDI+f4a )
Body
unregistriert
Zitat
Oirginally posted by Y0gi
sooooooooooooooo'n alarm
-